views:

152

answers:

7

Possible Duplicate:
How secure is a HTTP POST?

Suppose I have a login page in php where a user is required to enter his name and password. form method is post in this case.

Now someone(my friend) told me that the information(username and password) that is entered and sent to the server can be hacked just by fetching the header of the resulting page generated. So you should encrypt the header and that is why HTTPS is used.

This didn't make sense to me because I thought the information (username and password) sent via post method are completely secure and just by header hacking one cannot have access to to the username and password.

Is my friend correct? If no is there any way to do such stuff for someone who has no access to the code? How can I send my private information via HTTPS (page to be coded in php)?

EDIT:

Data through get method is sent via header. Right? Is data through post also sent via header?

+3  A: 

Your password is not secure if you just send it with POST - still visible and unencrypted, albeit a tiny bit less obvious.

Sending an unencrypted password via POST is the most insecure, yet still relatively sane way of doing this. (yes, there are less secure ways, but those are completely insane - sending a password form through GET is about as secure as broadcasting it on TV or printing it in the newspaper).

This is what a typical GET request looks like:

GET http://somedomain.example.com/path/file?here=are&the=GET&parameters=.
X-Some-Header: header content
X-Another-Header: 1

Here's a similar POST request (note that you can send both GET and POST parameters in a POST request):

POST http://somedomain.example.com/path/file?here=are&the=GET&parameters=.
X-Some-Header: header content
X-Another-Header: 1
Content-Length: 40

with_POST&=the&content=is&here_in=the&request=body

As you can see, HTTP is a completely plaintext protocol - there is no encryption performed on the data, so anyone can view and/or modify it in transit. Access to the code is not necessary at all - just watch the traffic and your data will be there, for anyone to see (you can verify this with tools such as Wireshark which allows you to view network traffic).

To remove this need to trust the whole world, HTTPS (S is for Secure) was created, which provides encryption ("only the sender and receiver can read it") and authentication ("the server is indeed yourserver.example.com, and not evilserver.example.net").

HTTPS is a wrapper around HTTP: where with HTTP, the client connects to the webserver and starts the conversation, HTTPS first establishes a secure SSL tunnel, and the HTTP communication goes through that. Setting up a HTTPS server is a bit more complex than HTTP, see e.g. this article.

Piskvor
Data through `get` mthod is sent via `header`. Right? Is data through `post` also sent via `header`?
Shekhar Gupta
@user242265: No, and no. GET data is sent in the URL, and POST data is sent in the request body (not headers). Edited my answer with an example.
Piskvor
+5  A: 

Without SSL, data sent through POST is equivalent to data sent through GET, or in other words, not encrypted at all.

Daniel Vandersluis
Not quite equivalent. If sent through a GET it is still in cleartext even on an SSL connection.
JohnFx
Sorry, I meant those two statements as two separate thoughts, I'll edit.
Daniel Vandersluis
@JohnFx: Yup - sending data through GET is insane: it'll get stored in access logs and other places.
Piskvor
@JohnFX: URLs in the GET header are encrypted, just like the rest of the data in HTTP over SSL/TLS ("HTTPS"). HTTP and TLS are separate layers. How do you figure that passwords transmitted via GET are not encrypted when sent over HTTPS?
bowenl2
Piskvor
@bowenl2: I stand corrected. After further research the URL is indeed encrypted when used with SSL, although as already mentioned, it still is not a good idea to send sensitive information in a get.
JohnFx
+2  A: 

In case of a login form, I use javascript to hash the password before submitting the form. It will make it more difficult to get to it.

pritaeas
Without some encryption, this is only minimally more secure than doing nothing at all.
JohnFx
I agree with JohnFx. In this case, the *hash* of the password is now the "password". Someone can still capture the hash and re-send it again later, allowing them access.
Adam Paynter
@Adam Paynter: Not if you use a nonce; but since this is all in plaintext, the attacker can easily just fake the initial server response and send hir own spoofed page which submits elsewhere.
Piskvor
@Piskvor: True, I just assumed that a nonce wasn't involved, according to the answer.
Adam Paynter
Also, if the attacker is quick enough (e.g. scripted), xe can grab and use your nonce before you do - that is not enough data to login, but enough for a DoS (as the nonce is already marked as "used" when you get around to using it).
Piskvor
A: 

From Wikipedia

HTTP is unsecured and is subject to man-in-the-middle and eavesdropping attacks which can let attackers gain access to website accounts and sensitive information. HTTPS is designed to withstand such attacks and is considered secure against such attacks.

If you're concerned about someone intercepting your data, use HTTPS.

Andy Evans
You can still launch man-in-the-middle attacks on SSL connections. For example if I gain access to the network of the host or the client then it becomes a trivial matter to perform an ARP poisoning attack thereby redirecting traffic through my computer and create a proxy. So if you access "https://gmail.com" for example my computer would then request that site and forward it to the target computer. If a user is smart and keeps an eye on the little lock that most browsers display now they would notice it is self signed, not signed by Google. Not many people notice mid session.
Peter Hanneman
How would that work, your proxy can't pretend to be gmail.com as it doesn't have it's private key. This is pretty much entirely the case that SSL is supposed to prevent.
John Burton
@Peter Hanneman: self-signed -> not in browser's CA list -> "invalid certificate" warning, not "just a lock icon"; OTOH@JB: 1. proxy serves up a fake HTTPS gmail login page 2. browser throws big scary warning about "invalid certificate" 3. user clicks "ok ok yes yes allow ok" without even reading the dialog, just to make the scary warning go away. 4. Profit!!!
Piskvor
Yes exactly the proxy computer would create a fake self signed certificate. Newer browsers like Chrome will alert you that there is something funny going on but like Poskvor said most people don't pay attention and will just click yes and accept the self signed cert. Tech savy users might be safe but you can't protect against stupid. The prime time to launch an attack such as this is mid session after the user might have already logged on. Even if you don't catch the username/password which are usually hashed client side before being sent out anyways you can still hijack the session.
Peter Hanneman
Most applications that use HTTPS to phone home such as an Adobe Flash or Air application generally aren't told to do anything special in the case of coming across a self signed cert and will accept it automatically which is just dumb since they don't even prompt the user of the potential problem. Only secure solution to browse the internet safely is to create a SSH connection to a physically secured computer and browse through that machine.
Peter Hanneman
A: 

I believe the php script that submits the form, and the form itself needs to be in a directory on the webserver that is set up with SSL. You have to have an SSL certificate enabled for that website, as well.

Dylan West
+1  A: 

I thought the information (username and password) sent via post method are completely secure

Wrong. Data sent via POST is practically as unsecure as sent via GET. The only (marginal) difference is that GET data is slightly more "accesible", via urls histories and perhaps logs. But if someone can sniff the link, he can spy very easily user and passwords sent via a http request, (POST or GET) unless SSL (https://) is used.

leonbloy
Data through get mthod is sent via header. Right? Is data through post also sent via header?
Shekhar Gupta
POST data is not sent in the http header. That make zero difference in what respects to security.
leonbloy
A: 

you can read the submitted data with Wireshark - http://de.wikipedia.org/wiki/Wireshark if you sent the form data without https.

User123