DefaultEncoder#encodeForXPath(String) uses html codec

[meg23]

From schal...@darkmist.net on January 26, 2010 21:44:51

What steps will reproduce the problem? 1. look at the method in the source code

xpath encoding != html encoding...

both 2.0 and 1.4

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=99

[meg23]

From manico.james@gmail.com on November 01, 2010 06:25:20

WTF. must fix this before GA.

Cc: planetlevel
Labels: Milestone-Release2.0

[meg23]

From manico.james@gmail.com on November 02, 2010 00:59:29

Status: Accepted

[meg23]

From kevin.w.wall@gmail.com on February 11, 2011 22:17:40

Labels: Component-Encoder

[xeno6696]

I think the age on this issue has demonstrated that even if developers are using ESAPI they sure as heck aren't using xpath.

HTML codec is a safe alternative given the dangerous characters that need escaping. @kwwall I don't think anyone uses this. Perhaps we deprecate the method, leave as is, and remove it entirely in a future release. I had to use the wayback machine to retreive the old IBM article.

[kwwall]

@xeno6696 May be using XPath, but not ESAPI's Encoder.encodeForXPath().

XPath is like a whole language unto itself, but it also generally has to operate on UTF-8, right (since that is what is used for XML encoding). So perhaps we need defer this until you complete that encoder for UTF-8 that you (@xeno6696) volunteered for.

[jeremiahjstacey]

Is there follow up with this from the UTF-8 work?

[xeno6696]

Damn... short answer: No. I completely forgot about this one. That said, from what Kevin said here, we XPath should get its own Codec. In the meantime I think the javadocs should be updated and this method deprecated until we supply a true Codec.

[kwwall]

Sigh. We really need to sign up a contributor whose GitHub user name is Godot so we can tag all these types of things as "Waiting for godot" (Dang; now that I wrote that in the comment, I see that's someone's real user name; if so, apologies in advance if he sees this, but I couldn't resist the joke. I'm sure he gets that all the time though. At least I didn't @ him.)

Seriously, though as per https://www.owasp.org/index.php/XPATH_Injection, under the "XPath Injection Defenses" this looks like doing this right is going to take much more than an XPathCodec, but rather it will require a full blown XPath Parameterized Type mechanism similar to what we have with SQL to prevent SQLi, which I guess would be something similar to what is discussed here. Doing this right seems complicated. If there are output encodings that we could use for encoding these characters:
( ) = ' [ ] : , * / WHITESPACE
then we could use the simpler approach described earlier in the same OWASP wiki page here.

If we do neither, I guess we could deprecate it with a warning and reference this GitHub issue of some OWASP wiki pages for more details. That's the probably the right thing to do?

Could either of you take a stab at writing up a deprecation comment for it? If nothing else, refer them to the links referenced above and this GitHub issue. Thanks!

[xeno6696]

I had to look up Godot.... "Waiting for someone who will never arrive..." That's epic!

/**
@Deprecated
In reviewing [this issue](https://github.com/ESAPI/esapi-java-legacy/issues/109), we the project maintainers have come to the conclusion that XPath 
is a distinct enough grammar that it is likely that the HTMLCodec doesn't provide sufficient 
protection.  We believe that the correct solution will be to create its own codec and offer a safer 
replacement.  
*/

[kwwall]

That works fine. I'd maybe add @see Javadoc annotation to refer them to these 2 OWASP wiki pages: https://www.owasp.org/index.php/XPATH_Injection_Java <https://www.owasp.org/index.php/XPATH_Injection_Java#Injection_countermeasure_n.C2.B02> and https://www.owasp.org/index.php/XPATH_Injection

…

-kevin -- Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

On Fri, Jan 25, 2019, 17:05 Matt Seil ***@***.*** wrote: I had to look up Godot.... "Waiting for someone who will never arrive..." That's epic! /** @deprecated In reviewing this issue, we the project maintainers have come to the conclusion that XPath is a distinct enough grammar that it is likely that the HTMLCodec doesn't provide sufficient protection. We believe that the correct solution will be to create its own codec and offer a safer replacement. */ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3nm3UDN9C5lA_kyft68k8rQoWmGVfOks5vG3_CgaJpZM4C6wgv> . On Fri, Jan 25, 2019, 17:05 Matt Seil ***@***.*** wrote: I had to look up Godot.... "Waiting for someone who will never arrive..." That's epic! /** @deprecated In reviewing this issue, we the project maintainers have come to the conclusion that XPath is a distinct enough grammar that it is likely that the HTMLCodec doesn't provide sufficient protection. We believe that the correct solution will be to create its own codec and offer a safer replacement. */ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3nm3UDN9C5lA_kyft68k8rQoWmGVfOks5vG3_CgaJpZM4C6wgv> .