Differentiating between parameters
Is it possible for a Web server (Netscape or Windows) to differentiate between the parameters sent in a GET, POST or as part of the HTTP Header? (I assume that these are three possible different methods of sending a parameter to an Internet application.) How can I retrieve the values of all the parameters sent, knowing if they have been sent using a method or the other?
I want to avoid that any user can request a URL, including as a GET or as
POST, a parameter that I am receiving from a trusted proxy as a HTTP header
parameter. I want to avoid that the trusted parameter is overwritten by the
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.
This was first published in August 2001