Einleitung
Attacks Targeting Application Logic
Attacks Targeting the Application Logic
Reducing the Attack Surface #1: Encrypting URL Data
Reducing the Attack Surface #2: TamperProofing Hidden Parameters
Reducing the Attack Surface #3: Protecting Session Tokens in HTTP Cookies
Reducing the Attack Surface #4: Protecting Session Tokens in URLs
Reducing the Attack Surface #5: Foolproof Referrer Enforcement
Fazit
Einleitung
Attacks Targeting Application Logic
While such automated learning and anomaly detection mechanisms are a great step forward, especially for securing against SQL and XSS injections, they can still be blind to application logic attacks. Simply stated, it is just not possible to have blocklists or whitelists to protect against attacks in the application’s logic itself.
Application logic attacks attempt to manipulate application inputs in order to directly target the application logic, rather than the peripheral environment – databases, operating systems, and development frameworks on the server side, and JavaScript Interpreters on the client side. The typical surface of such attacks is the integrity and the logic validation mechanism of the application itself, e.g. business logic, workflow, account creation, authorizations, logins, account modifications, shopping carts, session management, gift card or promotional code usage, fund transfers, etc.
Such an attack surface is exposed through URL paths, parameters, hidden parameters, session IDs, cookies, and headers. Attack input blends into the normal usage patterns and does not trigger negative or positive security policies. Besides, application-scanning technologies like code scanning (SAST) or vulnerability scanning (DAST) fail to detect them. More alarmingly, audit tools and procedures can be completely blindsided too.
Attacks Targeting the Application Logic
Example 1
A medical record on a system one might have a URL such as:http://example.com/RecordView?id=12345
If the application does not check that the authenticated user ID has read rights, then it could display data to the user that the user should not see.
Example 2
When a web application uses hidden fields to store status information, a malicious user can tamper with the values stored on his browser and change the referred information. For example, an e-commerce shopping site uses hidden fields to refer to its items, as follows:<input type="hidden" id="1008" name="cost" value="70.00">
In this example, an attacker can modify the “value” information of a specific item, thus lowering its cost.
Example 3
An attacker can tamper with URL parameters directly. For example, consider a web application that permits a user to select his profile from a combo box and debit the account:http://www.attackbank.com/default.asp?profile=741&debit=1000
In this case, an attacker could tamper with the URL, using other values for profile and debit.
Other parameters can be changed including attribute parameters. In the following example, it’s possible to tamper with the status variable and delete a page from the server:
http://www.attackbank.com/savepage.asp?nr=147&status=read
Modifying the status variable from “read” to “del” could delete the page.
Below, we present some key techniques used by the Barracuda Web Application Firewall to provide protection from such attacks.
Reducing the Attack Surface #1: Encrypting URL Data
The fact that these parameters which are plugged into the application logic are directly exposed in the URL is what makes these attacks possible. Encrypting and tamper-proofing them would completely deny these attacks. The Barracuda Web Application Firewall achieves exactly this by using URL Encryption.
When using URL Encryption, the Barracuda Web Application Firewall encrypts all the URLs that are visible to users. It ensures that URLs are encrypted on the way out and decrypted on the way back in. Users never get to see the actual parameters or paths of the URL.
The nature of the encryption/decryption process ensures that decryption will fail even if a single character is tampered with. Since this process is completely transparent to the protected applications, no change is required on them.
On encryption, the URL that is sent out to the users resembles the following:
http://example.com/9gh7filg6320ixtqa2bc0r
Notice that all the vulnerable parameters above are unavailable to attackers. In addition to logic attacks prevention, this also guarantees foolproof protection against zero-day attacks. The following is a screenshot that shows URL Encryption in action, notice the mouseover “Learn More” shows a completely encrypted URL:
Reducing the Attack Surface #2: TamperProofing Hidden Parameters
Hidden parameters are fields used by developers to embed state information within forms. Browsers do not display them and the assumption is that this information will remain unchanged when the client browser submits the form. However, attackers can easily view and manipulate them through commonly available tools such as Paros and Webscarab proxy.
Example #2 above is an example of such an attack.
The Barracuda Web Application Firewall prevents hidden parameter tampering by embedding encrypted hashes of the hidden parameters and comparing them with recomputed hashes when the form is submitted. This ensures that the data is not tampered with either on the client end or in transit.
Reducing the Attack Surface #3: Protecting Session Tokens in HTTP Cookies
As an example, in 2013, a security researcher exposed how he hacked Facebook Employees Secure Files Transfer service (http://files.fb.com). The crux of the attack was a parameter called “referer” in the cookie, which is base 64 encoded. It actually contains the email address of the user. Changing the email to that of another user and re-encoding it in base 64 allows you to change the victim’s password. A very old and simple trick from the hacking handbook, affecting one of the largest and most modern of web sites.
The Barracuda Web Application Firewall provides two strong protection techniques for securing against such attacks. One, it encrypts all cookies which makes them impossible to predict, as well as blocks the request if any tampering is found. Second, it provides cookie replay protection, which associates a cookie with the user’s IP address. If the cookie is seen from a different IP, the request is blocked.
Reducing the Attack Surface #4: Protecting Session Tokens in URLs
http://www.example.com/(S(pyt3py66t21z5v55vlm25t7y))/orderform.aspx
Such SessionID tokens can easily leak when they are stored by servers, proxies, and user agents, and shared by users, e.g., via copy/pasting or screenshots. The referrer header can also leak the sessionID to external web sites.
As described above, the URL Encryption process in the Barracuda Web Application Firewall completely encrypts the URL, hence this attack surface is mitigated.
Reducing the Attack Surface #5: Foolproof Referrer Enforcement
To overcome this, many applications implement referrer enforcement, where a step like step 5 would ensure that the client browser has been referred to it from step 4. However, faking the referrer is a trivial job, so this control can be easily bypassed.
However, if you were to use URL Encryption across the workflow, then this attack vector is nullified, as the attacker has no way of predicting the step 5’s referrer header without going through step 4. The referrer header, in this case, would be the dynamically-generated, encrypted URL for step 4.