Yep, that's me fixing some security issues while on vacation. This talk is about quality of life, multiple lines of defense, how to implement them in your typical web app, and why. Explained on passwords and Cross-Site Scripting. This slide deck contains extra speaker notes not available in the original deck.
In September 2016, Yahoo confirmed a 500 million accounts leak. The breach is said to have occurred in late 2014. It has changed lives of quite a few people.
Only three months later, in December 2016, Yahoo released a statement saying that 1 billion accounts were compromised in a different attack in 2013.
I'm not a market expert, but this stock price chart says Yahoo is doing quite fine. Obviously the breach had no influence on the stock price. But…
In July 2016, before the breaches were disclosed, Verizon announced its intent to acquire Yahoo's Internet business for $4.8 billion. On February 21, 2017, Verizon agreed to lower its purchase price for Yahoo by $350 million, and share liabilities regarding the investigation into the data breaches. Talk about losing money.
Russian agents were behind Yahoo hack, U.S. said in March 2017. I don't want to go into attribution business but let's focus on the small text below the picture →
Right, that seems quite bad. I'd say Mayer's quality of life has changed a bit.
A friend of mine called me some time ago, his voice shaking. He told somebody has hacked a legacy site his company had built. Unfortunately the site stored user passwords just like this and the attacker said he'd publish the database unless the company pays a ransom. That friend and his team had to work 24/7 for a few days to fix the app and some others. Life quality reduced. Eventually they didn't pay the ransom, and fortunately database was not released.
In summer 2015 a group or an individual named The Impact Team released 25 GB of company and user data taken from Ashley Madison, a Canadian dating site marketed to people who are married or in committed relationships. Not every user of the site had an affair, but most of the media presented the incident as “database of cheaters leaked”. Days after the data was published a lot of Ashley Madison users started to be blackmailed: “send bitcoinz and we will not tell your partner you had an account with Ashley Madison,” or “send bitcoinz and we will tell you whether your partner had an account, or not.” The hack made a mess of lot of lives.
Supposedly two Ashley Madison users commited suicide because of the hack. One of them was an american pastor, the other one a man my friend had talked to. Some other suicides eventually couldn't be confirmed as events linked to the leak, like the San Antonio police captain case.
In 2012, LeakedIn, I mean LinkedIn lost 6.5 million usernames and hashed passwords but in May 2016 it became apparent that the leak was much bigger than originally thought. It was 167 million credenentials in total. The company discovered the full extent only after somebody tried to sell the whole database dump.
This is Mark. Mark runs Facebook. Mark used the same password for LinkedIn, Pinterest, and Twitter. Don't be like Mark a don't use the same password for multiple services. Use strong unique passwords. Use a password manager to generate and keep your passwords. Have a backup plan in case you forget the master password.
In June 2016 a group called OurMine posted Mark's password,
dadada, on his Twitter.
Da in Russian means Yes. And guess what? This guy, Yevgeny Nikulin, a Russian national detained in downtown Prague, Czech Republic on October 5, 2016, is accused by American officials of hacking U.S. targets. Coincidence much, da.
Zuckerberg's password was stored hashed in the LinkedIn dump, this is the hash. But when passwords are hashed with unsalted SHA-1, it's quite easy to crack them.
For weak passwords like
dadada, you can even Google the unsalted SHA-1 hash.
When a Google search is not enough, or if you want to crack passwords for living, you'll need machine full of GPUs, like this one built by Jeremi Gosney and his company Sagitta HPC. It generates tens of billions of SHA-1 hashes per second.
When even a machine full of GPUs is not fast enough, maybe you'll more machines.
These Sagitta HPC guys are crazy. Now they're ordering their GPUs by kilos. So this is how 300 kg of NVIDIA GeForce GPUs looks like.
';-- have i been pwned?
Use Have I been pwned? to see if your account has been compromised in a public data breach. You can also set up notifications or search across an entire domain.
Security is not just “buy this box and plug it in the network”. When transmitting and receiving, the data goes through several layers. Each of the layers needs their own protection. A site using HTTPS to encrypt the traffic can still be hacked and have the database dumped. Users get phished on sites using HTTPS. But we still ❤ HTTPS.
Use Observatory by Mozilla to scan some of the layers, it will offer few hints to make them more secure. It scans HTTP headers, cookies, etc., and optionally includes results from third-party scanners, like the SSL Labs Server Test.
Password hashing, a second line of defense, protects users and their passwords when databases leak. Database leaks shouldn't happen, but they do. Multiple lines of defense offer protection when something goes wrong. I've actually started collecting info on how companies store user passwords. The collection is available at https://pulse.michalspacek.cz/…rds/storages.
Here's a Czech company using bcrypt. Their disclosure has been rated “A”. They have also provided historical info and some details in their FAQ. I always link to a public disclosure, so the site is actually more like a collection of links to who said what. Disclosure: I worked for Slevomat.cz in 2013–2014.
My scoring system is inspired by the SSL Labs Server Test rating and it works like this: the better the hashing algorithm is and the better the disclosure is, the better score the site gets. So if a site uses bcrypt (or PBKDF2, scrypt, or Argon2) and they tell us in their docs, they score “A”. If they tell us only in a blog post, talk, or on a social media they score “B”, because a talk or a blog post is quite invisible. Both “A” and “B” are scores for safe password storage.
A site scores “C” if they use unsuitable hashes like MD5 or SHA-1 with a salt and multiple iterations. They score “D”, if they hash passwords with one iteration of an unsuitable hashing function, with a salt. Grade “E” is for when they use plain fast hashes or encrypt passwords. Users are strongly advised to create unique passwords for sites with these scores, especially for sites with “D” or “E”.
Last but not least, “F” is for total failure, and that's when the site stores passwords just like this, in plaintext. When signing up for the service, users should, and I mean SHOULD use a unique password, not used anywhere else.
Cross-Site Scripting is not new. According to Open Sourced Vulnerability Database, the first XSS vulnerability was published in 1999.
Just in 2014–2016 Google has awarded researchers over $1.2 million for reporting XSS bugs in their applications via Google's Vulnerability Reward Program. Not bad.
A man, left, and $1M in $100 bills, right, according to PageTutor. Feels like it fits in a shoe box, right? This is roughly what Google has paid for XSS for 2 years.
<img src=x onerror=alert(1)>
img tag with onerror handler, not just a
When XSS is demonstrated or reported, it mostly comes as an
When developers forget to convert these special characters, mostly the first four lines, in user input to HTML entities, that's when bad things (and XSS) happens.
But XSS is much more than just
alert(1). Meet BeEF, the XSS framework. It comes with some 300 predefined modules, like fake Flash update notifications, fake login windows, code to take screenshots of pages, or play an audio file.
Developers quite often forget to escape special characters in input, and will keep doing so. Because deadlines, bad coffee, or one too many beers. So we need this.
A 2ⁿᵈ line of defense, like this one, might not work for all cases and/or users, but when primary defense layer fails it might just save your life. Or cookies.
Speaking of stealing cookies… this is exactly how it works.
PHPSESSID HTTP-Only cookie
Yet another 2ⁿᵈ line of defense was built right into your browser if you used Chrome or Internet Explorer, or Edge. It's not built into Firefox, but again, it's not a primary defense layer. It was removed from Chrome, Chromium, Edge in version 78. The XSS auditor, or XSS filter, prevents the reflected variant of XSS.
:-| → 1 →
:-) → 2 → App → 3 →
X-XSS-Protection: 1; mode=block
You can control the XSS filter by the
X-XSS-Protection response header. Using
mode=block is recommended, and will make the browser not display the page at all.
mode=block was also the default setting in Chrome 57–73. Previously, the browser tried to clean the page (and Chrome 74+ does that too, until the whole feature was removed in Chrome 78). You can test your browser's XSS auditor on my demo site, check the devtools console error message too.
<script> tag into the HTML the browser will not load the code from the specified URL provided the host or path is missing from the whitelist.
Content-Security-Policy: default-src 'self'
'self', the current origin.
Content-Security-Policy: default-src 'self'; img-src 'self' https://www.google-analytics.com
The header can be extended by allowing images also from
https://www.google-analytics.com for the Google Analytics tracking script to work properly. The script itself would need to be loaded from current origin now, and that's not how it works.
Content-Security-Policy: default-src 'self'; img-src 'self' https://www.google-analytics.com; script-src 'self' https://www.google-analytics.com 'unsafe-inline'
'unsafe-inline' directive. Yes, the JS code written directly in the HTML using
<script> tags or handlers like
onclick might be dangerous so it is called unsafe. But some libraries and/or tools need it.
'strict-dynamic' which makes the browser ignore host-based whitelists, and only works with nonces. But enables the already allowed script to load more scripts without actually extending the policy. See how
'strict-dynamic' works and test it on my CSP3 demo page.
To err is human, obviously, so please think about multiple lines of defense when building apps because even 20 years old attacks are still hot and dangerous.