Security & Authentication

CSCI 344: Advanced Web Technologies

Fall 2024

Announcements

1. This Friday (12/6): Quiz 2 review during class
2. HW5 due next Tuesday (12/10) at midnight
3. Office hours next week:
• Monday-Wednesday (12/9-12/11): Appointment slots from 12-2PM for individual help
• Mon-Th (12/9-12/12): “Open office hours” from 2-3PM
4. Take home Quiz 2 released on Wednesday morning (12/11), due Friday at midnight.
5. All late work must be submitted by next Friday, 12/13

Outline

• Security considerations
• Authentication strategies

Outline

• Security considerations
• Authentication strategies

Securing Data that You’re Collecting Over the Web

When you create a web application that gathers and stores user-generated data, what are your obligations?

Your Thoughts Here…

​

• Use the best methods to keep data private from other people.
• Be aware of the laws: keeping private info private (HIPPA)
• Hash the password
• Turn it into a jumbled string when you encode it.
• Developer clearance

Some Privacy, Security, and Ethical Considerations

1. Hashing DB Passwords
2. Protecting Data against unauthorized Use
3. Protecting against SQL injection attacks.
4. Using HTTPS
5. CSRF protection
6. XSS protection
7. Terms of Service

1. Hashing DB Passwords

• What is hashing?
• Why would it be important to hash passwords and not store them in plaintext?

2. Protecting Data Against Unauthorized Use

How do you safeguard this?

• Automated tests to ensure that the the queries are correct
• Locked server rooms / SSH access (clearance levels)
• Ensuring that your users understand whether and how their data might be shared.
• Anything else?

3. Protection from SQL Injection

If you don’t “sanitize” your query parameters, malicious hackers can append malicious SQL at the end of a request.

• ?q=beyonce; DELETE FROM users; DELETE from posts; DELETE FROM following;

​

Note that using SQLAlchemy models / helper functions will protect against SQL Injection attacks “for free.”

​

4. Using HTTPS

• HTTPS is the secure version of HTTP that is encrypted
• Only the client and the specific web server can encrypt / decrypt the message.
• For a web provider to set up HTTPS on a server, they need to register with a trusted certificate authority.
• Most web providers offer HTTPS configuration services for you (for free).
• Learn more below (and in the cybersecurity class)�

Read More

• https://www.cloudflare.com/learning/ssl/what-is-https/
• https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

5. CSRF (Cross-Site Request Forgery): What is it?

A way for a script or action to take advantage of a privileged session of another browser application.

As stated in this video, “CSRF hackers craft malicious ways to induced privileged users to perform unwanted actions by taking advantage of browser-target trust.”

5. CSRF Attack (GET): Example

1. You are logged into wellsfargo.com in one browser tab
2. You are logged into Reddit on another platform.
3. Malicious user disguises a link inside of the Reddit comments that convinces you to click on it.
4. Link takes advantage of the fact that you’re already logged into wellsfargo.com and initiates a money transfer.

5. CSRF: POST Attack

5. To Protect against CSRF attacks

1. Require that POST / PATCH / DELETE requests explicitly set a CSRF token either as a header or hidden form input (which the attacker cannot know)
2. Verify HTTP “origin” and “referer” headers�

Read More

• https://owasp.org/www-community/attacks/csrf
• http://www.redotheweb.com/2015/11/09/api-security.html

6. XSS (Cross-Site Scripting): What is it?

When a user injects a malicious script or HTML element on YOUR website that targets other users that use your platform (see video).

6. XSS (Cross-Site Scripting): Example

Here’s how it happens:

1. In the comments section PhotoApp, malicious user creates a button that will redirect anyone who clicks on it to a fake PhotoApp site that looks like the real one.
2. Another user, thinking the button is legitimate, is redirected to the fake site, and is asked to “re-enter their credentials.”
3. The malicious user steals the duped user’s credentials.
4. Malicious scripts can also be configured to send all of your cookies or other data to a malicious server (which could have sensitive data).

6. XSS (Cross-Site Scripting): Preventing It

Once a script is embedded in the codebase, that script is also able to access a user’s cookies and steal their tokens.

Protections

1. Always escape / “Sanitize” HTML in any JS form.
2. Ensure that your primary access token is set as an HttpOnly cookie (that JavaScript is not allowed to access).
1. By doing this, your token cannot be stolen.

6. XSS (Cross-Site Scripting): More Reading

• https://owasp.org/www-community/attacks/xss/
• http://www.redotheweb.com/2015/11/09/api-security.html
• https://brightsec.com/blog/xss-attack

​

7. Terms of Service

What needs to go into a terms of service agreement?

Your thoughts here…

Outline

• Security considerations
• Authentication strategies

General Authentication Workflow

Most authentication workflows consist of the following steps:

1. The user provides a username and password (usually using a web form).
2. The web server receives this information and queries the database to check that the username/password are valid.
3. If a user is found, the system generates and sends a credential that allows the user to access protected resources.
4. The client uses that credential to make any future requests
5. The credential has a way to be revoked (and/or expires at some point).

Two Common Authentication Workflows

1. When the client and the REST API are on the same server.
• Can take advantage of some some unique affordances of server / browser architecture, namely HTTP-only cookies�
2. When the client and the REST API are on different servers (like when your React Client was interacting with https://photo-app-secured.herokuapp.com/
• Needs a browser-independent way to generate and share credentials.

Approach 1: Session Cookies

Approach 1: Session Cookies

1. User logs in
2. Server generates a "sessionId" (signs it using "secret key"), which it saves somewhere (DB table, memory, etc.)
3. Server sets an HTTP-only cookie in the session that only it can see (not readable via JavaScript).
4. All subsequent requests to the server include the "cookie"
5. The server checks for the cookie in the sessionDB before returning protected resources.

https://medium.com/@prashantramnyc/difference-between-session-cookies-vs-jwt-json-web-tokens-for-session-management-4be67d2f066e

​

Cookies

1. Cookies are small pieces of information, stored in plaintext, that are transmitted back and forth from the browser to the server. Used to identify your computer as you interact with a server, and to persist contextual information between sessions.
2. Cookies can be created by the browser or by the web server
3. Cookies are sent back and forth via the HTTP request and response headers
4. Each server has its own cookie sandbox within the browser. Websites can only read/write cookies in their own sandbox (a security measure), and cannot read other server’s cookie caches.

Session Cookies

https://www.javatpoint.com/session-vs-cookies

​

Demo

https://photo-app-secured.herokuapp.com/login

Approach 2: Other machines accessing your API

For third-party clients, your REST API needs to provide a different way to authenticate, for instance by requesting an authentication token from an authentication endpoint:�� /api/token

​

In this model, the client will manage this token and use it to access privileged resources. Furthermore, the client also needs to track / manage expiring tokens and use the refresh token to generate a new access token.

Approach 2: JWT (JSON Web Token Approach)

1. User logs in
2. Server generates an "accessToken", encode the "userId" and "expiresIn", with the ACCESS_TOKEN_SECRET, then sends the "accessToken" to the browser (client side).
3. The browser (client side) receives the "accessToken" and saves it on the client side.
4. The "accessToken" is included in every subsequent request to the server.
5. Because no DB or state is required on the server for JWTs, this approach is often called a “stateless” approach (no stored context needed).

https://medium.com/@prashantramnyc/difference-between-session-cookies-vs-jwt-json-web-tokens-for-session-management-4be67d2f066e

​

2. JWT Workflow

Demo (Postman)

https://photo-app-secured.herokuapp.com/api/posts

Similarities & Differences

• Both approaches require an authentication step to checks for a username and password in the DB; both issue a string representing the transaction
• Both approaches require that the client securely save the “cookie” or the “jwt token” (otherwise vulnerable to various hacks).
• The main difference is that in case of the JWT approach the server does not need to maintain a DB of session Ids for lookup.
• One advantage of this is that the token can be decoupled from the server that issued the token (because the pertinent authentication info is embedded in the token itself..

JWTs (JSON Web Tokens) Workflow

JSON web tokens offer ONE (of many) ways to securely transmit authentication credentials between parties. Workflow:

1. User sends username and password to some authentication endpoint (e.g., /login)
2. Server checks if the credentials supplied by the user are valid. If they are, server encodes some information about the user in a “signed” token (which is just a string) and sends this token back to the user.
3. The user then includes this token in all future requests (via cookies, header, etc.).
4. Each time a new request is made, the server first checks if the token is valid, then it uses the “payload” (i.e. encoded JSON object) to see who is making the request and respond with the appropriate data (contextualized for the user).

JWTs: How Encoding Works

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

• Header – indicates which signing algorithm is being used.
• Payload – the data to encode (uses Base64Url)
1. Note: neither the header nor the payload are encrypted. Don’t put any super secret stuff in the JSON!
• Signature – uses the algorithm specified in the header to encode:�(the encoded header + encoded payload + and secret).
• Ensures that data has not been tampered with since it was issued by the server

IMPORTANT: JWTs are encoded but not encrypted

Source: https://jwt.io/introduction

Diagram of a JWT

• Header – indicates which signing algorithm is being used.
• Payload – the data to encode (uses Base64Url)
• Signature – uses the algorithm specified in the header to encode:�(the encoded header + encoded payload + and secret).

Pros: Useful for “Microservices”

It is often the case that the authentication server is on a completely different machine than the REST API that is serving your data:

1. https://auth.photoapp.com
• Responsible for generating the �Token / verifying username and �passworld
2. https://data.photoapp.com
3. https://chat.photoapp.com
4. https://ads.photoapp.com

One key advantage of using JWTs is that the same token can be used on both servers – so long as both servers share the same access and refresh token secrets!

Cons: Revoking the Token

• If an unauthorized person steals the JWT, there’s not an easy way to revoke access – you basically have to wait until the token expires.
• With a session token, you can easily remove the authorized sessionId from the databases and the user’s out of luck.
• Consider having short expiration windows to ensure safety.

​