4 ms·

I see some points but >CSRF isn't a browser vulnerability. It's a serverside application vulnerability. you didn't prove this one. CSRF is a browser vulnerabili

by homakov 15y ago

I see some points but >CSRF isn't a browser vulnerability. It's a serverside application vulnerability. you didn't prove this one. CSRF is a browser vulnerability. ANd I don't care about another stuff you said further - you probably right that most popular frameworks have the protection out of box - I know it, no surprise here:). But I did pretty wide audit - only rails' protection looks really elegant. Hm.. probably I'm too much fan of rails, true. And, please >Baking CSRF protection into the HTTP protocol is the opposite: it creates a "smart middleman" that will in the long term hamper security. Surely, I don't mean "Stop secure your apps from CSRF, it's not your problem". I just want to make browsers think about the issue as millions of developers have to. Because it is their issue, they are in charge. But we are fixing it on the backend(and we will have to for a next 10 years definitely)

Xk 15y ago
CSRF is NOT a browser vulnerability. The browser is doing exactly what it's supposed to do: load content. The browser can not (and should not) attempt to identify the "evil" HTTP requests from the "good" ones. The browser's job is to make requests. Now, you could argue the browser's job should be to implement security features as well. It does, after all, implement the same-origin policy. But, if you think about it, there is no good way for the browser to fix the CSRF issue. You can ask the user, which is what's suggested, but that never really works. They'll do one of two things: click "okay" every single time, or stop using your browser. I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window. The proposed "solution" to CSRF stops ALL of these use cases. The user would have to manually approve each and every one of them. Given that well under 1% of alerts would be true attacks, the user would almost definitely "okay" on the attacks as well: they would have been trained by thousands of other alerts that this is an acceptable thing to do. There was a paper by Barth and Jackson on CSRF defenses where they propose an Origin header, but that's the extent to which security is implemented in the browser. It is fundamentally up to the web application for verifying the user did in fact initiate the request. No amount of code in the web browser can get around this fact.
- homakov 15y ago
  >I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window. The proposed "solution" to CSRF breaks ALL of these uses. You definitely kidding me. Please point out where in my post I said to deny ALL requests. I was talking about ONLY POST requests. Probably I forgot to add it :) So, I'm talking only about forms sending and GET is ok sure.
  - Xk 15y ago
    Either you do it for everything, or you do it for only POST and you end up missing half of the vulnerabilities. Correct me if I'm wrong, but your CSRF attack used a GET request, did it not? [1] Web applications make state-changing operations on GET requests. You might not like it, but they do. [1] <img src="https://mail.google.com/mail/u/0/?logout https://mail.google.com/mail/u/0/?logout style="display: none;" />
    - homakov 15y ago
      >Web applications make state-changing operations on GET requests. You might not like it, but they do. but when developer made a mistake with GET it is 100% his problem - it's out of question. he should be punished :D
      - tptacek 15y ago
        Nonsensical. CSRF isn't God's punishment for REST-lessness.
      - baddox 15y ago
        You're both just choosing different places to draw the line between developer responsibility and browser responsibility.
        tptacek 15y ago
tptacek 15y ago
"I did pretty wide audit - only rails' protection looks really elegant." This is handwaving. You were wrong about this. I assume you want to know that, so I'm saying it bluntly. "I just want to make browsers think about the issue as millions of developers have to. Because it is their issue, they are in charge." No, the web browsers are not in charge. The secrets and sensitive actions are occurring on the servers, not in the browsers. The servers are what matter. The browser isn't protecting your email. The server is. The browser isn't protecting your bank account. The server is. The browser isn't controlling who is or isn't your Facebook friend. The server is.

by homakov 15y ago

Xk 15y ago

CSRF is NOT a browser vulnerability. The browser is doing exactly what it's supposed to do: load content. The browser can not (and should not) attempt to identify the "evil" HTTP requests from the "good" ones. The browser's job is to make requests. Now, you could argue the browser's job should be to implement security features as well. It does, after all, implement the same-origin policy. But, if you think about it, there is no good way for the browser to fix the CSRF issue. You can ask the user, which is what's suggested, but that never really works. They'll do one of two things: click "okay" every single time, or stop using your browser. I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window. The proposed "solution" to CSRF stops ALL of these use cases. The user would have to manually approve each and every one of them. Given that well under 1% of alerts would be true attacks, the user would almost definitely "okay" on the attacks as well: they would have been trained by thousands of other alerts that this is an acceptable thing to do. There was a paper by Barth and Jackson on CSRF defenses where they propose an Origin header, but that's the extent to which security is implemented in the browser. It is fundamentally up to the web application for verifying the user did in fact initiate the request. No amount of code in the web browser can get around this fact.

homakov 15y ago
>I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window. The proposed "solution" to CSRF breaks ALL of these uses. You definitely kidding me. Please point out where in my post I said to deny ALL requests. I was talking about ONLY POST requests. Probably I forgot to add it :) So, I'm talking only about forms sending and GET is ok sure.
- Xk 15y ago
  Either you do it for everything, or you do it for only POST and you end up missing half of the vulnerabilities. Correct me if I'm wrong, but your CSRF attack used a GET request, did it not? [1] Web applications make state-changing operations on GET requests. You might not like it, but they do. [1] <img src="https://mail.google.com/mail/u/0/?logout https://mail.google.com/mail/u/0/?logout style="display: none;" />
  - homakov 15y ago
    >Web applications make state-changing operations on GET requests. You might not like it, but they do. but when developer made a mistake with GET it is 100% his problem - it's out of question. he should be punished :D
    - tptacek 15y ago
      Nonsensical. CSRF isn't God's punishment for REST-lessness.
    - baddox 15y ago
      You're both just choosing different places to draw the line between developer responsibility and browser responsibility.
      - tptacek 15y ago

tptacek 15y ago

"I did pretty wide audit - only rails' protection looks really elegant." This is handwaving. You were wrong about this. I assume you want to know that, so I'm saying it bluntly. "I just want to make browsers think about the issue as millions of developers have to. Because it is their issue, they are in charge." No, the web browsers are not in charge. The secrets and sensitive actions are occurring on the servers, not in the browsers. The servers are what matter. The browser isn't protecting your email. The server is. The browser isn't protecting your bank account. The server is. The browser isn't controlling who is or isn't your Facebook friend. The server is.