Common Vulnerabilities and Recommendations Part-4

Improper Restriction of XXE Ref:

Improper Restriction of XXE Ref vulnerability occurs by an error during parsing an XML file that holds XML entities with URLs that can fix to XML documents outside the deliberated location. This will affect the product to embed incorrect XML documents into its output.

If the application fails to check the path to the documents prior to including them, the attacker crafts an XML document and is able to include arbitrary files from local or remote systems and set off the application to display it.

An attacker exploits this vulnerability by uploading an XML document that contains a DTD declaration, in particular an entity definition that refers to a local file on the server’s disk. For example, <!ENTITY xxe SYSTEM “file:///c:/boot.ini”>. The attacker would then include an XML entity reference that refers back to that entity definition, for example <div>&xxe;</div> . If the parsed XML document is then returned back to the user, the result will include the contents of the sensitive system file. 

This is caused by the XML parser, which is configured to automatically parse DTD declarations and resolve entity references, instead of disabling both DTD and external references altogether. 

The risk consequences for this vulnerability varies based on application implementation and environment and the attacker can perform local/remote file inclusion to remote code execution, external entity expansion attack, server side request forgery (SSRF), denial of service, and also full system compromise. This attack can also be used to execute port scans of the vulnerable system or servers located in the internal network.

Recommendations:

• Disable the ability to load entities from external sources.
• Use of complex data formats, such as JSON should be limited, and avoid serialization of sensitive data.
• XML or XSL file upload functionality should validate incoming XML using XSD validation or similar.
• Restricts processing user input directly, where possible. 
• Patch or upgrade all XML processors and libraries in use by the application.
• Disable DTD parsing and resolving of entities. Apply a strict XML schema on the server, and validate the input XML accordingly. 

Path Traversal:

A Path Traversal or Directory Traversal vulnerability permits the attacker to access files and directories that exist outside of the webroot folder. The attacker targets by manipulating variables that reference files with “dot-dot-slash (../)” sequences, or using absolute file paths or similar variations (such as ..\ in Microsoft Windows), and potentially able to access arbitrary files and directories on the server that is running in an application.

The application uses user input within the file path for accessing files on the application server’s local disk. This allows an attacker to arbitrarily determine the file path.

The risk on the application with this vulnerability is potentially leading to stealing sensitive information, denial of service, access tokens or backups, or even attackers can overwrite arbitrary files on the server, permitting them to alter the application data or behavior, hence the chance of taking full control of the server.

Recommendations:

• Disallowed passing user-supplied input to filesystem APIs altogether and employing strong input validation by maintaining a whitelist of files.
• Run a web server from a different disk instead of a system disk that contains critical operating system files and also restricts storing sensitive files in the server.
• Allow user input only for the filename, not for the path and folders.
• Restrict the privileges of the application’s operating system users to necessary files and folders.
• Explicitly limit the application to using a designated folder that is separate from the applications binary folder.

Cookie Injection: 

A Cookie Injection attack occurs when an attacker manipulates or modifies the contents of a cookie session in order to gain unauthorized access to the application by bypassing security measures. By using this vulnerability, attackers pose as a valid user, access sensitive information and perform actions on behalf of the victim, thus breaching privacy.

The attacker can exploit in other ways by using manipulated cookies to trick a server into obtaining a new version of the original intercepted cookies with modified values.

The security risk of this vulnerability leads to session hijacking, man-in-the-middle attack, sensitive information disclosure, directory traversal, cookie poisoning, SQL injection, access to admin accounts, taking over complete commands on the system.

Recommendations:

• Cookie variables need to be validated before being used.
• Ensure to set the HttpOnly flag for any sensitive server-side cookie.
• Session cookies should be unique and secure, randomly generated and inaccessible to attackers, so that they are impossible to guess or brute force.
• Utilize proper built-in session management features from a trusted and mature framework.
• If the application explicitly handles cookies directly in application code, explicitly set the “httpOnly” flag for each cookie set by the application. 
• Configure the application to always use “httpOnly” cookies, in the site-wide configuration file. 

Improper Encoding of Output: 

Improper Encoding or Escaping of Output vulnerability can permit attackers to replace the commands that are direct to another component by injecting malicious commands instead.

This vulnerability can affect the downstream component to use a decoding method that generates different data instead of software intended to send.

If an application processed crafted malicious input injected by the attacker, the received output could introduce special characters or special elements that will cause the data to be interpreted. Thus, the output data will produce the wrong operations, and be used to bypass protection mechanisms.

Many exploitations can be performed by the attacker by using this vulnerability such as injection attack, XSS attack, bypass authentication, etc.

Recommendations:

• Proper input sanitization, regardless of source and input should be based on a whitelist list.
• Encode all dynamic data prior to embedding it in output and encoding should be case-sensitive.
• In the Content-Type HTTP response header, explicitly define character encoding (charset) for the entire page.
• Implement either ESAPI encoding library or built-in platform functions and utilize AntiXSS library for previous versions of ASP.NET.

HTTP Response Splitting:

HTTP Response Splitting vulnerability occurs when an attacker exploits the response headers by injecting the malicious data characters without being validated by the application through an untrusted source. 

The successful exploit is carried out when an application permits input that includes carriage return (CR, ASCII 0x0D) and Line Feed (LR, ASCII 0x0A) characters supplied into the header. With these characters, attackers not only control the remaining headers and body response of the application but also permits them to generate additional responses completely under their control, set arbitrary headers, split responses into two or more, etc. 

This vulnerability is utilized to perform various attacks such as web cache poisoning, cross-site scripting (XSS), cross-user defacement, page hijacking, etc.

Recommendations:

• Sanitize and validate all inputs properly, including cookies and should be based on a whitelist.
• Implement URL-encode strings in all user inputs before including them into HTTP response headers such as Location or Set-cookie.
• Content-Secure Policy should be defined in the HTML when it is used.
• Use dynamic analyzers to validate the application while in the testing phase.
• Limit the control to the user over the value in the `Location` header.