I am trying to implement CSRF and SSL(they are not entirely dependent) and listing below my understanding on the topic for having a proof of understanding.
Please feel free to correct me about the understanding.
We see CSRF Token in almost all of our secure applications.
How Cross-Site Request Forgery (CSRF) works :
You logged into your bank account(eg. SBI or JPMC) and are looking at your accounts or it's just sitting their opened on your browser just because you got busy.
Now you receive an email may be text/image or anything on the next tab. The moment the email is received functions like onload etc other java script function may trigger a GET/PUT/POST request from your browser without you knowing about it.
Now things to note is that CSRF can't actually read anything from your secured webpage because the moment you have a proper SSL the secure pages are encrypted. And also CSRF can't steal your credentials. As a matter of fact it can't find out the CSRF token kept inside hidden tag inside secure website because its encrypted. It works only after you have authenticated yourself with the website and it fires requests which tricks the server into thinking that the request in coming from the browser you just logged into and thus server work as per the received request.
Now with hacker trying to open a CSRF attack, it tricks the browser to send url:
<img src="https://www.bankWebsite.com/transfer?amount=1000&destination=8990">
Thus without you knowing, from a session which is authenticated by you, a request is fired telling to transfer amount of 1000 in account number 8990 n BOOM you were robbed for 1000 bucks just like that.
How to protect youself:
CSRF protection can be done in a couple of ways:
1) Verifying the origin of request from header
2) Verifying the target of the request
3) CSRF token
How CSRF token protection works:
The CSRf token in present in the header/cookie. So when the hacker tricks the browser into sending the request to the server, the token is present only in the header and not in form submitted. So when the server goes to check whether the CSRF token received, it tries to match the CSRF token from the header with that received from the form/request. If it's not present/doesn't match then server identifies that it's an attack and stops the request from penetrating further.
Request you all to please correct me if my understanding about the CSRF attack, protection is correct or not ?
Also does it mean without proper implementation of SSL, CSRF is of no use ?
Request you all to please correct me if my understanding about the CSRF attack, protection is correct or not ?
Yes
Also does it mean without proper implementation of SSL, CSRF is of no use ?
If you send the token to and from the client in plain text (instead of encrypting it with SSL) then it can be intercepted by the attacker.
If the attacker knows what token to put in the form data, the protection is gone.
Related
My website is full SPA, and all of the authenticated user's requests are done using access token, the only form that unauthenticated users have access to is login form. So is csrf protection necessary? What potential security issues could I face if I disable csrf protection from my website? Thanks.
If I understand your setup, it is as follows:
User POSTs credentials (eg: login form)
Server returns auth token in response
User includes token in a request header with every subsequent request
If this is accurate, and assuming that you're using TLS and properly validating tokens, I think you are already well protected against Cross-Site-Request-Forgeries.
The typical CSRF protection is to send a token that only the legitimate website can see (eg, by setting a cookie), and then expecting that same token to be returned either in follow-up request headers, query parameters (not a good idea), or request body. Token-based authentication such as yours already meets these requirements.
In short, if an evil site is able to circumvent your setup to forge requests (CSRF), then the evil site could probably use the same vulnerability to defeat a typical CSRF protection.
Reading this section of the Django docs they recommend setting a csrftoken in a cookie and then having the client-side framework put this in a header which will be validated on a server-side request. However, doesn't having the token in a cookie defeat the purpose because the cookies are sent on every user's request?
Or is the "security" here that Django checks for that value in a header rather than checking the cookie value itself?
I do understand why this works for synchronous submissions, but in that case the csrftoken is written directly to the page rather than stored in a cookie, which seems more secure.
From the OWASP page on reviewing code for CSRF:
Checking if the request has a valid session cookie is not enough, we
need check if a unique identifier is sent with every HTTP request sent
to the application. CSRF requests WON'T have this valid unique
identifier. The reason CSRF requests won't have this unique request
identifier is the unique ID is rendered as a hidden field on the page
and is appended to the HTTP request once a link/button press is
selected. The attacker will have no knowledge of this unique ID, as it
is random and rendered dynamically per link, per page.
You've misunderstood a few things.
The token is always in a cookie; the code you link to is for getting it out of the cookie in your JS so that you can send it back.
And the point is, as your quote shows, that an attacker trying to post from a page that is not on the site will not have that cookie, so won't be able to inject the right value into the form or the header.
I'm not familiar with django csrf protection, but I think it's work like other csrf protections in other frameworks.
The trick is, send csrf token to the client through cookie and client use header to send it back to the server. Server ignore cookie, but not header. How it prevents csrf attack? For example, attacker can bind <img src="yourwebsite.com/action/destroy/data"> (or sends post request through javascript). Your browser sends csrf cookie (and also session cookie) with it. Because header is missing - attack is prevented.
Same with forms. I think both, headers and forms are equal secure.
But in both cases you are lost, if you have a xss vulnerability.
EDIT: as Daniel points out, it's make sense to remove csrf cookie. But this is not for security reason.
Good Morning,
I'm developing an app in ionic and there are some $http requests(angular) that send data to a server controller(yii 1) to save data on database. I finished my app, but it doesn't have security. I was wondering how to protect it, because right now anyone if look my $http request can know what parameters have to send, and kill my app.
What I should do to protect it? Maybe through tokens? I'm really lost with security methods.
Thank you so much,
Carles.
well When you research web application security you will come across Cross-Site Request Forgery (CSRF). This attack vector is taking advantage of cookies, but in a preventable way.
Most attacks focus on stealing your cookies because nearly every website uses cookies as a form of authentication. The setup is this: when a user logs into your server, you set a cookie in the browser. This cookie contains a unique ID which is a link to the user’s session information in your database. The browser supplies this cookie on future requests, and the server knows who you are.
On the surface this sounds not-so-bad, but here is the catch: the web browser can be tricked into making requests to your server, even if the end-user didn’t perform the action themselves.
Using POST Requests
It is sometimes thought that using proper form-based POST requests will mitigate this attack, but that is not true.
Using HTTP-Only or Secure cookies
While you definitely should use these flags on your session cookie, they don’t implicitly stop the attack: the browser still sends the cookies to your domain when a request is made to your domain. Your server does not know if this is a real user or an attack.
How To Prevent CSRF
You can achieve this by relying on a set of rules that browsers respect, called the Same-Origin Policy. This policy asserts that certain sensitive operations are performed by JavaScript code that is running on our website, not some other website.
Angular packages the CSRF token approach, making it simpler for us to implement. For every request that your Angular application makes of your server, the Angular $http service will do these things automatically:
Look for a cookie named XSRF-TOKEN on the current domain.
If that cookie is found, it reads the value and adds it to the request as the X-XSRF-TOKEN header.
Thus the client-side implementation is handled for you, automatically! But this does leave the server side pieces in your hands. You will need to do the following parts:
During login: create the CSRF token (with a random, un-guessable string), and associate it with the user session. You will need to send it on the login response as the XSRF-TOKEN cookie.
Assert that all incoming requests to your API have the X-XSRF-TOKEN header, and that the value of the header is the token that is associated with the user’s session.
That’s it! With a little bit of backend work, you now have a strategy which protects you from CSRF attacks.
you will find a working example of how to prevent CSRF attack here
and for theory of understanding CSRF attacks please follow this reference
I don't understand fully the point of csrf token protection.
That's the token that says that the POST is coming from my site.
But anyone has access to that token by just verifying their cookie content.
I don't understand then, how is this token protecting me?
To get the csrf cookie, can i make an ajax call to the server and just set the cookie that way? Will that break the csrf protection?
CSRF attacks involve malicious code hosted somewhere. The idea is this:
Attacker lures you to site, and your browser loads malicious code
Malicious code, in the context of that site it came from, attempts to carry out a POST to some known URL at some other secure site: your bank, your hospital, whatever.
If you happen to be logged in to the secure site, then your browser will have a secure session cookie for it. When the malicious code attempts the POST, then, your browser will dutifully send along the cookie. The bad code doesn't know what the cookie value is, but it doesn't have to.
The malicious code does, however, need to know everything else about how to put together the parameters for the POST request to be carried out. That's where the secure CSRF token idea comes from. The malicious code can't actually see what's on the pages in your browser from the real secure site. Thus, a secure site that expects a CSRF token won't see one when the malicious code attempts its POST operation.
(There are probably other variations on this; I'm not a security expert and I don't have exhaustive knowledge of attacks like this.)
csrf token confusion. i can just get it with wget, no cross-origin problems. what's the point then?
The part you're missing is cookies - wget will not send the cookie from the victim's browser along with the request.
The Synchronizer Token Pattern associates the CSRF token (which is visible in a hidden <input> field within the HTML) with the session cookie. If another user makes a request to get the CSRF token from your page, as they are not logged into the same session as their victim, this token will not be useable in their attack.
A CSRF attack works like follows. Imagine the following code on www.evil.com, a site that the attacker has managed to get their victim to visit (e.g. via a facebook post or an email):-
<form method="post" action="https://www.example.com/executeAction">
<input type="hidden" name="action" value="deleteAllUsers">
</form>
<script>document.forms[0].submit()</script>
As the victim is logged into your site (www.example.com) as an admin user, the form submission works and all users are deleted from your system.
The Synchronizer Token Pattern is the recommended way to fix this vulnerability. The CSRF token is a cryptographically secure random string. When a legitimate user loads your form and submits it, your system will check that the token POSTed matches the one expected. Any attacker cannot read the token from your site as any cross site access is protected by the Same Origin Policy
There is another prevention method known as Double Submit Cookies (which may match the method you are talking about). This works in a similar way, although there is no server side state of the CSRF token stored. This requires a cookie value to match a CSRF token that is submitted with the form, but as the attacker cannot set this cookie nor read it, they do not know the value to set the form submitted value to in order to match the cookie.
I have been reading about using a synchronizer token pattern to prevent CSRF (CSRF meaning Cross-site request forgery.), and I don't understand how it actually safe.
Let's say I have a fake bank site fakebank.com with two urls:
fakebank.com/withdrawForm.html - a GET request which displays the withdraw money form
fakebank.com/doWithdraw - POST to this url to do the withdraw
My understanding of the security flaw is that maliciousSite.com can spoof a POST request to fakebank.com/doWithdraw, and if you're currently logged in to fakebank, the POST will be successful.
Let's say we implement a Synchronizer Token Pattern which will embed a secret code on fakebank.com/withdrawForm.html. Can't maliciousSite.com just spoof a GET request for that form, parse the html result, get the token, and then create the POST request with that token?
This is assuming fakebank.com isn't checking HTTP Referrer or Origin or maliciousSite.com is successfully spoofing that the Referrer/Origin is fakebank.com.
The reason why this is secure, and maliciousSite.com cannot simply do a GET, steal the token, and then do a POST is that the request is done by the user's browser, not by the server at maliciousSite.com. All data returned from fakebank.com is returned to the user's browser, not to the server at maliciousSite.com. If maliciousSite.com does perform a GET to retrieve a token, it will be a different token than was issued to the user. maliciousSite.com cannot set this cookie into the user's browser to be submitted to fakebank.com because of same-domain restrictions.
The CSRF POST attack works by tricking the user's browser into requesting fakebank.com/withdrawForm.html directly using a properly formed POST request. The server at fakebank.com happily executes the requested POST, thus transferring funds using the parameters supplied in the POST body (which include a destination account belonging to the attacker that was put there by maliciousSite.com). The server at maliciousSite.com doesn't need to see the data returned, because the action has been taken (unless fakebank.com uses these CSRF tokens, which the maliciousSite.com can't possibly know unless it has been divulged in some way. It can't ask for it). If fakebank.com is using CSRF tokens, then maliciousSite.com will submit a POST request that is missing the token, thus indicating a potential CSRF attack in progress.
Vulnerabilities of this method include using a CSRF token that is not kept sufficiently secret and is divulged in some way. Also, if the CSRF token is not sufficiently random, then maliciousSite.com might be able to guess it. Also, if there is a weakness in the browser's enforcement of same domain policy, this could be exploited. Generally speaking, modern browsers are not vulnerable to this.
Please let me know if this is an insufficient explanation and I'll attempt to articulate it a little better for you.
And that is exactly the point. The Same Origin Policy in the browser does not allow GET requests to other sites. So no site can GET the CSRF token from another just using Javascipt within the browser.