ESAPI
DefaultEncoder#encodeForXPath(String) uses html codec
From [email protected] 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
From [email protected] on November 01, 2010 06:25:20
WTF. must fix this before GA.
Cc: planetlevel
Labels: Milestone-Release2.0
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.
@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.
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.
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!
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.
*/
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 <[email protected] 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 https://github.com/ESAPI/esapi-java-legacy/issues/109#issuecomment-457747271, or mute the thread https://github.com/notifications/unsubscribe-auth/AB3nm3UDN9C5lA_kyft68k8rQoWmGVfOks5vG3_CgaJpZM4C6wgv .
On Fri, Jan 25, 2019, 17:05 Matt Seil <[email protected] 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 https://github.com/ESAPI/esapi-java-legacy/issues/109#issuecomment-457747271, or mute the thread https://github.com/notifications/unsubscribe-auth/AB3nm3UDN9C5lA_kyft68k8rQoWmGVfOks5vG3_CgaJpZM4C6wgv .