The document discusses the importance of quality of life in web application security and the implementation of multiple lines of defense against cyber threats. It provides examples of major data breaches and the consequences of poor security practices, emphasizing the need for strong password management and various defense mechanisms, such as cross-site scripting protections. Recommendations include using unique passwords, employing secure hashing techniques, and utilizing advanced security features like content security policy to mitigate vulnerabilities.

1. QUALITY OF LIFEQUALITY OF LIFEMichal ŠpačekMichal Špaček www.michalspacek.comwww.michalspacek.com @spazef0rze@spazef0rze
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.

2. 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.

3. Only three months later, in December 2016, Yahoo released a statement saying
that 1 billion accounts were compromised in a different attack in 2013.

4. 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…

5. 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.

6. 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 →

7. Right, that seems quite bad. I’d say Mayer’s quality of life has changed a bit.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. In June 2016 a group called OurMine posted Mark’s password, dadada, on his Twitter.

14. 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.

15. 0f158e648228a19cab5f23acfd6c36f716a702a9
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.

16. For weak passwords like dadada, you can even Google the unsalted SHA-1 hash.

17. 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.

18. When even a machine full of GPUs is not fast enough, maybe you’ll more machines.

19. 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.

20. https://haveibeenpwned.com
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.

21. Variable binding
HTTPS
Firewalls
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.❤

22. 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.

23. 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/passwords/storages.

24. 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.

25. Slow password hashes + docs
Slow pw hashes + blog, FB, Twitter
SECURE
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.

26. Other hashes + salted + iterations
Other hashes + salted
Other hashes, or encrypted
WEAK
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”.

27. FAILFAILFAILFAILFAILFAIL
UNSAFE
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.

28. XSS
Cross Site Scripting
The concept of multiple lines of defense could also be demonstrated using Cross-
Site Scripting, an attack on users and their browsers. Using XSS, the attacker can
execute their malicious JavaScript downloaded from some other site in the context
of the vulnerable app.

29. Cross-Site Scripting is not new. According to Open Sourced Vulnerability
Database, the first XSS vulnerability was published in 1999.

30. $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.

31. 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.

32. <img src=x onerror=alert(1)>
Cross-Site Scripting happens when a bad guy injects a JavaScript into the page.
They can also inject an img tag with onerror handler, not just a <script> tag.

33. When XSS is demonstrated or reported, it mostly comes as an alert(1). While this
really is a proof that the attacker is able to run JavaScript, it might not be enough to
convince somebody that Cross-Site Scripting is dangerous and deserves a fix.

34. < → &lt;
> → &gt;
" → &quot;
' → &apos;
& → &amp;
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.

35. The Browser Exploitation Framework Project
BeEF
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.

36. 2nd
line of
DEFENSEDevelopers 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.

37. A 2nd
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.

38. Speaking of stealing cookies… this is exactly how it works.

39. To prevent JavaScript from stealing your session cookies, mark them as HTTP-Only
in the app you’ve built. Such cookies will still be sent over the wire, but JavaScript
won’t see them, so an attacker won’t be able to hijack the session using XSS. They
still might be able to sniff the cookie when it’s sent over plain HTTP, though.

40. XSS
Auditor
Yet another 2nd
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.

41. WEB
APP1 2
3
This is how reflected XSS works. The attacker sends a link with some evil JavaScript
in the URL to the user (1), user clicks the link and a request is being sent to the web
application (2). The request includes the JavaScript, which in turn gets injected into
the page and is send back to the user (3) and is executed in their browser. The
browser sees what’s coming back from the application and if it looks like the
JavaScript it sent out with the request then the XSS filter gets triggered, if enabled.

42. 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.

43. mode=block is 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.

44. Content Security Policy is the latest addition to already existing 2nd
lines of defense
against XSS. It’s a response header which provides a list of allowed URLs for the
browser to load images, JavaScript, CSS, etc. from into the page. So even if in the
attacker is able to inject a <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.

45. Content-Security-Policy: default-src 'self'
The Content-Security-Policy response header might look like this basic
example. This will allow JavaScript, images, CSS and some more to be loaded into
the page associated with the header only from 'self', the current origin.

46. 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.

47. Content-Security-Policy:
default-src 'self';
img-src 'self' https://www.google-analytics.com;
script-src 'self'
https://www.google-analytics.com 'unsafe-inline'
The origin for the Google Analytics script can be added to the whitelist too. The inline
JavaScript is also allowed here by using the '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.

48. csp-evaluator.withgoogle.com
Tools like the Google Tag Manager make CSP deployments hard. You need to make
your policy quite open, allow a lot of origins, or hostnames, enable inline JavaScript.
And that’s just making it easier for the attacker to find an opportunity to inject their
code. You can test your policy with CSP Evaluator to see if it can be bypassed. To
make deployments easier, CSP level 3 introduces '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.

49. Michal ŠpačekMichal Špaček www.michalspacek.comwww.michalspacek.com @spazef0rze@spazef0rze
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.