Outline More cross-site risks CSci 5271 Announcements intermission - PDF document

Outline More cross-site risks CSci 5271 Announcements intermission Introduction to Computer Security Web security, part 2 Confidentiality and privacy Stephen McCamant University of Minnesota, Computer Science & Engineering Even more web risks HTTP header injection Content sniffing Browsers determine file type from headers, extension, and content-based Untrusted data included in response guessing headers Latter two for ✘ ✶ % server errors Can include CRLF and new headers, or Many sites host “untrusted” images premature end to headers and media AKA “response splitting” Inconsistencies in guessing lead to a kind of XSS E.g., “chimera” PNG-HTML document Cross-site request forgery CSRF prevention Certain web form on ❜❛♥❦✳❝♦♠ used to wire money Give site’s forms random-nonce tokens Link or script on ❡✈✐❧✳❝♦♠ loads it E.g., in POST hidden fields with certain parameters Not in a cookie, that’s the whole point Reject requests without proper token Linking is exception to same-origin If I’m logged in, money sent Or, ask user to re-authenticate automatically XSS can be used to steal CSRF tokens Confused deputy, cookies are ambient authority

Open redirects Outline Common for one page to redirect More cross-site risks clients to another Target should be validated Announcements intermission With authentication check if appropriate Open redirect : target supplied in Confidentiality and privacy parameter with no checks Doesn’t directly hurt the hosting site Even more web risks But reputation risk, say if used in phishing We teach users to trust by site Note to early readers Outline More cross-site risks This is the section of the slides most likely to change in the final version Announcements intermission If class has already happened, make Confidentiality and privacy sure you have the latest slides for announcements Even more web risks Site perspective You need to use SSL Protect confidentiality of authenticators Finally coming around to view that more sites need to support HTTPS Passwords, session cookies, CSRF tokens Special thanks to WiFi, NSA Duty to protect some customer info If you take credit cards (of course) Personally identifying info (“identity theft”) Credit-card info (Payment Card Industry If you ask users to log in Data Security Standards) Must be protecting something, right? Health care (HIPAA), education (FERPA) Also important for users of Tor et al. Whatever customers reasonably expect

Server-side encryption Adjusting client behavior HTTPS and ♣❛ss✇♦r❞ fields are basic Also consider encrypting data “at rest” hints Consider disabling autocomplete (Or, avoid storing it at all) Usability tradeoff, save users from Provides defense in depth themselves Reduce damage after another attack Finally standardized in HTML5 May be hard to truly separate keys Consider disabling caching OWASP example: public key for website Performance tradeoff ✦ backend credit card info Better not to have this on user’s disk Or proxy? You need SSL User vs. site perspective Third party content / web bugs Much tracking involves sites other than User privacy goals can be opposed to the one in the URL bar For fun, check where your cookies are site goals coming from Such as in tracking for advertisements Various levels of cooperation Browser makers can find themselves in Web bugs are typically 1x1 images used the middle only for tracking Of course, differ in institutional pressures Cookies arms race Browser fingerprinting Privacy-sensitive users like to block Combine various server or JS-visible and/or delete cookies attributes passively Sites have various reasons to retain User agent string (10 bits) Window/screen size (4.83 bits) identification Available fonts (13.9 bits) Various workarounds: Plugin verions (15.4 bits) Similar features in Flash and HTML5 Various channels related to the cache (Data from ♣❛♥♦♣t✐❝❧✐❝❦✳❡❢❢✳♦r❣ , far from Evercookie : store in ♥ places, regenerate exhaustive) if subset are deleted

History stealing Browser and extension choices History of what sites you’ve visited is More aggressive privacy behavior lives not supposed to be JS-visible in extensions But, many side-channel attacks have Disabling most JavaScript (NoScript) HTTPS Everywhere (whitelist) been possible Tor Browser Bundle Query link color Default behavior is much more CSS style with external image for visited links controversial Slow-rendering timing channel Concern not to kill advertising support as Harvesting bitmaps an economic model User perception (e.g. fake CAPTCHA) Outline Misconfiguration problems More cross-site risks Default accounts Announcements intermission Unneeded features Framework behaviors Confidentiality and privacy Don’t automatically create variables from query fields Even more web risks Openness tradeoffs Using vulnerable components Large web apps can use a lot of Error reporting third-party code Few benign users want to see a stack backtrace Convenient for attackers too Directory listings OWASP: two popular vulnerable Hallmark of the old days components downloaded 22m times Readable source code of scripts Hiding doesn’t work if it’s popular Doesn’t have your DB password in it, does Stay up to date on security it? announcements

Clickjacking Crawling and scraping A lot of web content is free-of-charge, Fool users about what they’re clicking but proprietary on Yours in a certain context, if you view Circumvent security confirmations ads, etc. Fabricate ad interest Sites don’t want it downloaded Example techniques: automatically ( web crawling ) Frame embedding Transparency Or parsed and user for another Spoof cursor purpose ( screen scraping ) Temporal “bait and switch” High-rate or honest access detectable