Comments on: Script restrictions for mitigating XSS vulnerabilities http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/ Jesse Ruderman on Firefox, security, and more Fri, 09 Sep 2011 05:56:55 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Dominic Mitchell http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/comment-page-1/#comment-3810 Dominic Mitchell Tue, 07 Aug 2007 07:00:44 +0000 http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/#comment-3810 I always like the phrase “generating HTML”. If you're just chucking strings together, you're not generating HTML, you're generating security holes… I always like the phrase “generating HTML”. If you’re just chucking strings together, you’re not generating HTML, you’re generating security holes…

]]> By: Rob Sayre’s Mozilla Blog » Blog Archive » Interoperability and XSS Mitigation http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/comment-page-1/#comment-3806 Rob Sayre’s Mozilla Blog » Blog Archive » Interoperability and XSS Mitigation Mon, 06 Aug 2007 19:29:37 +0000 http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/#comment-3806 [...] lot people say this. Jesse is the latest. These days, there are some good libraries. There’s even one for PHP. But input [...] [...] lot people say this. Jesse is the latest. These days, there are some good libraries. There’s even one for PHP. But input [...]

]]> By: Robert Sayre http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/comment-page-1/#comment-3805 Robert Sayre Mon, 06 Aug 2007 13:47:09 +0000 http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/#comment-3805 I'm implementing it just to see what would happen. I'm not sure the proposal is a good idea either. I’m implementing it just to see what would happen. I’m not sure the proposal is a good idea either.

]]> By: Justin http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/comment-page-1/#comment-3801 Justin Mon, 06 Aug 2007 04:06:37 +0000 http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/#comment-3801 Personally I think Gerv has the right idea. I did a survey of XSS protections earlier this year and his proposal was the only one I found that addressed the issue as a combination of client and server responsibilities. I've also posted some thoughts on a broader approach that I'd been mulling over . Basically, I'm of the opinion that same-origin could use a bit of an upgrade. Of course, I completely agree with the benefits of pushing user-malleable data out-of-band. Plus, it's already a common practice in SQL via prepared statements and stored procedures. However, a few years ago I played around with building "safe" HTML entirely through server-side DOM manipulation. The result was clunky and had serious performance issues. Line-by-line HTML output ended up being a lot less resource-intensive than maintaining and manipulating a complete DOM tree in memory. I'm sure that my HTML generation issues could be mostly addressed by developing a good toolkit, but that's still only a partial solution. It doesn't matter if it's a stack frame or HTML, it's best to plan for potential overlap of user-data and application metadata. So, I'm all for a more robust form of HTML generation, but I'd also like to see some defense-in-depth against the range of origin-related vulnerabilities (like CSRF). Regardless, it's nice to see forward progress in this area. I'm not working on web app security these days, but I'm glad to see things moving forward. Personally I think Gerv has the right idea. I did a survey of XSS protections earlier this year and his proposal was the only one I found that addressed the issue as a combination of client and server responsibilities. I’ve also posted some thoughts on a broader approach that I’d been mulling over . Basically, I’m of the opinion that same-origin could use a bit of an upgrade.

Of course, I completely agree with the benefits of pushing user-malleable data out-of-band. Plus, it’s already a common practice in SQL via prepared statements and stored procedures. However, a few years ago I played around with building “safe” HTML entirely through server-side DOM manipulation. The result was clunky and had serious performance issues. Line-by-line HTML output ended up being a lot less resource-intensive than maintaining and manipulating a complete DOM tree in memory.

I’m sure that my HTML generation issues could be mostly addressed by developing a good toolkit, but that’s still only a partial solution. It doesn’t matter if it’s a stack frame or HTML, it’s best to plan for potential overlap of user-data and application metadata. So, I’m all for a more robust form of HTML generation, but I’d also like to see some defense-in-depth against the range of origin-related vulnerabilities (like CSRF).

Regardless, it’s nice to see forward progress in this area. I’m not working on web app security these days, but I’m glad to see things moving forward.

]]>