type • Browsers will determine how to interpret the file based on the Content-Type header • In this case, the file is served with text/plain • …which represents a plain text document 6
unrecognised, browsers will try to fix it with MIME Sniffing • …which determines the file type by inspecting the content with different algorithms (e.g. Magic Number) • But text/plain is a perfectly recognisable MIME type, how do we activate MIME Sniffing in this case?
the highest precedence according to the specs • However, older versions of Internet Explorer will first guess the file type by performing MIME Sniffing • If a HTML sequence is found within the first 256 bytes, then the file is parsed as HTML 9
file types • Namely, CSV file (.csv) and TXT file (.txt) • We could try different file extensions and hopefully the validation is based on a blacklist • The idea is that, even though we cannot upload HTML files, there are other file types that can execute JavaScript 13
• No mapping for the corresponding MIME type • No Content-Type for the file • MIME Sniffing is then activated on browsers to determine the file type • X-Content-Type-Options: nosniff is ignored in this case 15
the main domain (twitter.com) which sets document.domain="twitter.com" • An old technique for sub/parent domain communication • ❌ No such page was found • Steal session id • The session cookie is set on *.twitter.com! • ❌ Cannot read due to httpOnly • Control CSRF token • 21
is used to store all kinds of miscellaneous data, but not readable due to httpOnly • However, this cookie is not bound to the session (session ID is stored in a separate cookie) • Could we replace victim’s _twitter_sess with ours, and force victim to use our CSRF token? 23
domain, path) • Subdomain can set cookies for parent domain and the effective path • foo is a different cookie from foo; path=/api. Their cookie flags are also separate • However, the Cookie header only contains the name and value for each of the cookies • Server will see two cookies with the same name 27
account 3. Navigate victim to the XSS file 4. Override and fixate CSRF token 5. Logout attacker’s account 6. Next time victim logs in, attacker’s CSRF token will be used 35
but • …victim needs to re-login • Victim also needs to visit attacker’s website again to trigger the CSRF • Can we authorise a request without involving session? 36
without a session • However, we need browsers to attach the OAuth parameter in the Authorisation header • There is no way to do it without violating SOP, at least for navigation • Dead end? Let’s check the spec… 40
unknown extension 2. Attach OAuth parameter to the file URL 3. Make victim visit the file 4. The payload uses Cookie Tossing to override and fixate victim’s CSRF token 5. The payload performs actions on victim’s behalf 45
GitHub’s approach • Cookie Prefixes • Currently only available on Chrome • If a cookie name begins with __Host-, the cookie cannot be accessed/modified from subdomains • Same-Site Cookies • Also available on Chrome only • Cookies with the SameSite flag will not be included the the request is issued cross- origin • The “ultimate” CSRF killer 48