21–30 of 61 posts
We really need something like a "" block, where anything inside could never use JavaScript (including links that are to javascript: URLs). This would make life a lot easier for web developers.
I think what we've really learned from this is that the current JavaScript security model is not good for what people are using the web for these days. We really need something like a " " block, where anything inside could never use JavaScript (including links that are to javascript: URLs). This would make life a lot easier for web developers.
What we need is literal separation of control statements (eg, ) from content such that neither can be easily misinterpreted, but that would be a significant departure from existing design.
I think what we've really learned from this is that the current JavaScript security model is not good for what people are using the web for these days. We really need something like a " " block, where anything inside could never use JavaScript (including links that are to javascript: URLs). This would make life a lot easier for web developers.
Then XSS attacks would insert before =) What we need is literal separation of control statements (eg, ) from content such that neither can be easily misinterpreted, but that would be a significant departure from existing design.
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?
Don't trust any data that comes from outside your app (urls, querystrings, http request headers, databases, files) and you'll be right. Perl's Taint Mode enforces this automatically. Don't know if any other languages have it? http://www.webreference.com/programming/perl/taint/
Basically, web browsers need taint mode. The programming language that produces the web page is a whole other issue.
Earlier quoted context omitted.
Then XSS attacks would insert before =) What we need is literal separation of control statements (eg, ) from content such that neither can be easily misinterpreted, but that would be a significant departure from existing design.
That shouldn't work for the same reason that you can't escape a bound SQL query parameter in a pre-parsed query.
The real analogue to SQL query parameter binding would be an output format that keeps the two distinct.
Earlier quoted context omitted.
That shouldn't work for the same reason that you can't escape a bound SQL query parameter in a pre-parsed query.
That would require escaping the HTML on the server prior to output, which is exactly what we already have (and regularly fails, even when people think they're doing it right). The real analogue to SQL query parameter binding would be an output format that keeps the two distinct.
It's kind of a moot point since it will never happen, but it's not rocket science.
I'm usually the first person here to jump to 37s' defense. I know some of their people, they're hometown heroes, and I use and like their products. 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 s…
I never used to have travel insurance but after my first intercontinental flight my suite-case broke and I learned the importance of having one.
In a perfect world your support team would be able to distinguish between someone rambling about bytes and an actual security issue. That's hard without a lot of technical knowledge.
I believe that's why the Rails security team responded rather quickly and 37 Signals support team didn't. I'm sure they will do better in the future.
I think what we've really learned from this is that the current JavaScript security model is not good for what people are using the web for these days. We really need something like a " " block, where anything inside could never use JavaScript (including links that are to javascript: URLs). This would make life a lot easier for web developers.
I think what we've really learned from this is that the current JavaScript security model is not good for what people are using the web for these days. We really need something like a " " block, where anything inside could never use JavaScript (including links that are to javascript: URLs). This would make life a lot easier for web developers.
I'm usually the first person here to jump to 37s' defense. I know some of their people, they're hometown heroes, and I use and like their products. 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 s…
Actually it's pretty easy to defend. I never used to have travel insurance but after my first intercontinental flight my suite-case broke and I learned the importance of having one. In a perfect world your support team would be able to distinguish between someone rambling about bytes and an actual security issue. That's hard without a lot of technical knowledge. I believe that's why the Rails security team responded…