Crash browser warnings with pseudo-password fields

It seems there is no limit to human ingenuity if you need to get around some kind of restriction. For example, you need to connect the device to an outlet in the center of an inflatable pool - nothing happens, right? Wrong!


Or put out the fire on the other side of the railway tracks. And it is very necessary to stretch a hydrant there, but you can not stop the train - what are the options? None? Wrong again!


')
Noticed the trend? Let's extend it to the digital world and talk a bit about HTTPS.

You must use HTTPS. No, really, if you don’t wrap everything up with HTTPS, you’re doing something wrong. Browser developers are aware of this and are pressing naughty sites to their nails. The pressure especially increased in January, when Chrome and Firefox began to issue warnings at the same time , if the authorization form is transmitted over an insecure channel . Not everyone was happy about this, because ... damn, HTTPS is difficult, right? Not so, but this did not stop the company Oil and Gas International from registering a bug report in Mozilla :

“Your message about the unsafe transfer of a password and / or authorization automatically appears during authorization on our website Oil and Gas International - it is not needed and placed there without our permission. Please remove it immediately. We have our own security system, and it has never been hacked in more than 15 years. Your message is disturbing to our subscribers and is detrimental to our business. ”

It's pretty funny, because “to alarm subscribers and cause damage to business” is exactly what browser developers wanted! This is such a means of action to force organizations to protect their sites when simple common sense does not affect them. (By the way, I think that their 15-year period without hacking was still interrupted when they reported this “bug” and immediately underwent free pentest).

What to do? Well, it is clear that if such warnings interfere with your business, then you need to get rid of them! I'm not joking, some people actually did this:



In fact, I only found out about this yesterday, when one person described a conversation with a representative of the company ShopCambridge.ca:

“I spoke with the owner about using SSL before I signed up for their membership, but the platform developer told her (this is a franchisor’s system called ShopCity.com) that SSL more likely helps Google to monopolize the visibility of the content, rather than providing security.”

Back to ShopCity.com a little later, and now let's try to understand their logic. As you know, security warnings in the browser appear only if the input type attribute is set to "password". If so, then the idea arises - to create what looks like a form for entering a password, but in fact it is not:

<input id="pw" placeholder="Password" name="pw" maxlength="100" class="textbox" style="width:230px;margin-bottom:5px;" onclick="javascript:this.placeholder='';" type="textbox"> 

It only says "Password", and in fact the "textbox" attribute is set there. There is a single CSS class for some styling, but if you enter the cursor in the field, magic happens:

 <script> jQuery(document).on('click', '#pw', function() { jQuery(this).addClass('text-security'); }) </script> 

And here we have a completely new class in the field. And of course, the onclick event in the input field sets the placeholder text as an empty string. So what makes this new class? It just changes the font:

 .text-security { font-family: 'text-security-disc'; } 

And as you might have guessed, this “font” is nothing but the only symbol of the circle that you usually see when you enter the password in the correct password form. Everything should work in this order, because otherwise the placeholder does not show the inscription "Password", and you just see 8 circles for letters. And if everything is connected together, then the appearance of the password field is created, but since this is not a password field, then there are no browser warnings! It's like magic! More precisely, this is a pseudo-password field for cheating users so that they do not see the browser warning.

Both the script for adding a class and CSS for a font are embedded side by side into the page source, like some kind of an afterthought:



In general, this JS and CSS block is there twice, once on line 1111, and another time on line 1156. The most likely explanation that comes to my mind is that somewhere during this year, when security warnings started appearing at all unprotected sites, somewhere made some enterprising developer: "I know how to fix it!". O, and by the way, the font used was created at least two and a half years ago, which was much earlier than the security warnings appeared in browsers that this “patch” had to fix.

This is really ridiculous and could not be a coincidence. I mean, there were no other design decisions, after which a hack appeared as a by-product with the concealment of security warnings in browsers. It was a deliberate attempt to hide from the screen information that is valuable from a security point of view - it was made specifically to protect users. Fortunately, such nonsense no longer works in Chrome 62 and, as I wrote in the recent article Happy Path to HTTPS , this behavior will gradually become available to all users:



Ideally, the Firefox browser will also duplicate this patch, and Scott Helme has already registered a bug in Mozilla about the dubious behavior of ShopCambridge.ca . But it is clear that the crux of the problem lies in the fundamental lack of understanding of technology by developers of the franchisor ShopCity.com . If you remember, I mentioned them in the first message I received from one reader, and you can see the same hack on other sites of their platform, such as ShopMidland.com . When you try to download any of the unsafe sites on HTTPS, it issues an invalid certificate, in the case for ShopCity.com this:



Although it is not for ShopCity.com, but for Secure.ShopCity.com, so if you try to download https://www.shopcity.com , you will get another security exception, because, of course, the certificate is invalid! So I tried to download https://secure.shopcity.com instead, but here the certificate also (a little) does not work:



It seems that they simply do not care about the secure delivery of content, which returns us to the previous comment: "SSL rather helps Google to monopolize the visibility of the content, rather than providing security." I have heard this before from a person who can only be called an anti-vaccination agent in the technological world, he releases comments like these :

Google is just evil because it is a giant. He went to f ** c.

He explained that because of a bad code on the backend, the site can be hacked even with SSL, but the green lock remains misinforming users, so HTTPS is useless. If you search for the SSL tag in my blog, you can find surprisingly many similar statements that SSL is just a gangster protection from Google.

I actually contacted ShopCity.com and asked why they were behaving in this way , but at the time of publication I did not get an answer.

So what do these guys do? In fact, the answer is very simple:


For those who want to switch to HTTPS, see the 6-step guide "Happy Path" to HTTPS , which I have already mentioned. Now it is easier than ever and you don’t even need to fool your users!