Security Blog
The latest news and insights from Google on security and safety on the Internet
Safe Browsing Diagnostic To The Rescue
15 mai 2008
Posted by Niels Provos
We've been protecting Google users from malicious web pages since 2006 by showing warning labels in Google's search results and by publishing the data via the
Safe Browsing API
to client programs such as Firefox and Google Desktop Search. To create our data, we've built a large-scale infrastructure to automatically determine if web pages pose a risk to users. This system has proven to be highly accurate, but we've noted that it can sometimes be difficult for webmasters and users to verify our results, as attackers often use sophisticated obfuscation techniques or inject malicious payloads only under certain conditions. With that in mind, we've developed a Safe Browsing diagnostic page that will provide detailed information about our automatic investigations and findings.
The
Safe Browsing diagnostic page
of a site is structured into four different categories:
What is the current listing status for [the site in question]?
We display the current listing status of a site and also information on how often a site or parts of it were listed in the past.
What happened when Google visited this site?
This section includes information on when we analyzed the page, when it was last malicious, what kind of malware we encountered and so fourth. To help web masters clean up their site, we also provide information about the sites that were serving malicious software to users and which sites might have served as intermediaries.
Has this site acted as an intermediary resulting in further distribution of malware?
Here we provide information if this site has facilitated the distribution of malicious software in the past. This could be an advertising network or statistics site that accidentally participated in the distribution of malicious software.
Has this site hosted malware?
Here we provide information if the the site has hosted malicious software in the past. We also provide information on the victim sites that initiated the distribution of malicious software.
All information we show is historical over the last ninety days but does not go further into the past. Initially, we are making the Safe Browsing diagnostic page available in two ways. We are adding a link on the
interstitial
page a user sees after clicking on a search result with a warning label, and also via an "additional information" link in Firefox 3's warning page. Of course, for anyone who wants to know more about how our detection system works, we also provide a detailed
tech report [pdf]
including an overview of the detection system and in-depth data analysis.
Contributing To Open Source Software Security
5 mai 2008
Written by Will Drewry
From
operating systems
to
web browsers
, open source software plays a critical role in the operation of the Internet. The security of open source software is therefore quite important, as it often interacts with personal information -- ranging from credit card numbers to medical records -- that needs to be kept safe. There has been a long-lived discussion on whether open source software is inherently more secure than closed source software. While popular opinion has begun to tilt in favor of openness, there are still arguments for both sides. Instead of diving into those treacherous waters (or giving weight to the idea of "inherent security"), I'd like to focus on the fruits of this extensive discussion. In particular, David A. Wheeler laid out a "bottom line" in his
Secure Programming for Linux and Unix HOWTO
which applies to both open and closed source software. It predicates real security in software on three actions:
people need to actually review the code
developers/reviewers need to know how to write secure code
once found, security problems need to be fixed quickly, and their fixes distributed quickly
While distilling anything down to three steps makes it seem easy, this isn't necessarily the case. Given how important open source software is to Google, we've attempted to contribute to this bottom line. As Chris
said before
, our engineers are encouraged to contribute both software and time to open source efforts. We
regularly submit
the results of our automated and manual security analysis of open source software back to the community, including related software engineering time. In addition, our engineering teams frequently release software under open source licenses. This software was written either with security in mind, such as with
security testing tools
, or by engineers well-versed in the
security challenges
of their project.
These efforts leave one area completely unaddressed -- getting security problems fixed quickly, and then getting those fixes distributed quickly. It has been unclear how to best resolve this issue. There is no centralized security authority for open source projects, and operating system distribution publishers are the best bet for getting updates to the highest number of users. Even if users can get updates in this manner, how should a security researcher contact a particular project's author? If there's a potential, security-related issue, who can help evaluate the risk for a project? What resources are there for projects that have been compromised, but have no operational security background?
I'm proud to announce that Google has sponsored participation in oCERT, the
open source computer emergency response team
. oCERT is a volunteer workforce of security professionals from the open source community with the goal of providing security vulnerability mediation and incident response services to open source projects. It will strive to contact software authors with all security reports and aid in debugging and patching, especially in cases where the author, or the reporter, doesn't have a background in security. Reliable contacts for projects, publishers, and vendors will be maintained where possible and used for notification when issues arise and fixes are available for mediated issues. Additionally, oCERT will aid projects of any size with responses to security incidents, such as server compromises.
It is my hope that this initiative will not only aid in remediating security issues in a timely fashion, but also provide a means for additional security contributions to the open source community.
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