A Java Servlet Container cross-site scripting vulnerability has been discovered, that affects current and old versions of Tomcat, JRun, Websphere and Resin. The bug allows Javascript code to be embedded in a URL of a target servlet engine, which will result in the java script being executed within the users browser.

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 .

There's a whole slew of similar problems. For instance, on a bulletin-board type system, user A can enter a message with hostile JavaScript. When user B reads the message, the hostile JavaScript is executed in their browser.

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 "&lt;script&gt; ..." 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)