[owasp-intrinsic-security] HTML5 - Ideas for improvement

Arshan Dabirsiaghi arshan.dabirsiaghi at aspectsecurity.com
Tue Sep 16 09:57:48 EDT 2008


Wow, this is a long email. I'm sorry it's so long, but if you really want to help fix the web, which is the point of this group, then get a cup of coffee, give the kids some Benadryl, turn off American Idol and let's get started.
 
After going through my first pass of the HTML5 specifications in detail, I have to say that I'm surprisingly impressed with what I see. They've clearly started to think about security as a core principle. Unfortunately, they seem extremely focused on moving towards opt-in models of security, and I think this is a mistake for the upcoming Facebook/iGoogle generation of applications. The stakes are really high - and they're only getting higher.
 
I imagine we're only 2 years away from 'iLife' websites where you can manage your entire life through a single Internet web portal. I mean, wouldn't it be great if you could navigate to a single, SSL-enabled website where you could manage your bank accounts, send emails, track bills, read RSS, order food from your favorite restaurants, etc. Some of this stuff is possible right now with widgets, and as we all know that can be dangerous enough. Google will probably be doing all of these things plus holding my healthcare records before I turn 30.
 
Generally, more consolidation = bigger payoff = more value to attacker = more attackers = more attacks. They may be driving down the likelihood of issues with the increased security in the spec a bit, but they're raising the impact of a browser takeover significantly. Because of the imbalance between the impact and likelihood, the overall risk is going up. That being said though, the people in the WHATWG are now considering and attempting to prevent some problems that are caused when a site's security fails, not just problems that directly result from the spec. CSRF <img> attacks were not the fault of the spec because "non-idempotent GETs are the developers' fault." While true, it's kind of a cop out. People are going to make mistakes, and they should consider that as much as any other security driver. 
 
Unfortunately, that's where the big businesses want to go, so that's where they're going to go. The best we can do is try to help them build an infrastructure that's difficult to screw up in, and sandbox ourselves as much as possible so that in the event of a screw-up, the world doesn't end. With that spirit, here are the types of things we should be looking at regarding HTML5/XHR Level2/etc.:
 
1. Are there security design flaws inside the actual specification (oversights)?
2. Is there functionality that is too powerful to leave in the browser when considering the possibility of the users executing attacker-chosen JS (XSS)?
3. Could the API be more secure? Would another argument or less arguments to a function result in more security?
4. How could Function X be abused by a bot (bots, to me, are game changers)?
5. Could Function X be used to communicate in an unexpected way (to its own origin or others)?
 
I've got some random ideas on how to do some of some things in HTML5 a bit better, and I'll dump them here in a raw form, hoping that others on the list will help firm them up and contribute their own. We can and I will make our suggestions into an OWASP Wiki page, but I'll start here. I actually found very little wrong with the Access-Control specification - and I think that's probably in large part to the participation of Collin Jackson, an expert in our field.
 
 
Idea #1 - Improve specification with more stringent keywords (Access-Control specification)
 
The words 'may', 'should' and 'must' have very particular definitions when it comes to the specification (they are defined explicitly in RFC 2119). That's why this language makes me nervous:
 
> In particular, if a same origin request is redirected to a non same origin URL the specification should abort the request and either terminate 
> completely (as it did until now) or use the cross-site access request algorithm on the non same origin URL.
 
... or this:
 
> When making a cross-site access request, user agents should ensure to:
> Not reveal whether the requested resource exists, until access has been granted...
> Not inappropriately expose any trusted data of the response, such as cookies and HTTP header data. 
> Not allow the author to set cookies or authentication credentials for the request
 
This is a little thing, to be sure - but why not use the 'must' or 'must not' language here? When would cross-origin port scanning be acceptable?
 
Idea #2 - Allow passing of structured data in postMessage()
 
The postMessage API takes a string value from Site A and delivers it to Site B. Realistically, there are going to be many more situations where sites want to transfer structured data back and forth rather than simple strings. So, if a developer wants to pass structured data between two JavaScript pages, how might they do it? Obviously, they'll choose JSON. Therefore, what we've got is a situation where most of the people writing code for Site B are going to be running eval() on Site A's data, unvalidated. This is cross-origin XSS and can be used to bypass the same-origin policy as an attacker and gain access to Site B credentials when successfully attacking Site A.
 
Idea #3 - Programmatically Enforce Origin Checking in postMessage()
 
The postMessage API takes a string message from Site A and delivers it to Site B. In Site B's processing code, the developer is supposed to check from which origin it came from and validate that it came from a trusted origin. This is an error prone approach because it forces the developer to perform a security check that is not necessary to pass unit tests. 
 
Ideally, the user could bind a callback listener to an origin instead of programatically checking. The risk is if this origin-binding process is not required, the user will:

*	
	forget to put the check in entirely,
*	
	forget to strengthen the check after moving from a test environment (where the source origin is different from production),
*	
	make a mistake in the logic of the check

And otherwise make any other number of implementation mistakes. I think this is a more organized approach, as well as more secure.

Idea #4 - Remove globalStorage from Local Storage

I don't see the value-add here.

*	Hurts the privacy of the user
*	Urges developers to use it as a poor man's session
*	Enable global CSRF/XSS

There are many positive things to point out in the spec, too. I just wanted to highlight one:
 
Wildcard in Access-Control-Origin Allowed - But no ambient authentication for allow-all wildcards!
 
Let's consider the two scenarios where I imagine 2 parties would want cross-domain communication:
 
1. Site A wants its users to be able to access its partner Site B's data, while authenticated without proxying through Site A (think mashup).
2. Site A wants anyone and everyone to pull its data (think Yahoo! Weather widget).
 
I may not be very imaginative in coming up with these scenarios, but I can't think of a counterexample. It seems like Scenario #1 would be the only reason for XHR Level2/Access-Control because Scenario #2 is quite capable of being done with remote scripting/widgets. With that in mind, look at section 5.2, the access control resource check:
 
1. If the resource includes zero or more than one Access-Control-Allow-Origin <https://webmail.aspectsecurity.com/exchange/arshan.dabirsiaghi/Drafts/RE:%20[owasp-intrinsic-security]%20FW:%20New%20W3C%20access-control%20working%20draft.EML/1_text.htm#access-control-allow-origin-header>  headers return "fail" and terminate this algorithm.
2. If the Access-Control-Allow-Origin <https://webmail.aspectsecurity.com/exchange/arshan.dabirsiaghi/Drafts/RE:%20[owasp-intrinsic-security]%20FW:%20New%20W3C%20access-control%20working%20draft.EML/1_text.htm#access-control-allow-origin-header>  header value is the literal "*" character and the credentials flag <https://webmail.aspectsecurity.com/exchange/arshan.dabirsiaghi/Drafts/RE:%20[owasp-intrinsic-security]%20FW:%20New%20W3C%20access-control%20working%20draft.EML/1_text.htm#credentials>  is false return "pass" and terminate this algorithm.
 
So if the credentials flag is false and the Access-Control-Allow-Origin header is *, any origin is allowed to access your data. This seems safe to me, since no credentials are passed with the request, the user is essentially making an anonymous. If you want to enable Scenario #1, you can't wildcard everyone. Major security improvement if I understand this correctly.
 
 
This was only my first pass and these are the things that jumped out. I'm sure we can put together more. Give me a hand!
 
Cheers,
Arshan
 

________________________________

From: owasp-intrinsic-security-bounces at lists.owasp.org on behalf of Sebastien Deleersnyder
Sent: Sat 9/13/2008 3:11 PM
To: owasp-intrinsic-security at lists.owasp.org
Subject: [owasp-intrinsic-security] FW: New W3C access-control working draft



Hi

FYI:

  http://www.w3.org/TR/2008/WD-access-control-20080912/

Worth a review;

I undestand there'll be a last call working drafts ome time soon. 
So this is an excellent time to comment.

Regards

Seba

_______________________________________________
owasp-intrinsic-security mailing list
owasp-intrinsic-security at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-intrinsic-security


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-intrinsic-security/attachments/20080916/75b0d977/attachment.html 


More information about the owasp-intrinsic-security mailing list