Skip to content

XSRFProbe Internals

Infected Drake edited this page Dec 19, 2018 · 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. 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-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 requests with Anti-CSRF tokens. XSRFProbe has a list of tokens with which it compares every parameter of all requests (both GET and POST, POST has higher precedence over GET type requests).

Token Strength Calculation

Module: Entropy.py

Next XSRFProbe now goes for a basic strength check for the Anti-CSRF token (if discovered). As a standard it is by default set 5 bytes as minimum and 256 bytes as maximum token length.

Token Randomness Calculation

Module: Entropy.py

Now, XSRFProbe goes for a token randomness strength check by calculating Entropy of the Anti-CSRF token. 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, means the token isn't random enough and can be easily forged via guessing/bruteforcing.

Token Encoding Detection

Module: Encoding.py

Now that we have the token, its time that we go for checking the token encoding detection. 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 since, 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 some checks which can detect a persistent cookie 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, 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 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 supplied. 🙃

And finally by context analysis of all three requests, 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 then 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 and similarly 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, it goes for total removal of the Anti-CSRF token parameter from the POST request and makes the request. This time a comparison takes place between all response contents received and XSRFProbe does the relevant flagging if a vulnerable endpoint is noticed.

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 goes for a token analysis of all gathered Anti-CSRF tokens during all requests. This module has 2 functions:

  • Computing the Edit Distance of tokens via the Optimal Alignment Distance or the Damerau-Levenshtein Algorithm. If the edit distance ratio calculated is less than half than that 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 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 code 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