#XML External Entities Injection | Explore Tumblr posts and blogs

idiosys1 · 1 year ago

Text

10 security tips for MVC applications in 2023

Model-view-controller or MVC is an architecture for web app development. As one of the most popular architectures of app development frameworks, it ensures multiple advantages to the developers. If you are planning to create an MVC-based web app solution for your business, you must have known about the security features of this architecture from your web development agency. Yes, MVC architecture not only ensures the scalability of applications but also a high level of security. And that’s the reason so many web apps are being developed with this architecture. But, if you are looking for ways to strengthen the security features of your MVC app further, you need to know some useful tips.

To help you in this task, we are sharing our 10 security tips for MVC applications in 2023! Read on till the end and apply these tips easily to ensure high-security measures in your app.

1. SQL Injection: Every business has some confidential data in their app, which needs optimum security measures. SQL Injection is a great threat to security measures as it can steal confidential data through SQL codes. You need to focus on the prevention of SQL injection with parameterized queries, storing encrypted data, inputs validation etc.

2. Version Discloser: Version information can also be dangerous for your business data as it provides hackers with your specific version information. Accordingly, they can attempt to attack your app development version and become successful. Hence, you need to hide the information such as the server, x-powered-by, x-sourcefiles and others.

3. Updated Software: Old, un-updated software can be the reason for a cyber attack. The MVC platforms out there comprise security features that keep on updating. If you also update your MVC platform from time to time, the chances of a cyber attack will be minimized. You can search for the latest security updates at the official sites.

4. Cross-Site Scripting: The authentication information and login credentials of applications are always vulnerable elements that should be protected. Cross-Site Scripting is one of the most dangerous attempts to steal this information. Hence, you need to focus on Cross-Site Scripting prevention through URL encoding, HTML encoding, etc.

5. Strong Authentication: Besides protecting your authentication information, it’s also crucial to ensure a very strong authentication that’s difficult to hack. You need to have a strong password and multi-factor authentication to prevent unauthorized access to your app. You can also plan to hire security expert to ensure strong authentication of your app.

6. Session Management: Another vital security tip for MVA applications is session management. That’s because session-related vulnerabilities are also quite challenging. There are many session management strategies and techniques that you can consider such as secure cookie flags, session expiration, session regeneration etc. to protect access.

7. Cross-Site Request Forgery: It is one of the most common cyber attacks MVC apps are facing these days. When stires process forged data from an untrusted source, it’s known as Cross-Site Request Forgery. Anti-forgery tokens can be really helpful in protecting CSRP and saving your site from the potential danger of data leakage and forgery.

8. XXE (XML External Entity) Attack: XXE attacks are done through malicious XML codes, which can be prevented with the help of DtdProcessing. All you need to do is enable Ignore and Prohibit options in the DtdProcessing property. You can take the help of your web development company to accomplish these tasks as they are the best at it.

9. Role-Based Access Control: Every business has certain roles performed by different professionals, be it in any industry. So, when it comes to giving access to your MVC application, you can provide role-based access. This way, professionals will get relevant information only and all the confidential information will be protected from unauthorized access.

10. Security Testing: Finally, it’s really important to conduct security testing on a regular basis to protect business data on the app from vulnerability. Some techniques like vulnerability scanning and penetration testing can be implied to ensure regular security assessments. It’s crucial to take prompt actions to prevent data leakage and forgery as well.

Since maintaining security should be an ongoing process rather than a one-time action, you need to be really proactive with the above 10 tips. Also, choose a reliable web development consulting agency for a security check of your website or web application. A security expert can implement the best tech stack for better security and high performance on any website or application.

#web development agency #web development consulting #hire security expert #hire web developer #hire web designer #website design company #website development company in usa

2 notes · View notes

pentesttestingcorp · 2 months ago

Text

XML Injection in Laravel: Prevention & Secure Coding 🚀

Introduction

XML Injection in Laravel is a critical web security flaw that occurs when attackers manipulate XML input to exploit applications. This vulnerability can lead to data exposure, denial-of-service (DoS) attacks, and even remote code execution in severe cases.

In this post, we will explore what XML Injection is, how it affects Laravel applications, and most importantly, how to prevent it using secure coding practices. We will also show how our Website Vulnerability Scanner can detect vulnerabilities like XML Injection.

What is XML Injection?

XML Injection happens when an application improperly processes XML input, allowing attackers to inject malicious XML data. This can lead to:

Data theft – Attackers can access unauthorized data.

DoS attacks – Malicious XML can crash the application.

Code execution – If poorly configured, it can lead to executing arbitrary commands.

🔍 Example of an XML Injection Attack

Let's consider a Laravel-based ERP system that takes XML input from users:

<?xml version="1.0" encoding="UTF-8"?> <user> <name>John</name> <password>12345</password> </user>

An attacker can inject malicious data to extract sensitive information:

<?xml version="1.0" encoding="UTF-8"?> <user> <name>John</name> <password>12345</password> <role>&exfiltrate;</role> </user>

If the application does not sanitize the input, it may process this malicious XML and expose sensitive data.

How XML Injection Works in Laravel

Laravel applications often use XML parsing functions, and if improperly configured, they may be susceptible to XML Injection.

Consider the following Laravel controller that parses XML input:

use Illuminate\Http\Request; use SimpleXMLElement; class UserController extends Controller { public function store(Request $request) { $xmlData = $request->getContent(); $xml = new SimpleXMLElement($xmlData); $name = $xml->name; $password = $xml->password; return response()->json(['message' => "User $name created"]); } }

🚨 The Problem

The SimpleXMLElement class does not prevent external entity attacks (XXE).

Malicious users can inject XML entities to read sensitive files like /etc/passwd.

How to Prevent XML Injection in Laravel

✅ 1. Disable External Entity Processing (XXE)

Modify XML parsing with libxml_disable_entity_loader() to prevent external entity attacks:

use Illuminate\Http\Request; use SimpleXMLElement; class SecureUserController extends Controller { public function store(Request $request) { $xmlData = $request->getContent(); // Secure XML parsing $xml = new SimpleXMLElement($xmlData, LIBXML_NOENT | LIBXML_DTDLOAD); $name = $xml->name; $password = $xml->password; return response()->json(['message' => "User $name created securely"]); } }

✅ 2. Use JSON Instead of XML

If possible, avoid XML altogether and use JSON, which is less prone to injection attacks:

use Illuminate\Http\Request; class SecureUserController extends Controller { public function store(Request $request) { $validatedData = $request->validate([ 'name' => 'required|string', 'password' => 'required|string|min:6' ]); return response()->json(['message' => "User {$validatedData['name']} created securely"]); } }

✅ 3. Implement Laravel’s Built-in Validation

Always validate and sanitize user inputs using Laravel's built-in validation methods:

$request->validate([ 'xmlData' => 'required|string|max:5000' ]);

Check Your Laravel Website for XML Injection

🚀 You can test your Laravel application for vulnerabilities like XML Injection using our Free Website Security Scanner.

📸 Screenshot of Free Tool Webpage

Screenshot of the free tools webpage where you can access security assessment tools.

How It Works: 1️⃣ Enter your website URL. 2️⃣ Click "Start Test". 3️⃣ Get a full vulnerability report in seconds!

📸 Example of a Security Report to check Website Vulnerability

An Example of a vulnerability assessment report generated with our free tool, providing insights into possible vulnerabilities.

Final Thoughts

XML Injection in Laravel can lead to data breaches and security exploits if not handled properly. Following secure coding practices such as disabling external entities, using JSON, and validating input data can effectively prevent XML Injection attacks.

🔗 Check out more security-related articles on our blog: Pentest Testing Blog

💡 Have you checked your website for vulnerabilities? Run a free security scan now at Website Security Checker.

🔥 Stay secure, keep coding safe! 🔥

#cyber security #cybersecurity #data security #pentesting #security #laravel #php #xml

1 note · View note

projectcubicle1 · 1 year ago

Text

Web App Security: A Crucial Component in Your Business Strategy

The stark reality facing organizations today is that security threats are ever-increasing, and expanding in complexity faster than ever before. From small-scale businesses to multinational firms, no entity is immune from potential cyber attacks. This crucial aspect can impact not only your business operations but also its reputation and customer trust. Web apps are especially exposed to third party manipulation, as they serve as an important tool for internal users and customers alike. So to highlight the relevance of making them as secure as possible, here’s an overview of why web app security should be high on your list of considerations when devising an optimized business strategy.

Why Web App Security is Essential

The necessity of web app security for your business cannot be stressed enough. It goes beyond protecting data — it’s about safeguarding the trust and confidence of your users. Here are just a few reasons why it's essential: Guard Your Reputation: A compromised system can result in leaked user data leading to grave loss of faith amongst clients or customers, so it should be part of your broader risk management strategy. Comply With Legal Requirements: Specific industries have strict regulations for data security. Ignoring these can lead to hefty fines or legal consequences. Defend Company Assets: Protect proprietary data, such as source code files from theft by competitor firms which enhances competition effectively. An ounce of prevention is worth a pound of cure. Taking proactive steps like staying updated on the latest cybersecurity threats, implementing robust protection measures, and educating your staff about best practices will go a long way towards improving your overall app security.

Identifying Potential Threats to Your App

In web app security, the first line of defense is accurate identification. You need to recognize what threats could compromise your app's safety. Here are a few examples: SQL Injection Attacks: These happen when an intruder manipulates your SQL query through insecure user input fields, accessing or manipulating sensitive data in the process. Cross-Site Scripting (XSS): This occurs when attackers inject malicious scripts into websites viewed by other users. Cross-Site Request Forgery (CSRF): In CSRF attacks, unsuspecting users get tricked into executing unauthorized commands intended for higher privileged accounts. Then there are more sophisticated methods such as Server Side Request Forgery and XML external entity injection among many others which you should also watch out for. The good news is that using an online PHP vulnerability scanner helps identify weaknesses that can serve as entry points for these cyber attackers. Such tools continually monitor your site, exposing any flagged vulnerabilities so they can be fixed proactively.

Effective Strategies for Enhancing App Safety

Protection is vital when it comes to handling threats. Here are some strategies that can significantly enhance your web app's safety: Regularly Updating Your Software: Routinely updates, including server operating system and any other software you utilize on your website, provide necessary patches that address known vulnerabilities. Using the HTTPS Protocol: Transferring data via HTTP renders the sensitive user information vulnerable during transit. HTTPS implementations add a layer of security by encrypting this data during transportation. Implementing Strong Password Policies: Encourage users to use complex passwords and change them regularly. This creates an extra level of protection against brute force attacks. Incorporating Firewalls: Web Application Firewalls (WAFs) work as filters or monitors which help defend against exploitations like SQL injection attacks or cross-site scripting. Differing levels of protective actions can be combined into several layers - analogous to a multi-tiered security net around your online business assets. Hence, utilizing an amalgamation of these measures offers greater assurance in defending against potential cyberattacks.

Dealing with Cyber Attacks in Business

Cyber attacks are an unfortunate reality for businesses, and can impact web apps as well as other digital assets, as discussed. But knowing how to respond effectively can minimize damage and speed recovery. Consider the following guidelines: Prompt Incident Reaction: Once an attack occurs, quickly identify what has been impacted. Accelerated responses can help you close loopholes. Data Preservation: Keep a backup of your data on a reputable cloud storage service, as it will support quick revivals after cyberattacks without significant losses. Communication Strategy: Inform impacted users honestly and promptly about any breaches. Transparency helps repair trust. Dealing with a breach involves more than mere technicalities; part of it is managing public relations too. By ensuring transparent engagement with all stakeholders during such crises, you’ll be able to regain trust, rather than watching it all drain away.

Wrapping Up

The short and sweet version of all this is that web app security remains a flagship consideration for companies across the world. Getting to grips with the potential threats, equipping your systems to defend against them and formulating a comprehensive crisis management strategy are all part of smarter business planning. As technology continues to evolve, always stay up-to-date with the latest security measures for protecting your online assets, as failure to do so could result in potentially catastrophic losses both financially and reputation-wise. And since malicious third parties are doing the same, you can’t be caught sleeping on this strategic issue. Read the full article

0 notes

idiosys-tech · 2 years ago

Text

10 security tips for MVC applications in 2023

Model-view-controller or MVC is an architecture for web app development. As one of the most popular architectures of app development frameworks, it ensures multiple advantages to the developers. If you are planning to create an MVC-based web app solution for your business, you must have known about the security features of this architecture from your web development company. Yes, MVC architecture not only ensures the scalability of applications but also a high level of security. And that’s the reason so many web apps are being developed with this architecture. But, if you are looking for ways to strengthen the security features of your MVC app further, you need to know some useful tips.

To help you in this task, we are sharing our 10 security tips for MVC applications in 2023! Read on till the end and apply these tips easily to ensure high-security measures in your app.

Since maintaining security should be an ongoing process rather than a one-time action, you need to be really proactive with the above 10 tips. Also, choosing a reliable web development company is essential to prevent your MVC app from potential threats. If you are looking for one, you can contact us at Idiosys Technologies. We boast a team of veteran app developers, who can provide you with a strong and secure MVC-based application for your business.

#hiresecurityexpert #webdevelopmentcompany

0 notes

enhanceandgo · 2 years ago

Text

CompTIA CySA+ CS0-003: XML external entity injection attack

XML is used to transport data between client and a server, for example, between a server and a web browser. But the problem arises when they leverage standard library or platform API to process XML data on the server end. XML specification contain lot of features and standard parsers support these features, which can lead to lot of vulnerabilities. XML external entities are entities that are…

View On WordPress

0 notes

network-security-concepts · 4 years ago

Text

XML External Entities Vulnerability

What is XML External Entity Injection? By definition, "external entity" in XML is a synonym for "entity" - a thing created by an author. XML data may be transmitted over the network in a manner analogous to TCP/IP. However, instead of TCP or IP, XML data is sent as a markup language, with its vocabulary and rules.

XML external entity injections (also called XXE) are a web security vulnerability that allows attackers to manipulate an application's processing of XML information. For example, an XXE could allow an authorized user to submit malicious XML data to arbitrary web servers. Or an authorized user could use a special browser command to execute arbitrary code within the application's internals. In some cases, an attacker could also escalate an XXE to compromise the target server or other back-end infrastructure by leveraging the XML mentioned above vulnerability to do server-side script forgery (SSRF).

What are the different ways of exploiting XML External Entities? In general, these vulnerabilities can be controlled through two other methods. The first method is called an "XML External Entity Injection" attack. The attacker uses a program or tool to inject an XHTML entity or other HTML text or data into the target application. The attacker needs to create a form to submit the required entity to exploit this type of vulnerability. After successfully submitting the form, the browser will wait until the required entity is available before finally sending the document to the attacker's destination URL. If you have found websites offering free service or paid service, you can use their "get document element" feature to retrieve an appropriate entity from them.

The second method of XML External Entities exploitation is through "back-end scripting." In this case, the attacker uses a utility or script that runs on the targeted server after the successful submission of the entity. Once the script has been executed, the back-end application will run the same commands that it requests from the server (such as updating a database or generating output text) using the same XHR to communicate with the back-end server.

Now that you are familiar with the essential nature of this kind of vulnerability, you may be wondering how they can be exploited and how to protect yourself against them. To begin with, you can prevent XML External Entities by performing the proper steps in your development process. For example, to fix the "XML External Entities" problem, you can optimize your web servers' security configuration so that cross-site scripting (XSS) attacks are prevented. Another way to prevent XML External Entities is by using the XML Sitemap mechanism. This mechanism enables you to discover any hidden attack surface on your website by monitoring your visitors' links when accessing your site.

XML Sitemap is an essential component of the "XML External Entities" protection. By marking every incoming link as an "XML External Entities" link, you will effectively minimize the risk of XML External Entities. Moreover, you should disable the "XML External Entities" feature on your server-side code. Finally, you should perform regular database maintenance and update your application regularly to prevent blind vulnerabilities. By following these simple steps, you can improve the security of your website.

#XML External Entities Injection

0 notes

peligeyrufus · 5 years ago

Text

DOES HTTPS GUARANTEE A SAFE WEBSITE?

No doubt surfing a secured web application has become a matter of necessity, for individuals, small, medium and large organizations to maintain some acceptable level of perceived risk.

The web application has evolved from being an information repository containing static document(one-way flow of information) to highly functional applications which incorporate the two-way flow of information between the server and browser.

Now, because of this evolvement, several vulnerabilities have originated from intercepting communications on an HTTP (hypertext transfer protocol) web application to attacks that directly target the server or client components of a web application, regardless of whether the application applied HTTP or HTTPS (hypertext transfer protocol secure). yes! you read right “HTTPS”, many people have been lead to believe that accessing an HTTP web application is a guarantee that you’re browsing safe but the truth remains, we’re all exposed to the risks of the internet despite the widespread usage of HTTPS on web applications.

HTTPS, the purpose and why it doesn’t guarantee a safe website

HTTPS stands for hypertext transfer protocol secure and it refers to the process of using Transport Secure Layer(TLS)/Secured Socket Layer(SSL) to encrypt the transfer of information contained in a website. This information may include login credentials, banks and payment details, and personal information.

HTTPS generally prevents man-in-the-middle(MITM) attacks and also a third party from intercepting communications made between the browser and server but do not prevent attacks that directly target the clients and server. According to OWASP (Open Web Application Security Project), the top 10 vulnerabilities in 2020 are

Injection

Broken Authentication

Sensitive Data Exposure

XML External Entities

Broken Access Control

Security misconfigurations

Cross-site scripting (XSS)

Insecure Deserialization

Using components with known vulnerabilities

Insufficient logging and monitoring

Amongst the above-mentioned list of top 10 web vulnerabilities, HTTPS only prevents Sensitive Data Exposure (some other attacks can still render the web application critically exposed to this vulnerabilities e.g SQL injection) by enforcing encryption on communications but can not prevent the other 9 from the list and many other not mentioned here. For this reason, surfing the internet on HTTPS does not guarantee a website is safe and secured.

#web #hack

1 note · View note

comp6841 · 6 years ago

Text

Lectures - Week 5 (Mixed)

Vulnerabilities

One of the most fundamental concepts in security is the idea of a vulnerability - a flaw in the design of a system which can be used to compromise (or cause an unintended usage of) the system. A large majority of bugs in programming are a result of memory corruptions which can be abused to take control - the most ubiquitous example of this is the buffer overflow; the idea that you can overwrite other data alongside a variable which can change both data and control of a program. The common case is when programmers fail to validate the length of the input when reading in a string in C. Another fairly common bug relates to the overflow of unsigned integers; failing to protect against the wraparound can have unintended consequences in control flow.

‘NOP Sled’

Richard also mentioned in the 2016 lectures the idea of a NOP sled which I found quite interesting. The idea is that due to run time differences and randomisation of the stack, the address the program will jump to (from the return address) can sometimes be difficult to predict. So to make it more likely it will jump where the attack wants, he converts a large set of memory to NOP (no operation) instructions which will just skip to the next one; then finally after the “NOP sled” his code will execute.

printf(”%s Printf Vulnerabilities”);

One of the most hilarious programming vulnerabilities related to the usage of the printf function. Basically if you have an input which is accepted from the terminal and you plug this (without parsing) into a printf, an attacker could potentially feed in an input such as “%s”. (i.e. the title) Now since you haven’t specified a 2nd argument, it will just keep reading all the variables in memory until you hit a “\0″. In fact you can abuse this even further to overwrite memory with the “%n” format string - it will overwrite an integer with the number of characters written so far.

Handling Bugs

Many of the bugs we know of today are actually reported in online databases such as the National Vulnerability Database or Common Vulnerability & Exposures (CVE) Databases. There is actually lots of pretty cool examples online in these, however most of these have been actually fixed - we call them zero day vulnerabilities if the vendor hasn’t fixed them (and if they are then abused then zero day exploits).

When working in security, it’s important to understand the potential legal consequences associated with publicly releasing damaging vulnerabilities in software. This is where responsible disclosure comes in - the idea that if you find a bug you disclose it to a software vendor first and then give them a reasonable period of time to fix it first. I think I discussed an example from Google’s Project Zero Team a couple weeks ago - however just from a quick look there was a case in March where their team released the details on a flaw in the macOS’s copy-on-write (CoW) after the 90 day period for patching. (it’s important to note they gave them reasonable time to fix it)

OWASP Top 10

This was a pretty cool website we got referred to mainly regarding the top bugs relating to web security (link); I’ll give a brief overview here:

Injection - sends invalid data to get software to produce an unintended flow of control (i.e. SQL injection)

Broken authentication - logic issues in authentication mechanisms

Sensitive data exposure - leaks in privacy of sensitive customer data

XML External Entities (XXE) - parsing XML input with links to external bodies

Broken action control - improper access checks when accessing data

Security misconfigurations - using default configs, failing to patch flaws, unnecessary services & pages, as well as unprotected files

Cross-Site Scripting (XSS) - client injects Javascript into a website which is displayed to another user

Insecure deserialisation - tampering with serialization of user data

Using components with known vulnerabilities - out of date dependencies

Insufficient logging and monitoring - maintaining tabs on unusual or suspicious activity, as well as accesses to secure data

Some Common Bugs

Just a couple of the bugs that were explored in some of the 2016 lecture videos:

Signed vs unsigned integers casts - without proper checks can lead to unintended control flow

Missing parenthesis after if statement - only executes next line and not all within the indentation

Declaring array sizes wrong - buf[040] will be interpreted as base 8

Wrong comparators - accidentally programming ‘=‘ when you intended ‘==‘

A lot of the more common bugs we used to have are getting a lot easier to detect in the compilation process; GCC has a lot of checks built in. Valgrind is also a really awesome tool to make sure your not making any mistakes with memory.

WEP Vulnerability

I actually discussed this idea already in the week 1 lectures here - just for the sake of revision I will give a basic overview here. The basic idea is that WEP uses a stream cipher RC4 which XORs the message with a key; however the issue is that we know information about the structure of TCP/IP packets. Within a local network the local IPs are usually of the form A.B.C.D (i.e. 192.168.20.4 for a specific computer) where each letter represents a byte in the range 0-255. (0-255 are usually reserved and not used for computers in the network) Due to subnetting (i.e. with a subnet mask 255.255.255.0 on private network) the last byte D is usually the only one that changes - this means we effectively have 254 combinations.

Since we know where the destination address is located within the packet, an attacker can potentially record a packet and modify this last byte - they can send out all 256 possible combinations to the router (remember it’s encrypted so we can’t limit it to 254). The router will then decrypt the message and then encrypt it with the key used for communications with the attacker - and voila the system is compromised.

Hashes

Richard gave a brief overview of the basis of many of our hash functions which is the Merkle-Damgard construction. The basic idea behind it is to break the message into blocks - the size varies on the hash type and if its not a multiple of the required length then we need to apply a MD-compliant padding function. This usually occurs with Merkle-Damgard strengthening which involves encoding the length of the original message into the padding.

To start the process of hashing we utilise an initialisation vector (number specific to the algorithm) and combine it with the first message block using a certain compression function. The output of this is then combined with the 2nd message block and so forth. When we get to the end we apply a finalisation function which typically involves another compression function (sometimes the same) which will reduce the large internal state to the required hash size and provide a better mixing of the bits in the final hash sum.

Length Extension Attacks

I think after looking at the Merkle-Damgard construction it now becomes pretty obvious why using MACs of the form h(key|data) where the length of the data is known are vulnerable to length-extension attacks. All you need to be able to reverse in the above construction is the finalisation function and the extra padding (which is dependent upon the length which we’re assuming we know); then you can keep adding whatever message blocks you want to the end!

Digital Signatures

The whole idea behind these signatures is providing authentication - the simplest method of this is through asymmetric key encryption (i.e. RSA). If your given a document, you can just encrypt it with your private key - to prove to others that you indeed signed it, they can attempt to decrypt it with your public key. There is a problem with this approach however - encryption takes a lot of computation and when the documents become large it gets even worse. The answer to this is to use our newfound knowledge of hashing for data integrity - if we use a hash (’summary of the document’), we can just encrypt this with our private key as a means of signing it!

Verifying Websites

One of the hardest issues we face with the ‘interwebs’ is that it is very difficult to authenticate an entity on the other end. We’ve sort of scrambled together a solution to this for verifying websites - certificate authorities. (I could go on for ages about the problems with these being ‘single points of failure’ but alas I don’t have time)

The idea behind these bodies is that a website will register with the entity with a specific public key. The CA will then link this public key (in a “big ol’ secure database”) with the ‘identity’ of the website. To understand how it works its best to consider the example of when you access any website with HTTPS. (i.e. SSL) When you visit www.example.com, they will then provide their public key and a digital signature of key (signed by the cert authority’s private key) in the form of a X.509 certificate. The user will have access to CA’s public key as part of their browser and will then be able to verify the identity of the website. (the cert is encrypted with the CA’s private key - see above image) An attacker is unable to fake it as they don’t know the certificate authorities’ private key.

Attacking Hashed Passwords

Given there is only a limited number of potential hashes for each algorithm, there is a growing number of websites online which provide databases of plaintext and their computed hashes - these are what we refer to as hash tables. We can check a hash very quickly against all the hashes in this database - if we find a match, we either know the password or have found a collision.

Rainbow tables are a little more complex - in order to make one you need a hashing function (the same as the password) and a reduction function; the latter is used to convert the hash into text (i.e. a base64 encode and truncation). These tables are made of a number of ‘chains’ of a specified length (let’s say we choose 1,000,000) - to create a chain you start with a random seed then apply both the above functions to this seed. You then iteratively do this process another 1,000,000 times (chosen length) and store the final seed and value (only these). In order to try and determine a match to the rainbow table, you apply the same two functions to the password for the required length - however, at each step you compare the hash to the result of each of the chains in the table. If you find a match, you can reproduce the password.

Both of the attacks against password hashes described above rely on an attacker doing a large amount of work in advance, which they will hopefully be able to use in cracking many passwords in the future. (it’s basically a space-time tradeoff) An easy way we can destroy all the work they have done is through a process known as salting. Basically what you do is generate a random string which you concatenate with the password when creating a hash - you need to store this alongside the password in order to check it in future. This means an attacker can’t use pre-computed tables on your hash; they have to do all the work again for your particular salt!

Richard discussed another interesting concept called ‘key stretching’ in the lectures - it’s basically the idea that you can grab a ‘weak password hash’ and continuously hash it with a combination of the (’hash’ + ‘password’ + ‘salt’). This process of recursively hashing makes it insanely difficult for an attacker to bruteforce. This is combined with the effects of a ‘salt’ which (on its own) renders rainbow tables (’pre-computed hashes’) useless.

Signing Problems with Weak Hashes

One of the problems with using a hash which is vulnerable to second-preimage attacks is that it becomes a lot easier to sign a fake document. Consider the example of a PDF document certifying that I give you $100. If you wanted you could modify the $100 to $100,000, however this would change the resultant hash. However since it’s a PDF you could modify empty attribute fields or add whitespace such that you can modify the hash an enormous amount of times (i.e. to bruteforce the combinations). Since the hash is vulnerable to second-preimage this means that given an input x (the original signed document) we are able to find an x’ (the fake signed document) such that h(x) = h(x’).

Dr Lisa Parker (guest speaker)

I wasn’t able to make the morning lecture, although I will try and summarise my understanding of the key points from this talk:

More holistic approaches to systems improvement have better outcomes (’grassroots approach’ is just as important as targeted)

Unconscious bias is present across a wide variety of industries (i.e. judges harsher before lunch, doctors prescribing drugs for free lunch)

Codes of conduct intended to reduce corruption; pharmaceuticals try to dodge with soft bribes, advertising, funding research

Transparent reporting reduces malpractice

Enforcing checklists useful for minimising risk

OPSEC Overview (extended)

We traditionally think of OPSEC has been based in the military, however many of the principles can apply in more everyday scenarios:

Identifying critical information

Analysis of threats

Analysis of vulnerabilities

Assessment of risk

Application of appropriate OPSEC measures

A lot of the ideas behind gathering information (recon) revolve around collecting “random data”, which at first may not appear useful, however after managing to piece them together, they are. One of the quotes from Edward Snowden (I think) I found quite interesting, “In every step, in every action, in every point involved, in every point of decision, you have to stop and reflect and think, “What would be the impact if my adversary were aware of my activities?””. I think it’s quite powerful to think about this - however at the same time we don’t want to live with complete unrealistic paranoia and live as a hermit in the hills.

One of the easiest ways to improve your OPSEC is through limiting what you share online, especially with social media sites. Some of the basic tips were:

Don’t share unless you need to

Ensure it can’t be traced (unless you want people to know)

Avoid bringing attention to yourself

You can try and conceal your identity online through things like VPNs and Tor Browser. It is important that in identities you have online that you don’t provide a means to link them in any way (i.e. a common email) if you don’t want someone to be able to develop a “bigger picture” about you. For most people, I think the best advice with regards to OPSEC, is to “blend in”.

Passwords (extended)

I am really not surprised that the usage of common names, dates and pets is as common as it is with passwords. Most people just like to take the lazy approach; that is, the easiest thing for them to remember that will ‘pass the test’. Linking closely with this is the re-use of passwords for convenience - however for security this is absolutely terrible. If your password is compromised on one website and your a ‘worthy target’, then everything is compromised.

HaveIBeenPwned is actually a pretty cool website to see if you’ve been involved in a breach of security. I entered one of my emails, which is more of a ‘throwaway one’ I use for junk-ish accounts on forums and whatnot - it listed that I had been compromised on 11 different websites. I know for a fact that I didn’t use the same password on any of those; secondly for most of them I didn’t care if they got broken.

I think offline password managers are an ‘alright way’ to ensure you have good unique passwords across all the sites you use. (be cautious as they can be a ‘single point of failure’) However when it comes to a number of my passwords which I think are very important - I’ve found just randomly generating them and memorising them works pretty well. Another way is to form long illogical sentences and then morph them with capitalisation, numbers and symbols. You want to maximise the search space for an attacker - for example if your using all 96 possible characters and you have a 16-character password then a bruteforce approach would require you to check 2^105 different combinations (worst-case).

The way websites store our passwords is also important to the overall security - they definitely shouldn’t be stored in plaintext, should use a ‘secure hash function’ (i.e. not MD5) and salted. I’m pretty sure I ranted about a mobile carrier that I had experiences with earlier in my blog, that didn’t do this. This means if the passwords were ‘inevitably’ all stolen from the server, the attacker just gets the hashes, and they can’t use rainbow tables because you hashed them all. Personally, I really like the usage of multi-factor authentication combined with a good password (provided those services don’t get compromised right?). Although, you want to avoid SMS two-factor as it’s vulnerable to SIM hijacking.

#week5 #lectures #reflection

4 notes · View notes

cyber-sec · 6 years ago

Text

Internet Explorer zero-day lets hackers steal files from Windows PCs

Source: https://www.zdnet.com/article/internet-explorer-zero-day-lets-hackers-steal-files-from-windows-pcs/

More info: http://hyp3rlinx.altervista.org/advisories/MICROSOFT-INTERNET-EXPLORER-v11-XML-EXTERNAL-ENTITY-INJECTION-0DAY.txt

4 notes · View notes

hackgit · 3 years ago

Text

VulnLab A Web Vulnerability Lab Project. Vulnerabilities: 1. SQL Injection 2. Cross Site...

VulnLab A Web Vulnerability Lab Project. Vulnerabilities: 1. SQL Injection 2. Cross Site Scripting (XSS) 3. Command Injection 4. Insecure Direct Object References (IDOR) 5. Cross Site Request Forgery (CSRF) 6. XML External Entity (XXE) Insecure Deserialization 7. File Upload 8. File Inclusion 9. Broken Authentication https://github.com/Yavuzlar/VulnLab

#cybersecurity #infosec #infosecurity #pentesting #bugbounty #hacking #hackers

0 notes

pentesttestingcorp · 5 months ago

Text

Preventing XML External Entity (XXE) Injection in Laravel

As cybersecurity threats evolve, XML External Entity (XXE) injection remains a significant vulnerability affecting applications that parse XML input. If left unchecked, attackers can exploit XXE to access sensitive files, execute remote code, or perform denial-of-service (DoS) attacks. Laravel, a popular PHP framework, can also be vulnerable if not properly secured. This blog explores XXE injection, its risks, and how to protect your Laravel application with a coding example.

What Is XML External Entity (XXE) Injection?

XXE injection occurs when an XML parser processes external entities in XML input. Attackers can manipulate these external entities to gain unauthorized access to files, network resources, or even escalate their privileges.

Real-Life Scenario of XXE in Laravel

Suppose your Laravel application accepts XML files for data import or integration. If your XML parser allows external entities, an attacker could upload malicious XML files to exploit your system.

Example Malicious XML Code:

xml <?xml version="1.0"?> <!DOCTYPE root [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <root> <data>&xxe;</data> </root>

The above code retrieves sensitive system files (/etc/passwd) by exploiting the external entity xxe.

How to Protect Laravel Applications from XXE?

Here’s a step-by-step guide to securing your Laravel application:

1. Disable External Entity Processing

The first defense against XXE is to disable external entity processing in your XML parsers. For PHP’s libxml, you can disable it globally or for specific instances.

Example Code to Disable External Entity Loading:

php // Disable loading external entities libxml_disable_entity_loader(true); // Securely parse XML $xmlContent = file_get_contents('path/to/xml/file.xml'); $dom = new DOMDocument(); $dom->loadXML($xmlContent, LIBXML_NOENT | LIBXML_DTDLOAD);

2. Use Secure Libraries

Instead of using default XML parsers, consider using secure alternatives like SimpleXML with proper configuration or third-party libraries designed for secure XML parsing.

3. Validate User Inputs

Sanitize and validate all user inputs to ensure they meet your application’s requirements. Reject malformed or suspicious XML files.

Leverage Free Website Security Tools

To ensure your Laravel application is free from vulnerabilities like XXE, perform regular security scans. Our Free Website Security Scanner is designed to identify such vulnerabilities and provide actionable insights.

Example Screenshot: Free Tool in Action

After scanning your application, you’ll receive a detailed report highlighting any vulnerabilities.

Example Screenshot: Vulnerability Assessment Report

How Our Tool Helps with XXE Prevention

Our free tool identifies vulnerabilities like XXE in your Laravel application by simulating real-world attacks. It highlights areas needing immediate action and provides recommendations to secure your app.

Conclusion

XML External Entity (XXE) injection is a critical security risk for Laravel applications. By disabling external entity processing, validating inputs, and using secure libraries, you can mitigate these risks. Additionally, tools like our Free Website Security Checker make it easier to detect and resolve vulnerabilities effectively.

Start your journey toward a more secure Laravel application today!

#cyber security #cybersecurity #data security #pentesting #security #the security breach show #laravel #xml

1 note · View note