107 reputation
38
bio website
location
age
visits member for 2 years, 3 months
seen Dec 17 '12 at 20:59

Aug
28
comment Web Browsers and Cross Origin Resource Sharing
My comment about protecting against CSRF was misleading. What I forgot to mention was that the specific server endpoint drops all requests that are not BOTH post and content-type: application/json. The thing I am actually trying to understand from this is that for that specific scenario (request MUST be post and application/json) if clients would be protected from CSRF attacks? I ask because I can't figure out how to allow a browser to make this type of request without a server explicitly allowing it through CORS.
Aug
28
comment Web Browsers and Cross Origin Resource Sharing
@D.W. Not all requests, just some server endpoints reject anything that isn't a POST and Content-Type: application/json (weblogs.asp.net/scottgu/archive/2007/04/04/…). Therefore, I'm not sure exactly how someone could submit a cross origin POST of Content-Type: application/json if CORS is not explicitly enabled.
Aug
28
comment Why can I read the response to this CSRF attack?
I thought in CSRF attacks, the browser can POST to a server, but since it is cross domain you won't be able to read the response. And that is why CSRF attacks only concern themselves with requests that cause side effects (and why idempotent GETs are safe)
Aug
28
comment Web Browsers and Cross Origin Resource Sharing
Perhaps, but they wrote that my "server does not return the proper CORS headers to deny access for cross domains. Furthermore, there are older browsers that do not even implement CORS that are also vulnerable to CSRF attacks."
Aug
27
comment Web Browsers and Cross Origin Resource Sharing
True, but that is only in the case of a CORS defined simple request. I am referring to a non-simple request like say a POST with Content-Type: application/json. Lets assume the server rejects any request that is not of this type (ASP.NET page method default settings are like this)
Aug
27
comment Web Browsers and Cross Origin Resource Sharing
Protecting clients from CSRF. I agree with you, and am only confused because a security firm recently told me that because I don't explicitly handle CORS I am vulnerable. I can't find enough data that I am correct on this guess though
Aug
27
comment Web Browsers and Cross Origin Resource Sharing
I agree with this, but I am mostly wondering if random clients who are browsing the web and are sent to a malicious website that plants a CSRF attack against them are safe. I guess there are older browsers that would not honor some of these safeguards, but I can't personally find one that does in this context
Aug
23
comment How does ViewState protect against CSRF?
So then the security of this is due to the fact that it's very hard to forge a valid viewstate since it is essentially equivalent to forging a session key?
Aug
23
comment How does ViewState protect against CSRF?
But the difference here with most csrf tokens is that it is validated server side against the session id... which in this case is submitted with the csrf attack. So as long as you didn't modify the view state you will be ok. And since post params aren't part of view state this seems like it wont be very effective
Aug
23
comment CSRF cookie vs session based tokens
I am a bit confused. Why would the window of opportunity differ between a cookie or session value, assuming the csrf token is updated at the same frequency in either case?