Basics of Web Security Flashcards
HTTP is stateless
§ No inherent state in HTTP
- server does not keep any state after TCP connection is closed
§ For static sites, not an issue
- developing “applications” almost impossible though - e.g., Facebook, Amazon, …
§ Need to introduce state in HTTP
- dubbed „sessions“
§ Using HTTP Authentication not feasible
- logout hard to impossible
Cookies
§ Small pieces of text
- initially sent by the Web server
- stored by the Web browser
- sent on every request to matching domain
§ Server can control attributes for cookie
- secure: only sent via HTTPS connections - HttpOnly: not accessible from JavaScript
- Expires: how long cookies are stored
• allow for long-term (e.g. Google, Facebook) and short-term (e.g., Banking) sessions
- Set-Cookie: language=german
§ Web browser always sends cookies on request
- regardless of where request originated from
- Transmitted as HTTP header
Isolating sites from each other
§ Modern Web pages incorporate documents from many other parties
- advertisement
- social media etc.
§ Without isolation policy, all document could read content from other sites
- recall: all requests to any domain are made with cookies attached
§ The most basic security policy is called „Same-Origin Policy“
- Resources can only access other resources if protocol, port, and host match
- few exceptions: images may be rendered, scripts may be included
Can http://www.foo.com/dir/page.html access the following resources?
- http://www.foo.com/dir/page2.html
- https://www.foo.com/dir/page.html
- http://foo.com/dir/page.html
- http://www.foo.com:81/index.html
- Yes
- No, protocol (and port differs) [https]
- No, host differs
- No, post differs; with 80 it would work
XSS attacks
Reflected Server-Side Cross-Site Scripting
§ User must visit malicious link
§ No persistent change to the server
Persistent Server-Side Cross-Site Scripting
§ Attacker can store malicious payload on server
§ Every user is affected on every visit
=> highest impact
Reflected Client-Side Cross-Site Scripting
§ User must visit malicious link
§ No persistent changes to the client
§ (not visible in server logs)
Persistent Client-Side Cross-Site Scripting
§ User must visit malicious link once
§ Single user affected on every visit
=> most sneaky one
Mitigating the effect of Cross-Site Scripting
§ Proposed Mitigation: Content Security Policy (CSP)
- explicitly whitelist allowed, trusted resources
- disallow dangerous constructs like eval, inline scripts and event handlers
- delivered over an HTTP header
- important: CSP does not stop XSS, but tries to mitigate the effect
Content Security Policy - Basics
§ default-src ‘self’ ‘none’ https://.example.org https://
• ‘self’: own origin
• ‘none’: no origin whatsoever allowed
Content Security Policy – script-src specialities
§ ‘unsafe-inline’ / ‘unsafe-eval’
- explicitily allows inline scripts, event handlers and eval constructs
§ ‘nonce-ABCDEF’
- only allows scripts to be executed if matching nonce is set
§ ‘sha256-AzQxy7DeLbz7dgM//hBUno53vYKU=’
- only allow scripts with that sha256 hash to be executed
§ ‘strict-dynamic’
- trusted scripts may programmatically create other scripts
• create Element and append Child, not via document.write
- invalidates any URL-based whitelisting
§ Given the policy, will this execute all code (running at example.org)?
§ script-src ‘self’ https://cdn.example.org ‘unsafe-inline’
script
var script=document.createElement(“script”);
script.src = “https://cdn.example.org/ad.js”; document.write(script.outerHTML);
/script
Yes, unsafe-inline allows inline scripts and cdn is whitelisted
§ Given the policy, will this execute all code (running at example.org)?
§ script-src ‘self’ ‘nonce-ABCDEF’
script
var script=document.createElement(“script”);
script.src = “http://ad.com/ad.js”; document.body.appendChild(script);
/script
No, script does not carry the correct nonce
§ Given the policy, will this execute all code (running at example.org)?
§ script-src ‘self’ ‘nonce-ABCDEF’
script nonce="ABCDEF"
var script=document.createElement("script");
script.src = "http://ad.com/ad.js"; document.body.appendChild(script);
/script
No, the nonce is right, but the “self” =/ “http://ad.com/ad.js”
§ Given the policy, will this execute all code (running at example.org)?
§ script-src ‘self’ ‘nonce-ABCDEF’ ‘strict-dynamic’
script nonce="ABCDEF"
var script=document.createElement("script");
script.src = "http://ad.com/ad.js"; document.body.appendChild(script);
/script
Yes, since createElement is used to create second script (strict-dynamic)
§ Given the policy, will this execute all code (running at example.org)?
§ script-src ‘self’ ‘nonce-ABCDEF’ ‘strict-dynamic’
script nonce=”ABCDEF”
document.write(“”);
/script
No, since strict-dynamic disables host-based whitelisting of resources
XSS Vectors attacks
- > Full script tag injection
- b - -script - alert(1) -/script - -/b -
- > HTML element attributes
- img src=”x” onerror=”alert(1)” -
For the following code snippet, decide if the CSP script-src ’self’, ’adcompany.com’, ’strict-dynamic’ will allow all code to run.
-script src=”https://adcompany.com/ad.js” - -/script -
No code will run, since the ’strict-dynamic’ directive disables host-based whitelisting.
Build a CSP which allows the following code snippet to run. Be as concise as possible, i.e. use as little directives as possible.
-script src=”https://adcompany.com/ad.js” -
-script nonce=”ABCDEF” -
eval(“alert(1);”);
-/script -
script-src ’adcompany.com’, ’nonce-ABCDEF’, ’unsafe-eval’
