## Client-Side Security ### Cross-Site Request Forgery (CSRF) - Also called *session riding*, *Sea Surf*, *XSRF* - Attack: Attacker creates request in the name of a user - Topic: Session management - Cookies are always sent with each request - Neither browser nor server decide when cookies are sent - Sessions are state on server (can be modified) - XSS is broader attack - User being a victim to XSS could be victim to CSRF - XSS can create CSRF attacks - But: CSRF possible without script *injection* (user visiting the site of the attacker) - Example: - Bank uses cookies for session management - Form with transaction data is sent with cookies - Attack: - User visits malicious site - Site could send request to bank to submit transaction (including the session cookie) - Problem: Servers accept requests from outside their domain #### Attack - Exploit trust of a server having in the user's browser - Works with GET and POST (e.g., image tag, iframes, css, scripts) - Requirements: - User is logged in on target site - User visits a site which has a CSRF attack against the target site - Login CSRF - CCS, 2008 - Special case - Attack confidentiality - Attacker logs user into attacker's Google account and can monitor the user's behavior - e.g. Google search ![](images/csrf-login.png) #### Examples - 2006: Digg.com (User likes a certain post) - 2007: WordPress (Arbitrary code execution) - 2007: GMail filters (forward mails) - 2013: TP-Link routers (configuration changes; DNS server change) - ... a lot more ... #### Prevention - Check `Referer` header (naive) - Check `Origin` header - CSRF-Token - Double CSRF Token - Custom header - `SameSite` cookies ##### Referer-Header Checking - Naive approach - Server could check `Referer`-header of request - Problem: - Header is not always present - Header can be stripped by attacker - Header can not be set by attacker **but** - e.g., using a `data:` URL - e.g., using the Referrer-Policy of Chrome - Not privacy-conform - What behavior if header is missing? - Trade-off between utility vs. security - e.g., Reject or accept? ##### Origin-Header checking - Check `Origin` header (does not contain complete URL, privacy-friendly) - Currently, only sent with XMLHttpRequest, WebSockets - Problem: Wide-spread adoptions is unlikely ##### CSRF-Token - Server generates random token for user - Stored in session (server-side) - Form contains hidden token (sent from server) - Client sends token with request to server - Server compares sent token with the stored token - Protection: - Attacker doesn't have token - Origin of request is the same as the origin of the server (because server sent the token) - Problem: With an XSS, attacker could read token (obviously) ##### Double Submit Cookie - Called *‌Stateless CSRF Defense* - Idea: Token contained in **cookie** and form - Important: Token sent in cookie - Server generates token - Send in cookie (`HttpOnly`) and form - OR send in cookie only (not `HttpOnly`) and JavaScript inserts token into form - Client sends cookie token and form token to server - Server compares both cookies - Advantage: Server is stateless - Problem: Cookie tossing - Scenario: Attacker controls sub-domain - Attacker may set cookie token value for parent-domain ##### Custom Headers - Idea: - Use XMLHttpRequests for state-changing requests (with custom header) - Only handle request if the custom header is set - e.g. `X-My-CSRF-Header` - Protected via Same-origin policy and CORS - SOP: Same-origin requests allowed (for own site) - CORS: Cross-origin requests can be allowed (*Allow-list certain origins*) - Advantage: - No server state required - No randomness required - Disadvantage: - Change application ##### `SameSite` cookies - SameSite is cookie option - `Strict`: - Never send cookies in cross-origin request - e.g., link to facebook.com would not send cookie - `Lax` (default): - Cookies are send along safe request (GET, HEAD, OPTIONS, TRACE) - Cookies are not send with `POST`, `PUT`, `DELETE` - Protection against POST-based CSRF - **No** Protection against GET-based CSRF ### Cross-Origin Data Leakage - Goal: Attack confidentiality - Attack: - User visits malicious site - Malicious site requests a JS file in the `script` tag (SOP isn't applied here) - Malicious site steals information from the embedded JS file #### JSON/JavaScript Hijacking - 2006 - Request JSON file with JS - e.g. `` - Overwrite `Array()` function to steal JSON data - Fixed nowadays #### Cross-Site Scripting Inclusion (XSSI) - Attack: - Server sends data within JS files (if user is logged in) - Attacker overwrites executed functions - Attacker includes the script and extracts the information - *Compare to JSONP* - Exploits - Registered global variable (and print them) - Trivial case - e.g. `window.result_of_secret = ''` - Overwrite global functions/prototypes/prototype functions - e.g., `Array.prototype.forEach` - e.g., using `this` within callbacks - e.g., `Function.prototype.call` - e.g., `Object.prototype.toString()` - Identification - USENIX, 2015 - Apply to each cross-origin request - Send two requests (one with cookies, one without cookies) - Diff the result sizes - If difference is large enough, data is sent with the Cookie-Request - Real-world examples: - Stolen credit card info - Reading emails - Account data stealing from hosting services - Prevention - Restrict the loading of sensitive scripts from other origins (e.g., tokens, see CSRF protection, CORS) - Do not send data with JavaScript (use extra service) - Receive data using XMLHttpRequest (protected using SOP/CORS) - Use inline scripts only + CSP nonces - i.e., add data into script-tag in HTML page of original site - No external script ==> no leakage of information - Examples: - `Array.prototype.forEach = function(callback) { console.log(this); }` - `arguments.callee.caller`: Reference to who called me - `Object.defineProperty(Function.prototype, 'toString', {writable: false});` ### UI Redressing / Click Jacking - Attack: - Trick user into clicking on something without noticing - Usually, another site is framed and the including page controls most of the frames property - Weakness: - Framing is controlled by the including page (position, size, visibility, timing, ...) - Example: - Overlay site with iframe with tweet which should be posted - iframe is almost invisible - Behind the "SEND" button of the frame is a "PLAY" button - Improvement: - Let iframe follow mouse movement (frame can navigate the `top` frame) - Double Framing (frame inside the frame, bypass `X-Frame-Options: SAMEORIGIN`) - Defense: - *Framing should be controlled by included page* - FrameBusters - Site prevents being displayed in a frame - e.g., hide the body by default, only show if `self === top` - Header `X-Frame-Options` - Non-standardized header - Allow sites which may frame the site - `DENY`: Deny framing - `SAMEORIGIN`: Only allow framing in same origin (origin of top page or origin of framing page, depends on browser) - `ALLOW-FROM`: Whitelisted domains - CSP `frame-ancestors` - Replaces `X-Frame-Options` - `'none'`: Deny from any host - `'self'`: Same origin - ``: Whitelist specific URLs ![](images/clickjacking.png) ### The Great Cannon - Attack tool to create DDOS attacks - Great Cannon uses MitM to inject JS code into sites (e.g., search results from Baidu) - JS opens connections to target sites (e.g., New York Times, GitHub, ...) - Defense: **Sub-Resource Integrity (SRI)** - `