News for hackers. Stuff that matters.
Re:Ask HN: Testing your site for XSS exploits by planck on Thursday August 13, 2009 @06:00PM (#761792)
Assume all data entered by users is malicious and encode it properly on display. That's really all there is to it.
Re:Ask HN: Testing your site for XSS exploits by pwmanagerdied on Thursday August 13, 2009 @06:08PM (#761804)
Amen to that.

Everyone overcomplicated the issue, it's not a difficult issue to solve: whenever untrusted data is to be displayed to a user, escape it. Problem solved.

Re:Ask HN: Testing your site for XSS exploits by lhorie on Thursday August 13, 2009 @09:37PM (#762166)
Tools like Paros http://www.parosproxy.org/index.shtml will spider/scan for some common attack patterns.

It's also definitely nice to have a dedicated qa person (preferably someone familiar with the code) trying to break your site, both manually and with tools like Selenium http://seleniumhq.org/

Re:Ask HN: Testing your site for XSS exploits by tonystubblebine on Thursday August 13, 2009 @05:00PM (#761681)
For people using Rails, sanitize all input before it goes in. Here's a library for web params. http://code.google.com/p/sanitizeparams/
Re:Ask HN: Testing your site for XSS exploits by there on Thursday August 13, 2009 @05:33PM (#761740)
so when some new technique comes out down the road that your input filtering didn't catch, are you going to update everything in your database? and what about data that gets in from other sources?

i don't see the benefit in filtering input; html and alert()'s inside a database don't affect anything until they come back out.

Re:Ask HN: Testing your site for XSS exploits by tonystubblebine on Sunday August 16, 2009 @09:01PM (#767114)
The benefit to filtering input is that it is less error prone for programmers. The filter on output method that most Rails programmers use involves setting it up on an output-by-output method. I like the input technique because it only needs to be configured once.

I think the risk of new techniques getting by this filter are low (although the risk of the filter having bugs is high, as judged by the number of bugs that popup in more critical software). In XSS there are only a limited set of attack vectors (iframe, javascript, flash), and those get filtered completely. The underlying filter is based on whitelisting, so it's not like new additions to the HTML spec are going to open security holes before we have a chance to close them (it's the opposite, new, safe HTML additions will need to be explicitly allowed before they can be used).

Re:Ask HN: Testing your site for XSS exploits by mbrubeck on Thursday August 13, 2009 @07:36PM (#761997)
Also, proper sanitization is different for HTML, JavaScript, SQL, URIs, and other contexts.
Re:Ask HN: Testing your site for XSS exploits by tonystubblebine on Sunday August 16, 2009 @09:02PM (#767117)
The question is specifically about XSS, so the context is by definition HTML and Javascript.
Re:Ask HN: Testing your site for XSS exploits by yan on Thursday August 13, 2009 @04:22PM (#761620)
I would pay someone like me to assess your code and pentest your site :)

If you're planning on doing this yourself, OWASP (www.owasp.org) is a great resource.