Outline More web risks Confidentiality and privacy CSci 5271 Announcements intermission Introduction to Computer Security Web/crypto/middleboxes combined slides More crypto protocols More causes of crypto failure Stephen McCamant University of Minnesota, Computer Science & Engineering Firewalls and NAT boxes Intrusion detection systems HTTP header injection Content sniffing Browsers determine file type from headers, Untrusted data included in response headers extension, and content-based guessing Latter two for ✘ ✶ % server errors Can include CRLF and new headers, or premature end to headers Many sites host “untrusted” images 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 E.g., in POST hidden fields Link or script on ❡✈✐❧✳❝♦♠ loads it with certain Not in a cookie, that’s the whole point parameters Reject requests without proper token Linking is exception to same-origin Or, ask user to re-authenticate If I’m logged in, money sent automatically XSS can be used to steal CSRF tokens Confused deputy, cookies are ambient authority Open redirects Misconfiguration problems Common for one page to redirect clients to another Target should be validated Default accounts With authentication check if appropriate Unneeded features Open redirect : target supplied in parameter with no Framework behaviors checks Don’t automatically create variables from query fields Doesn’t directly hurt the hosting site But reputation risk, say if used in phishing We teach users to trust by site
Openness tradeoffs Using vulnerable components Large web apps can use a lot of third-party code Error reporting Few benign users want to see a stack backtrace Convenient for attackers too Directory listings OWASP: two popular vulnerable components downloaded 22m times Hallmark of the old days Readable source code of scripts Hiding doesn’t work if it’s popular Doesn’t have your DB password in it, does it? Stay up to date on security announcements Clickjacking Crawling and scraping A lot of web content is free-of-charge, but Fool users about what they’re clicking on proprietary Circumvent security confirmations Yours in a certain context, if you view ads, etc. Fabricate ad interest Sites don’t want it downloaded automatically ( web Example techniques: crawling ) Frame embedding Or parsed and user for another purpose ( screen Transparency Spoof cursor scraping ) Temporal “bait and switch” High-rate or honest access detectable Outline Site perspective More web risks Protect confidentiality of authenticators Confidentiality and privacy Passwords, session cookies, CSRF tokens Announcements intermission Duty to protect some customer info More crypto protocols Personally identifying info (“identity theft”) Credit-card info (Payment Card Industry Data Security More causes of crypto failure Standards) Health care (HIPAA), education (FERPA) Firewalls and NAT boxes Whatever customers reasonably expect Intrusion detection systems You need to use SSL Server-side encryption Finally coming around to view that more sites need Also consider encrypting data “at rest” 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 ✦ backend Also important for users of Tor et al. credit card info
Adjusting client behavior User vs. site perspective HTTPS and ♣❛ss✇♦r❞ fields are basic hints Consider disabling autocomplete User privacy goals can be opposed to site goals Usability tradeoff, save users from themselves Such as in tracking for advertisements Finally standardized in HTML5 Browser makers can find themselves in the middle Consider disabling caching Of course, differ in institutional pressures Performance tradeoff 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 the one in Privacy-sensitive users like to block and/or delete the URL bar cookies For fun, check where your cookies are coming from Sites have various reasons to retain identification Various levels of cooperation Various workarounds: Web bugs are typically 1x1 images used only for Similar features in Flash and HTML5 tracking Various channels related to the cache Evercookie : store in ♥ places, regenerate if subset are deleted Browser fingerprinting History stealing History of what sites you’ve visited is not supposed Combine various server or JS-visible attributes to be JS-visible passively But, many side-channel attacks have been possible User agent string (10 bits) Window/screen size (4.83 bits) Query link color Available fonts (13.9 bits) CSS style with external image for visited links Plugin verions (15.4 bits) Slow-rendering timing channel Harvesting bitmaps (Data from ♣❛♥♦♣t✐❝❧✐❝❦✳❡❢❢✳♦r❣ , far from exhaustive) User perception (e.g. fake CAPTCHA) Browser and extension choices Outline More web risks More aggressive privacy behavior lives in extensions Confidentiality and privacy Disabling most JavaScript (NoScript) Announcements intermission HTTPS Everywhere (whitelist) Tor Browser Bundle More crypto protocols Default behavior is much more controversial More causes of crypto failure Concern not to kill advertising support as an economic Firewalls and NAT boxes model Intrusion detection systems
Upcoming events Outline More web risks Confidentiality and privacy Inidividual progress reports due tonight Announcements intermission Exercise set 4 out, due next Wednesday More crypto protocols Project meetings next week More causes of crypto failure HA2 due a week from Friday Firewalls and NAT boxes Intrusion detection systems Abstract protocols Protocol notation Outline of what information is communicated in ❆ ✦ ❇ ✿ ◆ ❇ ❀ ❢ ❚ ✵ ❀ ❇❀ ◆ ❇ ❣ ❑ ❇ messages Omit most details of encoding, naming, sizes, choice of ❆ ✦ ❇ : message sent from Alice intended for Bob ciphers, etc. ❇ (after :): Bob’s name Describes honest operation ❢ ✁ ✁ ✁ ❣ ❑ : encryption with key ❑ But must be secure against adversarial participants Seemingly simple, but many subtle problems Needham-Schroeder Needham-Schroeder MITM ❆ ✦ ❈ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❊ ❈ Mutual authentication via nonce exchange, assuming ❈ ✦ ❇ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❊ ❇ public keys (core): ❇ ✦ ❈ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❊ ❆ ❆ ✦ ❇ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❊ ❇ ❈ ✦ ❆ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❊ ❆ ❇ ✦ ❆ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❊ ❆ ❆ ✦ ❈ ✿ ❢ ◆ ❇ ❣ ❊ ❈ ❆ ✦ ❇ ✿ ❢ ◆ ❇ ❣ ❊ ❇ ❈ ✦ ❇ ✿ ❢ ◆ ❇ ❣ ❊ ❇ Certificates, Denning-Sacco Attack against Denning-Sacco ❆ ✦ ❙ ✿ ❆❀ ❇ A certificate signed by a trusted third-party ❙ binds ❙ ✦ ❆ ✿ ❈ ❆ ❀ ❈ ❇ an identity to a public key ❆ ✦ ❇ ✿ ❈ ❆ ❀ ❈ ❇ ❀ ❢ Sign ❆ ✭ ❑ ❆❇ ✮ ❣ ❑ ❇ ❈ ❆ ❂ Sign ❙ ✭ ❆❀ ❑ ❆ ✮ ❇ ✦ ❙ ✿ ❇❀ ❈ Suppose we want to use S in establishing a session ❙ ✦ ❇ ✿ ❈ ❇ ❀ ❈ ❈ ❆ ✦ ❙ ✿ ❆❀ ❇ ❇ ✦ ❈ ✿ ❈ ❆ ❀ ❈ ❈ ❀ ❢ Sign ❆ ✭ ❑ ❆❇ ✮ ❣ ❑ ❈ key ❑ ❆❇ : ❙ ✦ ❆ ✿ ❈ ❆ ❀ ❈ ❇ By re-encrypting the signed key, Bob can pretend to be ❆ ✦ ❇ ✿ ❈ ❆ ❀ ❈ ❇ ❀ ❢ Sign ❆ ✭ ❑ ❆❇ ✮ ❣ ❑ ❇ Alice to Charlie
Recommend
More recommend
