hackademix.net

According to an independent study by Google Switzerland, IBM Internet Security Systems and CSG ETH Zurich, Mozilla Firefox users are the safest among web surfers (on average), because they are more likely to be running the latest and most secure version of their browser.
This research analyzed the user agent headers sent with Google search queries beetween January 2007 and June 2008 (lots of data points!), finding that more than 83% of the surveyed Firefox browsers were up-to-date. Safari scored 65.3%, Opera 58.1% and IE, not surprising, was the worst with 47.6% (it should be noticed, though, that IE6 has been considered, rightly, an “insecure version”).

The most important factor in this achievement is probably Firefox’s streamlined patching process, which is painless and hard to avoid: in facts, security updates are downloaded in background and proposed to the user as soon as they’re ready. He can refuse installing (e.g. not to interrupt his work), but as soon as the browser restarts they get installed nonetheless.
There’s obviously room for improvement. For instance, upgrading requires administrative privileges. Therefore, a warning to low-permissions users saying something like “You’re running an outdated version of Firefox, please ask your administrator to upgrade” would be helpful. But even so, Firefox already shows a stunning lead over its competitors.

One of the declared limits of this study is that nothing could be said about browser plugins, universally recognized as an endless source of security pain. Even on this side, though, Firefox has some clear advantages: plugins can be disabled either manually, from the Tools|Add-Ons|Plugins panel, or automatically through a centralized blacklist. Last but not least, if you’re really security minded, you can always adopt a whitelist approach.

Researcher NKTPRO does not like the way Yahoo! manages security reports.

Last year he discovered a XSS Vulnerability in Yahoo! Mail, allowing attackers to steal Yahoo! accounts. After asking for “para-legal” advice, he decided to do the right thing and go for responsible disclosure. Communication was described as “very good” in the beginning, but almost two months later it wasn’t clear if the bug had been fully fixed yet, and no public acknowledgment of the problem nor credits to the reporter were given, anyway.

By contrast, Google maintains a dedicated communication channel for security researchers, is known to fix reported issues very timely and publicly thanks reporters.

Some weeks ago, NKTPRO found another XSS vulnerability affecting Yahoo! blogs, and this one was even worse: persistent, CSS-based and working with IE6, IE7 and Firefox 2 (unless NoScript was installed), it could enable attackers to build worms spreading through Yahoo! networks at a potentially very fast pace. Since our hero is apparently a nice guy, he decided to give Yahoo! a second chance, filing a responsible report again. But after waiting one month, frustrated by its counterpart’s kind of expected (lack of) responsiveness, he gave up and went for full disclosure, greeted by the almost unanimous approval of his fellow sla.ckers.

After full disclosure, the one-month old bug has been fixed in 3 days.

“Full vs responsible disclosure” is a potentially endless debate, but here we can see two different “corporate styles”, Yahoo!’s and Google’s, eliciting different reactions from whitehat hackers and ultimately leading to different results:

1. You can be open about your issues and your security processes, and “reward” reporters, not necessarily with money prizes, which may become dangerous when they feed an anonymous, uncontrolled vulnerability brokerage market. Most of these guys would just appreciate their name attached to your security page, for the glory and something interesting to add to their CV. In turn, you get valuable bug reports with practical proof of concepts, and a reasonable time frame to make your users safer and run regression tests.
2. Or you can decide to discourage confidential reports, either by threatening legal consequences for “testers” or just refusing to give public credit on their findings. It can work once, but as soon as it’s clear that responsible disclosure is not an option, you will be forced into tracking every each full disclosure forum out there and playing catch up in a rush because your vulnerabilities are already public and script kiddies may be busy with your users (good luck with code quality).

So, “big brother” concerns aside, do you feel safer with a Yahoo! Mail account or a GMail one?

The mass SQL injection attacks we talked about in in several posts, being mainly targeted to ASP sites running on Microsoft IIS and backed by Microsoft SQL Server, gathered lots of (quite undeserved) bad press to Microsoft.
Therefore the Microsoft Security Response Center felt the need to do something more than saying “blame developers for their poor coding practice”, and asked the HP Web Security Research Group (formerly SPI Labs) to create a tool helping site owners to identify their SQL injection holes.
So now, after one month of development, HP is announcing Scrawlr, the “SQL Injector and Crawler”.

Scrawlr will crawl a website while simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities. […] It can even provide proof positive results by displaying the type of backend database in use and a list of available table names. There is no denying you have SQL Injection when I can show you table names!

Scrawl can be thought as a free version of the professional scanners in HP’s products portfolio, with some limitations making it suitable for self-diagnosis of your site in the specific context of this kind of non-targeted massive attacks, which usually inject URL query parameters from links, rather than POST requests from forms. In facts, it

• Will only crawl up to 1500 pages
• Does not support sites requiring authentication
• Does not perform Blind SQL injection
• Cannot retrieve database contents
• Does not support JavaScript or flash parsing
• Will not test forms for SQL Injection (POST Parameters)

Scrawl can be dowloaded here.
Of course, once you’ve found your site is vulnerable (and if you’re in doubt, it’s 99% likely to be) you still need to plug your holes.
If you’ve got the budget for a professional code review and cleanup service, just ask :)

For xB Browser, for users running XeroBank, we’ve removed noscript and replaces it with SPP. That allows users to protect against cross-site scripting, and false certificates, without dealing with NoScript issues.

Does anybody know what this XeroBank guy is talking about?

SPP can’t obviously stand for Site Pecurity Policy. It wouldn’t make sense (spelling and grammar aside) because SSP is not meant and not going to replace NoScript anytime soon. The SSP we know does not allow “users to protect against” anything, it just allows compliant web sites to protect their own users (which is great, anyway).

So, any hint about this SPP supposed NoScript killer?

Although all the source code of Firefox is public and can be scrutinized during development at any time, a Tipping Point Security Advisory has been announced right in the middle of the Firefox 3 download day.
A unlucky coincidence, of course: only a conspiracy theorist could suspect that the timing had been chosen in order to maximize the hype effect for the Zero Day Initiative.

However Mozilla developers are working around the clock, and there’s already a patch being privately tested. All the information publicly available so far is that this vulnerability allows a malicious web page to trigger the execution of arbitrary code on the client side, and affects Firefox 2, 3 and likely all the products based on the same rendering engines. Technical details and exploitation proof of concepts are being kept private by Tipping Point as well until the patch is shipped, therefore Mozilla users should be relatively safe: after all we can be 99.99% sure every browser out there is vulnerable to something; we just hope that the bad guys don’t know the details yet.

I can add that, even in this case, NoScript users are the safest.