Q

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 user.


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

Dig deeper on Web Server Threats and Countermeasures

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close