meta user
network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 9 months |
| seen | Dec 17 '12 at 20:59 | |
| stats | profile views | 2 |
|
Sep 14 |
accepted | Current best practices to prevent persistent XSS attacks |
|
Aug 30 |
asked | Current best practices to prevent persistent XSS attacks |
|
Aug 29 |
accepted | Web Browsers and Cross Origin Resource Sharing |
|
Aug 28 |
awarded | Supporter |
|
Aug 28 |
awarded | Commentator |
|
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 |
accepted | Why can I read the response to this CSRF attack? |
|
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 |
accepted | How does ViewState protect against CSRF? |
|
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 |
asked | Why can I read the response to this CSRF attack? |
|
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 27 |
asked | Web Browsers and Cross Origin Resource Sharing |
|
Aug 24 |
awarded | Scholar |
|
Aug 24 |
accepted | CSRF cookie vs session based tokens |
|
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 |
