Category Archives: browser security

The Twelve Web Security Truths

Posted on
Reply

My current writing project has taken time away from adding new content lately. Here’s a brief interlude of The Twelve Web Security Truths I’ve been toying with as a side project. They are modeled on The Twelve Networking Truths from RFC 1925.

  1. Software execution is less secure than software design, but running code has more users.
  2. The time saved by not using parameterized queries to build SQL statements should be used to read about using parameterized queries.
  3. Same Origin Policy restricts the DOM access and JavaScript behavior of content loaded from multiple origins. Malware only cares about plugin and browser versions.
  4. Content like XSS exploits are affected by the Same Origin Policy, which is nice for XSS attacks that inject into the site’s origin.
  5. CSRF countermeasures like Origin headers mitigate CSRF, not XSS. Just like X-Frame-Options mitigates clickjacking, not XSS.
  6. Making data safe for serialization with JSON does not make the data safe for the site.
  7. There are four XSS vulns in your site today. Hackers will find two of them, the security team will find one, the dev team will introduce another one tomorrow.
  8. Blacklists miss the payload syntax that works.
  9. A site that secures user data still needs to work on the privacy of user data.
  10. Hashing passwords with 1000-round PBKDF2 increases the work factor to brute force the login page by a factor of 1. Increasing this to a 10,000-round PBKDF2 scheme provides an additional increase by a factor of 1.
  11. The vulnerabilities in “web 2.0″ sites occur against the same HTML and JavaScript capabilities of “web 1.0″ sites. HTML5 makes this different in the same way.
  12. A site is secure when a compromise can be detected, defined, and fixed with minimal effort and users are notified about it.
  13. Off-by-one errors only happen in C.

Enjoy. And stick around for (the not quite yet imminent arrival of) new content. Thanks for reading!

"Mozilla Sniffer" Add-on Tests Security of Security Testers

Posted on
Reply

An article on Netcraft describes the discovery of a back door that wheedled its way into the popular Web Application Security Penetration Testing collection of Firefox Add-ons.

The attacker exhibited some degree of mad genius by claiming the Add-on fixed problems with the very popular Tamper Data add-on — popular, it’s worth nothing, among security testers and web developers.

The back door was discovered by chance when a vigilant user noticed his browser sending HTTP traffic to an unknown web site. (Check out the article for more details.)

This would make a great example for Chapter Seven, Malware and Browser Attacks, of The Book. Whereas many attacks target vulnerabilities in plugins like PDF readers or Flash player, there has not been as great a number of (observed) back-doored or otherwise malicious plug-ins.

Mozilla Sniffer may be the first back-doored Add-on for Firefox, but it’s not the first one to be malicious. In December 2008 an Add-on dully labeled, “Basic Example Plugin for Mozilla,” was discovered to be siphoning users’ banking credentials from the browser.

Malicious plug-ins are a natural evolution of malware authors’ endeavors to pull valuable data from the browser. Plug-ins are cross-platform and don’t require buffer overflows or privileged access (other than having the user install it). In another sense these attacks are not really a dramatic evolution, but a small speciation of a well-established tactic1. As browser computing becomes more analogous with desktop computing the risks have simply shifted from downloading and installing an unverified .exe file to installing some unverified JavaScript as a browser extension.

Watch for more malicious plug-ins to follow the steps of Mozilla Sniffer. One improvement will likely be in the command-and-control channel. A more subtle plug-in might only launch on random pages or random times in order to decrease detection. Or the plug-in might have a pre-defined list of strings (bank, check-out, credit card, password) that cause it to trigger — although Mozilla Sniffer already did this. The plug-in could even check a twitter feed or a URI shortener to dynamically load commands or report its data to a twitter feed rather than a static IP address.

=====
1 If you don’t believe in evolution then blame Noah for bringing a pair of hackers aboard the Ark. He squeezed them between the penguins and the dinosaurs. I personally doubt this account of history because of the dubious possibility of hackers breeding.