<script> tag referencing that contact list, and install some interceptor code that overloads setting e.g. the "email" property on any object: That enables the malicious code to see the values in the JSON.Here are a couple of their proposed measures:
1. "Add the session cookie to the request as a parameter." Knee-slapper, that. See, the exploit only works because vulnerable sites put your identity into the cookie, and use a single URL for all users to download the object; the server uses the cookie to send you your personalized contact list. So the attacker just has to hardcode
<script src="http://yoursite.com/contact-list">. The paper proposes uniquifying the URL. Here's an idea: design your app so that each user's info is at a unique URL in the first place!2. Send all legitimate requests for JSON data using HTTP POST! That way you know any GET requests are malicious ones from
<script> tags. They do concede that "The use of GET for better performance is encouraged by Web application experts from Sun and elsewhere". There's no use for this measure if you use unique URLS, of course.So yeah, this is a serious problem, but not for apps using best web architecture practices. Millions of web developers read papers like that and then crap all over the web.
3 comments:
Even with a user-specific URI, if the client (browser, xmlhttprequest, library, etc) sends along authentication information - either in the form of a cookie or Authentication header - then the data will be retrieved and readable.
Depending on the client/browser to not allow code from one domain to send messages to a different domain is a tricky thing - there has to be a better way, but I don't know what it is right now. I just hope I can figure it out before it's a problem with the code I've written at my new company.
Right -- but the attacker wouldn't know the user specific URI. The real hole is that the vulnerable sites use a single URL the attacker can know in advance.
> design your app so that each user's info is at a unique URL in the first place!
This discloses the user-specific token in a variety of ways that aren't usually the case with cookies - e.g. httpd/proxy log files, Referer headers, etc.
By all means, use a unique URI for users, but do it in combination with another token like a cookie, not instead of another token.
Post a Comment