Tag Archives: Security

The target=”_blank” phishing attack vector

If you use target=”_blank” you need to also use rel=”noopener noreferrer”

 

Ben Halpern writes:

If you use the target=”_blank” attribute on a link, and do not accompany it with a rel=”noopener” attribute, you are leaving your users open to a very simple phishing attack.

When a website uses target=”_blank” on their links in order to open a new tab or window, that website gives the new page access to the existing window through the window.opener API, allowing it a few permissions. Some of these permissions are automatically negated by cross-domain restrictions, but window.location is fair game.

In order to restrict the behavior window.opener access, the original page needs to add a rel=”noopener” attribute to any link that has target=”_blank”. However, Firefox does not support that tag, so you should actually use rel=”noopener noreferrer” for full coverage. Some amount of prevention can be acheived through scripting, though, as observed with Twitter, this seems to fail on Safari.

Read more from The Practical Developer

How To Safely Hash A Password

If you’re not using bcrypt get with it or be vulnerable

 

Coda Hale writes:

Use bcrypt.

Why Not {MD5, SHA1, SHA256, SHA512, SHA-3, etc}?

These are all general purpose hash functions, designed to calculate a digest of huge amounts of data in as short a time as possible. This means that they are fantastic for ensuring the integrity of data and utterly rubbish for storing passwords.

A modern server can calculate the MD5 hash of about 330MB every second. If your users have passwords which are lowercase, alphanumeric, and 6 characters long, you can try every single possible password of that size in around 40 seconds.

For PHP 5.5, use password_hash(). For PHP 5.3.7 through PHP 5.4.x use the password_compat polyfill on GitHub.

Read the full article at codahale.com

An Introduction to Content Security Policy – HTML5 Rocks

Mike West runs through everything you need to know about Content Security Policy

 

Instead of blindly trusting everything that a server delivers, CSP defines the Content-Security-Policy HTTP header that allows you to create a whitelist of sources of trusted content, and instructs the browser to only execute or render resources from those sources. Even if an attacker can find a hole through which to inject script, the script won’t match the whitelist, and therefore won’t be executed.

Read more from the source: HTML5 Rocks – A resource for open web HTML5 developers

The Moonpig Bug: How 3,000,000 Customers’ Details Were Exposed

Some idiot thought that instead of OAuth tokens or the like, “let’s use the integer user id as proof that the user logged in ok”

 

It’s been all over the British news today: developer Paul Price found a bug in photo-crap-maker Moonpig’s site, one that might have exposed three million users’ personal information. Paul’s got a great technical post about it at http://ifc0nfig.com/moonpig-vulnerability/ — but there’s no decent non-techie explanation except for the one-paragraph summaries in newspapers. It was a perfect storm of tech incompetence: here’s how to avoid doing it yourself.

Watch Tom Scott’s video at youtube.com

Heartbleed, Shellshock and now Poodlebleed: are we safe on the web?

Use this online test to check your server then use Firefox and set security.tls.version.min to 1

 

Luke Rehmann explains:

Poodlebleed is a vulnerability in the design of SSL version 3.0. Poodle is actually an acronym for Padding Oracle On Downgraded Legacy Encryption. The vulnerability allows the decryption to plaintext of secure connections. The bug was discovered by Google Security Team researcher Bodo Möller in collaboration with Thai Duong and Krzysztof Kotowicz.

Read more at poodlebleed.com