Forum Moderators: buckworks
I have a page:
http://www.mydomain.com/PrequalifyForm
-this has the basic stuff but also ask for SSN, CC, DOB, etc...
I then post this page to:
[sub.domain.domain.com...]
I personally don't think the posted data is secure buy my co-worker does. Who is right?
Thanks.
[edited by: lorax at 11:41 pm (utc) on Nov. 9, 2007]
[edit reason] delinked example [/edit]
Something like:
Browser (User's Data: 12345) -> SSL Transfer (User's Data: %g#nWqgx*8) -> Your Server (User's Data: 12345)
[edited by: ccDan at 10:59 pm (utc) on Nov. 9, 2007]
Javascript/ajax or any other persistent code could capture everything in the clear before its posted over https unless the entire page is in https to begin with.
in face with PCI requirments your will get in deep doodoo if you don't encrypt all pages that accept and or transfer personal information regarding a payment transaction.
http://www.mydomain.com/PrequalifyForm
I then post this page to:
[sub.domain.domain.com...]You would be CORRECT. The form itself is not secure. So it transfers as non-secure data to the secure server. If it is intercepted in transit it's already too late.
A basic rundown: when you have an SSL cert, the browser recognizes the certificate authority and "knows" it's public encrypting algorithm. So when it lands on a secure page, it says, OK, encrypt every request sent from this page.
ccDan's post is almost correct. It is vital that a browser knows how to use an SSL's "public key" to encrypt data prior to being sent. Otherwise what would be the point? Any data submitted by a browser could be intercepted and abused. The SSL server maintains the private key to decrypt the data server-side. The inverse is true when a browser requests a page via SSL: the server sends it encrypted and the browser decrypts it into the plain text/html that you see.
When a page is not on a secure server, or the cert is "broken" somehow, any data posted from it is transfered as plain text. So your co-worker is incorrect.
If an admin page I wrote is in http, but posts to https, the data is secure right?
If someone was capturing the stream from the person entering the data to the form on an http connection protocol, they would get everything. Both the form & destination page for storing the data should both be https to get the encription. Edited to add: as stated by ByronM, rocknbil & ccDan (giving credit, where credit is due)
Is the file recieving the data protected from being able to be accessed from everone? Meaning, could I put in the URL to the file and see it? Just because the file is in a directory, served up by https, does not stop anyone from opening it.
WW_Watcher
[edited by: WW_Watcher at 5:09 pm (utc) on Nov. 16, 2007]
I've actually read the exact opposite, that only the destination page need be in https. What would be involved with "capturing the stream from the person entering the data to the form on an http connection protocol"? Would the capturer have to have access to my system or is being on the Internet enough to pull this off?
I've actually read the exact opposite, that only the destination page need be in https. What would be involved with "capturing the stream from the person entering the data to the form on an http connection protocol"? Would the capturer have to have access to my system or is being on the Internet enough to pull this off?
Many sites use javascript/ajax for form validation - in doing so the form is consistently transferring information back and forth in the clear unless the form/java script is invoked via HTTPS.
There is absolutely NO reason to have a non HTTPS post to a HTTPS because the transaction isn't secured from the get go.
many sites post https for logins so the initial page is in the clear (and no mixed secure/non secure warnings) but that is about all i would do in such a fashion.
I've actually read the exact opposite, that only the destination page need be in https.
Can you point to references? This would absolutely have to be wrong.
What would be involved with "capturing the stream from the person entering the data to the form on an http connection protocol"?
One way is an abuse of port scanning. I'm no hacker so I can't explain the specifics. :-)
The entire idea of SSL is to encrypt data coming from your browser to the server, and vice versa.
It is vital that a browser knows how to use an SSL's "public key" to encrypt data prior to being sent. Otherwise what would be the point?
Remember, you are often transmitting data over thousands of miles of wires, even through the air, sometimes through hundreds of computers. Anywhere in between, someone can attach a covert eavesdropping device and log that data into a file. Think about that. :-)
And some users' browsers might throw a warning as well when posting from non-ssl to ssl. If you can call the page in SSL, do it and it might just save you a few customers
-Corey
