Outline Cross-site scripting CSci 5271 More cross-site risks Introduction to Computer Security Web security, part 2 Announcements intermission Stephen McCamant Confidentiality and privacy University of Minnesota, Computer Science & Engineering Even more web risks XSS: HTML/JS injection Why XSS is bad (and named that) Note: CSS is “Cascading Style Sheets” ❛tt❛❝❦❡r✳❝♦♠ can send you evil JS directly Another use of injection template But XSS allows access to ❜❛♥❦✳❝♦♠ data Attacker supplies HTML containing JavaScript (or Violates same-origin policy occasionally CSS) OWASP’s most prevalent weakness Not all attacks actually involve multiple sites A category unto itself Easy to commit in any dynamic page construction Reflected XSS Persistent XSS Injected data used to produce page later Injected data used immediately in producing a page For instance, might be stored in database Commonly supplied as query/form parameters Can be used by one site user to attack another user Classic attack is link from evil site to victim site E.g., to gain administrator privilege DOM-based XSS No string-free solution For server-side XSS, no way to avoid string Injection occurs in client-side page construction concatenation Flaw at least partially in code running on client Web page will be sent as text in the end Many attacks involve mashups and inter-site Research topic: ways to change this? communication XSS especially hard kind of injection
Danger: complex language embedding Danger: forgiving parsers JS and CSS are complex languages in their own right History: handwritten HTML, browser competition Can appear in various places with HTML Many syntax mistakes given “likely” interpretations But totally different parsing rules Handling of incorrect syntax was not standardized Example: ✧✳✳✳✧ used for HTML attributes and JS strings What happens when attribute contains JS? Sanitization: plain text only Sanitization: context matters Easiest case: no tags intended, insert at document An OWASP document lists 5 places in a web page text level you might insert text Escape HTML special characters with entities like For the rest, “don’t do that” ✫❧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 benign markup Browser capabilities continue to evolve like ❁❜❃ Attempts to list all bad constructs inevitably But, even benign tags can have JS attributes incomplete Handling well essentially requires an HTML parser Even worse for XSS than other injection attacks 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 ❁s❝r✐♣t❃ UTF-7 is similar but uses only ASCII What happens to ❁s❝r❁s❝r✐♣t❃✐♣t❃ ? Encoding can be specified in a ❁♠❡t❛❃ tag, or some browsers will guess ✰❆❉✇✲s❝r✐♣t✰❆❉✹✲
Filter failure: event handlers Use good libraries ❁■▼● ♦♥♠♦✉s❡♦✈❡r❂✧❛❧❡rt✭✬①ss✬✮✧❃ Coding your own defenses will never work Put this on something the user will be tempted to Take advantage of known good implementations click on Best case: already built into your framework There are more than 100 handlers like this Disappointingly rare recognized by various browsers Content Security Policy Outline Cross-site scripting New HTTP header, W3C candidate recommendation More cross-site risks Lets site opt-in to stricter treatment of embedded content, such as: Announcements intermission No inline JS, only loaded from separate URLs Disable JS ❡✈❛❧ et al. Confidentiality and privacy Has an interesting violation-reporting mode Even more web risks HTTP header injection Content sniffing Browsers determine file type from headers, Untrusted data included in response headers extension, and content-based guessing Can include CRLF and new headers, or premature Latter two for ✘ ✶ % server errors 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 Outline Cross-site scripting Common for one page to redirect clients to another Target should be validated More cross-site risks With authentication check if appropriate Announcements intermission Open redirect : target supplied in parameter with no checks Confidentiality and privacy Doesn’t directly hurt the hosting site But reputation risk, say if used in phishing Even more web risks We teach users to trust by site Note to early readers Outline Cross-site scripting This is the section of the slides most likely to change More cross-site risks in the final version Announcements intermission If class has already happened, make sure you have the latest slides for announcements Confidentiality and privacy 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 Data Security If you ask users to log in 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 hints Also consider encrypting data “at rest” Consider disabling autocomplete (Or, avoid storing it at all) Usability tradeoff, save users from themselves Provides defense in depth Finally standardized in HTML5 Reduce damage after another attack Consider disabling caching May be hard to truly separate keys Performance tradeoff OWASP example: public key for website ✦ backend Better not to have this on user’s disk credit card info Or proxy? You need SSL
User vs. site perspective Third party content / web bugs Much tracking involves sites other than the one in the URL bar User privacy goals can be opposed to site goals For fun, check where your cookies are coming from Such as in tracking for advertisements Various levels of cooperation Browser makers can find themselves in the middle Web bugs are typically 1x1 images used only for Of course, differ in institutional pressures tracking Cookies arms race Browser fingerprinting Privacy-sensitive users like to block and/or delete Combine various server or JS-visible attributes cookies passively Sites have various reasons to retain identification User agent string (10 bits) Window/screen size (4.83 bits) Various workarounds: Available fonts (13.9 bits) Similar features in Flash and HTML5 Plugin verions (15.4 bits) Various channels related to the cache Evercookie : store in ♥ places, regenerate if subset are (Data from ♣❛♥♦♣t✐❝❧✐❝❦✳❡❢❢✳♦r❣ , far from exhaustive) deleted History stealing Browser and extension choices More aggressive privacy behavior lives in extensions History of what sites you’ve visited is not supposed to be JS-visible Disabling most JavaScript (NoScript) But, many side-channel attacks have been possible HTTPS Everywhere (whitelist) Query link color Tor Browser Bundle CSS style with external image for visited links Default behavior is much more controversial Slow-rendering timing channel Concern not to kill advertising support as an economic Harvesting bitmaps model User perception (e.g. fake CAPTCHA) Outline Misconfiguration problems Cross-site scripting Default accounts More cross-site risks Unneeded features Announcements intermission 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 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
Recommend
More recommend
