-
Notifications
You must be signed in to change notification settings - Fork 199
XSRFProbe Internals
XSRFProbe has various checks for detecting whether an endpoint is vulnerable to CSRF attacks.
Following are the various checks XSRFProbe executes before declaring any endpoint as vulnerable.
- Origin Based Request Validation Check
- Referer Based Request Validation Check
- Anti-CSRF Token Detection in POST Queries
- Anti-CSRF Token Strength Detection
- Anti-CSRF Token Randomness Calculation
- Anti-CSRF Token Encoding Detection
- Session Cookie Persistence Checks
- Cross-Site Cookie Validation Checks
- POST-Based Request Forgery Detection on Forms
- Tampering Requests for Detection Back-End Validation
- POST-Scan Token Analysis of all Anti-CSRF Tokens Gathered
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.
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.
Module: Token.py
Checks on whether the site validates POST requests with Anti-CSRF tokens. XSRFProbe now dissects the POST query and compares every parameter of the query to a predefined list of known Anti-CSRF tokens. Now when it finds a matching parameter, it starts the next subsequent check.
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.
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.
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.
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.
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.
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.
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.
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.
Last Updated — 31/10/2019 by @0xInfection
- Home Welcome to XSRFProbe!
- Getting Started Getting started and setting up XSRFProbe.
- General Usage Basic usage of XSRFProbe.
- Advanced Usage Useful for advanced users who know what they're doing.
- XSRFProbe Internals How XSRFProbe works, intended for developers.
- Some FAQs Some discussions on topics which a user should understand.
- Contributing Making new pull requests.
- Reporting Bugs Issuing new bugs to XSRFProbe.