Javascript security | Hacker News Reader

Javascript security

blog.jgc.org

16 pointstonyskn8 comments

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.

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

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-t...

  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. :-)

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.

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.

understood

I like how you mentioned frameworks like RoR that have XSRF prevention built in. Not enough security talks mention things like that.

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.

Reply on news.ycombinator.com