4 ms·

A page that lets you run arbitrary JavaScript in your own browser is not automatically vulnerable . For it to be a vulnerability you must be able to run arbitr

by brlewis 15y ago

A page that lets you run arbitrary JavaScript in your own browser is not automatically vulnerable . For it to be a vulnerability you must be able to run arbitrary JavaScript in someone else's browser. If these pages protect against CSRF, most of them aren't vulnerable, expresslane being one case where I think you could get the JS to someone else without CSRF.

jlongster 15y ago
You could "share" link with your own javascript embedded in it that reads cookies and sends them to your logging server. Or customize the website so that when somebody types their password, it sends it to your logging server. If you can run custom javascript on a page, it's a security problem.
- brlewis 15y ago
  That attack fails if the page prevents CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prev...
  - jlongster 15y ago
    Not if the page simply a normal page that you would type in your URL. CSRF doesn't make sense there. I could send you a link to facebook.com with an embedded script.
    - brlewis 15y ago
      If the page accepts URL parameters or POST data, CSRF makes perfect sense.
      - judofyr 15y ago
        > If the page accepts URL parameters … CSRF makes perfect sense. No, it doesn't. CSRF makes perfect sense when there is data on the server that is being modified by a request. A simple "search.php?query=…" doesn't need CSRF protection. If you're passing parameters that modify the server in the URL (instead of a part of the post data) you're using HTTP wrong and adding CSRF protection in the query string is the wrong solution.
        brlewis 15y ago
        You're right about the search example. That doubles the list of demonstrated vulnerabilities in this article from 1 to 2. I certainly agree that using GET for changing server state would be wrong. I don't know if any of the examples in the article work that way, since all we're provided with is a screenshot with an alert box. That's demonstrated sloppiness on Apple's web site, but not enough information to demonstrate vulnerability. (I'm definitely voting up your reply for intelligent discussion.)
  - romaniv 15y ago
    Not necessarily. Typical CSRF implementations prevent the server from accepting inputs coming from an "unauthorized" page. This might or might not prevent XSS from being triggered on the client side. XSS can propagate to other users via database rather than HTTP requests. In general, you should prevent attacks in one-by-one manner. Hoping that one security mechanism will accidentally fix other issues will result in design that is insecure, convoluted and hard to reason about. Remember: you have to prevent all attacks. Attackers only need to find one vulnerability to attack. Therefore, any kind of complexity in design works to their advantage.
    - mike-cardwell 15y ago
      Exactly. Don't defend from XSS by implementing CSRF defences. Defend from XSS by making sure you properly encode every piece of data that enters your web page. Then add CSRF on top, to prevent third party sites from initiating "clicks" on your page. Then implement Content-Security-Policy to help defend against programmer mistakes which leave CSRF/XSS holes open.
    - brlewis 15y ago
      I agree that XSS can propagate to other users via database...I'm pretty sure the expresslane example is a real vulnerability for that reason. But note that the grandparent post was not describing an attack via the database. I am not hoping that CSRF prevention will make everything OK on the Apple website (which I have no affiliation with, by the way). Nor am I saying XSS prevention is not worthwhile. I'm merely pointing out that this blog post is not demonstrating 11 vulnerabilities in Apple's web site. There might actually be 11 vulnerabilities, but the blog post doesn't give enough information for us to know.
    - Joeri 15y ago
      Exactly, defense in depth is the name of the game. An example of a defense in depth strategy: Layer 1: Customer runs a WAF (web app firewall) to do some CSRF and XSS mitigation Layer 2: App contains its own intrusion detection system that preprocesses all requests for "typical" SQL injection, CSRF and XSS attacks and prevents the rest of the code from executing if this is the case. I'm using PHP-IDS for this. Layer 3: every request to the server must submit an anti-CSRF token and is immediately refused if it does not do so. Layer 4: Business logic contains its own positive input validation (all input must be in the expected format), and prevents the rest of the code from executing if the input is not valid. This is meant to prevent XSS and SQL injection when data enters the system. Layer 5: all DB requests use parameters instead of concatenating variables into queries to mitigate the risk of SQL injection. Layer 6: All output is encoded to prevent XSS attacks when data leaves the system. In such a solution you can have a security issue in one of the layers and still have a system that is secure.
- dmitri1981 15y ago
  It might sound trivial, but on many systems it can lead to serious privilege escalation and expose huge vulnerabilities further up in the chain. Check out the case study below for an example in real world. http://mobile.eweek.com/c/a/Security/Hackers-Hit-Apacheorg-Compromise-Passwords-896918/ http://mobile.eweek.com/c/a/Security/Hackers-Hit-Apacheorg-C... Also, if you want to learn more about avoiding these issues, OWASP is one of the best sources out there. https://www.owasp.org/index.php/Main_Page https://www.owasp.org/index.php/Main_Page
tripzilch 15y ago
If the arbitrary JS is specified by a specially crafted URL or form POST, you can make the JS execute in someone else's browser as easily as getting someone to click on a very innocent-looking link. And as soon as you can get someone to execute arbitrary JS on a particular domain, any CSRF protection will be useless because you practically control their browser. (You can even literally control their browser, if you use BeEF http://www.bindshell.net/tools/beef.html http://www.bindshell.net/tools/beef.html ) You can even completely hide the XSS happening by loading it into an invisible IFRAME, while the main page keeps the victim's attention occupied by playing the promised video of a cute kitten playing with a ball of string.
- brlewis 15y ago
  Both of those attacks fail if the page protects itself against CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prev...
  - mike-cardwell 15y ago
    You can initiate an XSS attack without making any cross site requests. Being able to launch a CSRF attack, is not a prerequisite for being able to launch an XSS attack. It does help though.
    - brlewis 15y ago
      If I didn't know that, my original post would have said that all the Apple pages would be invulnerable if they prevented CSRF. I think the expresslane page is one where data could go in the database and others could see it. CSRF is not a prereq in general, but it is a prereq for the attacks tripzilch listed.
  - oscardelben 15y ago
    A simple example: you can pass a link to someone and have some javascript that submits form for them without them knowing.
- 15y ago
justinschuh 15y ago
These screenshots show pretty textbook reflected XSS vulnerabilities, so I don't see why you think there's a CSRF vulnerability required for an exploit. Most of the targets are innocuous operations that aren't modifying any persistent state, so they wouldn't normally have CSRF protection. In particular, the search queries all appear to support direct-linking (notice the query string), which means they can't employ CSRF mitigations (because it would break the links).
- brlewis 15y ago
  Yes, the search query string is one where CSRF prevention would be out of place. Most of them, though, are intermediate results in a user-specific interaction where CSRF prevention wouldn't break anything. There are a lot of web frameworks out there; some of them likely do CSRF prevention by default. From this article we can definitely conclude that Apple web sites are sloppy in 11 places, but there's not enough information to say there are 11 vulnerabilities.
  - justinschuh 15y ago
    I'm getting the impression you don't entirely understand how CSRF exploits and mitigations work. Things like CSRF cookies are intended to protect persistent state at the server. I don't think I've ever seen CSRF mitigations used to gate response output. And to be honest, it doesn't sound like a good strategy because it wouldn't necessarily protect the target from exploit. You're still likely to have other vectors of bypassing a CSRF protection used in such a manner.
    - brlewis 15y ago
      Your impression is entirely mistaken. I do entirely understand CSRF exploits and mitigations. I think what's happening is that when I write "not a demonstrated vulnerability" you (and others) are reading "a fine and dandy example of web programming". That's why phrases like "doesn't sound like a good strategy" keep popping up in your reply and others when I'm not talking about recommended strategy. When I wrote my first comment, this story was at the top of the front page. A story about 10 demonstrated vulnerabilities on Apple's web sites would belong there. A story about 2 demonstrated vulnerabilities and 8 instances of sloppiness that might be vulnerabilities but we don't know without more information -- that's not really a top-of-the-front-page story.
tripzilch 15y ago
(come on people, what's with all the downvotes? this is an interesting discussion! maybe the premise is incorrect but the answers are super informative) Hey brlewis, even though we haven't managed to (completely/reliably) crack your CSRF example YET ... I hope you agree that it's better to not have an XSS in the first place rather than rely on CSRF to make it (way) more difficult, right?
- brlewis 15y ago
  Agreed. The screenshots in the article show bugs that should be fixed whether or not they're currently exploitable. And they might even be currently exploitable...more info needed.

by brlewis 15y ago

jlongster 15y ago

You could "share" link with your own javascript embedded in it that reads cookies and sends them to your logging server. Or customize the website so that when somebody types their password, it sends it to your logging server. If you can run custom javascript on a page, it's a security problem.

brlewis 15y ago
That attack fails if the page prevents CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prev...
- jlongster 15y ago
  Not if the page simply a normal page that you would type in your URL. CSRF doesn't make sense there. I could send you a link to facebook.com with an embedded script.
  - brlewis 15y ago
    If the page accepts URL parameters or POST data, CSRF makes perfect sense.
    - judofyr 15y ago
      > If the page accepts URL parameters … CSRF makes perfect sense. No, it doesn't. CSRF makes perfect sense when there is data on the server that is being modified by a request. A simple "search.php?query=…" doesn't need CSRF protection. If you're passing parameters that modify the server in the URL (instead of a part of the post data) you're using HTTP wrong and adding CSRF protection in the query string is the wrong solution.
      - brlewis 15y ago
        You're right about the search example. That doubles the list of demonstrated vulnerabilities in this article from 1 to 2. I certainly agree that using GET for changing server state would be wrong. I don't know if any of the examples in the article work that way, since all we're provided with is a screenshot with an alert box. That's demonstrated sloppiness on Apple's web site, but not enough information to demonstrate vulnerability. (I'm definitely voting up your reply for intelligent discussion.)
- romaniv 15y ago
  Not necessarily. Typical CSRF implementations prevent the server from accepting inputs coming from an "unauthorized" page. This might or might not prevent XSS from being triggered on the client side. XSS can propagate to other users via database rather than HTTP requests. In general, you should prevent attacks in one-by-one manner. Hoping that one security mechanism will accidentally fix other issues will result in design that is insecure, convoluted and hard to reason about. Remember: you have to prevent all attacks. Attackers only need to find one vulnerability to attack. Therefore, any kind of complexity in design works to their advantage.
  - mike-cardwell 15y ago
    Exactly. Don't defend from XSS by implementing CSRF defences. Defend from XSS by making sure you properly encode every piece of data that enters your web page. Then add CSRF on top, to prevent third party sites from initiating "clicks" on your page. Then implement Content-Security-Policy to help defend against programmer mistakes which leave CSRF/XSS holes open.
  - brlewis 15y ago
    I agree that XSS can propagate to other users via database...I'm pretty sure the expresslane example is a real vulnerability for that reason. But note that the grandparent post was not describing an attack via the database. I am not hoping that CSRF prevention will make everything OK on the Apple website (which I have no affiliation with, by the way). Nor am I saying XSS prevention is not worthwhile. I'm merely pointing out that this blog post is not demonstrating 11 vulnerabilities in Apple's web site. There might actually be 11 vulnerabilities, but the blog post doesn't give enough information for us to know.
  - Joeri 15y ago
    Exactly, defense in depth is the name of the game. An example of a defense in depth strategy: Layer 1: Customer runs a WAF (web app firewall) to do some CSRF and XSS mitigation Layer 2: App contains its own intrusion detection system that preprocesses all requests for "typical" SQL injection, CSRF and XSS attacks and prevents the rest of the code from executing if this is the case. I'm using PHP-IDS for this. Layer 3: every request to the server must submit an anti-CSRF token and is immediately refused if it does not do so. Layer 4: Business logic contains its own positive input validation (all input must be in the expected format), and prevents the rest of the code from executing if the input is not valid. This is meant to prevent XSS and SQL injection when data enters the system. Layer 5: all DB requests use parameters instead of concatenating variables into queries to mitigate the risk of SQL injection. Layer 6: All output is encoded to prevent XSS attacks when data leaves the system. In such a solution you can have a security issue in one of the layers and still have a system that is secure.
dmitri1981 15y ago
It might sound trivial, but on many systems it can lead to serious privilege escalation and expose huge vulnerabilities further up in the chain. Check out the case study below for an example in real world. http://mobile.eweek.com/c/a/Security/Hackers-Hit-Apacheorg-Compromise-Passwords-896918/ http://mobile.eweek.com/c/a/Security/Hackers-Hit-Apacheorg-C... Also, if you want to learn more about avoiding these issues, OWASP is one of the best sources out there. https://www.owasp.org/index.php/Main_Page https://www.owasp.org/index.php/Main_Page

tripzilch 15y ago

If the arbitrary JS is specified by a specially crafted URL or form POST, you can make the JS execute in someone else's browser as easily as getting someone to click on a very innocent-looking link. And as soon as you can get someone to execute arbitrary JS on a particular domain, any CSRF protection will be useless because you practically control their browser. (You can even literally control their browser, if you use BeEF http://www.bindshell.net/tools/beef.html http://www.bindshell.net/tools/beef.html ) You can even completely hide the XSS happening by loading it into an invisible IFRAME, while the main page keeps the victim's attention occupied by playing the promised video of a cute kitten playing with a ball of string.

brlewis 15y ago
Both of those attacks fail if the page protects itself against CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prev...
- mike-cardwell 15y ago
  You can initiate an XSS attack without making any cross site requests. Being able to launch a CSRF attack, is not a prerequisite for being able to launch an XSS attack. It does help though.
  - brlewis 15y ago
    If I didn't know that, my original post would have said that all the Apple pages would be invulnerable if they prevented CSRF. I think the expresslane page is one where data could go in the database and others could see it. CSRF is not a prereq in general, but it is a prereq for the attacks tripzilch listed.
- oscardelben 15y ago
  A simple example: you can pass a link to someone and have some javascript that submits form for them without them knowing.
15y ago

justinschuh 15y ago

These screenshots show pretty textbook reflected XSS vulnerabilities, so I don't see why you think there's a CSRF vulnerability required for an exploit. Most of the targets are innocuous operations that aren't modifying any persistent state, so they wouldn't normally have CSRF protection. In particular, the search queries all appear to support direct-linking (notice the query string), which means they can't employ CSRF mitigations (because it would break the links).

brlewis 15y ago
Yes, the search query string is one where CSRF prevention would be out of place. Most of them, though, are intermediate results in a user-specific interaction where CSRF prevention wouldn't break anything. There are a lot of web frameworks out there; some of them likely do CSRF prevention by default. From this article we can definitely conclude that Apple web sites are sloppy in 11 places, but there's not enough information to say there are 11 vulnerabilities.
- justinschuh 15y ago
  I'm getting the impression you don't entirely understand how CSRF exploits and mitigations work. Things like CSRF cookies are intended to protect persistent state at the server. I don't think I've ever seen CSRF mitigations used to gate response output. And to be honest, it doesn't sound like a good strategy because it wouldn't necessarily protect the target from exploit. You're still likely to have other vectors of bypassing a CSRF protection used in such a manner.
  - brlewis 15y ago
    Your impression is entirely mistaken. I do entirely understand CSRF exploits and mitigations. I think what's happening is that when I write "not a demonstrated vulnerability" you (and others) are reading "a fine and dandy example of web programming". That's why phrases like "doesn't sound like a good strategy" keep popping up in your reply and others when I'm not talking about recommended strategy. When I wrote my first comment, this story was at the top of the front page. A story about 10 demonstrated vulnerabilities on Apple's web sites would belong there. A story about 2 demonstrated vulnerabilities and 8 instances of sloppiness that might be vulnerabilities but we don't know without more information -- that's not really a top-of-the-front-page story.

tripzilch 15y ago

(come on people, what's with all the downvotes? this is an interesting discussion! maybe the premise is incorrect but the answers are super informative) Hey brlewis, even though we haven't managed to (completely/reliably) crack your CSRF example YET ... I hope you agree that it's better to not have an XSS in the first place rather than rely on CSRF to make it (way) more difficult, right?

brlewis 15y ago
Agreed. The screenshots in the article show bugs that should be fixed whether or not they're currently exploitable. And they might even be currently exploitable...more info needed.