Laplandia / owaspantisamy

Automatically exported from code.google.com/p/owaspantisamy
0 stars 0 forks source link

<input> tag not filtered! #58

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Configuring in antisamy policy file some tags to be validated.
2. Policy file doesn't contain any rules for 'input' tag (this means if the
input text contains a <input> tag, an error should be thrown:
error.tag.notfound=The {0} tag has been filtered for security reasons. The
contents of the tag will remain in place.
) 
3. Validate an html input text, containing the not allowed tag 'input':
e.g.: 'tgdan <input> g  h'
Code:

AntiSamy as = new AntiSamy();
CleanResults test = as.scan(inputText, antiSamyPolicy);
List errors = test.getErrorMessages();
if (errors.size() > 0) {
logger.info(Logger.EVENT_SUCCESS, "Cleaned up invalid HTML input: " + errors);
//throw exception if there are errors
throw new ValidationException(context + ": Invalid HTML input", "" + errors);
}

What is the expected output? What do you see instead?
The expected behavior when calling the code presented above is to get an
exception, ValidationException, because <input> is not allowed by the
antisamy html policy file. But, I don't receive errors, so, from antisamy
point of view, the html input text is valid.

What version of the product are you using? On what operating system?
Windows XP, Antisamy 1.3, Nekohtml 1.9.12, XercesImpl 2.9.1

Please provide any additional information below.

The interesting thing is that I get this weird behavior only for this tag
(input), for all other 'unknown'(from antisamy policy point of view) tested
tags (e.g: output, bhji, etc), the behavior is as expected, normal, output:
invalid html input.
When debugging, I saw that after html input text was parsed, the resulted
dom object contain the <input> element with no children (different from all
other tags), so it goes through 'if ( node instanceof Element &&
node.getChildNodes().getLength() == 0 )' branch (AntiSamyDOMScanner:279).
And here, the tag is removed and then returns. So, the scanning doesn't get
to the line where it should verified the tag against rules defined in the
policy. I think there is an open issue regarding the parsing by nekohtml.
Thank you in advance,
Dan Strajan,
Java Developer

Original issue reported on code.google.com by M4tr4gun4 on 20 Oct 2009 at 10:07

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for the detailed write up, we'll look into this.

Original comment by arshan.d...@gmail.com on 7 Nov 2009 at 8:13

GoogleCodeExporter commented 9 years ago
Thanks for accepting the issue.
[Additional information]
The same happens for tags like <?tag> or <!tag> or <|tag>. This is a very 
unpleased
behavior, since the tags starting with such special characters ( ?, !, |, etc) 
are
skipped. I mean, the html text containing such tags, from antisamy point of 
view , is
VALID. 
Note: antisamy xml policy file is the same, does not contain rules for tags 
starting
with mentioned characters, meaning that suck tags must be rejected when 
scanning,
must generate ValidationException errors.

Thank you,
Dan Strajan.

Original comment by M4tr4gun4 on 23 Nov 2009 at 8:12

GoogleCodeExporter commented 9 years ago
The "input" tag not being reported is fixed, since it's not on the list of tags 
that
could, if allowed by policy, remain and remain empty.

However, the fake and invalid tags you report I'm not sure I have a great 
answer for.
I recognize that it's currently not being reported correctly, but making a hack 
to
detect those specifically invalid tags when there really is no security problem 
seems
to me to be worse than the original problem.

The error messages are for guidance to users who need to fix their problems. If 
an
attacker is throwing random/invalid tags at you, it doesn't really matter that 
they
don't get perfect error messages.

The error messages are not intended to be a "security" log, by any means. It's a
best-effort attempt to capture why the input didn't work and what can be done 
to make
it work.

Thanks for the report!

Original comment by arshan.d...@gmail.com on 25 Nov 2009 at 10:25