11–20 of 61 posts
Looking at the patch, it appears that their "check for UTF-8" function wasn't perfect. Is this correct? If so, how is this exploitable?
Earlier quoted context omitted.
That's because Microsoft is good at anything that they throw resources at. Unfortunately, we haven't thrown enough resources at determining what to throw resources at.
Well, good enough at least. ;-) Honestly the AV was a good move. Give stuff like that away for free for long enough and the public perception of Microsoft and security may change.
You found a security exploit, feel special. Finding an exploit isn't a voucher to rant against the people responsible for it. The bottom line is that nobody can be 100% sure that their data is secure after they've put it in the hands of a third party.
I think my point was a lot more nuanced than you give it credit for.
"Web application security is still an immature field, and many of the layers are sufficiently poorly designed that issues like this will pop up for a good long while. Just like buffer overflows have been a weak spot for C security as long as the Internet has been around, escaping issues will continue to be a weak spot for web security for as long as we're afflicted with this particular architecture."
It seems like a field not only in its infancy but also oddly unglamorous and under-reported. There's no repository (that I know of, at least) of vulnerability reports of major web apps, for instance, yet it's easy to look up an exhaustive history of Flash vulnerabilities down to the seventeenth decimal sub-version. And yet the various XSS/CSRF/etc vulnerabilities are easily as dangerous and as exploitable. Twitter's dreams of a billion users and a new internet were not exposed by a buffer overflow, after all.
I read through the code, but I don't really know Ruby that well, so I'm not 100% sure of what the exploit was. Looking at the patch, it appears that their "check for UTF-8" function wasn't perfect. Is this correct? If so, how is this exploitable?
I read through the code, but I don't really know Ruby that well, so I'm not 100% sure of what the exploit was. Looking at the patch, it appears that their "check for UTF-8" function wasn't perfect. Is this correct? If so, how is this exploitable?
As I understand it, Rails' string escaping would treat an invalid byte sequence (eg, 0xFF, 0x1C) as a single multi-byte code point, and thus not filter it, even though 0x1C (which is ' The browser, however, would correctly treat 0xFF as an invalid initial byte, and then interpret the next character point, 0x1C (' So, you could pass arbitrary characters through Rails' string escape functions by prepending an initial i…
Earlier quoted context omitted.
I think my point was a lot more nuanced than you give it credit for.
There's an interesting tangent towards the end - "Web application security is still an immature field, and many of the layers are sufficiently poorly designed that issues like this will pop up for a good long while. Just like buffer overflows have been a weak spot for C security as long as the Internet has been around, escaping issues will continue to be a weak spot for web security for as long as we're afflicted wit…
Earlier quoted context omitted.
There's an interesting tangent towards the end - "Web application security is still an immature field, and many of the layers are sufficiently poorly designed that issues like this will pop up for a good long while. Just like buffer overflows have been a weak spot for C security as long as the Internet has been around, escaping issues will continue to be a weak spot for web security for as long as we're afflicted wit…
I think you're probably wrong about that; more security practitioners are familiar with OWASP than with any other security advocacy/advisory group.
This is hard to defend, guys.
It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them.
If you're selling accounts on a web app, you need:
* A security page * With a PGP key * And an email contact * of someone who will write back * who knows what a security vulnerability is * and who will write back quickly.
That's it. Do that, and you're not a punch line. If someone dumps zero-day about you onto Twitter, you're already two steps ahead in the PR war, because you had a reasonable process, and the researcher ignored it.
Bonus points --- things that are trivial to do, but that nobody's even asking you to do:
* You can assign special issue numbers to vulnerabilities, to make the researcher feel like an XSS disclosure isn't the same thing as a bug in your online help.
* You can thank researchers privately, and let them know that you'd really like them to keep disclosing thing to you --- you could even give them (wait for it) a phone number.
* You can do what every vendor with a real security team does, and keep a public web page thanking people who have discreetly disclosed vulnerabilities to you.
For all the horrible, terrible, awful things about Internet Explorer (namingly: standards support and UI) ... they are innovating heavily in security: http://www.microsoft.com/windows/internet-explorer/features/...
Microsoft is actually decent at security now. The AV they released for free was actually on par with a few commercial products out there (all AV at the moment is pretty bad though, if you're curious). The really difficulty with Microsoft and security is countering their reputation for bad security that they earned over the past several years.
Can someone help to compile a good security policy and guideline for web apps? I guess every web app should have a page dedicated to security similar to privacy policy and terms of service. What are the essential information should go there? Special email dedicated to report security issues? PGP key to encrypt emails? and What else?
Perl's Taint Mode enforces this automatically. Don't know if any other languages have it? http://www.webreference.com/programming/perl/taint/