Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Canonicalization might not be performed #234

Closed
meg23 opened this issue Nov 13, 2014 · 3 comments
Closed

Canonicalization might not be performed #234

meg23 opened this issue Nov 13, 2014 · 3 comments

Comments

@meg23
Copy link

meg23 commented Nov 13, 2014

From schulger...@widmann.de on May 25, 2011 05:43:27

There's a bug in DefaultEncoder.canonicalize(String input).

It's supposed to use the settings
Encoder.AllowMultipleEncoding and
Encoder.AllowMixedEncoding
but it's effectively using
!Encoder.AllowMultipleEncoding and
!Encoder.AllowMixedEncoding

See lines 116-123:

public String canonicalize( String input ) {
if ( input == null ) {
return null;
}
return canonicalize(input,
ESAPI.securityConfiguration().getAllowMultipleEncoding(),
ESAPI.securityConfiguration().getAllowMixedEncoding() );
}

It should be

public String canonicalize( String input ) {
if ( input == null ) {
return null;
}
return canonicalize(input,
!ESAPI.securityConfiguration().getAllowMultipleEncoding(),
!ESAPI.securityConfiguration().getAllowMixedEncoding() );
}

because

canonicalize(String, boolean, boolean)

is defined as

canonicalize(String input, boolean restrictMultiple, boolean restrictMixed)

and not as

canonicalize(String input, boolean allowMultiple, boolean allowMixed)

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

@meg23
Copy link
Author

meg23 commented Nov 13, 2014

From sickska...@gmail.com on July 11, 2011 16:42:50

Related to: https://code.google.com/p/owasp-esapi-java/issues/detail?id=231

@xeno6696
Copy link
Collaborator

@kwwall going to close this one. While what the person says is true, I don't think its safe to reverse any boolean logic this far into the life of the API.

@kwwall
Copy link
Contributor

kwwall commented Jun 14, 2016

At a minimum, perhaps some clarification in the Javadoc is in order then?
B/c it seems as though what we are saying is "yes, this probably is not the
intended behavior, but by now so many people may be relying on this broken
behavior that fixing it could have unintended consequences."

If we are going to change the actual behavior, we should at least document
what it is actually doing, don't you agree? Changing the names of the
formal parameters would be a good start. And maybe a "@see" to refer to
this bug report.

-kevin
Sent from my Droid; please excuse typos.
On Jun 14, 2016 8:42 AM, "Matt Seil" notifications@github.com wrote:

Closed #234 #234.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#234 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AB3nm4nx5yOBBKi0_9O55yN9AP5Bccmwks5qLqG_gaJpZM4C6zAO
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants