4 ms·

Javascript security

16 points by tonyskn 16y ago

DjDarkman 16y ago
The global scope thing is not entierly true, you can use closures to minimize the global scope usage. The problem is not that bad: - on the server side, always sanitize user input - only put script tags from places you trust
joubert 16y ago
I think it would be better to not conflate language and runtime issues. For example, one can improve language misfeatures such as semicolon insertion, lack of built-in name pacing, etc. Even when you improved this, you would still want to improve the (browser + DOM) architecture/runtime, but in many cases these are orthogonal concerns.
jgrahamc 16y ago
Since this old presentation of mine has resurfaced (first on Reddit and now here), here's the comment I made on Reddit: A good companion to this presentation is Douglas Crockford's presentation on JavaScript security: http://javascript.crockford.com/security.ppt (Warning: PowerPoint). He makes similar points about the security of JavaScript and comes up with a different solution. He proposes doing away with most of JavaScript and allowing only a safe-subset of the language to be used." As a follow-up I had proposed signing of <SCRIPT> tags: http://blog.jgc.org/2009/09/solving-xss-problem-by-signing-tags.html http://blog.jgc.org/2009/09/solving-xss-problem-by-signing-t...
- mfukar 16y ago
  He proposes doing away with most of JavaScript and allowing only a safe-subset of the language to be used. If only there was such a thing. :-)
- va_coder 16y ago
  Do you work on projects as a programmer where the project has rich ui requirements and tight deadlines? I ask this because your advice not to use Javascript is, to me, completely unrealistic.
  - jgrahamc 16y ago
    Yes, I manage a team of guys doing just that. And there's no avoiding JavaScript today. This was a presentation at a security conference.
    - va_coder 16y ago
      understood I like how you mentioned frameworks like RoR that have XSRF prevention built in. Not enough security talks mention things like that.
- dredge 16y ago
  I'd not seen this presentation before, but was just pleasantly surprised when I saw my own screenshots on slide 15! Interestingly, while Twitter instantly suspended the account I used to demonstrate that, it was many months later that they removed the application I'd registered, until then it was possible to inject (the same) JavaScript by authorising that application to another account. It's entirely possible that someone was abusing the issue, long after that post was written.

16 points by tonyskn 16y ago

The global scope thing is not entierly true, you can use closures to minimize the global scope usage. The problem is not that bad: - on the server side, always sanitize user input - only put script tags from places you trust

joubert 16y ago

I think it would be better to not conflate language and runtime issues. For example, one can improve language misfeatures such as semicolon insertion, lack of built-in name pacing, etc. Even when you improved this, you would still want to improve the (browser + DOM) architecture/runtime, but in many cases these are orthogonal concerns.

jgrahamc 16y ago

Since this old presentation of mine has resurfaced (first on Reddit and now here), here's the comment I made on Reddit: A good companion to this presentation is Douglas Crockford's presentation on JavaScript security: http://javascript.crockford.com/security.ppt (Warning: PowerPoint). He makes similar points about the security of JavaScript and comes up with a different solution. He proposes doing away with most of JavaScript and allowing only a safe-subset of the language to be used." As a follow-up I had proposed signing of <SCRIPT> tags: http://blog.jgc.org/2009/09/solving-xss-problem-by-signing-tags.html http://blog.jgc.org/2009/09/solving-xss-problem-by-signing-t...

mfukar 16y ago
He proposes doing away with most of JavaScript and allowing only a safe-subset of the language to be used. If only there was such a thing. :-)
va_coder 16y ago
Do you work on projects as a programmer where the project has rich ui requirements and tight deadlines? I ask this because your advice not to use Javascript is, to me, completely unrealistic.
- jgrahamc 16y ago
  Yes, I manage a team of guys doing just that. And there's no avoiding JavaScript today. This was a presentation at a security conference.
  - va_coder 16y ago
    understood I like how you mentioned frameworks like RoR that have XSRF prevention built in. Not enough security talks mention things like that.
dredge 16y ago
I'd not seen this presentation before, but was just pleasantly surprised when I saw my own screenshots on slide 15! Interestingly, while Twitter instantly suspended the account I used to demonstrate that, it was many months later that they removed the application I'd registered, until then it was possible to inject (the same) JavaScript by authorising that application to another account. It's entirely possible that someone was abusing the issue, long after that post was written.