19 ms·

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 s

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

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