Filter Failure: One-Pass Delete Filter Failure: UTF-7
Total Page:16
File Type:pdf, Size:1020Kb
Outline Cross-site scripting, cont’d CSci 5271 More cross-site risks Introduction to Computer Security Announcements intermission Web security and crypto failure combined Confidentiality and privacy lecture Stephen McCamant Even more web risks University of Minnesota, Computer Science & Engineering More crypto protocols More causes of crypto failure Filter failure: one-pass delete Filter failure: UTF-7 You may have heard of UTF-8 Encode Unicode as 8-bit bytes Simple idea: remove all occurrences of <script> UTF-7 is similar but uses only ASCII Encoding can be specified in a <meta> What happens to <scr<script>ipt>? tag, or some browsers will guess +ADw-script+AD4- Filter failure: event handlers Use good libraries <IMG onmouseover="alert('xss')"> Coding your own defenses will never work Put this on something the user will be Take advantage of known good tempted to click on implementations There are more than 100 handlers like Best case: already built into your this recognized by various browsers framework Disappointingly rare Content Security Policy Outline Cross-site scripting, cont’d New HTTP header, W3C candidate recommendation More cross-site risks Lets site opt-in to stricter treatment of Announcements intermission embedded content, such as: Confidentiality and privacy No inline JS, only loaded from separate URLs Even more web risks Disable JS eval et al. More crypto protocols Has an interesting violation-reporting mode More causes of crypto failure 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 1% 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 bank.com used to wire money Give site’s forms random-nonce tokens Link or script on evil.com loads it E.g., in POST hidden fields with certain parameters Not in a cookie, that’s the whole point Linking is exception to same-origin Reject requests without proper token 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 Cross-site scripting, cont’d Common for one page to redirect clients to another More cross-site risks Target should be validated Announcements intermission With authentication check if appropriate Confidentiality and privacy Open redirect: target supplied in parameter with no checks Even more web risks Doesn’t directly hurt the hosting site More crypto protocols But reputation risk, say if used in phishing We teach users to trust by site More causes of crypto failure Newly released assignments HA 2 questions 1. Network sniffing Exercise set 4 due next Wednesday 2. Offline dictionary attack 4/10 3. Forging predictable cookies HA2 due Monday 4/15 (also tax day) 4. SQL injection 5. Cross-site scripting 6. Crypto. attack against a poor MAC Outline Site perspective Cross-site scripting, cont’d More cross-site risks Protect confidentiality of authenticators Passwords, session cookies, CSRF tokens Announcements intermission Duty to protect some customer info Confidentiality and privacy Personally identifying info (“identity theft”) Credit-card info (Payment Card Industry Even more web risks Data Security Standards) More crypto protocols Health care (HIPAA), education (FERPA) Whatever customers reasonably expect More causes of crypto failure You need to use SSL Server-side encryption Finally coming around to view that Also consider encrypting data “at rest” more sites need to support HTTPS (Or, avoid storing it at all) Special thanks to WiFi, NSA Provides defense in depth If you take credit cards (of course) Reduce damage after another attack If you ask users to log in May be hard to truly separate keys Must be protecting something, right? OWASP example: public key for website Also important for users of Tor et al. ! backend credit card info Adjusting client behavior User vs. site perspective HTTPS and password fields are basic hints User privacy goals can be opposed to Consider disabling autocomplete site goals Usability tradeoff, save users from themselves Such as in tracking for advertisements Finally standardized in HTML5 Browser makers can find themselves in Consider disabling caching the middle Performance tradeoff Of course, differ in institutional pressures Better not to have this on user’s disk Or proxy? You need SSL Third party content / web bugs Cookies arms race Much tracking involves sites other than Privacy-sensitive users like to block the one in the URL bar and/or delete cookies For fun, check where your cookies are Sites have various reasons to retain coming from identification Various levels of cooperation Various workarounds: Web bugs are typically 1x1 images used Similar features in Flash and HTML5 only for tracking Various channels related to the cache Evercookie: store in n places, regenerate if subset are deleted Browser fingerprinting History stealing History of what sites you’ve visited is Combine various server or JS-visible not supposed to be JS-visible attributes passively User agent string (10 bits) But, many side-channel attacks have Window/screen size (4.83 bits) been possible Available fonts (13.9 bits) Query link color Plugin verions (15.4 bits) CSS style with external image for visited links (Data from panopticlick.eff.org, far from Slow-rendering timing channel exhaustive) Harvesting bitmaps User perception (e.g. fake CAPTCHA) Browser and extension choices Outline Cross-site scripting, cont’d More aggressive privacy behavior lives in extensions More cross-site risks Disabling most JavaScript (NoScript) Announcements intermission HTTPS Everywhere (whitelist) Tor Browser Bundle Confidentiality and privacy Default behavior is much more Even more web risks controversial Concern not to kill advertising support as More crypto protocols an economic model More causes of crypto failure Misconfiguration problems Openness tradeoffs Error reporting Default accounts Few benign users want to see a stack Unneeded features backtrace Directory listings Framework behaviors Hallmark of the old days Don’t automatically create variables from Readable source code of scripts query fields Doesn’t have your DB password in it, does it? Using vulnerable components Clickjacking Large web apps can use a lot of Fool users about what they’re clicking third-party code on Circumvent security confirmations Convenient for attackers too Fabricate ad interest OWASP: two popular vulnerable Example techniques: components downloaded 22m times Frame embedding Hiding doesn’t work if it’s popular Transparency Stay up to date on security Spoof cursor announcements Temporal “bait and switch” Crawling and scraping Outline A lot of web content is free-of-charge, Cross-site scripting, cont’d but proprietary More cross-site risks Yours in a certain context, if you view ads, etc. Announcements intermission Sites don’t want it downloaded Confidentiality and privacy automatically (web crawling) Even more web risks Or parsed and user for another More crypto protocols purpose (screen scraping) High-rate or honest access detectable More causes of crypto failure Abstract protocols Protocol notation Outline of what information is A ! B : N ; fT ; B; N g communicated in messages B 0 B KB Omit most details of encoding, naming, A ! B: message sent from Alice sizes, choice of ciphers, etc. Describes honest operation intended for Bob But must be secure against adversarial B (after :): Bob’s name participants f¡¡¡gK: encryption with key K Seemingly simple, but many subtle problems Needham-Schroeder Needham-Schroeder MITM A ! C : fN ;Ag A EC Mutual authentication via nonce exchange, C ! B : fN ;Ag A EB assuming public keys (core): B ! C : fN ;N g A ! B : fN ;Ag A B EA A EB C ! A : fN ;N g B ! A : fN ;N g A B EA A B EA A ! C : fN g A ! B : fN g B EC B EB C ! B : fN g B EB Certificates, Denning-Sacco Attack against Denning-Sacco A certificate signed by a trusted A ! S : A; B S third-party binds an identity to a S ! A : CA;CB public key A ! B : C ;C ; f (K )g A B SignA AB KB CA = SignS(A; KA) B ! S : B; C Suppose we want to use S in S ! B : CB;CC establishing a session key KAB: B ! C : C ;C ; f (K )g A ! S : A; B A C SignA AB KC By re-encrypting the signed key, Bob can S ! A : CA;CB A ! B : C ;C ; f (K )g pretend to be Alice to Charlie A B SignA AB KB Envelopes analogy Design robustness principles Use timestamps or nonces for Encrypt then sign, or vice-versa? freshness On paper, we usually sign inside an Be explicit about the context envelope, not outside. Two reasons: Don’t trust the secrecy of others’ Attacker gets letter, puts in his own secrets envelope (c.f. attack against X.509) Signer claims “didn’t know what was in Whenever you sign or decrypt, beware the envelope” (failure of non-repudiation) of being an oracle Distinguish runs of a protocol Implementation principles Outline Cross-site scripting, cont’d Ensure unique message types and More cross-site risks parsing Design for ciphers and key sizes to Announcements intermission change Confidentiality and privacy Limit information in outbound error Even more web risks messages More crypto protocols Be careful with out-of-order messages More causes of crypto failure Random numbers and entropy Netscape RNG failure Early versions of Netscape SSL Cryptographic