By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The problem you have to deal with is that it's possible for the user to send you as part of a GET, POST or header (or in a cookie) anything they want to. Consider what would happen if a hostile user wrote a proxy program that edits the data stream and sends you what they want you to have. In fact, there have been many notable security problems that revolve around this general problem. For example, some shopping carts put information in cookies that a user could edit with a text editor, changing product prices. Other systems authenticate users correctly, but store the account number in a cookie that could be changed (this is particularly interesting in banking or stock trading systems). What this really means is that you cannot trust any of the data you get sent -- you have to re-verify it every time. There are a couple of ways you can avoid this problem. One is to send the user a token that contains the encrypted state. You probably also want to append a SHA1 hash to the end of the data to test for modification, too. This leaves open the chance of a replay attack, but that may or may not be an issue for you. Another would be to give the user (in a cookie, or parameter, or URL) a large, opaque token that is hard to spoof. For example, generate 16 or 32 bytes of random data, and use that as an associative key for the state data that you keep on your server. You need to handle timeouts of these session states (if one isn't used in say, ten minutes, an hour, a day, it depends on how friendly you want to be, then you discard it), and some other details, but the chance that an attacker could effectively synthesize an active token is about equivalent to the strength of the crypto you're using. An improvement on this design would be to create a new random token for each page. Thus, the token isn't a session id, but a next-session-step id. I hope this helps and gives you some ideas on how to solve your problem.
Dig Deeper on Web Server Threats and Countermeasures
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.