Javascript encoding does not follow the recommendations of the OWASP XSS Prevention Cheat Sheet

[rshanlever]

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"?

[jmanico]

The OWASP XSS cheatsheet is older research that is no longer accurate, but it’s still safe. ESAPI and the Cheatsheet encode way more than necessary. Again it’s a safe choice, but not a necessary one when the library is used correctly. No one has ever discovered a bypass against our encoding rules and many have tried. We would love researchers to try more! So please take a look at our wiki to see proper usage docs. If you bypass any of those you’re a star! Aloha, -- Jim Manico @manicode Secure Coding Education +1 (808) 652-3805

…

On Apr 3, 2018, at 8:04 AM, rshanlever ***@***.***> wrote: 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"? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[rshanlever]

Thanks for the info. Would it make sense to update the OWASP XSS cheatsheet with the newer logic from this encoder?

[jmanico]

I’m hesitant to, since the CS over-encodes for safety yet this library focuses on only encoding what is necessary. Let me think about this for a bit. You’re not first to make this observation. Aloha, -- Jim Manico @manicode

…

On Apr 3, 2018, at 8:38 AM, rshanlever ***@***.***> wrote: Thanks for the info. Would it make sense to update the OWASP XSS cheatsheet with the newer logic from this encoder? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jmanico]

At the very least I'll document this different and explain why it exists.

[jmanico]

We stand by our encoding rules and plan to change the cheatsheet. We're closing this out as well.

[jmanico]

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!