6 ms·

But what if the person simply broke out of the <noscript_within> tag? <noscript_within><div id="comments"><div id="comment"></noscript_within><script src="myfi

But what if the person simply broke out of the <noscript_within> tag? <noscript_within><div id="comments"><div id="comment"></noscript_within><script src="myfile.js"></script></div></div></noscript_within> Probably the best method for this is giving the amount of characters are in the <noscript_within> tag. I don't believe this would break caching, as the length only changes when the content changes.

exit 16y ago
i suggested that (deleted comment), but it seems easy enough to at least scan for a closing "</noscript_within>" tag in the comment body.
- sounddust 16y ago
  Until someone writes </noscript_within > or < /noscript_within> and your script doesn't catch it but the browser accepts it. Or one of hundreds of other small details that neither one of us has thought of yet.
  - chime 16y ago
    That's why browser makers have to agree on the acceptable usage and suggest what web devs should search/for and sanitize. Right now, browser makers do not recommend anything except "sanitize your input" and that means something completely different for each browser.
- dasil003 16y ago
  it seems easy enough... Yes, every single XSS vulnerability is pretty easy to fix on its own. The problem is that you'll never get all of them across browsers. It's time that browser makers went back to the drawing board and came up with a base security model to cut the fat away from the basic attack footprint. Some drastic limit on the source of executable JS files, specified in an HTTP header, could be very effective.
  - chime 16y ago
    > It's time that browser makers went back to the drawing board and came up with a base security model to cut the fat away from the basic attack footprint. Some drastic limit on the source of executable JS files, specified in an HTTP header, could be very effective. Absolutely! I'm just surprised that so many people here are against any changes to the browsers while expecting that every single developer in the world ensure there's not one bug in their code. This isn't the same thing as PHP's safe_mode that never really worked as excepted. This is more like crossdomain.xml file. It is something browser makers can proactively do to improve security. Sure, web developers should keep sanitizing inputs as much as possible. And browsers should try to prevent XSS as much as possible. Why can't both work together? Why is it only the developers' problem?
    - seancron 16y ago
      I don't think people are against changes to the browsers. I think they just realize that there are many different browsers out there that each do things slightly differently. If you've ever tried to get CSS working for all possible browsers, you've probably come across cases where it works in some browsers, but not others (I'm looking at you IE6), and you have to use a hack to get it to work. Changes to browser standards occur at a much slower rate than changes to your code. Politics, competition, and disagreements on standards often get in the way. Just look at all the controversy over the HTML 5 video codec. Unless browser makers, by some miracle, agree on a common standard for browser security, there are always going to be little idiosyncrasies that occur from browser version to browser version. Just because it's secure in all the browsers you tested, doesn't mean that it's secure in the browsers you didn't test. The best solution as of right now is to develop ways of writing more secure code, with less potential for human error.

exit 16y ago

i suggested that (deleted comment), but it seems easy enough to at least scan for a closing "</noscript_within>" tag in the comment body.

sounddust 16y ago
Until someone writes </noscript_within > or < /noscript_within> and your script doesn't catch it but the browser accepts it. Or one of hundreds of other small details that neither one of us has thought of yet.
- chime 16y ago
  That's why browser makers have to agree on the acceptable usage and suggest what web devs should search/for and sanitize. Right now, browser makers do not recommend anything except "sanitize your input" and that means something completely different for each browser.
dasil003 16y ago
it seems easy enough... Yes, every single XSS vulnerability is pretty easy to fix on its own. The problem is that you'll never get all of them across browsers. It's time that browser makers went back to the drawing board and came up with a base security model to cut the fat away from the basic attack footprint. Some drastic limit on the source of executable JS files, specified in an HTTP header, could be very effective.
- chime 16y ago
  > It's time that browser makers went back to the drawing board and came up with a base security model to cut the fat away from the basic attack footprint. Some drastic limit on the source of executable JS files, specified in an HTTP header, could be very effective. Absolutely! I'm just surprised that so many people here are against any changes to the browsers while expecting that every single developer in the world ensure there's not one bug in their code. This isn't the same thing as PHP's safe_mode that never really worked as excepted. This is more like crossdomain.xml file. It is something browser makers can proactively do to improve security. Sure, web developers should keep sanitizing inputs as much as possible. And browsers should try to prevent XSS as much as possible. Why can't both work together? Why is it only the developers' problem?
  - seancron 16y ago
    I don't think people are against changes to the browsers. I think they just realize that there are many different browsers out there that each do things slightly differently. If you've ever tried to get CSS working for all possible browsers, you've probably come across cases where it works in some browsers, but not others (I'm looking at you IE6), and you have to use a hack to get it to work. Changes to browser standards occur at a much slower rate than changes to your code. Politics, competition, and disagreements on standards often get in the way. Just look at all the controversy over the HTML 5 video codec. Unless browser makers, by some miracle, agree on a common standard for browser security, there are always going to be little idiosyncrasies that occur from browser version to browser version. Just because it's secure in all the browsers you tested, doesn't mean that it's secure in the browsers you didn't test. The best solution as of right now is to develop ways of writing more secure code, with less potential for human error.