With all the nuances of XSS is it impossible to protect against?
This seems to me like the single biggest security hole because of the complexity involved in solving - and the fact that most web apps want rich text.
There are resources to help but it seems like it will never be 100%
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
…If you don’t want the cookie read by JavaScript, then don’t allow it.
HttpOnly has been supported for nearly a decade by IE6 and has been adopted by all the major browsers.
This is the typical response that is given for XSS “It’s your fault - you let nasty javascript run on your webpage”.
I agree - that is a problem.
But, Javascript simply shouldn’t be able to access cookie information that only the browser and server need to know.
If this were the case session hijacking via document.cookie wouldn’t occur.
Of course. Yes, HttpOnly, set that and your JS wont be able to access the cookies.
Supported browsers:
Because Site A’s owners allowed Site B’s owners to inject a cross site scripting attack into Site A. The browser doesn’t care where the scripts source is (on Site B), because Site A is telling the browser, its ok to go and fetch the script from Site B, and it trusts Site A.
The only solution to this from a browser point of view is to only load scripts whos url resolve to Site A. Which means you couldn’t use google ajax libraries, adsense code, amazon affiliate links etc etc.
The onus is on Site A to make sure they are not vulnerable to xss attacks.
I was hoping you could simply remove javascripts ability to access something that creates the security hole (cookies) but it doesn’t look like you can do it.
Receiving HTML input is not insecure. Sending the HTML to a browser is.
You should first clean the HTML before sending it back to the client.
Either encode the HTML, turning stuff like < into < etc.
Or scrub it with something like: http://htmlpurifier.org/
Cookies don’t create any security hole in JavaScript. JavaScript can no more access cookies from other sites than any server side processing can. In fact its access is more limited than server side code is since a page can include elements pulled from different sites where server side processing can access third party cookies relating to those sites whereas regardless of where the JavaScript comes from because it runs in the browser it can only access cookies for the site it is running on.
Cookies don’t create any security hole in JavaScript.
Once you’re logged in to an application that uses session to keep you logged in - if you post the cookie information to an external site they can use that same cookie to be logged in.
If that’s correct then Javascript allowing access to this cookie information created by the server is absolutey a security hole in Javascript.
You’re right, though encoding the HTML isn’t what I am after as I want the HTML to work as HTML on the page.
I’ll take a look under the hood of htmlpurifier.
Cheers,
Don’t allow script tags obviously. But also consider tags with src attributes including style rules with src
Just because a filename has a certain extension doesn’t mean that’s what kind of file it is.
The same applies to cookies created with any server side language as well (and you have to create a cookie to record that the person is logged in as otherwise you’d have to get them to log in to each page since a cookie is the ONLY way to maintain info between pages).
The security hole you are talking about is specific to the way cookies work and has nothing whatever to do with JavaScript (or PHP or .NET or whatever other language you are using to set the cookie with).
Anyway, if you use a session cookie instead of specifying an expiry date then the cookie is stored within the browser itself and isn’t written to a separate file and so can’t be sent anywhere.
The security issue you are talking about only exists for cookies that are intended to last for longer than the current browser session and therefore need to be stored in a separate file that can be read in the next time the person uses the browser. You should never store session data in such a cookie as te whole point of session data is that you keep it inside the browser where it will be automatically deleted at the browser end when the browser is closed.
So in fact your security hole only exists if you write your PHP or .NET or whatever so that it creates the wrong sort of cookie for the session. Of course if you use the appropriate session tools built into server side languages then the right sort of cookie will be created automatically. There is then no reason why your JavaScript would need to access the session cookie at all and even if it did copy the session cookie into another more permanent cookie the server would still expire the session after a couple of hours or so if the person hadn’t logged off by then and then the session data would be useless.
The only alternative to using a session cookie to control the logged in session is to store the session id in the querystring instead and there it is easy to copy and use from elsewhere.
I understand, what I’m questioning is why Javascript supports getting at this info in the first place.
Why is it not possible for Javascript only to access cookies that have been created by javascript - and cookies sent by the server are controlled by the browser but innaccessible to js?
You’ve lost me, but I don’t understand fully the security issue so bear with me… This is this scenario I’m considering - is it possible?
Before we shake our fingers at Site A’s owner for allowing document.cookie to be sent - Why should this data be accessible in the first place?
Good question. I don’t see where browsers should accept something like
<div style=“background-image: url(http://maldomain.com/mal.js);”>
and let it run either. Hopefully they won’t very soon.