So you need to protect yourself. Follow these rules and your online social life won’t become anti-social.
Category Archives: Security Tips
Safe Browsing and Google Analytics: Keeping More Users Safe, Together
Posted by Stephan Somogyi, Product Manager, Security and Privacy
[Cross-posted on the Google Analytics Blog]
If you run a web site, you may already be familiar with Google Webmaster Tools and how it lets you know if Safe Browsing finds something problematic on your site. For example, we’ll notify you if your site is delivering malware, which is usually a sign that it’s been hacked. We’re extending our Safe Browsing protections to automatically display notifications to all Google Analytics users via familiar Google Analytics Notifications.
Google Safe Browsing has been protecting people across the Internet for over eight years and we’re always looking for ways to extend that protection even further. Notifications like these help webmasters like you act quickly to respond to any issues. Fast response helps keep your site—and your visitors—safe.
Pwnium V: the never-ending* Pwnium
Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team
[Cross-posted from the Chromium Blog]
Around this time each year we announce the rules, details and maximum cash amounts we’re putting up for our Pwnium competition. For the last few years we put a huge pile of cash on the table (last year it was e million) and gave researchers one day during CanSecWest to present their exploits. We’ve received some great entries over the years, but it’s time for something bigger.
Starting today, Pwnium will change its scope significantly, from a single-day competition held once a year at a security conference to a year round, worldwide opportunity for security researchers.
For those who are interested in what this means for the Pwnium rewards pool, we crunched the numbers and the results are in: it now goes all the way up to $∞ million*.
We’re making this change for a few reasons:
- Removing barriers to entry: At Pwnium competitions, a security researcher would need to have a bug chain in March, pre-register, have a physical presence at the competition location and hopefully get a good timeslot. Under the new scheme, security researchers can submit their bugs year-round through the Chrome Vulnerability Reward Program (VRP) whenever they find them.
- Removing the incentive for bug hoarding: If a security researcher was to discover a Pwnium-quality bug chain today, it’s highly likely that they would wait until the contest to report it to get a cash reward. This is a bad scenario for all parties. It’s bad for us because the bug doesn’t get fixed immediately and our users are left at risk. It’s bad for them as they run the real risk of a bug collision. By allowing security researchers to submit bugs all year-round, collisions are significantly less likely and security researchers aren’t duplicating their efforts on the same bugs.
- Our researchers want this: On top of all of these reasons, we asked our handful of participants if they wanted an option to report all year. They did, so we’re delivering.
Logistically, we’ll be adding Pwnium-style bug chains on Chrome OS to the Chrome VRP. This will increase our top reward to $50,000, which will be on offer all year-round. Check out our FAQ for more information.
Happy hunting!
*Our lawyercats wouldn’t let me say “never-ending” or “infinity million” without adding that “this is an experimental and discretionary rewards program and Google may cancel or modify the program at any time.” Check out the reward eligibility requirements on the Chrome VRP page.
More Protection from Unwanted Software
Posted by Lucas Ballard, Software Engineer
SafeBrowsing helps keep you safe online and includes protection against unwanted software that makes undesirable changes to your computer or interferes with your online experience.
We recently expanded our efforts in Chrome, Search, and ads to keep you even safer from sites where these nefarious downloads are available.
- Chrome: Now, in addition to showing warnings before you download unwanted software, Chrome will show you a new warning, like the one below, before you visit a site that encourages downloads of unwanted software.
- Search: Google Search now incorporates signals that identify such deceptive sites. This change reduces the chances you’ll visit these sites via our search results.
- Ads: We recently began to disable Google ads that lead to sites with unwanted software.
If you’re a site owner, we recommend that you register your site with Google Webmaster Tools. This will help you stay informed when we find something on your site that leads people to download unwanted software, and will provide you with helpful tips to resolve such issues.
Using Google Cloud Platform for Security Scanning
Posted by Rob Mann, Security Engineering Manager
[Cross-posted from the Google Cloud Platform Blog]
Deploying a new build is a thrill, but every release should be scanned for security vulnerabilities. And while web application security scanners have existed for years, they’re not always well-suited for Google App Engine developers. They’re often difficult to set up, prone to over-reporting issues (false positives)—which can be time-consuming to filter and triage—and built for security professionals, not developers.
Today, we’re releasing Google Cloud Security Scanner in beta. If you’re using App Engine, you can easily scan your application for two very common vulnerabilities: cross-site scripting (XSS) and mixed content.
While designing Cloud Security Scanner we had three goals:
- Make the tool easy to set up and use
- Detect the most common issues App Engine developers face with minimal false positives
- Support scanning rich, JavaScript-heavy web applications
To try it for yourself, select Compute > App Engine > Security scans in the Google Developers Console to run your first scan, or learn more here.
- Parse the HTML and emulate a browser. This is fast, however, it comes at the cost of missing site actions that require a full DOM or complex JavaScript operations.
- Use a real browser. This approach avoids the parser coverage gap and most closely simulates the site experience. However, it can be slow due to event firing, dynamic execution, and time needed for the DOM to settle.