Mitigating Attack Types Part 3
Session Management
Sessions keep track of users and their actions
Store user-relevant data (profile settings, shopping cart)
Must be protected
Session info can be used to impersonate you
Cookies
HTTP is stateless
So where do we store state info? Web cookies!
Securing cookies
Secure: send only over HTTPS
HttpOnly: Cannot be accessed from JS
SameSite: Request and cookie must come from the same domain
Expiration: Persistent vs non-persistent
Session Hijacking
Taking over a user’s session
MITM (sniffing)
Compromised browser
Predictable session IDs
Bad application programming
Cookie Poisoning
Attacker changes a cookies contents
Then sends the altered cookie to exploit a website
Defense?
Input validation. Validate the cookie
Encryption
Expiration
Cross-Site Request Forgery (CSRF/XSRF)
Mitigation on web server side
Stateful apps: CSRF tokens
Random value stored on server, sent back by client in hidden fields with every request
Per session or per page (no “back”)
Don’t send them using cookies!
Stateless Apps
Double submit cookies
Random value not stored on server but set in cookie and request field. Must match
Domain/Origin/Referrer Header
Check that the originating website matches the request
Origin/Referrer: safer, cannot be programmatically altered using JavaScript
SameSite Cookie Attribute
Browser decides whether to send cookies along with cross-sit requests: Lax, Strict, None
Captchas
Cookie protection (helps, but not enough for anti-CSRF)
HTTPonly, secure, path, expiration, etc
Clickjacking – Stealing a users clicks and inputs
Mitigations:
Frame busting – code that forces elements to be the top most element in the page
HTTP Headers – define which kind of frame content is acceptable
Last updated