On multiple lines of defense, how to implement them in your typical web app, and why. Explained on passwords and Cross-Site Scripting.
Datum a akce
19. 3. 2017, Human Inference Kick-Off, Sitges, Spain (délka přednášky 75 minut)
- Uh, huh.
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.
- Yahoo confirms massive data breach
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.
- Yahoo says 1 billion user accounts were hacked
Only three months later, in December 2016, Yahoo released a statement saying that 1 billion accounts were compromised in a different attack in 2013.
- NASDAQ: YHOO 46.29 USD (Mar 15, 2017)
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…
- Verizon will pay $350 million less for Yahoo
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. says
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 →
- Marissa Mayer, Yahoo's chief executive, lost her 2016 bonus and 2017 stock compensation after an investigation into a security breach of user accounts.
Right, that seems quite bad. I'd say Mayer's quality of life has changed a bit.
- Blackmailing, because plaintext passwords
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.
- Ashley Madison
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.
- Ashley Madison: ‚Suicides‘ over website hack
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.
- LinkedIn lost 167 million account credentials in data breach
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.
- Mark Zuckerberg
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.
- Hey, @finkd You were in Linkedin Database with the password „dadada“ ! DM for proof..
In June 2016 a group called OurMine posted Mark's password,
dadada, on his Twitter.
- Digital trail betrays identity of Russian ‚hacker‘ detained in Prague
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.
- SHA-1 hash
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.
- Google SERP
For weak passwords like
dadada, you can even Google the unsalted SHA-1 hash.
- 9× GeForce GTX
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.
- High Performance Cracking Cluster
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?
- Variable binding, HTTPS, Firewalls + The Seven Layers of OSI
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.
- Observatory by Mozilla
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 storage disclosures
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.
- www.slevomat.cz password storage disclosures
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.
- Secure: A, B
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.
- Weak: C, D, E
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“.
- Unsafe: F
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.
- XSS, Cross-Site Scripting
- What is the first published XSS vuln that you are aware of? 1999–07–09 according to our list.
Cross-Site Scripting is not new. According to Open Sourced Vulnerability Database, the first XSS vulnerability was published in 1999.
- $1.2 million
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.
- Man and money
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)>
imgtag 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.
- BeEF: The Browser Exploitation Framework Project
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.
- 2ⁿᵈ line of defense
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.
- „Don't worry, I gotcha…“
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.
- Bunny steals cookie from baby
Speaking of stealing cookies… this is exactly how it works.
- XSS Auditor
Yet another 2ⁿᵈ line of defense is built right into your browser if you use Chrome or Internet Explorer, or Edge. It's not built into Firefox, but again, it's not a primary defense layer. 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-Protectionresponse header. Using
mode=blockis recommended, and will make the browser not display the page at all.
mode=blockis also the default setting since Chrome 57. Previously, the browser tried to clean the page. You can test your browser's XSS auditor on my demo site.
- Response Headers:
<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.comfor 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
onclickmight be dangerous so it is called unsafe. But some libraries and/or tools need it.
- CSP ✅
'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.
- Stop executing scripts on this 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.