FAQs

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 you're scanning, it 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.

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 we are using some kind of automated scanner) and ultimately to IP blocking.

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

It is possible since XSRFProbe is highly customisable. You can simple head over to the configuration file and edit the HEADER_VALES as per the syntax of Python dictionary as follows:

1. Your header field name should be the key.
2. The header 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 token 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.

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. Ususally the following 2 HTTP Error quotes are encountered:

• 50x (Internal Error)
• 429 (Too Many Requests)

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 repo for further development.