Comments (3)
It's not exactly wrong as some parsers will decode HTML entities without the trailing semicolon.
So this test is technically ambiguous. Remember we are trying to encode/decode/canonicalize in a way that makes attacks difficult or impossible. We are not necessarily trying to strictly implement a spec. The real world implementations are more complex than specs.
Still, this issue keeps coming up over the years. Especially in the case where the semicolon is present it seems like we are producing the result least likely to be right.
Simply switching to using the longest (instead of shortest) possible match would fix a lot.
from esapi-java-legacy.
@planetlevel , Agreed with statement "Simply switching to using the longest (instead of shortest) possible match would fix a lot."
Do we expect any tentative timeline for the fix?
from esapi-java-legacy.
@mukesh4804 wrote:
Do we expect any tentative timeline for the fix?
Hard to say, but I can almost guarantee that it will be at least 6 months or longer should we decide to prioritize a fix for this. We tend to prioritize fixes that have security implications and also focus on ones that have the broadest impact to the security community. Not that many ESAPI clients use the decoders in the first place. In fact, the OWASP Java Encoder project does not even offer decoders! They just generally are not needed.
The implementation of the ESAPI output encoders were intentionally written to provide a "safe harbor" to users who used a popular set of badly broken and vulnerable browsers from a certain company whose first goal was definitely not security and who played fast and loose with the W3C specs. It might be argued that the "specs are the only things that (should) matter", but attackers don't care about adherence to specs, but only what the actual behavior is. Thus this "safe harbor", tended in the direction of aggressively encoding things. As a result, I suspect that the decoders were designed to match so that the respective encoder / decoder acted as inverse operations. So this is only speculation but that may be why the decoders seem to be operating on shortest match rather than the longest match.
That said, I think the ESAPI team would address this as a low priority bug. Its hard to see (outside of contrived cases of course) how such decoder bugs not following the W3C specs to the letter is going to cause a security problem. For output encoding, certainly. But most often when I see decoders being used, that raises a red flag in my mind. From a security perspective at least, decoders really shouldn't be necessary. Decoding should be left to the purview of the end user's browsers. Of all the hundreds of security code reviews that I've done, I can never really recall where an ESAPI decoder was actually needed. At best, it was unnecessary and mostly harmless. Hence, to me, this is a Low priority.
And given that it's a low priority, it honestly may never get fixed unless someone creates a PR to address it. So, it this is important to you, I'd say submit a PR for it (see the CONTRIBUTING-TO-ESAPI.txt file). But even then, it's likely that it will still be 6 months or so until the next ESAPI release unless we need to patch some security issue.
from esapi-java-legacy.
Related Issues (20)
- ESAPI is not returning right logger level HOT 6
- Javadoc needs updated to correct links to OWASP ESAPI wiki page HOT 1
- HTTPUtilities needs its Javadoc seriously reworked
- Fix Javadoc code example in ValidationErrorList
- ั ะท HOT 1
- Context should also be logged in HTMLValidationRule
- canonicalize sees entity which isn't there HOT 7
- ESAPI excludes transitive dependency xalan from xom, but does not include it itself HOT 2
- Logs printed using println() are always printed and no option to disable them. HOT 2
- Insecure default signature key length HOT 3
- Change AntiSamy to eventually use SAX parser by default, but allow DOM parser to be used for backward compatibility
- Does esapi-java-legacy support jDK17 HOT 1
- Fix typo in comment in validation.properties files HOT 2
- Option to omit event type prefix in logs HOT 1
- Fix Encoder.encodeForLDAP and Encoder.encodeForDN so they are strictly conformant with Section 3 of RFC 4515 HOT 1
- Revert Dependency Check goal from 'purge' to 'check' once NVD API stops returning 503 'Service Unavailable' errors HOT 1
- DefaultEncoder / getCanonicalizedURI returns mix encoding for HTML special characters HOT 5
- Fix Encoder.getCanonicalizedURI(URI) for the test case of a double-ampersand in the HTML Query HOT 1
- HTMLEntityCodec Mysteriously decodes &or HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from esapi-java-legacy.