Why is it necessary to validate data in a servlet obtained by calling HttpSession.getAttribute()?

Question

I am new to WebApp programming and am trying to understand the security implications of not validating data obtained by calling the javax.servlet.http.HttpSession.getAttribute() interface method. I know as a general rule that one should always validate data obtained from a non-trusted source, but I guess I don't understand why the contents of the session would be untrusted. This is based on my (probably unwarranted) assumptions that the only way data could be added to the session would be by calling HttpSession.setAttribute() and that only trusted code that is within the scope of the same application should be able to do that.

I guess what I am really asking is how an attacker would exploit my failure to perform proper validation of data obtain from the HttpSession. Is it because the implementation is unknown and it cannot be guaranteed that the contents of the session are not constructed somehow from data in the HTTP request (aside from a session id) and thus are subject to tampering? Or is it because trusting the contents of session means implicitly trusting the session id, which may be compromised and point to the wrong session? (although for that to happen it seems like the attacker would have to have some means of creating an alternate session that contains the compromised data).

Assuming that the contents of the session is not constructed from data in the request, is it the case that the only way this vulnerability could be exploited is if there is another vulnerability that would allow an attacker to create a bad session? E.g. uploading executable code and getting the server to execute it and return a session id that is captured and replayed?

Answer 1

No, you're right, there isn't a way for an external attacker to inject content into a session attribute.

I don't see any reason to validate data from session storage. If you've got attacker code running in your servlet container you're already in a much worse situation than anything to do with input validation.

Answer 2

You have two choices: (a) validate all data before storing it into the session, or (b) validate data after reading it out of the session. I think choice (a) makes a lot more sense. If that's the approach you follow, then no, you don't need to validate the data you pull out of the session, as it will already have been validated (before it was stored in the session).

Answer 3

In most cases your right. Properly validating data before it goes into the session would generally allow you to trust the session. One thing to consider is that these days many applications use external data sources to synchronize sessions using external data sources (redis, mongo, etc) to scale apps horizontally. If that data source is compromised, an attacker could exploit your app via the session attributes