Hacker News Reader

Comment by jlongster | Hacker News Reader

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.

View on HN

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-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

That attack fails if the page prevents CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prev...

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.

If the page accepts URL parameters or POST data, CSRF makes perfect sense.

> 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.

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.)

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.

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.

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.

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.

Reply on news.ycombinator.com