In other words, what are the most-used techniques to sanitize input and/or output nowadays? What do people in industrial (or even just personal-use) websites use to combat the problem?
... with html entity (he can encode it in base 64 :) )
remi bourgarel
2010-07-02 13:58:59
@remi - are you serious?
orokusaki
2010-07-04 16:36:27
@orokusaki [You never know :)](http://www.recursion.com/interpolique.html)
Sidnicious
2010-08-31 19:21:55
A:
If you are developing in .NET one of the most effective ways to avoid XSS is to use the Microsoft AntiXSS Library. It's a very effective way to sanitize your input.
backslash17
2010-06-28 03:48:06
A:
In JSTL/JSP the best way to protect against XSS is to use the c:out tag without setting the default escapeXml parameter equal to false.
<c:out value="${somePossiblyDangerousVar}"/>
BuckWild
2010-08-30 02:55:00
A:
There are only two major areas in your code which need to be addressed properly to avoid xss issues.
before using any user input value in queries, use the database helper functions like mysql_escape_string over the data and then use it in query. It will gurantee xss safety.
before displaying user input values back into form input fields, pass them through htmlspecialchars or htmlentities. This will convert all xss prone values into characters that the browser can display without being compromised.
Once you have done the above, you are more than 95% safe from xss attacks. Then you can go on and learn advanced techniques from security websites and apply additional security on your site.
What most frameworks do is that they discourage you to directly write html form code or do queries in string form, so that using the framework helper functions your code remains clean, while any serious problem can be addressed quickly by just updating one or two lines of code in the framework. You can simply write a little library of your own with common functions and reuse them in all your projects.
Samnan
2010-08-31 12:31:25
to be clear, when you're dealing with data going to the database, you're talking SQL injection, not cross site scripting. Also, per http://php.net/manual/en/function.mysql-escape-string.php, this function is deprecated (since it ignores the charset, and may be vulnerable to charset encoding filter evasion techniques), so mysql_real_escape_string() should be used. Of course, with PHP, there's more that needs to be done, too: http://php.net/manual/en/security.database.sql-injection.php
atk
2010-09-01 02:11:06
A:
A client's company had a security audit for its website, stripping these tags from user input prevented XSS tests from red flagging.
array('<','>',"'",'(',')','\\','"','-','script'); // edit: Limited use, pls disregard.
Added: Pádraic Brady has an article about this just 2 days ago, HTML Sanitisation: The Devil's In The Details (And The Vulnerabilities)
doingsitups
2010-09-01 01:40:13
This list does not work in all contexts, such as html tag attributes are not quoted (space becomes dangerous), or when script is split with a newline or unprintable 0-width character (such as BOM, IIRC). Also, this encourages a blacklisting approach, assuming that we can come up with everything that's dangerous, and a mistake (or enhancement to what web browsers interpret) results in a security vulnerability. Furthermore, what if those characters are really needed? Like what about the name "O'Malley" - it's inappropriate to modify the input. Output encoding is a far better solution.
atk
2010-09-01 02:14:37
you are right, this is not a good way, we did this just to get past the audit, we only had login and search field on that website.
doingsitups
2010-09-01 08:06:06
even. just to get past an audit, it's a bad idea. the client and the client's customers are now using p(likely) vulnerable software for a vulnerability they spicifi ally do not want, as evidenced by hhe audit. Your copmany made a risk decision on behalf o fyour customer instead of properly fixing the probel, whiich could create liabilty for yor company. not a wise decision.
atk
2010-09-01 12:59:24
You make it sound like it doesn't work, it does, we don't save what customer's type in, and we no longer use GET to propagate error messages, so I actually don't quite understand why those are vectors for attack, this is probably ignorant of me, but doesn't XSS require someway to propagete to another user? In anycase, thanks to this thread, I am more aware of the importance of keeping safe from XSS.
doingsitups
2010-09-01 14:53:59
It works for certain circumstances and it doesn't work for other circumstances. And errors result in vulnerabilities. There's a whole class of research called filter evasion, which makes blacklisting even more risky. And yes, for XSS to be valuable, it has to target another user, but it doesn't have to be stored, and it doesn't have to be error messages. It simply has to be in the page. Take a look at http://www.cgisecurity.com/xss-faq.html and owasp.org and ha.ckers.org and sla.ckers.org for more details if you want to do some interesting reading.
atk
2010-09-02 18:19:31