Outline Cross-site scripting Announcements intermission CSci 5271 More cross-site risks Introduction to Computer Security Confidentiality and privacy Day 19: Web security, part 2 Stephen McCamant Even more web risks University of Minnesota, Computer Science & Engineering DNSSEC SSH Reflected XSS Persistent XSS Injected data used to produce page Injected data used immediately in later producing a page For instance, might be stored in Commonly supplied as query/form database parameters Can be used by one site user to attack Classic attack is link from evil site to another user victim site E.g., to gain administrator privilege DOM-based XSS No string-free solution Injected occurs in client-side page For server-side XSS, no way to avoid construction string concatenation Flaw at least partially in code running Web page will be sent as text in the end on client Research topic: ways to change this? Many attacks involve mashups and XSS especially hard kind of injection inter-site communication
Danger: complex language embedding Danger: forgiving parsers JS and CSS are complex languages in History: handwritten HTML, browser their own competition Can appear in various places with HTML Many syntax mistakes given “likely” But totally different parsing rules interpretations Example: ✧✳✳✳✧ used for HTML Handling of incorrect syntax was not attributes and JS strings standardized What happens when attribute contains JS? Sanitization: plain text only Sanitization: context matters Easiest case: no tags intended, insert An OWASP document lists 5 places in at document text level a web page you might insert text Escape HTML special characters with For the rest, “don’t do that” entities like ✫❧t❀ for ❁ Each one needs a very different kind of escaping OWASP recommendation: ✫ ❁ ❃ ✧ ✬ ✴ Sanitization: tag whitelisting Don’t blacklist In some applications, want to allow Browser capabilities continue to evolve benign markup like ❁❜❃ Attempts to list all bad constructs But, even benign tags can have JS inevitably incomplete attributes Even worse for XSS than other Handling well essentially requires an injection attacks HTML parser But with an adversarial-oriented design
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 UTF-7 is similar but uses only ASCII ❁s❝r✐♣t❃ Encoding can be specified in a ❁♠❡t❛❃ What happens to ❁s❝r❁s❝r✐♣t❃✐♣t❃ ? tag, or some browsers will guess ✰❆❉✇✲s❝r✐♣t✰❆❉✹✲ Filter failure: event handlers Use good libraries Coding your own defenses will never ❁■▼● ♦♥♠♦✉s❡♦✈❡r❂✧❛❧❡rt✭✬①ss✬✮✧❃ 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 New HTTP header, W3C candidate Announcements intermission recommendation Lets site opt-in to stricter treatment of More cross-site risks embedded content, such as: Confidentiality and privacy No inline JS, only loaded from separate URLs Even more web risks Disable JS ❡✈❛❧ et al. DNSSEC Has an interesting violation-reporting SSH mode
HA 2 questions Upcoming assignments 1. Network sniffing 2. Offline dictionary attack Progress reports due tonight by 3. Forging predictable cookies 11:55pm 4. SQL injection Exercise set 3 due Thursday at 11:55pm 5. Cross-site scripting 6. Crypto. attack against a poor MAC Outline HTTP header injection Cross-site scripting Announcements intermission Untrusted data included in response More cross-site risks headers Can include CRLF and new headers, or Confidentiality and privacy premature end to headers Even more web risks AKA “response splitting” DNSSEC SSH Content sniffing Cross-site request forgery Certain web form on ❜❛♥❦✳❝♦♠ used to Browsers determine file type from headers, extension, and content-based wire money guessing Link or script on ❡✈✐❧✳❝♦♠ loads it Latter two for ✘ ✶ % server errors with certain parameters Many sites host “untrusted” images Linking is exception to same-origin and media If I’m logged in, money sent Inconsistencies in guessing lead to a automatically kind of XSS Confused deputy, cookies are ambient E.g., “chimera” PNG-HTML document authority
CSRF prevention Open redirects Common for one page to redirect Give site’s forms random-nonce tokens clients to another E.g., in POST hidden fields Target should be validated Not in a cookie, that’s the whole point With authentication check if appropriate Reject requests without proper token Open redirect : target supplied in Or, ask user to re-authenticate parameter with no checks XSS can be used to steal CSRF tokens Doesn’t directly hurt the hosting site But reputation risk, say if used in phishing We teach users to trust by site Outline Site perspective Cross-site scripting Protect confidentiality of authenticators Announcements intermission Passwords, session cookies, CSRF tokens More cross-site risks Duty to protect some customer info Personally identifying info (“identity theft”) Confidentiality and privacy Credit-card info (Payment Card Industry Even more web risks Data Security Standards) Health care (HIPAA), education (FERPA) DNSSEC Whatever customers reasonably expect SSH 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 ♣❛ss✇♦r❞ fields are basic hints User privacy goals can be opposed to Consider disabling autocomplete site goals Usability tradeoff, save users from Such as in tracking for advertisements themselves Browser makers can find themselves in Finally standardized in HTML5 Consider disabling caching the middle 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 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 ♥ 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 But, many side-channel attacks have User agent string (10 bits) been possible Window/screen size (4.83 bits) Query link color Available fonts (13.9 bits) CSS style with external image for visited Plugin verions (15.4 bits) links (Data from ♣❛♥♦♣t✐❝❧✐❝❦✳❡❢❢✳♦r❣ , far from Slow-rendering timing channel Harvesting bitmaps exhaustive) User perception (e.g. fake CAPTCHA)
Browser and extension choices Outline Cross-site scripting More aggressive privacy behavior lives Announcements intermission in extensions Disabling most JavaScript (NoScript) More cross-site risks HTTPS Everywhere (whitelist) Tor Browser Bundle Confidentiality and privacy Default behavior is much more Even more web risks controversial DNSSEC Concern not to kill advertising support as an economic model SSH Misconfiguration problems Openness tradeoffs Error reporting Default accounts Few benign users want to see a stack backtrace Unneeded features 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 Fool users about what they’re clicking Large web apps can use a lot of on third-party code 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 Spoof cursor Stay up to date on security Temporal “bait and switch” announcements
Recommend
More recommend
