Navigation Menu

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

HttpParamtervalue for allowing Xml Data #337

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

HttpParamtervalue for allowing Xml Data #337

meg23 opened this issue Nov 13, 2014 · 2 comments

Comments

@meg23
Copy link

meg23 commented Nov 13, 2014

From bhuvanes...@gmail.com on July 14, 2014 14:54:30

Hi All,

I'm trying to modify the validator.httpParamterValue which is having the value as
Validator.HTTPParameterValue=^[\p{L}\p{N}.-/+=_ !$*?@:%]{0,1000}$.

I'm, unable to parse the xml input :
JLTF53SR00CIndividualIndividualADMSRaddJLTF53SR00C00010.

Please provide me a regex which would pass the entire input xml for HttpParamter value.

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

@xeno6696
Copy link
Collaborator

xeno6696 commented Jan 1, 2016

What you're asking for is illegal according to the HTTP 1.1 specification. Please note that the characters [ and < and > are all reserved characters within the HTTP 1.1 spec. They can only be included in an HTTP header value if they are appropriately escaped with quotes, which is also lacking in the provided input.

The proper place for HTML/XML content is NOT in an HTTP header. Re-architect your communication protocol to conform to web standards! Seriously, as an attacker, I live for finding nonstandard implementations like this, because they're nearly always proprietary and innately exploitable. Keep HTML/XML content in the request body where they belong.

@kwwall -- recommend closing.

@kwwall
Copy link
Contributor

kwwall commented Jan 6, 2016

@xeno6696 is correct, what bhuvanes...@gmail.com is asking for is forbidden by the spec, so we definitely should NOT allow it or otherwise try to support it. An attacker of course can pass whatever "evil" characters that they wish in HTTP request headers, but that doesn't mean that OWASP should do something to encourage developers to accept that.

Am I closing this. #willnotfix

@kwwall kwwall closed this as completed Jan 6, 2016
@kwwall kwwall added the wontfix label Jan 6, 2016
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