FAQs

Some Important FAQs

Why should I supply cookies?

XSRFProbe has got 2 modules for checking:

• Cookie Persistence
• Cross-Origin Cookie Validation

Both of which are crucial to a successful CSRF attack.

For a basic and a successful CSRF attack, an attacker needs to get the user's session cookies or trick the user into doing something unsavoury that will generate a Cross-Origin request and make changes using the session of the victim provided that the site which you're scanning should provide the user with long duration session tokens explicitly. So it is recommended, that for a thorough assessment of the attack scenario, you should supply a valid cookie (preferably a session cookie).

Another scenario where cookies could be useful is when it gives you an elevated privilege on the site. The cookie you supply will help identify that you're a registered user on the site. This is useful for sites where unless you login, you really don't have access to much of the site (eg. Social Networking sites, e-commerce sites, etc).

Why is using random-user-agents not recommended?

XSRFProbe usually uses a single default user-agent pretending to be a legitimate Windows 10 Chrome browser. Using random user-agents is not recommended since, with each iterating request, if the user-agent changes, it might lead to triggering some security mechanisms which in turn might lead to detection (that you are using some kind of automated scanner) and might ultimately lead to IP blocking.

What if I want my own custom headers while making requests?

You can of course set additional headers to the basic existing set of headers using the --headers argument. XSRFProbe is equipped with a default set of headers to accurately impersonate a standard browser:

{
    'User-Agent'        : 'Mozilla/5.0 (Windows; U; Windows NT 10.0; en-US) AppleWebKit/604.1.38 (KHTML, like Gecko) Chrome/68.0.3325.162',
    'Accept'            : 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
    'Accept-Language'   : 'en-US,en;q=0.5',
    'Accept-Encoding'   : 'gzip',
    'DNT'               : '1',
    'Connection'        : 'close'
}

However it is also possible to use a whole new complete set of headers. You can simply head over to the configuration file and edit the HEADER_VALUES as per the syntax of a standard Python dictionary as follows:

1. Your header field name should be the key.
2. A field value should be assigned to the key.

For example, if you want to assign the Max-Forwards header field with a value of 10, and cache content, you'll do something like this.

HEADER_VALUES = {
                 'Max-Forwards': '10',
                 'Cache': 'Pragma'
            )

What about form field generation?

XSRFProbe has got multiple checks before declaring any endpoint as vulnerable. If a form is found, it will make requests and submit the form at least three times for checking basic POST-Based Request Forgery (See XSRFProbe Internals for more info).

So as you can understand, the more the form field string generation length, the more stress it causes to the site. So choosing the string length for form filling wisely is crucial.

I have some directories which I don't want to scan, is it possible?

Absolutely. There are often sensitive directories on a website which you might not want XSRFProbe to access, we understand that. So just simply stating a comma separated list of the directories via the argument --exclude will do the magic. You also can head over to the configuration file, config.py and edit the EXCLUDE_DIRS variable as per the syntax of a Python List.

EXCLUDE_DIRS = ['dontscanme/', 'sensitive/', 'notraffic/'] 

During scanning I received a HTTPError, what happened?

It means XSRFProbe has successfully DoS'ed the site, by sending a horde of requests which the site couldn't handle. Usually the following 2 HTTP Error codes are encountered:

• HTTP 503 (Service Unavailable) - XSRFProbe has most probably DoS'ed the site, hence the Internal Error.
• HTTP 429 (Too Many Requests) - Temporary ban on for making too many requests within short time. Using --random-agent will help you avoid this error.

I am getting VULNERABLE in various endpoints, but they're not. Why?

It is quite possible for this tool (though extremely rare) to give out some false positive, although significant efforts have been made to eliminate False Positives, eg. eliminating Self-CSRFs via exclusion lists. However, no False Negatives are produced.

How do I know if this tool actually works? Where can I test it?

Eager to test XSRFProbe? There are actually a lot of test websites on which you can test this tool. Below are a few sites and pages where you can test it:

• http://webscantest.com/csrf/token.php - CSRF Token Reuse Demonstration (Replay Attacks).
• http://webscantest.com/csrf/csrfpost.php - POST-Based CSRF Demonstration.
• https://hack.me/101991/login-csrf-concept.html - Hack Me Login CSRF Concept Demonstration.

Are there different colour codes?

Yes there are! Similar to my previous projects, this is also a command line tool which highlights using colour codes. Red indicates high severity whereas Brown indicates low/moderate severity. Bright Green indicates no vulnerability.

Keep a watch on this repository for further development.