Home => Submitting Data
|[Formatted for Printing]||From the personal web site of Michael Horowitz|
Created: February 27, 2020 | Updated Dec 30, 2020 | Updated: Oct 14, 2020
This page is "secure" which means that it was sent to you using HTTPS, which, in turn, means that it was encrypted in-flight between my web server and your computer. Fine. But what does that say about the data someone enters on this page?
The fact that a web page was downloaded to you securely (HTTPS) implies nothing about how data entered on that page is uploaded. Don't believe me? I don't blame you. But, it's true. And yes, this means you have been lied to for years about secure web pages/sites. Many many years. The forms below illustrate my point.
The HTTPS Submit button below works as expected, whatever data you type is uploaded using HTTPS and you end up at a secure web page on this site. Boring.
However, the HTTP submit button below uploads the data you enter to a non-existing page on my JavaTester.org website. You get a 404 error because the web page does not exist. That is irrelevant to the issue at hand. YOU SHOULD GET AN ERROR (or warning) THAT DATA IS BEING SUBMITTED INSECURELY VIA HTTP. Most browsers (test results are below) fail to warn the user. (I would have sent the data to a valid HTTP web page, but I don't have one. All my websites use nothing but HTTPS.)
Here is the underlying HTML for these two forms. In the first one, the FORM ACTION specifies HTTPS, in the second one it uses HTTP.
- - - - - - - - - - - - - - - - - - - - - -< form action="http://JavaTester.org/insecuretestpage.php" method="post">
- - - - - - - - - - - - - - - - - - - - - -
I find this quite ironic. When it comes to data being sent from a web server computer to you, the browsers are quite strict, but in the other direction, the direction where passwords travel ... not so much.
To illustrate the strict security of incoming/downloaded data, realize that although a web page may appear to be a single thing, under the covers it is composed of many individual components. The most obvious components are the images. Each image is fetched individually. For a web page to be considered "secure" by a web browser, all the images need to have been retrieved using HTTPS. If one of them was, instead, included using HTTP, then the page is considered Mixed Mode (or mixed content) and many browsers will issue a warning.
I created a sample web page that does exactly this (see mixedmode.php) so you can see the warnings, if any, from your web browser. There are warnings about insecurely retrieving images, but none about insecurely transmitting a password. Go figure.
Windows 10: Firefox version 73 (current as of Feb. 2020) warns: "The information you have entered on this page will be sent over an insecure connection and could be read by a third party. Are you sure you want to send this information?"
Android 10: Firefox (version 68.5.0) and Firefox Focus (version 8.0.26) warn with the same text, but different colors. The warning is exactly the same as Firefox on Windows.
iOS 13.3.1: Safari warns "This form is not secure. Are you sure you want to submit it?" This was tested in February 2020 with the then-current version, but I could not figure out, specifically, which version of Safari it was.
I am told by a trustworthy source that Safari on macOS does warn about this. I don't have exact details on versions of Safari or macOS.
The following web browsers fail to warn about the insecure data transmission and instead go directly to the non-existing page. They result in the Page Not Found error shown above.
Google has struggled like heck to close this security flaw on desktop OSs.
To be fair, some web browsers are not ALL bad. Take, for example, Chrome 80 on Windows. While it does not issue an obvious in-your-face warning, it does detect the possible insecure data transmission and it makes a small change to the address bar. Below we see three different indicators Chrome uses.
On the top, it is displaying the fully secure page, my blog about hovering the mouse over a link. Don't you miss green for indicating a good state? On the bottom it is viewing my Mixed Mode tester page which it detects as obviously not secure. This page is in the middle and I am pretty sure that no one will have any clue what the "i" in a circle means. If you click it, Chrome says "Your connection to this site is not fully secure." Useless words that convey no information.
On Android 9, however, Chrome is not so indicating. As the screen shots below indicate, both the Mixed Mode page and this page display exactly the same in the address bar.
And, anyone who uses multiple browsers and/or multiple operating systems will never be able to track the meaning of the assorted icons used by different browsers.
I first wrote about this back in January 2006 How Secure Is That Web Page In The Window?. Back then, Firefox version 3 had an option about this, you could be warned, or not, about submitting information that was not encrypted. Firefox version 4 made it harder to control this. Interestingly, the warning from Firefox back then is exactly the same warning that it issues today.
That blog was prompted by an episode of the Security Now podcast with Steve Gibson from late in 2005. Interestingly, even after that podcast, Gibson's own personal website (grc.com) suffered from this problem. The site was all HTTPS but, on at least one page, it used HTTP to submit data.
Leo Notenboom also wrote about this, back in July of 2008: How Can an Https Website Still Not Be Secure?. He revised the article on March 18, 2020.
Internet Explorer, now part of history, gets mixed reviews. In February 2020, I tested IE 11 running on Windows 7.
The good news is that IE issues a warning (shown below) when HTTP is used to send data from an HTTPS page.
Bad news awaits however. If you click the More Info button, you end up with the following Question and Answer which is full of lies.
Updated Oct 14, 2020. The insecure data submission now goes to my old JavaTester.org site. In early 2020, I gave up my FlashTester.org site which was used originally. Also added that Chrome version 87 is supposed to finally warn about this.
|@defensivecomput||TOP||Home => Submitting Data|
|michael--at--michaelhorowitz.com||Last Updated: December 30, 2020 5PM UTC|