1

I am submitting a form by using "POST" method. But, even I submit the form using "POST" method, I can see the submitted form data in http headers. Am using live http headers plugin to check the headers. I am trying to save secure info. If the browser has "live http headers" plugin, easily any one can trap the data. So, if I want to hide the submitted data in http headers also, what do I need to do?

If it is not possible to hide the submitted form data in http headers, which mechanism I could follow to encrypt the data at client side(so that even if data is visible in http headers, it would be in encrypted format. So, no one can understand) and decrypt and process the data at server side. I am totally blocked here.
Please help me out from this. appreciate any help. Thanks in advance.

venky
  • 400
  • 1
  • 6
  • 19
  • 3
    Use SSL. That should make things secure. – Wojciech Owczarczyk Mar 20 '14 at 07:50
  • @Wojtek, thanks for reply. I tried with https, it still not working. Any other suggestion? – venky Mar 20 '14 at 09:58
  • HTTPS is the correct way to do this, and it's supported in all browsers. you won't have to encrypt data in a header, with https the browser encrypts and signs the body of the message for you. can you let us know the error that you got while you tried to enable https? – Angular University Mar 24 '14 at 21:52
  • It is not showing any error. Every thing is working properly in https port. But, the data Am sending is visible in http header. Even visibility is not matter here, but the data is not visible in encrypted format, instead, it is in actual form. So, any one can understand the form data I submitted. I just want to let the form data visible in encrypted form in http headers. So that no one can understand. – venky Mar 25 '14 at 06:06
  • Surely you need to be able to decrypt the message at the other end? If it can be decrypted at either end, there is no point in doing this? If you want to obfuscate the code (Make it harder for inexperienced, prying eyes) you can always post a base64'd JSON string to your server instead of the standard post key => values. – Dave Mackintosh Mar 25 '14 at 09:06
  • What do you mean by "I can see the submitted form data in http headers" are you passing data on cookies? There should be no relevant information on the Headers. – Pedro.The.Kid Mar 28 '14 at 14:13

5 Answers5

5

There appears to be a bit of confusion regarding how an Http POST works. I'm assuming you are viewing the headers in either the client browser's debugger or on the server. In that case, the data being sent should be readable. The client side debugger actually displays the headers before they are encrypted and sent across the wire.

On the server, the post data should also be available in unencrypted format.

What is sent over the internet would be encrypted, provided that you are using https:// in your form action instead of http://

B2K
  • 2,541
  • 1
  • 22
  • 34
  • Yeah. You are absolutely right. Am viewing data in client browser's debugger. My main issue is, even if we enable debugger also, the data should be in encrypted format. Because, some technical person may start debugger secretly before we take system at internet center and can gather the submitted form data after we left. Do you have any idea how to proceed. Appreciate your help. Thanks for reply. – venky Mar 28 '14 at 07:06
  • @venky That makes no sense. Are you saying they'll open the debugger to steal some unsuspecting users data who sits down at that machine? That sounds more like paranoia than a legitimate security concern. If you want even that to be secured, you'll need to develop an application in silverlight or flash, and encrypt the data using a reversible algorithm before transmitting it to your server. – B2K Mar 28 '14 at 10:37
  • 2
    @venky: If the attacker has full access to the client computer and can freely manipulate it, they can collect any data that the user has entered. There is nothing you as the developer of a web application can do about it. – pixelistik Mar 30 '14 at 22:34
  • @pixelistik good point. I was thinking of a public internet terminal. Ty – B2K Mar 31 '14 at 02:08
2

You can't really do that, I mean you could but anything on the front end can be easily reverse engineered. Your best bet for securing form data is to implement CSRF of which Jeff Atwood did a good post on here and the comments are quite good as well.

Aside from that; like one of the comments above says, you can use SSL to secure the data going to and from the server.

Comments weren't long enough for this

The steps towards getting secure, without knowing your technology stack would be to get an SSL certificate for the origin and destination of your post request, if you don't have control of the destination your journey ends here but head over to one of the hundreds of SSL certificate providers available, I usually use Start SSL because it's free and pretty good.

You'll need to give us some more info on your technology stack to go any further but assuming you're using PHP and Apache you'll need to do a few things on your server to get the certificate.

Firstly generate your Private Key using this command:

openssl genrsa -des3 -out www.yourdomainname.com.key 2048

It will ask you for a few details, fill them all out as best you can and write them down somewhere, specifically the password.

Once you have this, you need to generate a certificate signing request or a CSR for short, this is achieved by running the below command 

openssl req -new -key www.yourdomainname.com.key -out www.yourdomainname.com.csr

The password you entered to create the private key, when it asks; enter it here.

You'll also be asked for a load of details, from my memory this is what it will ask and it's generic format

Country Name: GB
State or Province Name (in full): London
Locality Name (city): London
Organization Name: Your company name
Organizational Unit Name: Probably IT or development
Common Name: Enter your domain name here in FULL, without http://

When it asks for

Email Address
password challenge
optional company name

don't enter anything...

validate your CSR using 

openssl req -noout -text -in www.mydomain.com.csr

You can now use this CSR to sign your request with Start SSL Once you have your crt from Start SSL open your server config (with apache its usually http-vhosts.conf in /etc/apache2/extra/ and create this block inside of it

<VirtualHost *:443>
  DocumentRoot /var/www/www.yourdomainname.com
  ServerName www.yourdomainname.com
  SSLEngine on
  SSLCertificateFile /path/to/your/www.yourdomainname.com.crt
  SSLCertificateKeyFile /path/to/your/www.yourdomainname.com.key
  SSLCertificateChainFile /path/to/StartSSL.crt
</VirtualHost>

Restart apache and you should be able to access your website using https

Hopefully I've got that all correct, I'll edit for any issues.

Dave Mackintosh
  • 2,738
  • 2
  • 31
  • 40
  • Thanks for Reply. You mean submit form using https protocol as origin also https? If not, can you give me brief idea about how to submit over ssl? – venky Mar 24 '14 at 13:04
  • The destination and origin for the post request would both need to be supportive of the HTTPS protocol, depending on your technology stack you'd need to set your server up to use a certificate to sign each request, there are plenty of providers of these certificates and you can even self sign for development. You can get an SSL certificate from here http://www.startssl.com/ if you tell me your technology stack I can point you to a config tutorial for it. – Dave Mackintosh Mar 24 '14 at 13:29
  • It's worth noting that even *with* SSL I suggest adding support for CSRF validation on each of your forms. There are a lot of issues with cross site scripting and forged form submissions that it eradicates. – Dave Mackintosh Mar 24 '14 at 13:30
  • Sorry, just read your comment again. You'll never be able to sensibly protect the visibility of your post data client side. It can only be securely transmitted but not invisible. – Dave Mackintosh Mar 24 '14 at 14:02
  • Am using JEE technology in this. As we can't avoid the data visibility in http headers, I just want to let the data in encrypted form. So that no one can understand the submitted form data even if it is visible in http headers. – venky Mar 25 '14 at 06:10
1

Well, there is no easy way but from other posts that I have found:

  1. Take a look at this post. This does not hide the values in POST but using jquery serializes them. You can use your own conventions to make it look like a mess.

  2. Take a look at this article. CLearly explains everything you should know about cross site request forgery.

  3. Have a look at this link. They provide a toolkit to use encrypted forms, called Open Data Kit.

Are you using OpenSSL?

Community
  • 1
  • 1
Abhishek Deb
  • 883
  • 1
  • 10
  • 24
1

The simplest solution is to enable HTTPS support on your server, and serve the pages only via HTTPS, by turning off the standard HTTP connector.

You won't have to any special development, just switching to HTTPS will ensure that the data cannot be read in transit, and gives the assurance to the viewers of your pages that it's really your server that they are talking with, and not someone doing a man-in-the-middle attack.

The HTTPS technology transparently handles all the concerns that you are trying to handle manually. The browser will exchange with the server a temporary encryption key that is used to encrypt all data sent data back and forth.

The server contains a certificate signed by a certificate authority that is used to sign the data, to prove to browsers that it's really your server.

All of this is handled in a completely transparent and automated way, without any extra development. You just need to contact a certificate authority and get them to create you a certificate, see this tutorial.

You also need to enable HTTPS on the server, this is done via configuration and all servers support it.

Angular University
  • 42,341
  • 15
  • 74
  • 81
0

A "header" is just another encapsulation. There is no difference between that and the abstract idea of "body". One is not inherently more or less safe for carrying data over wire, so your focus should not be on solving this issue. Also, post data technically is in the body.

If security is your objective here, then you will focus on preventing what someone could do if they had privilege in your client/server exchange. Then you would use SSL, http-only cookies (or well thought-out local storage) good session timeouts, and your usual smart coding practices. Generally we should assume most data is viewable in transit, and prioritize against making that privilege even worthwhile for an attacker

If you were really that truly concerned about MITM attacks against your form post data, I suppose you could throw together a little JS to encrypt and maybe even post over web-sockets, but that's akin to not really doing anything at all IMHO.

Zachary Iles
  • 161
  • 7