Is there an SQL injection equivalent on url-passed parameters to a servlet?

Question

In SQL injection an attacker can craft a string that if left unchecked and executed it can complete and execute arbitrary SQL commands.

Is there an equivalent to these kinds of attacks in JSP pages? Specifically, is an error handler, which only prints URL-passed parameters on screen, capable of executing arbitrary code this way?

EDIT: Original post above, obviously parameters should NEVER be passed to the system unchecked. In case of web-apps that handle any kind of CRUD operations over any kind of persistence records using parameters it's a must. The attack is known as HTTP Parameter pollution, or HPP.

Based on the "No system is 100% secure" mantra, I would like to know is something as seemingly inoffensive as printing the parameters can be abused.

Answer 1

If all it does is print the parameters then the main attack vector is XSS.

Although this cannot execute code on the server, it can execute code in the browser.

So if an attacker sends a legitimate user a link

http://www.example.com/foo.jsp?foo=<script>alert(123)</script>

and when the link is followed the script code is executed in the user's browser by the page, then the page is vulnerable. Effectively the client side of the session is now under control of the attacker if the attacker had done something more evil rather than just displaying an alert box. For example, sending cookies to themselves or injecting a keylogger.

There are many variations on this attack and it doesn't have to be in the form of script tags.

Answer 2

Executing arbitrary code is doubtful, other forms of injections are a possibility.

Things such as HTML injection or even XSS might occur if the input is not properly checked and/or output encoding is not performed.

Also consider the possibility of phishing and non-persistent defacement.

An error handler should never be dependent on GET parameters and should only display minimal information. It is recommended not to use a GET parameter to generate an error message.

Hope this helps!

Answer 3

As mentioned above, your primary attack vector for displaying query string parameters would be XSS vulnerability. If this data never goes to a persistent layer it is known as a Type II (Reflected) XSS attack.

You should always consider the context in which untrusted data is presented. Many modern templating/web frameworks like Jinja and Angular provide automatic contextual escaping. Even so , you should still be validating and sanitizing all untrusted data that you come in contact with.

If an attacker knows your query string parameters are not being sanitized, he could create a parameter that sends a session cookie to a remote server, quite easily. This is why you must always practice defense in depth in security. HttpOnly (if using cookies) / Content Security Policy / Sanitization / Validation / Encryption, etc...