I found a web page is vulnerable to XSS vulnerability and I would like to bypass the CSRF protection with the XSS vulnerability.
However, the CSRF protection method is to use x-csrf-token in the request header and it is not in the response header.
Is there a way to bypass the CSRF protection method.
Try to decode CSRF token, it could be hashed using MD5, SHA or etc.
If CSRF set in cookie, try to read cookie and inject it in request.
Try to find CSRF token in JS code in page, then inject it in request.
Related
Wouldn't a malicious site be able to read the cookie using xss cookie stealing and put it in the header of an ajax request?
Of course, if the site is vulnerable to xss, it's also vulnerable to csrf, but that's the smaller issue then.
If there is no xss though, the attacker has no way to read the token due to the same origin policy.
I am getting this error please haldle the csrf token in django project.When I first made an AJAX call with a POST request, I got a HTTP 403 Forbidden error. A quick debug led me to the CSRF authorisation problem. The backend refused to authorise the request because there is no accompanying CSRF token to prove that the request is not from a foreign site.
From the documentation:
"The CSRF middleware and template tag provides easy-to-use
protection against Cross Site Request Forgeries. This type of attack occurs when a malicious website contains a link, a form button
or some JavaScript that is intended to perform some action on your
website, using the credentials of a logged-in user who visits the
malicious site in their browser."
Therefore, when making a POST request, you should always include a CSRF token.
For more information, including how to use it with AJAX calls, please refer to the documentation:
https://docs.djangoproject.com/en/3.0/ref/csrf/
I already worked with JWT on mobile app but I will implement it on a website for the first time for the authentication and I have a little thing I still didn't understood :
if I use JWT token with localStorage, XSS attacks are possible
if I use JWT token with cookies, CRSF attacks are possible
..., but if I use JWT token over HTTPS with httpOnly+secure cookies and a token lifetime of 1 month, are CSRF attacks still possible in this case ?
I see all over the web for custom token with cookie or custom token with localStorage or JWT but I didn't explicitly get the answer of httpOnly+secure cookie + JWT + HTTPS + the need of CSRF.
If you are using JWT as an authentication token, it should be stored as a cookie marked httpOnly and secure, as apposed to using Local/Session Storage. As you mention, this protects against XSS attacks, where we are concerned about malicious JavaScript being injected into our page and stealing our session token.
A cookie marked httpOnly cannot be read by JavaScript, so it cannot be stolen in an XSS attack.
Local/Session Storage, however, can be read by JavaScript, so putting the session token there would make it vulnerable to an XSS attack.
However, making the session token cookie httpOnly and secure still leaves you vulnerable to CSRF attacks. To see why, remember that cookies are marked with the domain from which they originated, and the browser only sends cookies that match the domain to which the request is being sent (independent of the domain of the page the request was sent from). For example, suppose I'm signed into stackoverflow.com in one tab, and in another tab go to evil.com. If evil.com makes an ajax call to stackoverflow.com/delete-my-account, my stackoverflow authentication token cookie will be sent to the stackoverflow server. Unless that endpoint is protecting against CSRF, my account will be deleted.
There are techniques for preventing CSRF attacks. I would recommend reading this OWASP page on CSRF attacks and preventions.
I'm using the chrome rest client to test the api calls.
A GET request is working fine but while making a POST request , getting 403 hidden response.
description is
CSRF verification failed. Request aborted
I'm setting as Content-Type=application/json.
One way would be to use #csrf_extempt, but seems to be good choice.
How to resolve above issue ?
Using #csrf_extempt is infact a good practice when you are providing an API to your site. Cross-site request forgery is what csrf is but in your case it won't be a forgery since an api can(should) be called from any site but yours.
.
Moreover sharing csrf token will prove to be very tricky.
In thre request, include an X-CSRFToken header with the CSRF token value obtained from the csrftoken cookie.
I don't get one thing about CSRF protection in django. For example we have some malicious site. What is the problem to send get-request from this site to csrf protected url, parse the page and get csrf value, then post with this value?
For example we have some malicious site. What is the problem to send
get-request from this site to csrf protected url, parse the page and
get csrf value, then post with this value?
If you do this, the session counterpart of the CSRF cookie will not match, and your request will be rejected.
Also, it should be noted that referrer check is done only for HTTPS requests to prevent a MitM vulnerability.
See this django wiki entry for a discussion on how CSRF protection works, and this SO question that discusses the MitM attack specifically.
The main purpose of Django's CSRF is explained in the Django Docs (https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#how-it-works):
This ensures that only forms that have originated from your Web site
can be used to POST data back.
So it checks several things - cookie, referrer, posted value. And there are some limitations, that you cannot always modify all these values at your will. For example - you can set X-CSRFToken token and the POST value in an AJAX call, but the browser will not allow you to override the referrer header... You might succeed to do a successful POST using urllib2 or similar library, but this is not covered by the CSRF protection, as it is the same as you POST on a page.
Again - CSRF means Cross Site Request Forgery and it is what it protects.
REFERRER will be checked. If the REFERRER does correspond to correct URL then POSTing data is not valid.