Skip to main content

Exploiting Manual Web Application Findings

  • Overview
  • SQLi: SQL Injection
  • XSS: Cross-site scripting
  • CSRF: Cross-site request forgery
  • Session Token Entropy
  • Fuzzing/Input validation
  • Functional/Business logic testing

Overview​

Although these aren't all of the different types of tests to validate, these generally provide the major findings and give you a good baseline for learning other types of web-based attacks.

In a network level penetration test, time is of the essence. You need to have a solid understanding of the underlying infrastructure, application, and possible vulnerabilities. You should understand how to identify those vulnerabilities, and what type of impact they might have if not resolved.

SQLi​

SQLi vulnerabilities can lead to a full compromise of the database or of the system itself. Two open source tools commonly used are SQLMap and Sqlninja.

XSS​

This is probably one of the most common vulnerabilities to identify. XSS is a user attack that is caused by the lack of input validation of the application. XSS attacks can be reflective and stored, which allow an attacker to write script code into a user's browser. With reflective XSS we need to use social engineering to trick the victim into going to the link that will trigger the XSS. If it were stored XSS, we most likely only need to wait until our code was executed.

If you find an XSS, you can not only cause a victim to become part of your pseudo-botnet, you can also steal the contents of the copy memory, redirect them to links, turn on their camera, and so much more.

See BeEF: Browser exploitation framework.

XSS Obfuscation​

it is really common to find that the application provides some sort of input validation for these vulnerable XSS-fields. This means the XSS is still valid, but you don't have all the normal characters you need to successfully take advantage of this vulnerability. Nevertheless, these filters usually are improperly configured. Because there are so many different types of ways to encode your XSS attacks, the filters usually fail.

Here are a quick and dirty tricks to get a working list of encoders:

CSRF​

CSRF happens when you can force an action to happen to a victim that is uwnanted. In a correct process, there would be a CSRF token generated on every page and whenever you progressed through the application, it would verify the previous token. You can think of this as tracking the current session/process and if any of those tokens are empty or wrong, do not process a transaction.

A typical example is that you send someone a link who is currently logged into their bank account. When they access the link you sent them, it automatically transfers money out of their account into your account. This happens because there is no verification that the user wen through the correct process to transfer money.

There are many complex ways to test this, but the one of the easiest is to manually run these tests is through proxying traffic. You'd go through the procfess of making a transaction and seeing if you can replay it without having to perform any additional actions.

For more information on CSRF check OWASP CSRF Cheat Sheet.

Session Tokens​

What you want to look for in a session token are:

  1. The fact that they can't be guessed (properly randomizeed).
  2. They properly track a user.
  3. When they expire.
  4. If they are secure, that they input, and that they are properly utilized.

We can use Burp to capture an authentication process, and see in the response that there is a set-cookie value for the session tokens. Right click within the raw response section and send this request to the Sequencer feature. From there you can identify which session tokens are important to you and then Start live capture to start generating session tokens. After so many tokens, it will give you summaries of entropy (randomness), character-level analysis, and bit-level analysis.

It takes a lot of your own judgment and experience to uunderstand when session cookies are or aren't secure. Every major web application uses different types of implementations and algorithms to generate sessino tokens, so running manual tests and reviewing source code maybe required.

Fuzzing/Input Validation​

One quick feature of Burp Suite during manual testing is the Intruder function, in which you have the ability to tamper with any part of the request and provide your own data.

Intruder is very useful if you want to supply your own fuzzer input to test a variable.

Since we already have our traffic flowing through Burp, we can go to the Proxy tab and to your History tab. Right click on any request of your interest and then click Send to Intruder. From here you can configure which parameters to test and which attack type to use (e.g., Sniper). From the Payloads ta you can load a list of anything based on what I am interacting with (e.g., database, LPAD queries, number IDs).

For more information, review different types of attacks on Burp Suite.

After you start the attack, as the requests start populating, you can tell if a site is different based on parameter injection in different ways. One way to tell is by the length of the source code on that page when that string is injected.

Functional/Business logic testing​

Functional testing (i.e., horizontal/vertical user rights testing, application flow testing) is really where you make your money. This is where successful testers spend a majority of their time. Anyone can run scans, but if you are an effective and efficient manual tester, you are leagues above the norm.

  • Testing that users aren't able to see other user's sensitive data.
  • Regular users can't access administrative pages.
  • Users can't change data values of other users.
  • Workflows cannot be modified outside their intended flow.

If you are interested in learning more, you can check OWASP Web Application Penetration Testing Guide.