Web Security

Going to quote these lines in any #tradeoff discussions going forward:

Would you like the strongest encryption algo in world? Yes.
Would you like logins to take ten minutes? No.
- @stevekinney in @FrontendMasters course on web security

— Ankit Kashyap (@ankitwww) February 8, 2025

the most secured systems are the ones people don't want to use.

In security world, perfect is many times opposite of good.

Cookies

• small pieces of data stored on the client side to track and identify users

• Cookies are used to implement sessions.

• You don't need to be logged in.

• Cookies are not always tied to authentication and authorization.

• Without some kind of expiration, cookie last for the duration of the session.

• For expiration - two options - Expires or Max age

• How to delete the cookie

  • You can't
  • But, you can set its expiration date to some time in the past.

• httpOnly

  • JS can't change cookie httpOnly
  • Sometimes you want js to still read/edit the cookie (e.g. dark mode?)
  • Setting the HttpOnly flag on a cookie enhances security by making it inaccessible to JavaScript running in the browser. This helps protect against cross-site scripting (XSS) attacks, where a malicious script could otherwise steal sensitive cookies (e.g., session tokens) and send them to an attacker.
    • XSS attacks inject scripts into web pages that run in the user's browser.
    • If session cookies are accessible through document.cookie, attackers can steal them and hijack user sessions.
    • HttpOnly prevents this by restricting cookies to be sent only in HTTP(S) requests.
  • HttpOnly does not protect against Cross-Site Request Forgery (CSRF) attacks. To mitigate CSRF, combine HttpOnly with CSRF tokens or set SameSite=Strict or SameSite=Lax.
  • HttpOnly does not encrypt cookies; always use Secure to ensure cookies are sent only over HTTPS.

• Secure

  • The Secure flag in a cookie ensures that the cookie is only sent over HTTPS and never transmitted over an unencrypted HTTP connection. This prevents attackers from intercepting and stealing the cookie through man-in-the-middle (MITM) attacks.

• Signing/hashing the cookie

  • Signing a cookie means adding a cryptographic signature to its value to ensure integrity and authenticity. This prevents attackers from tampering with or forging the cookie's content while still allowing the server to read it.

• Signing vs Encrypting:

  • encryption and signing are fundamentally different cryptographic operations, and they serve distinct purposes.
    
    

• SameSite: Restricts how cookies are sent with cross-origin requests

• But Site !== origin

  • example.com and login.example.com are same site
  • Exceptions: github.io and vercel.com sub domain

• Same Origin Policy

  • Protocol + Host + Port = origin

• More on this in CSRF

• The SameSite attribute in cookies controls whether cookies are sent with cross-site requests. It helps prevent Cross-Site Request Forgery (CSRF) attacks by restricting when a browser should send cookies.

  

  Weired things
  

  

Session Hijacking

• Privilege Escalation
• Man-in-the-middle - HTTP
• SQL Injection - Escape user inputs
  • 
• Parameter Injections in URLs, non-sql DBs
  • Use input validations
  • Use allowLists instead of blockLists
  • avoid ppl to slide properties/things like {...obj, admin: true} in PATCH apis

Cross-site request forgery

A vulnerability that allows an attacker to make unauthorized requests in the user's behalf.

3 Ingredients to the CSRF

CSRF fixes

SameSite Cookie and CSRF

SameSite:Lax is default these days
SameSite:None is irresponsible

SameSite=Strict:

• Banks or critical sites can enforce it - but a social media won't go for it.
  • Otherwise, message forwards and links shared across other website won't work smoothly and would show up login page again (degraded experience).
• SameSite: Restricts how cookies are sent with cross-origin requests
• Site !== origin
  • example.com and login.example.com are same site
  • origin - Protocol + hots + port
  • Exceptions: github.io and vercel.com sub domain

Always remember, CSRF does not need to come from javascript - it can be in CSS too (like background url as get request endpoint)

Like - deleting github repor - lots of back and forth and minimizing CSRF.

CORS: Origin + Methods + Header +

Cross-Site Scripting

This is coming from your own house!
XSS - The Samy worm 2005

React and XSS

https://github.com/payloadbox/xss-payload-list

Content Security Policy

CSP can be thought of a second layer defense.

NONCE

If you need inline script or css loading . Bit like CSRF.

Original Slides from Steve Kinney course

![[Web_Security.pdf]]

if above not working - https://drive.google.com/file/d/1UiGq-Ok7Z-ak4lBR7yH9YEAPnFeqvM9i/view?usp=sharing