As mentioned in http://jonathanblog2000.blogspot.ca/2015/09/http-cross-origin-request-and-http.html, CORS is for preventing malicious javascript code to access response returned from a different domain, so even if user are tricked to open a malicious web page, it cannot load the response returned from user's real server. This is mostly implemented by enforcing the "Access-Control-Allow-Origin" header on client side.
Cross Site Request Forgery (CSRF), on other hand, is for a different kind of attack, it leverages the fact that browser automatically sends the cookie including authentication cookie with the request to the same server, so if the server based on the authentication cookie to validate the request, then the server will accept the malicious request as a valid one. In this case, the malicious request is sent from the same browser instance triggered by a link in an email or a different web page, CORS will not prevent this kind of attack, as the attacker does not need to get the response for his purpose. As long as the request is processed by server, then the attach is achieved.
To avoid the CSRF attack, the server needs to use something to validate the client request other than session cookie, for example, a http header for CSRF token returned from server will be a good choice. The idea is when the app sends any update (POST, PATCH) request to server, this CSRF header needs to be included by javascript code, so the server can valid the request by checking this particular header. The request will be executed only if the header is correct.
Note, although malicious code can trick user to send a Get requests to the real server, but it cannot get or parse the server response to find the CSRF token from the response, as the malicious js code is loaded from a different domain, and CORS limitation will block it to load the response returned from the real server. So the malicious code can never send a post request with the CSRF token in it to pass the server side check.
Cross Site Request Forgery (CSRF), on other hand, is for a different kind of attack, it leverages the fact that browser automatically sends the cookie including authentication cookie with the request to the same server, so if the server based on the authentication cookie to validate the request, then the server will accept the malicious request as a valid one. In this case, the malicious request is sent from the same browser instance triggered by a link in an email or a different web page, CORS will not prevent this kind of attack, as the attacker does not need to get the response for his purpose. As long as the request is processed by server, then the attach is achieved.
To avoid the CSRF attack, the server needs to use something to validate the client request other than session cookie, for example, a http header for CSRF token returned from server will be a good choice. The idea is when the app sends any update (POST, PATCH) request to server, this CSRF header needs to be included by javascript code, so the server can valid the request by checking this particular header. The request will be executed only if the header is correct.
Note, although malicious code can trick user to send a Get requests to the real server, but it cannot get or parse the server response to find the CSRF token from the response, as the malicious js code is loaded from a different domain, and CORS limitation will block it to load the response returned from the real server. So the malicious code can never send a post request with the CSRF token in it to pass the server side check.
No comments:
Post a Comment