0

I found a lot of popular sites not having crsf token in cookie header, does that mean all of these sites are vulnerable?

I tried to learn more about it and found there's something called CORS which protects it but I can't understand what is it.

Please share your methodology if possible, like what will you test for if you don't find a site with crsf token? how will you check if it has one or not?

4

The simple answer is “no”. Cross-Site Request Forgery (CSRF) tokens are a generalized defense against CSRF, but other conditions must be at play to be vulnerable. For example, the attacker needs to be able to predictably make a valid request to the site. There are also other design factors that can be used to mitigate against the threat of CSRF.

Auth/Session cookies tend to make attacks easier because they are submitted with any request to the domain regardless of whether the request came from the same origin site. Cross Origin Resource Sharing (CORS) helps prevent this by blocking cross-origin requests unless the site the request is being made against explicitly allows cross-origin requests. However, GET requests are usually allowed so long as they are not made via JavaScript, so sometimes a CSRF attack can sneak in by requesting content using an image tag.

Related to Auth Cookies... another mitigation against CSRF might be to submit the auth token as a header, rather than a cookie. This requires that your requests have the token added explicitly with each request, thus mitigating the risk of the browser automatically adding the authorization to requests not made by your own code. The token is usually stored in Local Storage for this, which can only be accessed from code that loads from the same domain as the code that saved it.

As mentioned above, to be vulnerable the malicious code needs to be able to predict how it needs to interact with the site to get a useful response. For example, if the site under attack were a bank, the malicious code needs to be able to determine the complete details of a request to transfer money to be able to do so. If the money transfer request assumes a default source account, this is much easier for the attacker to do since they won’t need to guess that information because the server assumed the user’s context by default.

That said, in most cases the attacker may be able to access quite a lot about the user from your site if they have enough time to play around with it from their own account. So assuming the attacker can’t do something because a cross-site request wouldn’t be successful in a single step would be folly. In the prior example, they would just need to make a request to get a list of the user’s accounts before they can make a request to transfer money.

  • why everyone show the example of img tag? is it the only way to do it and if yes then why so? – Ashwin Jun 23 '18 at 18:23
  • I don't believe it's the only way... but my experience and education have focused more on defense than offense, so I've never really needed to know the alternatives in-depth. It's notable though because it doesn't get the same restrictions as JS-based requests. XSS attacks often use them to exfiltrate data by putting it in the query-string of the image request. There's some similar tricks I've seen recently using image URLs for CSS content. No image tag, but it still makes a request out like it's looking for an image. – nbering Jun 23 '18 at 18:31
3

The statement, "every site without a CSRF token is vulnerable to a CSRF attack", is not accurate. It certainly does not apply to static websites that have no server-side functionality, where CSRF is not even applicable/possible. Additionally, the OWASP CSRF Prevention Cheat Sheet mentions some other CSRF-prevention mechanisms that do not use CSRF tokens:

Adding CSRF tokens, a double submit cookie and value, encrypted token, or other defense that involves changing the UI can frequently be complex or otherwise problematic. An alternate defense which is particularly well suited for AJAX endpoints is the use of a custom request header. This defense relies on the same-origin policy (SOP) restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers don't allow JavaScript to make cross origin requests.

A particularly attractive custom header and value to use is:

X-Requested-With: XMLHttpRequest

or

Sometimes it's easier or more appropriate to involve the user in the transaction in order to prevent unauthorized transactions (forged or otherwise).

The following are some examples of challenge-response options:

  • Re-Authentication (password or stronger)
  • One-time Token
  • CAPTCHA

Otherwise, any web application that doesn't implement any of these mechanisms and does have HTTP GET or POST requests that initiate actions may be vulnerable.

CSRF and CORS are rather separate concepts even though there is some similarity, at least at the root of it all.

CORS, or Cross-Origin-Resource-Sharing allows a server to define a policy of which origins (other domains) may retrieve information from it. Even though the default policy prevents another origin from reading data, it does not prevent a CSRF attack from succeeding.

Please share your methodology if possible, like what will you test for if you don't find a site with crsf token? how will you check if it has one or not?

You can check for a CSRF token by examining cookies, the request body, and the HTML, although it may depend on the specific system used.

You can test for CSRF vulnerabilities by crafting a test HTML page that attempts to perform sensitive requests towards the website in question.

  • I have two things to ask here. CRSF if one way process and CORS is two way, am I right? Am not sure but crsf has something to do with content type header, don't know exactly what it is but read somewhere and I couldn't understand it, do you have any idea about it? – Ashwin Jun 24 '18 at 4:07
  • CSRF could be said to be one-way, yes. CORS itself is a feature, not a vulnerability. I'm not sure what you mean by the content type header. – multithr3at3d Jun 24 '18 at 4:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.