Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

9/15/2016
05:00 PM
Connect Directly
Facebook
Twitter
RSS
E-Mail
50%
50%

Google Chrome To Flag Non-HTTPS Logins, Credit Card Info 'Not Secure'

The move is part of a larger Google push to lock down Web traffic using encryption between the browser and Web server.

Google's Chrome 56 browser as of January 2017 will flag as "not secure" any non-HTTPS sites that transmit password and credit-card information.

Hypertext Transport Protocol Secure (HTTPS) combines the Web's lingua franca hypertext transport protocol with encryption from Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to guarantee the authenticity of a website, protect communication between client and server, and obviate man-in-the-middle attacks.

Currently, Chrome delivers HTTP connections with its neutral indicator, which Google says doesn't reflect the real lack of security in HTTP environments. "When you load a website over HTTP, someone else on the network can look at or modify the site before it gets to you," Chrome Security Team member Emily Schechter wrote in a Sept. 8 blog post. HTTPS usage is on the upswing and that more than half of Chrome desktop page loads are now served over HTTPS, she wrote.

Google Chrome is the most widely used browser in the world, with approximately 54% of the combined desktop and mobile user segments as of August, according to Net Market Share.

Google is also a member of the Let's Encrypt consortium, a certificate authority that aims to lock down the Web via HTTPS. The certificates are available for free and are easily configured, according to the Internet Security Research Group, which provides the certificate service. 

Without giving any timeframes, the vendor says it will also label HTTP pages "not secure" in Incognito browsing mode, where users may believe they have greater privacy than they actually do.

"Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS," Google says.

It's unclear how much this flagging will affect user behavior or increase online security, since as Google itself acknowledges, users don't view the lack of a green-lock secure icon in their browser bar as a warning. Users also get saturated by frequent security warnings.

Generally, when the Chrome team makes a user-visible security and/or privacy change, they do their homework well in advance of shipping, according to Jeremiah Grossman, chief of security strategy for SentinelOne.

"Google likely has solid data that this change will have the necessarily motivational impact to get more website owners to switch to HTTPS," Grossman says. "No Website owner wants to have their visitors presented with some type of scary warning about using their website, so this encourages them to upgrade."

Where does that leave makers of other popular Web browsers? Mozilla says that its Firefox Developer Edition has had similar security warnings since January, "displaying a struck-through lock icon when there is a password field on a non-secure site," according to a Mozilla spokesperson. As a result, Mozilla reports a 20% reduction in presentation of password fields on non-secure pages since January, the spokesperson adds.

Apple did not respond to a request for more information about securing its Safari browser.

Related Content:

 

Terry Sweeney is a Los Angeles-based writer and editor who has covered technology, networking, and security for more than 20 years. He was part of the team that started Dark Reading and has been a contributor to The Washington Post, Crain's New York Business, Red Herring, ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Google Cloud Debuts Threat-Detection Service
Robert Lemos, Contributing Writer,  9/23/2020
Shopify's Employee Data Theft Underscores Risk of Rogue Insiders
Kelly Sheridan, Staff Editor, Dark Reading,  9/23/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-26120
PUBLISHED: 2020-09-27
XSS exists in the MobileFrontend extension for MediaWiki before 1.34.4 because section.line is mishandled during regex section line replacement from PageGateway. Using crafted HTML, an attacker can elicit an XSS attack via jQuery's parseHTML method, which can cause image callbacks to fire even witho...
CVE-2020-26121
PUBLISHED: 2020-09-27
An issue was discovered in the FileImporter extension for MediaWiki before 1.34.4. An attacker can import a file even when the target page is protected against "page creation" and the attacker should not be able to create it. This occurs because of a mishandled distinction between an uploa...
CVE-2020-25812
PUBLISHED: 2020-09-27
An issue was discovered in MediaWiki 1.34.x before 1.34.4. On Special:Contributions, the NS filter uses unescaped messages as keys in the option key for an HTMLForm specifier. This is vulnerable to a mild XSS if one of those messages is changed to include raw HTML.
CVE-2020-25813
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, Special:UserRights exposes the existence of hidden users.
CVE-2020-25814
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, XSS related to jQuery can occur. The attacker creates a message with [javascript:payload xss] and turns it into a jQuery object with mw.message().parse(). The expected result is that the jQuery object does not contain an <a> ...