Argh, this is at least the second XSS vulnerability that’s been found in Skype in the last few months.
> skype.com has to validate the input characters and sanitize the output
I don’t like this solution. It mostly works for the phone number field, but not for other fields. (I want my status to be “<script>alert('XSS!')</script>”, damnit!)
The right solution is to make sure that when data gets inserted into code, it’s encoded. If you’re inserting text into an HTML document, run it through an HTML encoder. If you’re inserting text into an SQL statement, run it through an SQL encoder.
Or, use something that distinguishes between code and data, like an HTML templating system or parametrized queries.
I think that's what Sidnic meant by templating -- that you have precisely one well tested encoding step in the system, near the end. This reduces the number of failure modes you need to test for.
In a previous project, we didn't even have an effective means of counting all the potential points of failure; you really don't want that, because it takes a lot of effort to fix.
Sometimes templating isn't an option, or isn't enough. You have to make sure you escape in the right context.
I've seen developers use PHP's htmlspecialchars() (or hand-rolled versions thereof) when rendering snippets of inline JavaScript. The problem is that only HTML entity encodes <, >, &, ', and ", which still leaves you open to XSS because it doesn't encode all the characters that can be exploited in a JavaScript context.
Following the OWASP guidelines will negate all of that danger.
7 comments
[ 3.9 ms ] story [ 23.3 ms ] threadhttps://twitter.com/#!/noptrix/status/91910866538217472
And the HN discussions about the previous vulnerability: http://news.ycombinator.com/item?id=2522466 and http://news.ycombinator.com/item?id=2522453
I don't use Skype, and I'm no fan of Microsoft, but this security advisory is just shameless (and harmful) self promotion.
> skype.com has to validate the input characters and sanitize the output
I don’t like this solution. It mostly works for the phone number field, but not for other fields. (I want my status to be “<script>alert('XSS!')</script>”, damnit!)
The right solution is to make sure that when data gets inserted into code, it’s encoded. If you’re inserting text into an HTML document, run it through an HTML encoder. If you’re inserting text into an SQL statement, run it through an SQL encoder.
Or, use something that distinguishes between code and data, like an HTML templating system or parametrized queries.
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_P...
In a previous project, we didn't even have an effective means of counting all the potential points of failure; you really don't want that, because it takes a lot of effort to fix.
I've seen developers use PHP's htmlspecialchars() (or hand-rolled versions thereof) when rendering snippets of inline JavaScript. The problem is that only HTML entity encodes <, >, &, ', and ", which still leaves you open to XSS because it doesn't encode all the characters that can be exploited in a JavaScript context.
Following the OWASP guidelines will negate all of that danger.