Could post request with URL parameters be csrf hacked?
If server side has only "Consumes application/json" protection.
Using HTTPS.
If u have appropriate link, pls, share it.
"Some applications will check that the Content-Type HTTP header is "application/json", so it will prevent a CSRF attack. A better security would be to use an authenticity token, this will protect HTTP requests even if the data type is not JSON."
Thx, Adithya!
Related
I'm a bit confused from the online information.
I'm using CSRF protection using Spring security on my back-end.
I wanted to ask is it safe to send CSRF token from my angular front-end, while I'm passing the token within HTTP header using Ajax GET method?
Because according to Spring docs I shouldn't use GET method, but on the other hand it doesn't say anything about if it's okay to use GET Ajax when I pass it in HTTP header.
Second,
If I shouldn't use GET, how do I use REST service & CSRF protection? should I give up GET method or CSRF protection?
Since GET requests should not modify any state on the server and should be "read-only" usually CSRF protection should not be needed for GET requests.
The problem about leakage is mostly related to browser usage because GET requests usually do not contain a body and thus the token is sent as request parameter. Thus the CSRF token could be visible through shoulder surfing, stored as a bookmark, appear in the browser history or logged on the server (altough logging also applies to AJAX requests).
Since you are talking about AJAX requests most of this leakage does not apply, although setting it in header may help in case of URLs appearing in the logs, but logs could also contain headers.
But actually using a custom header (with or without token) is often used to prevent CSRF attacks because AJAX requests cannot set custom headers cross-domain other than
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type
Thus using a custom header like X-Requested-With: XMLHttpRequest which is e.g. set by jQuery and verifying this header on the server can prevent CSRF attacks.
Last but not least there is one interesing article about having the same token for GET and POST requests and having same-origin access to the GET request via an XSS vulnerability of a separate web application in the same origin where the token can be leaked from the GET request and used for a POST. The solution there is to either not use CSRF tokens for GET or use different tokens for GET and POST.
Basically regarding your questions, if your GET does not have any side-effects, a CSRF token is not really needed but would not hurt. On the other hand, if your GET request changes something on the server, you should think about using another verb (e.g. POST) depending on what you want to do and then protect your POST requests with a CSRF token or a custom header.
I want to protect my API against CSRF and my first HTTP request to the API is a POST request: What is the best approach to tackle this problem?
I am using Spring Security v4.
Observation:
Since this is the first request (POST) to the API I don t have any reference to a CSRF token which could have been received as part of the response of a previous Http request.
Question:
1) How is this problem solved in spring security?
I want to post directly to my API something like this, but I don't posses any CSRF token value yet with the first request to my API.:
POST myendpoint/students HTTP/1.0
{'param1':'value1', .....}
response.setHeader("Access-Control-Allow-Origin", "https://example.com");
I only wanted to allow 'https://example.com' to access my Java servlet with POST request. How do I can enable CORS in IBM WebSphere 7.0.0.27
Thanks
I cannot provide specific informations about Websphere 7, but it is not complicated to write a servlet filter, which handles the CORS preflight requests. Here are two resources that explain the protocol:
http://www.html5rocks.com/en/tutorials/cors/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
The filter needs to do 2 tasks:
Recognize if the http request is a CORS preflight request.
If it is a CORS preflight request:
set Access-Control-Allow-Origin: https://example.com
set other Access-Control-* header
Hope it helps a bit.
Please have a look at https://www.owasp.org/index.php/CSRFProtector_Project or the CSRF information in General. There is a J2EE filter as well on their page.
You have to build a filter which checks the origin header (if you do it on your own) it is no rocket science, but some browsers do implement the spec differently. Chrome does always set the origin header.
Even with CORS you would still need to protect against the old CSRF attack like auto form submit as this would not set origin header as far as I know.
I used Java Hipster to create my Rest API. I want to use this Rest API in my Java code (I'm developing an Android application). But I don't understand how authenticate me to use my Rest API !
As example, my api is blabla/api/getUser. With Firebug I tried to understand how call my API. I simulate a HTTP request POST with parameters ?id=x and my token in the header (token I got from the request to login from the browser). It's okay, it works, I have my information.
But now, in my java code, I can't send the same HTTP request because I don't know the token. How can I get it ? How can I log me as admin ?
I know : login for admin, password for admin and the URL of my API and parameters I have to send.
Thank's !
OAUTH2
POST
URL:
http://localhost:8080/oauth/token
in the header:
Authorization: eg. 'BASIC Y2xpZW50aWQ6Y2xpZW50c2VjcmV0'
BASE 64 encoding the client details (source: www.base64encode.org/)
Y2xpZW50aWQ6Y2xpZW50c2VjcmV0 == clientid:clientsecret
in the body:
username
password
grant_type
scope
curl -X POST -vu clientid:clientsecret http://localhost:8080/oauth/token -H "Accept: application/json" -d "username=admin&password=admin&grant_type=password&scope=read"
edit:
in android look at retrofit by square
We're building an app with a Java Spring/Hibernate backend running in JBoss. The frontend is AngularJS.
We haven't yet done anything to setup XSRF tokens on the server end. We also don't (not yet anyway) have a requirement to allow other domains access to our web resources.
I figured I'd try to see if our site was vulnerable to an XSRF attack so I set up a malicious webapp to post to one of our real app's urls using Angular's $http.post(). I logged in to the real app, then I tried posting from the malicious app.
In the browser I got a 401 response and saw the error:
XMLHttpRequest cannot load http://localhost:8080/user/delete. No
'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://localhost:6543' is therefore not allowed access. The response
had HTTP status code 401.
The server side isn't setup to set Access-Control-Allow-Origin on the response thus the above error.
So my question is, is simply omitting Access-Control-Allow-Origin from the response header adequate to prevent XSRF attacks?
Is there a way I could still do an XSRF attack on my site even though Access-Control-Allow-Origin is not set? If so how? I'd like to demo this attack.
Thanks.
No, this is not sufficient. Even though the browser gives the 'Access-Control-Allow-Origin' error, the request has still been made by the browser. If withCredentials is specified by the attacking page:
$http.post(url, {withCredentials: true, ...})
then this request will be sent to your domain with the victim's authentication cookies, meaning that the request to http://www.example.com:8080/user/delete will succeed.
Also, this request could also be made without XHR using a standard HTML form:
<form method="post" action="http://www.example.com:8080/user/delete">
and JavaScript would just be used to submit the form rather than making the request itself.
An easy way to protect your system against CSRF is to check for a custom header such as X-Requested-With or the Origin header. X-Requested-With cannot be sent cross domain without enabling CORS server-side. However, the Synchronizer Token Pattern is still the strongest method of CSRF prevention as this is not subject to flaws in browser plug-ins such as a previous flaw in Flash that allowed headers to be sent that weren't normally possible from a browser.