Javascript encoding does not follow the recommendations of the OWASP XSS Prevention Cheat Sheet
rshanlever opened this issue · 6 comments
From: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
"RULE 3 - JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
...
Except for alphanumeric characters, escape all characters less than 256 with the \xHH format to prevent switching out of the data value into the script context or into another attribute. DO NOT use any escaping shortcuts like " because the quote character may be matched by the HTML attribute parser which runs first. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends " and the vulnerable code turns that into \" which enables the quote."
I had some developers using the older ESAPI Encoder and some using this project and noticed the following difference:
import org.owasp.esapi.ESAPI;
import org.owasp.encoder.Encode;
public class EncoderTest {
public static void main(String[] args) {
String testString = "--></script><script src=//58348 id=\"";
System.out.println("Testing ESAPI encoder enccodeForJavaScript with " + testString);
System.out.println("OUTPUT::" + ESAPI.encoder().encodeForJavaScript(testString));
System.out.println("Testing OWASP encoder with " + testString);
System.out.println("OUTPUT::" + Encode.forJavaScript(testString));
}
}
RESULT:
Testing ESAPI encoder enccodeForJavaScript with --></script><script src=//58348 id="
OUTPUT::\x2D\x2D\x3E\x3C\x2Fscript\x3E\x3Cscript\x20src\x3D\x2F\x2F58348\x20id\x3D\x22
Testing OWASP encoder with --></script><script src=//58348 id="
OUTPUT::--></script><script src=//58348 id=\x22
In the owasp-java-encoder the --> is encoded to --> in the ESAPI encoder it is encoded to \x2D\x2D\x3E.
I don't think the sample attack string represents a successful attack, but I thought it noteworthy that it didn't follow the guidance from the cheat sheet. Has the OWASP/security community changed it's thoughts around "escape all characters less than 256 with the \xHH format"?
Thanks for the info. Would it make sense to update the OWASP XSS cheatsheet with the newer logic from this encoder?
At the very least I'll document this different and explain why it exists.
We stand by our encoding rules and plan to change the cheatsheet. We're closing this out as well.
I updated the OWASP XSS Cheatsheet (which I helped write and currently maintain) to discuss this issue. https://www.owasp.org/index.php?title=XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet&type=revision&diff=242574&oldid=240557 So hopefully we are all in sync!