Outline The web from a security perspective (contd) SQL injection - PDF document

Outline The web from a security perspective (cont’d) SQL injection CSci 5271 Announcements intermission Introduction to Computer Security Web security, combined slides Web authentication failures Cross-site scripting Stephen McCamant University of Minnesota, Computer Science & Engineering More risks Confidentiality and privacy Same-origin policy GET, POST, and cookies ●❊❚ request loads a URL, may have parameters Origin is a tuple (scheme, host, port) delimited with ❄ , ✫ , ❂ E.g., (http, www.umn.edu, 80) Standard: should not have side-effects Basic JS rule: interaction is allowed only with the P❖❙❚ request originally for forms same origin Can be larger, more hidden, have side-effects Different sites are (mostly) isolated applications Cookie : small token chosen by server, sent back on subsequent requests to same domain User and attack models Outline The web from a security perspective (cont’d) “Web attacker” owns their own site SQL injection ( ✇✇✇✳❛tt❛❝❦❡r✳❝♦♠ ) Announcements intermission And users sometimes visit it Realistic reasons: ads, SEO Web authentication failures “Network attacker” can view and sniff unencrypted Cross-site scripting data More risks Unprotected coffee shop WiFi Confidentiality and privacy Relational model and SQL Example SQL queries Relational databases have tables with rows and ❙❊▲❊❈❚ ♥❛♠❡✱ ❣r❛❞❡ ❋❘❖▼ ❙t✉❞❡♥ts ❲❍❊❘❊ single-typed columns ❣r❛❞❡ ❁ ✻✵ ❖❘❉❊❘ ❇❨ ♥❛♠❡❀ Used in web sites (and elsewhere) to provide ❯P❉❆❚❊ ❱♦t❡s ❙❊❚ ❝♦✉♥t ❂ ❝♦✉♥t ✰ ✶ ❲❍❊❘❊ scalable persistent storage ❝❛♥❞✐❞❛t❡ ❂ ✬❏♦❤♥✬❀ Allow complex queries in a declarative language SQL

Template: injection attacks SQL + injection Why is this named most critical web app. risk? Your program interacts with an interpreted language Easy mistake to make systematically Untrusted data can be passed to the interpreter Can be easy to exploit Attack data can break parsing assumptions and Database often has high-impact contents execute arbitrary commands E.g., logins or credit cards on commerce site Strings do not respect syntax Using tautologies Key problem: assembling commands as strings Tautology: formula that’s always true ✧❲❍❊❘❊ ♥❛♠❡ ❂ ✬✩♥❛♠❡✬❀✧ Often convenient for attacker to see a whole table Looks like ✩♥❛♠❡ is a string Classic: ❖❘ ✶❂✶ Try ✩♥❛♠❡ ❂ ✧♠❡✬ ❖❘ ❣r❛❞❡ ❃ ✽✵❀ ✲✲✧ Non-string interfaces Retain functionality: escape Sanitizing data is transforming it to prevent an attack Best fix: avoid constructing queries as strings Escaped data is encoded to match language rules SQL mechanism: prepared statement for literal E.g., ❭✧ and ❭♥ in C Original motivation was performance But many pitfalls for the unwary: Web languages/frameworks often provide other Differences in escape syntax between servers syntax Must use right escape for context: not everything’s a string Lazy sanitization: whitelisting Poor idea: blacklisting Allow only things you know to be safe/intended Space of possible attacks is endless, don’t try to Error or delete anything else think of them all Want to guess how many more comment formats Short whitelist is easy and relatively easy to secure SQL has? E.g., digits only for non-negative integer Particularly silly: blacklisting ✶❂✶ But, tends to break benign functionality

Attacking without the program Blind SQL injection Attacking with almost no feedback Often web attacks don’t get to see the program Common: only “error” or “no error” Not even binary, it’s on the server Surmountable obstacle: One bit channel you can make yourself: if (x) delay Guess natural names for columns 10 seconds Harvest information from error messages Trick to remember: go one character at a time Injection beyond SQL Outline The web from a security perspective (cont’d) SQL injection XPath/XQuery: queries on XML data Announcements intermission LDAP: queries used for authentication Web authentication failures Shell commands: example from Ex. 1 Cross-site scripting More web examples to come More risks Confidentiality and privacy Hands-on assignment 2 questions Outline The web from a security perspective (cont’d) 1. Network sniffing SQL injection 2. Offline dictionary attack Announcements intermission 3. Forging predictable cookies Web authentication failures 4. SQL injection Cross-site scripting 5. Cross-site scripting More risks 6. Crypto. attack against a poor MAC Confidentiality and privacy Per-website authentication Building a session HTTP was originally stateless, but many sites want Many web sites implement their own login systems stateful login sessions ✰ If users pick unique passwords, little systemic risk ✲ Inconvenient, many will reuse passwords Built by tying requests together with a shared ✲ Lots of functionality each site must implement correctly session ID ✲ Without enough framework support, many possible pitfalls Must protect confidentiality and integrity

Session ID: what Session ID: where Must not be predictable Session IDs in URLs are prone to leaking Not a sequential counter Including via user cut-and-paste Should ensure freshness Usual choice: non-persistent cookie E.g., limited validity window Against network attacker, must send only under HTTPS If encoding data in ID, must be unforgeable Because of CSRF (next time), should also have a E.g., data with properly used MAC non-cookie unique ID Negative example: crypt(username ❦ server secret) Session management Account management Limitations on account creation Create new session ID on each login CAPTCHA? Outside email address? Invalidate session on logout See previous discussion on hashed password Invalidate after timeout storage Usability / security tradeoff Automated password recovery Needed to protect users who fail to log out from public Usually a weak spot browsers But, practically required for large system Client and server checks Direct object references Seems convenient: query parameter names For usability, interface should show what’s possible resource directly But must not rely on client to perform checks E.g., database key, filename (path traversal) Attackers can read/modify anything on the client Easy to forget to validate on each use side Alternative: indirect reference like per-session table Easy example: item price in hidden field Not fundamentally more secure, but harder to forget check Function-level access control Outline The web from a security perspective (cont’d) SQL injection E.g. pages accessed by URLs or interface buttons Announcements intermission Must check each time that user is authorized Web authentication failures Attack: find URL when authorized, reuse when logged off Cross-site scripting Helped by consistent structure in code More risks Confidentiality and privacy

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 occasionally CSS) Violates same-origin policy 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?