5 ms·
Wow, this attack was XSS 101. And it could have been mitigated with anti-XSS 101: rejecting all form posts containing angle-brackets.
by strommen 10y ago
Wow, this attack was XSS 101.
And it could have been mitigated with anti-XSS 101: rejecting all form posts containing angle-brackets.
- moloch 10y agoThis is insufficient to prevent XSS, or DMI -the de facto anti-XSS is contextual (generally HTML) encoding, and it is the only proper mitigation. Blacklisting specific characters such as angle brackets is not safe, and will end in tears.
- strommen 10y agoYes, blacklisting is insufficient in general. But it covers many cases, including the one here. Contextual encoding must be done each and every place you emit user input into HTML, and it's easy to screw this up. Character blacklisting provides an extra layer of protection. Unless you're intending for your user to post HTML, or math inequalities, or diff patches - there's no reason to allow angle brackets on a form post.
- alisey 10y ago> But it covers many cases, including the one here. In my experience, it doesn't even cover cases such as this one, but it certainly makes developers confident they don't need to apply contextual escaping.
- moloch 10y ago> Yes, blacklisting is insufficient in general. But it covers many cases, including the one here. Contextual encoding must be done each and every place you emit user input into HTML, and it's easy to screw this up. Blacklists are only acceptable if you do it in addition to contextual encoding wherever you emit user controlled data, and even then a much stronger protection would be to whitelist acceptable characters. Either way, contextual encoding whenever you emit user data is the only real protection. --And even then it's not a good fallback protection, a strong Content-Security-Policy should be your fallback protection. > Unless you're intending for your user to post HTML, or math inequalities, or diff patches - there's no reason to allow angle brackets on a form post. Form posts are not the only vector for XSS, any HTTP request can be potentially exploited to perform XSS (and any part of an HTTP request), doesn't matter if it's a Form, an AJAX request, an HTTP header value, or a GET parameter, they're all potential attack vectors.
- bennofs 10y agoWhy is blacklisting not safe, assuming you contextually blacklist?
- strommen 10y agoRead this: https://stackoverflow.com/questions/5696244/is-escaping-and-sufficient-to-block-xss-attacks https://stackoverflow.com/questions/5696244/is-escaping-and-...
- moloch 10y agoThere are a huge number of contextual corner cases, this cheat sheet lists just a few: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She...
- tedunangst 10y agoI don't understand what that page is trying to tell me. What is the "filter" that <body onload=alert()> evades?
- greglindahl 10y agoProgramming like that leads to websites where using single quotes in a form gets a mysterious error. (They were trying to stop SQL injection in the most user-unfriendly way possible.)
- tptacek 10y agoIt's a stretch to say that an attack based on lcamtuf's "Postcards From A Post-XSS World" is "XSS 101". It's "XSS 201" at least. And "rejecting all form POSTs containing angle brackets" is definitely not the XSS 101 prevention mechanism! Don't do that.
- wglb 10y agoUm, no.