Hi,
I'm hoping some security gurus can help me out here.
I'm creating a site where the users must be able to completely customize their site with html, javascript, and css. That's a lot to ask, security-wise.
First off, giving each user their own subdomain isn't feasible. I do have an SSL certificate for this domain, however. Thus, my current security method is to force all important authenticating or authentication-required pages to be accessed via the SSL link. All customizable pages are required to be viewed on non-secured links.
When they signin, I set two cookies:
- MAC'd preferences cookie (basically username and timezone)
- MAC'd session SSL-only cookie
Any javascript on a site can only access the MAC'd preferences cookie*. If some javascript messes with it, then it is reset the next time the cookie owner visits a secured page. If the javascript steals the cookie, then all the hacker has is a preferences cookie and can't do much of anything.
Assuming all output on the SSL'd pages is very carefully filtered and escaped, is there anything that can go wrong with this setup? Can they do anything else with javascript that I should be worried about (or that they couldn't do if they weren't on the same domain)?
- Nathaniel
*Tested on FF 1.5 and IE6
XSS vulnerabilities besides cookie stealing
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
That's a very novel solution to the problem. Of course, the user can still hang a browser with an infinite loop alert, but I believe that as long as all browsers observe the ssl only cookie parameter correctly, there shouldn't be any cookie stealing going on.
However... make sure that JavaScript can't use XMLHttpRequest to make the client perform a request for a secure page. Also, watch for bugs in browsers in the implementation of the Same-Origin Policy (it should cover protocols too, but you never know)
It's interesting. I'd like to know how it turns out.
However... make sure that JavaScript can't use XMLHttpRequest to make the client perform a request for a secure page. Also, watch for bugs in browsers in the implementation of the Same-Origin Policy (it should cover protocols too, but you never know)
It's interesting. I'd like to know how it turns out.
ThanksAmbush Commander wrote:That's a very novel solution to the problem.
I'm not too worried about them hanging the browser; it'd be a pain for some users, but it isn't all that different from someone linking to a page that crashes a browser, and I could do that from this very post.Ambush Commander wrote:Of course, the user can still hang a browser with an infinite loop alert, but I believe that as long as all browsers observe the ssl only cookie parameter correctly, there shouldn't be any cookie stealing going on.
I'm not sure what I'll do if a certain browser doesn't observe the ssl only parameter correctly. I'll cross that bridge when I come to it.
Ah, yes. I hadn't considered XMLHttpRequest. Still, that's a lot easier to strip out than every possible bit of javascript.Ambush Commander wrote:However... make sure that JavaScript can't use XMLHttpRequest to make the client perform a request for a secure page. Also, watch for bugs in browsers in the implementation of the Same-Origin Policy (it should cover protocols too, but you never know)
Thanks for the once-over!
- Nathaniel