Internet Forms Security

[Yahweh]

Lets say, in spite of sending form data using "method=post", someone intercepted the URL which read "showsensitivedata.asp?name=Yahweh&password=x2m4FS032202m3m2mbx0MNSx2n2LSKDFOW".

Although the password is unreadable, how do I prevent someone from just copy/pasting that URL into their own browser and being able to log into my account?

 

[jeremyp]

Lets say, in spite of sending form data using "method=post", someone intercepted the URL which read "showsensitivedata.asp?name=Yahweh&password=x2m4FS032202m3m2mbx0MNSx2n2LSKDFOW".

Although the password is unreadable, how do I prevent someone from just copy/pasting that URL into their own browser and being able to log into my account?

You can't unless you use an SSL connection.

 

[Molinaro]

Why not use method=post?

 

[Yahweh]

You can't unless you use an SSL connection.

I should have clarified in my opening post that I'm talking about the kind of code I'd have to program, not whether form data can be intercepted at all. As in, what kind of code would I have to write so that intercepted form data isn't a security problem.

For instance, I like to write scripts that authenticate a user each time he or she makes changes to the database, and I usually this by using hidden form fields which store username and an encrypted password. Before database changes are made, the script checks to see that the username and password matches a user in the database, however this security doesn't do me any good if someone intercepts the form data.

Why not use method=post?

See opening post:

Lets say, in spite of sending form data using "method=post", someone intercepted the URL which read "showsensitivedata.asp?name=Yahweh&password=x2m4FS 032202m3m2mbx0MNSx2n2LSKDFOW".

However, method=post doesn't always work, because the data is stored in HTTP headers which can be retrieved pretty easily using PHP and ASP server variables. Something as simple as request.servervariables("ALL_HTTP") can reveal quite a lot of information about a user, and sometimes it can contain sensitive information.

Here's a page I wrote to demonstrate how much information you send to every website you visit on the internet:
http://www.fstdt.com/security.asp

The sourcecode for that page is only 3 lines, and with a little more effort someone could get all of your referral information since the start of your online session.

 

[Molinaro]

Doh!

When I 1st read your post I read it as "..instead of..", rather than, ".. in spite of..".

 

[kevin]

Lets say, in spite of sending form data using "method=post", someone intercepted the URL which read "showsensitivedata.asp?name=Yahweh&password=x2m4FS032202m3m2mbx0MNSx2n2LSKDFOW".

Although the password is unreadable, how do I prevent someone from just copy/pasting that URL into their own browser and being able to log into my account?

You're looking for how to do web sessions. Here's some info on how to do these with ASP:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnasp/html/aspwsm.asp

and PHP:
http://www.oreilly.com/catalog/webdbapps/chapter/ch08.html

BTW depending on the language you're using it may not be possible to tell if data came from a GET or POST, so even if you're relying on POST to protect, it's frequently possible to stick the data in a GET URL and have it work.

 

[jeremyp]

I should have clarified in my opening post that I'm talking about the kind of code I'd have to program, not whether form data can be intercepted at all. As in, what kind of code would I have to write so that intercepted form data isn't a security problem.

I understand that. Intercepted form data is always going to be a security problem which is why you've got to stop it from being intercepted.

For instance, I like to write scripts that authenticate a user each time he or she makes changes to the database, and I usually this by using hidden form fields which store username and an encrypted password. Before database changes are made, the script checks to see that the username and password matches a user in the database, however this security doesn't do me any good if someone intercepts the form data.

You should use a session identifier for this. When the person first logs in, create a unique id for the session and send that back and forwards (or put it in a cookie), not the user id and password. For each subsequent HTTP request, which supplies the session id, the first thing you do is check that the id is a valid one that you issued (for this reason, don't use a simple incrementing counter to generate the id) and that it has come from the same IP address as the initial login request. If you're using PHP, a lot of this is handled automatically. Read about session variables and session_start(). ASP has similar features.

Of course, none of this solves the problem of somebody intercepting the original login request. for that you'll have to use a more sophisticated authentication mechanism than user/password or use SSL to encrypt the connection.

However, method=post doesn't always work, because the data is stored in HTTP headers which can be retrieved pretty easily using PHP and ASP server variables. Something as simple as request.servervariables("ALL_HTTP") can reveal quite a lot of information about a user, and sometimes it can contain sensitive information.

Here's a page I wrote to demonstrate how much information you send to every website you visit on the internet:
http://www.fstdt.com/security.asp

The sourcecode for that page is only 3 lines, and with a little more effort someone could get all of your referral information since the start of your online session.

You only have two choices, GET and POST. There is no third option.

 

[Tirdun]

You only have two choices, GET and POST. There is no third option.

Well, cookies/session values.

Generally I use a session cookie to store a key (php and asp have hash generators based on timestamps and random seeds), then validate+replace that key for each page viewed against a database. The browser sends key+ip address to the db, the db checks and does a timestamp compare.