Skip to content

XSRFProbe Internals

Infected Drake edited this page Jan 6, 2019 · 20 revisions

Understanding how XSRFProbe Works

XSRFProbe has various checks for detecting whether an endpoint is vulnerable to CSRF attacks.

Types of Checks:

Following are the various checks XSRFProbe executes before declaring any endpoint as vulnerable.

  1. Origin Based Request Validation Check
  2. Referer Based Request Validation Check
  3. Anti-CSRF Token Detection in POST Queries
  4. Anti-CSRF Token Strength Detection
  5. Anti-CSRF Token Randomness Calculation
  6. Anti-CSRF Token Encoding Detection
  7. Session Cookie Persistence Checks
  8. Cross-Site Cookie Validation Checks
  9. POST-Based Request Forgery Detection on Forms
  10. Tampering Requests for Detection Back-End Validation
  11. CSRF Proof of Concept Generation and Testing
  12. POST-Scan Token Analysis of all Anti-CSRF Tokens Gathered

Origin Based Forgery Checks

Module: Origin.py

Checks on whether the site validates Cross-Origin requests. It has got 2 checks:

  • First, it sets the Origin header similar to the same host netloc and makes the request.
  • Second, it sets the Origin to a fake website pretending to be making a cross-origin request.

Referer Based Forgery Checks

Module: Referer.py

Checks on whether the site validates Cross-Origin Referer Header-based requests. Similarly, this too It has got 2 checks:

  • First, it sets the Referer header similar to the same host netloc and makes the request.
  • Second, it sets the Referer to a fake website pretending to be making a cross-origin request.

Anti-CSRF Token Detection

Module: Token.py

Checks on whether the site validates POST requests with Anti-CSRF tokens. There are two checks for this.

When after these two checks, it finds a token, it starts the next subsequent check.

Token Strength Calculation

Module: Entropy.py

With the token in hand, XSRFProbe goes for a basic strength check for the Anti-CSRF token. As a standard it is by default set to 5 bytes as minimum and 256 bytes as maximum token length. It compares the strength of the Token and then logs out relevant information.

Token Randomness Calculation

Module: Entropy.py

Next, XSRFProbe goes for a token randomness check by calculating Entropy of the Anti-CSRF token.

For a particular web application to be attack proof, all Anti-CSRF tokens must be of high Entropy (highly random), so that specific pattern of token generation isn't detected.

For this purpose Shannon Entropy is used. As a base standard, a token with entropy above 2.4 is considered strong and un-forgable. An entropy lower than that of 2.4, isn't considered random enough and can be easily forged via guessing/bruteforcing.

Token Encoding Detection

Module: Encoding.py

Now that we have the token, its time XSRFProbe goes for checking whether or not the token is string encoded. XSRFProbe has a very efficient module which uses regular expressions and it can easily detect almost every string encoding type easily. If XSRFProbe finds a particular token string encoded, it flags the endpoint as vulnerable.

If the token is some sort of encoded string hash, and not some randomly generated token, the application is most probably vulnerable in-spite of presence of CSRF tokens, since many tokens can probably be decrypted and a specific sequence of token generation can be predicted.

Cookie Persistence

Module: Persistence.py

XSRFProbe has also got significant checks for testing cookie validation and relative persistence. This is a crucial step and XSRFProbe has got two different checks which can detect a persistent cookie by:

  • Parsing the cookies for the expires flag. Once the flag is found, XSRFProbe now extracts the timestamp value from the cookie and determines how long the cookie is persistent.
  • The second check implemented is by observing the variation of the Set-Cookie header under different user-agents.

The module works most efficiently when you supply a cookie with the -c/--cookie argument.

Cross Site Cookie Validation

Module: Cookie.py

Next, XSRFProbe goes about parsing the cookies found for SameSite Flags. If a Cross-Origin session cookie is found without a SameSite Flag Attribute, XSRFProbe declares the endpoint as vulnerable. This is yet another highly crucial step in detecting possible cross site request forgeries and XSRFProbe make three consecutive requests to confirm this vulnerability.

  • First, it sets the Referer header similar to the same host netloc, sets the cookie and makes the GET/POST request.
  • Second, it sets the Referer header to a fake website so as to pretend making a cross-origin request, this time without the cookie.
  • And finally, comes the highly crucial check, it sets the Referer header to a fake website, pretending to be a Cross-Origin request, but this time with the cookie value supplied. 🙃

And finally by context analysis of all three request responses, XSRFProbe determines whether an endpoint is vulnerable to CSRF attacks.

POST-Based Forgery Checks

Module: CheckPOST.py

XSRFProbe gathers all forms it finds in every pages it crawls and stores them. Now, it makes requests pretending to be 3 different users submitting the same form, for determining an end-point as vulnerable.

  • First, it makes a normal request and submits the form as User 1, check if a Anti-CSRF token is present in the request, and takes note of the response content.
  • Second, it makes another request and submits the same form as User 2, checking for any Anti-CSRF Token presence in request, and takes note of response content. Similarly it makes a third request.

Next it compares the response content via Ratcliff-Obershelp Algorithm and determines the number of differences between response lengths.

If XSRFProbe notices considerable response differences via the algorithm, it flags the endpoint as vulnerable to POST-Based Request Forgery attack.

Tampering and Forging Requests

Module: Tamper.py

Next, XSRFProbe proceeds for tampering and forging special requests for determining whether there is proper back-end validation. To do so, XSRFProbe has got another of 3 sets of checks for determining vulnerability. Here you go:

  • First, XSRFProbe tampers the token by index removal, meaning, it removes a character from the Anti-CSRF token, and matches the response content with a normal request's response body.
  • Secondly, it goes for tampering the token string by index replacement, which means it replaces a single character from a specific index and replaces it with another character, so as to keep the token length same and makes the request. Again the usual comparison takes place.
  • And finally, XSRFProbe entirely removes the Anti-CSRF token parameter from the POST query and makes the request.

This time too a comparison takes place between all response contents received and XSRFProbe does the relevant flagging if a vulnerable endpoint is noticed.

Generating Proof of Concepts

Module: Generator.py

Now as we have the vulnerability detected, XSRFProbe will now proceed for generating custom PoCs (Proof of Concepts) for the related vulnerability detected. This module has 2 different submodules:

  • Normal PoC Generator: This sub-module generates a PoC form which require user-interaction. This allows you to fill up the form fields by yourself/victim and submit the request manually.
  • Malicious PoC Generator: This sub-module comes into play when you supply the --malicious argument and let's you generate PoC forms (malicious) which can be used in real-world exploitation. This module will prompt you to enter the default values of those form fields required and generates auto-submit forms which does not require any user interaction (as soon as you open the form, it will be automatically submitted).

Post-Scan Token Analysis

Module: Analysis.py

And here comes the bonus part, the post-scan token analysis. After all the scanning and detection phases are complete, XSRFProbe now analyses the Anti-CSRF tokens gathered during all requests. This module has 2 functions:

  • Computing the Edit Distance of tokens via the Optimal Alignment Distance Algorithm or the Damerau-Levenshtein Algorithm. If the edit distance ratio calculated is less than half than half the length of the Anti-CSRF token, this means the Anti-CSRF token isn't quite strong, since only half of the Anti-CSRF token is generated (dynamic) and other half is known (static).
  • Detecting the pattern of Anti-CSRF Token generation as well as the static part and dynamic part (if any) of the Anti-CSRF tokens.

So this was all about how XSRFProbe works under the hood. The source is highly documented and if you like you can go through the source code to understand some relevant points how this tool works.

XSRFProbe Wiki Index

Clone this wiki locally