This is a cache of https://security.googleblog.com/2011/06/. It is a snapshot of the page as it appeared on 2025-08-19T16:21:47.402+0200.
Google Online Security Blog: June 2011
Security Blog
The latest news and insights from Google on security and safety on the Internet
Introducing DOM Snitch, our passive in-the-browser reconnaissance tool
June 21, 2011
Posted by Radoslav Vasilev, Security Test Engineer
(Cross-posted from the
Google Testing Blog
)
Every day modern web applications are becoming increasingly sophisticated, and as their complexity grows so does their attack surface. Previously we introduced open source tools such as
Skipfish
and
Ratproxy
to assist developers in understanding and securing these applications.
As existing tools focus mostly on testingserver-side code, today we are happy to introduce
DOM Snitch
— an experimental* Chrome extension that enables developers and testers to identify insecure practices commonly found in client-side code. To do this, we have adopted
several approaches
to intercepting JavaScript calls to key and potentially dangerous browser infrastructure such as document.write or HTMLElement.innerHTML (
among others
). Once a JavaScript call has been intercepted, DOM Snitch records the document URL and a complete stack trace that will help assess if the intercepted call can lead to cross-site scripting, mixed content, insecure modifications to the
same-origin policy for DOM access
, or other client-side issues.
Here are the benefits of DOM Snitch:
Real-time:
Developers can observe DOM modifications as they happen inside the browser without the need to step through JavaScript code with a debugger or pause the execution of their application.
Easy to use:
With built-in
security heuristics
and nested views, both advanced and less experienced developers and testers can quickly spot areas of the application being tested that need more attention.
Easier collaboration:
Enables developers to easily export and share captured DOM modifications while troubleshooting an issue with their peers.
DOM Snitch is intended for use by developers, testers, and security researchers alike.
Click here
to download DOM Snitch. To read the documentation, please visit
this page
.
*Developers and testers should be aware that DOM Snitch is currently experimental. We do not guarantee that it will work flawlessly for all web applications. More details on known issues can be found
here
or in the project’s
issues tracker
.
Protecting users from malware hosted on bulk subdomain services
June 17, 2011
Posted by Oliver Fisher, Google Anti-Malware Team
Over the past few months, Google’s systems have detected a number of bulk subdomain providers becoming targets of abuse by malware distributors. Bulk subdomain providers register a domain name, like example.com, and then sell subdomains of this domain name, like subdomain.example.com. Subdomains are often registered by the thousands at one time and are used to distribute malware and fake anti-virus products on the web. In some cases our malware scanners have found more than 50,000 malware domains from a single bulk provider.
Google’s automated malware scanning systems detect sites that distribute malware. To help protect users we recently modified those systems to identify bulk subdomain services which are being abused. In some severe cases our systems may now flag the whole bulk domain.
We offer many services to webmasters to help them fight abuse, such as:
Webmaster Tools
lets webmasters find examples of URLs under their domains that may be distributing malware.
Google Safe Browsing Alerts for Network Administrators
allows owners of Autonomous Systems to get notifications for hosts that are involved in malware delivery.
If you are the owner of a website that is hosted in a bulk subdomain service, please consider contacting your bulk subdomain provider if Google SafeBrowsing shows a warning for your site. The top-level bulk subdomain may be a target of abuse. Bulk subdomain service providers may use Google’s tools to help identify and disable abusive subdomains and accounts.
Trying to end mixed scripting vulnerabilities
June 16, 2011
Posted by Chris Evans and Tom Sepez, Google Chrome Security Team
A “mixed sc
ripting” vulnerability is caused when a page served over HTTPS loads a script, CSS, or plug-in resource over HTTP. A man-in-the-middle attacker (such as someone on the same wireless network) can typically intercept the HTTP resource
load and gain full access to the website loading the resource. It’s often as bad as if the web page hadn’t used HTTPS at all.
A less severe but similar problem -- let’s call it a “mixed display” vulnerability -- is caused when a page served over HTTPS loads an image, iFrame, or font over HTTP. A man-in-the-middle attacker can again intercept the HTTP resource load but normally can only affect the appearance of the page.
Browsers have long used different indicators, modal dialogs, block options or even click-throughs to indicate these conditions to users. If a page on your website has a mixed scripting issue, Chromium will currently indicate it like this in the URL bar:
And for a mixed display issue:
If any of the HTTPS pages on your website show the cross-out red https, there are good reasons to investigate promptly:
Your website won’t work as well in other modern browsers (such as IE9 or FF4) due to click-throughs and ugly modal dialogs.
You may have a security vulnerability that could compromise the entire HTTPS connection.
As of the first Chromium 14 canary release (14.0.785.0), we are trialing blocking mixed scripting conditions by default. We’ll be carefully listening to feedback; please leave it on
this Chromium bug
.
We also added an infobar that shows when a script is being blocked:
As a user, you can choose to reload the website without the block applied. Ideally, in the longer term, the infobar will not have the option for the user to bypass it. Our experience shows that some subset of users will attempt to “click through” even the scariest of warnings -- despite the hazards that can follow.
Tools that can help website owners
If Chromium’s UI shows any mixed content issues on your site, you can try to use a couple of our developer tools to locate the problem. A useful message is typically logged to the JavaScript console (Menu -> Tools -> JavaScript Console):
You can also reload the page with the “Network” tab active and look for requests that were issued over the http:// protocol. It’s worth noting that the entire origin is poisoned when mixed scripting occurs in it, so you’ll want to look at the console for all tabs that reference the indicated origin. To clear the error, all tabs that reference the poisoned origin need to be closed. For particularly tough cases where it’s not clear how the origin became poisoned, you can also
enable debugging to the command-line console
to see the relevant warning message.
The latest Chromium 13 dev channel build (13.0.782.10) has a command line flag:
--no-running-insecure-content
. We recommend that website owners and advanced users run with this flag, so we can all help mop up errant sites. (We also have the flag
--no-displaying-insecure-content
for the less serious class of mixed content issues; there are no plans to block this by default in Chromium 14).
The Chromium 14 release will come with an inverse flag: --allow-running-insecure-content, as a convenience for users and admins who have internal applications without immediate fixes for these errors.
Thanks for helping us push website security forward as a community. Until this class of bug is stamped out, Chromium has your back.
Labels
#sharethemicincyber
#supplychain #security #opensource
AI Security
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux
kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2025
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2024
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Aug
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2010
Nov
Oct
Sep
Aug
Jul
May
Apr
Mar
2009
Nov
Oct
Aug
Jul
Jun
Mar
2008
Dec
Nov
Oct
Aug
Jul
May
Feb
2007
Nov
Oct
Sep
Jul
Jun
May
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow