News: Common servlet engine security hole exposed
- Posted by: Floyd Marinescu
- Posted on: July 03 2001 15:07 EDT
Why would a user execute malicious code in his own browser?
An excerpt from a Cert advisory on this bug explains it all:
Many Internet web sites overlook the possibility that a client may send malicious data intended to be used only by itself. This is an easy mistake to make. After all, why would a user enter malicious code that only the user will see?
However, this situation may occur when the client relies on an untrustworthy source of information when submitting a request. For example, an attacker may construct a malicious link such as
<_A href="http://example.com/comment.cgi? mycomment=<SCRIPT>malicious code</SCRIPT>" > Click here</a>
TSS Note: I put a "_" in front of the 'A' A so that TheServerSide.com doesn't convert this line into a real HTML link.
When an unsuspecting user clicks on this link, the URL sent to example.com includes the malicious code. If the web server sends a page back to the user including the value of mycomment, the malicious code may be executed unexpectedly on the client. This example also applies to untrusted links followed in email or newsgroup messages.
Read Java servlet cross-site scripting vulnerability .
- Common servlet engine security hole exposed by Howard Lewis Ship on July 04 2001 09:32 EDT
- Common servlet engine security hole exposed by Race Condition on July 05 2001 14:08 EDT
- Common servlet engine security hole exposed by Bob Lee on July 06 2001 00:07 EDT
- Common servlet engine security hole exposed by Scott Stirling on July 09 2001 17:40 EDT
One of the problems here is using the JSP <%= %> directive (or <% out.println(...) %>). This sends raw characters straight to the client's web browser.
My Tapestry framework filters all output by default, converting troublesome characters into escaped entities. Thus user B would be sent "<script> ..." and would see "<script> ...".
Does this problem exist if you choose not to use the query string? Will it be a problem if the page submits hidden fields instead?
It seems to me that there are situations where this could be a desired functionality and that it should be the application's responsibility to filter these types of input, not the container's. Am I interpretting this incorrectly?
I think you are correct. If my application is expecting a parameter value, the application should know what range of values to expect and then filter them.
This was posted as "cross-site scripting fix" on the Macromedia security bulletin site, and a fix was posted for all versions of JRun at the end of June:
Macromedia Product Security Bulletin (MPSB01-06)