Cross Site Scripting Attacks

Outline
 Cookies and Sessions – Refresher
 Cross-Site Attacks
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)
COOKIES AND SESSIONS
How things work before we start messing with them….
Web browsing is stateless
 Browser does not maintain a connection to the server while
you look at a page
 You may: never return/be a long time on a page/be on for one
second
 Server needs to distinguish you from other clients (browsers)
 Browser state is stored in “Cookies”
 Server state is stored in “Sessions”
Have you noticed how….

Some sites always seem to want to know who you are!

Have you noticed how….

Other sites always seem to know who you are!

How you see YouTube
How YouTube sees you (and everyone else)
Multi-User Environment

 A server is interacting with many different browsers at the

same time needs to know which browser a particular
request came from
 Request / Response initially was stateless
All browsers looked identical
Was really bad and didn’t last very long!
Web Cookies to the Rescue
 Cookies are ‘arbitrary’ pieces of data
 Chosen by the Web server and sent to the browser
 Browser returns them unchanged to the server
 Introduces a state (memory of previous events) into otherwise
stateless HTTP transactions.
 What is a Cookie?
c
k byth
ebr
owse
ron  Small amount of information
 Initially sent from server to browser, then back
to server on future page requests
TTPG ET orPOST
 Typical uses: Authentication, User tracking,
preferences, shopping carts
If you don’t know who this is, see:
https://en.wikipedia.org/wiki/Cookie_Monster
 Set in header of browser’s
HTTP GET or POST requests
Cookie transfer
Cookie transfer
Session cookie  Only exists whilst the user has website open
 Closing the browser (or tab) will usually remove them

Persistent cookie  Exists on the computer until a future date

 Expiry dates often set in far future. Each time a website is accessed the
website can access the cookie

HttpOnly cookie  Only useable via HTTP or HTTPS, so no javascript

 Reduces threat of session cookie theft via cross site scripting

Secure cookie  Only usable via HTTPS, so cookie data is encrypted

Third-party cookie  Used for tracking purposes

 Domain is different to site visited
Cookies in the Browser

 Marked with the web addresses they come from

 Browser only sends back cookies that were originally set by the same
web server
 Expiration date
 Some last for years
 Others go away as soon as the browser is closed
Sessions in the Server

 Server application behaviour:

 Meets a new (unmarked) browser = Create a session

 Set a session cookie:

 Stored in the browser

 Indicates the session id

(Browser now has a unique “mark”)
Session Identifier
 Large, random number placed in a browser cookie the first time the browser is
encountered

 Number is used to pick from the many sessions that the server has active at any one
time

 Server software stores data in the session that it wants to have from one request to
another from the same browser.

 Examples of session stored data:

 Shopping cart

 Login information
 Cookies and Session IDs

Source: https://cscie12.dce.harvard.edu/lecture_notes/2006-07/20070410/slide46.html
Stateless vs Stateful apps
Sticky sessions
 Sticky sessions:

 Makes it possible for the load

balancer to identify requests
coming from the same client and
to always send those requests to
the same server.Stored in the
browser

 Required for stateful apps, that

store user data locally on a
remote server.
CROSS SITE ATTACKS
Misusing cookies and sessions
Background

Samy Kamkar

https://www.youtube.com/watch?v=DtnuaHl378M (5 mins)
Two Types of Attack

Cross-Site Scripting  Attacker adds malicious code to vulnerable server

 Typically, server fails to validate user input
(XSS)
 Eg: JS in forum message. Code run in user
browser when visits site
 Can be reflected, stored (persistent) and DOM
based.
 Normally performed against stateful apps

Cross-Site Request Forgery

 Attacker uses victim’s own browser to make
(CSRF)
requests
 Victim is authenticated on server
What damage can be done?
Damage Samy’s JS can do?

Web
server
Legitimate FB Request

Alice Untrusted FB Request

Trusted
JS
JS JS Un-Trusted
JS
JavaScript:
- Sends requests
- Uses session cookie
ENTER XSS ATTACKS
Channeling Sam’s code to Alice’s browser
Basic trick to XSS Attack
In Samy’s
browser

Hidden CODE

In Alice’s
browser

Hidden CODE
Stealing the cookie to run attack
outside Alice’s account
More practical: Perform request on
Alice’s own browser
How to prevent it?
 Filter input on arrival

 Encode data output

 Use appropriate response headers (e.g HttpOnly, Secure cookie)

 Use Content Security Policies: e.g Content-Security-Policy: script-src 'self'

ENTER CROSS SITE REQUEST
FORGERY ATTACKS (CSRF)
 CSRF key components
• A relevant action: There is an action within the application that the attacker has a reason to induce
(e.g such as changing the user's own password).
• Cookie-based session handling: Performing the action involves issuing one or more HTTP
requests, and the application relies solely on session cookies to identify the user who has made the
requests. There is no other mechanism in place for tracking sessions or validating user requests.
• No unpredictable request parameters: The requests that perform the action do not contain any
parameters whose values the attacker cannot determine or guess.
Normal Site Request
 Cross-Site Request

Knowing source of request: Referrer field: Good idea but often stripped out for privacy
Legitimate Cross-Site Request

Legitimate cross-site request (FB Like)

Implementing CSRF attacks

 Server knows which ID

Session ID 1
belongs to which user
Alice  Normally, Sam cannot add
friends to Alice account
Session ID 2 Web
 All requests sent by Sam
Site applied to his account only
Bob

Session ID 3

Sam
Stealing Alice’s Session ID

 Server will see Session ID

Session ID 1
and assume request is
from Alice
Alice
 Why is this approach
Session ID 2 Web impractical to achieve?
Site
Bob ____________________

Session ID 3

Sam
Method 2 Running code in Alice’s Browser

CODE Session ID 1
 If Sam can get Alice to run
his code on her browser…
Session ID 1
Alice  Sam’s request will use
Alice’s Session ID...
Session ID 2 Web
 Sam does not need to
Site know Alice’s Session ID
Bob

Session ID 3  So, the attack is launched

from victim’s own browser
Sam
Attack : Add Friend
How to prevent it?
CSRF Token: most secure option and preferred one
POST /email/change HTTP/1.1 Host: vulnerable-website.com Content-Type:
application/x-www-form-urlencoded Content-Length: 68 Cookie:
session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@normal-user.com
How to prevent it?
Checking the referer header (commonly used on embedded network devices)
Outline
 Cookies and Sessions – Refresher
 Cross-Site Attacks
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)