FAQs

Some Important FAQs

Why should I supply cookies?

XSRFProbe has got 2 modules for checking

• Cookie Persistence
• SameSite Cookie Flags

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 tokens or trick the user into doing something unsavoury that will generate a Cross-Origin request and make changes using the session cookie of the victim. In addition, the site which you're scanning should provide the user with long duration session tokens explicitly. So for full assessment of a website, a cookie (preferably a session cookie) is required and is a must. So it is recommended, that for a thorough assessment of the attack scenario, you should supply a valid session cookie.

Another scenario where cookies could be useful is when it gives you an elevated privilege on the site. This is useful for sites where unless you login, you really can't do much (eg. Social Networking sites, e-commerce sites, etc).

Why is using random-user-agents not recommended?

XSRFProbe usually uses a single default agent-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/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727)',
    '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 since XSRFProbe is highly customisable. You can simple 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 is the buzz 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, just simply stating a comma separated list of the directories via the argument --exclude will do, but you also can head over to the configuration file 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 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?

This is a beta release of XSRFProbe v2 and it is quite possible for this tool to give out some false positive, although significant efforts have been made to eliminate False Positives. However, no False Negatives are produced.

Keep a watch on this repository for further development.