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
21 juin 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
17 juin 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
16 juin 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.
Libellés
#sharethemicincyber
#supplychain #security #opensource
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
2024
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2023
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2022
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2021
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2020
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2019
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2018
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2017
déc.
nov.
oct.
sept.
juill.
juin
mai
avr.
mars
févr.
janv.
2016
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2015
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2014
déc.
nov.
oct.
sept.
août
juill.
juin
avr.
mars
févr.
janv.
2013
déc.
nov.
oct.
août
juin
mai
avr.
mars
févr.
janv.
2012
déc.
sept.
août
juin
mai
avr.
mars
févr.
janv.
2011
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
2010
nov.
oct.
sept.
août
juill.
mai
avr.
mars
2009
nov.
oct.
août
juill.
juin
mars
2008
déc.
nov.
oct.
août
juill.
mai
févr.
2007
nov.
oct.
sept.
juill.
juin
mai
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow