As a blanket approach to dealing with XSS attacks, rather than having to remember to escape user-generated code, is there a way to instruct the browser not to execute any script or script-function which isn't signed with a particular public key (embedded in the top of every page, but not necessarily authenticated. This is only meant for dealing with XSS, not man-in-the-middle)? Then you could just sign all the "real" scripts


This would be a real hit to performance. Imagine you have a ton of embedded functions within your HTML page. Each would need to be signed seperately. Furthermore your server side code needs to be able to access your keystore to sign the code as often pages are generated dynamically. This would mean a substantial overhead to be dealt with.

Also note that JavaScript executing user input, which contains JavaScript will be hard to handle.

For instance let's say you have XSS on a user parameter which is embedded back into the page by a JavaScript function, your server will actually sign it before sending as it will not know that that part of the code isn't legitimate... and then we are back at the old problem of input/output validation.

Anyway most of this can be fixed with CSP anyway.

| improve this answer | |
  • Yes, I see it's a performance hit for browsers, but not for the server. You sign the code ahead of time (as a "compilation" step), not dynamically. If you sign dynamically generated code, then that defeats the whole purpose (since dynamically generated code can contain user input). – dspyz Mar 9 '14 at 20:13
  • How many sites do you know that are worth performing XSS attacks on that aren't dynamically generated? – Lucas Kauffman Mar 9 '14 at 20:13
  • Well, the page could still have dynamically generated components, but those components would be unsigned. The unsigned parts are allowed to contain data, but not instructions/code/scripts of any kind. The point is, if the programmer forgets to do something or does it wrong, it will cause the script to simply fail to run (rather than run untrusted code). – dspyz Mar 9 '14 at 20:18
  • Once you've got the data separated it's pretty easy to go the whole hog and use CSP to enforce no in-page script at all. It's the separation step (avoiding inline event handlers, eval et al) that is the difficult bit. – bobince Mar 10 '14 at 17:32
  • Also if a signature is valid across the whole site, which presumably it would have to be if it's not dynamic, then an attacker could take a signed script block and inject it into a different victim page where it might have a negative effect. It just means the attacker has to inject larger building blocks than single lines of code. You could make the building blocks large and with well-defined interfaces, enough to be safe in any page, but then again, you've just done the separation job there and you could put them in external script files with CSP. – bobince Mar 10 '14 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.