XSRFProbe Internals

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.

• Origin Based Forgery Checks - Checks on whether the site validates Cross-Origin requests.
• Referer Based Forgery Checks - Checks on whether the site validates Referer-based requests.
• Anti-CSRF Token Detection -
  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 - 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 - 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 unforgable. An entropy lower than that of 2.4, means the token isn't random enough and can be easily forged via guessing/bruteforcing.
• Cookie Persistence - 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 efficiently when you supply a cookie with the -c/--cookie argument.
• Cookie Flags Checks - 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 - 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 Radcliff-Obershelp Algorithm and determines the no 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.

NOTE: The forms generated are as per input values of 2 standard forms.

• Tampering and Forging Requests - 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 - 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.