Outline The web from a security perspective CSci 5271 Introduction - PDF document

Outline The web from a security perspective CSci 5271 Introduction to Computer Security SQL injection Web security, part 1 Announcements intermission Stephen McCamant University of Minnesota, Computer Science & Engineering Web authentication failures Once upon a time: the static web Web applications HTTP: stateless file download protocol The modern web depends heavily on active software TCP , usually using port 80 Static pages have ads, paywalls, or “Edit” buttons HTML: markup language for text with formatting and Many web sites are primarily forms or storefronts links Web hosted versions of desktop apps like word All pages public, so no need for authentication or processing encryption Server programs Client-side programming Java: nice language, mostly moved to other uses Could be anything that outputs HTML ActiveX: Windows-only binaries, no sandboxing In practice, heavy use of databases and frameworks Glad to see it on the way out Wide variety of commercial, open-source, and Flash and Silverlight: most important use is DRM-ed custom-written video Flexible scripting languages for ease of development PHP , Ruby, Perl, etc. Core language: JavaScript JavaScript and the DOM Same-origin policy JavaScript (JS) is a dynamically-typed prototype-OO Origin is a tuple (scheme, host, port) language E.g., (http, www.umn.edu, 80) No real similarity with Java Basic JS rule: interaction is allowed only with the Document Object Model (DOM): lets JS interact with same origin pages and the browser Different sites are (mostly) isolated applications Extensive security checks for untrusted-code model

GET, POST, and cookies User and attack models ●❊❚ request loads a URL, may have parameters “Web attacker” owns their own site delimited with ❄ , ✫ , ❂ ( ✇✇✇✳❛tt❛❝❦❡r✳❝♦♠ ) Standard: should not have side-effects And users sometimes visit it Realistic reasons: ads, SEO P❖❙❚ request originally for forms “Network attacker” can view and sniff unencrypted Can be larger, more hidden, have side-effects data Cookie : small token chosen by server, sent back on Unprotected coffee shop WiFi subsequent requests to same domain Outline Relational model and SQL The web from a security perspective Relational databases have tables with rows and single-typed columns SQL injection Used in web sites (and elsewhere) to provide Announcements intermission scalable persistent storage Allow complex queries in a declarative language SQL Web authentication failures Example SQL queries Template: injection attacks Your program interacts with an interpreted language ❙❊▲❊❈❚ ♥❛♠❡✱ ❣r❛❞❡ ❋❘❖▼ ❙t✉❞❡♥ts ❲❍❊❘❊ ❣r❛❞❡ ❁ ✻✵ ❖❘❉❊❘ ❇❨ ♥❛♠❡❀ Untrusted data can be passed to the interpreter ❯P❉❆❚❊ ❱♦t❡s ❙❊❚ ❝♦✉♥t ❂ ❝♦✉♥t ✰ ✶ ❲❍❊❘❊ Attack data can break parsing assumptions and ❝❛♥❞✐❞❛t❡ ❂ ✬❏♦❤♥✬❀ execute arbitrary commands SQL + injection Strings do not respect syntax Why is this named most critical web app. risk? Key problem: assembling commands as strings Easy mistake to make systematically ✧❲❍❊❘❊ ♥❛♠❡ ❂ ✬✩♥❛♠❡✬❀✧ Can be easy to exploit Looks like ✩♥❛♠❡ is a string Database often has high-impact contents Try ✩♥❛♠❡ ❂ ✧♠❡✬ ❖❘ ❣r❛❞❡ ❃ ✽✵❀ ✲✲✧ E.g., logins or credit cards on commerce site

Using tautologies Non-string interfaces Best fix: avoid constructing queries as strings Tautology: formula that’s always true SQL mechanism: prepared statement Often convenient for attacker to see a whole table Original motivation was performance Classic: ❖❘ ✶❂✶ Web languages/frameworks often provide other syntax Retain functionality: escape Lazy sanitization: whitelisting Sanitizing data is transforming it to prevent an attack Allow only things you know to be safe/intended Escaped data is encoded to match language rules Error or delete anything else for literal Short whitelist is easy and relatively easy to secure E.g., ❭✧ and ❭♥ in C But many pitfalls for the unwary: E.g., digits only for non-negative integer Differences in escape syntax between servers But, tends to break benign functionality Must use right escape for context: not everything’s a string Poor idea: blacklisting Attacking without the program Space of possible attacks is endless, don’t try to Often web attacks don’t get to see the program think of them all Not even binary, it’s on the server Want to guess how many more comment formats Surmountable obstacle: SQL has? Guess natural names for columns Harvest information from error messages Particularly silly: blacklisting ✶❂✶ Blind SQL injection Injection beyond SQL Attacking with almost no feedback XPath/XQuery: queries on XML data Common: only “error” or “no error” LDAP: queries used for authentication One bit channel you can make yourself: if (x) delay Shell commands: example from Ex. 1 10 seconds More web examples to come Trick to remember: go one character at a time

Outline Note to early readers The web from a security perspective This is the section of the slides most likely to change SQL injection in the final version If class has already happened, make sure you have Announcements intermission the latest slides for announcements Web authentication failures Outline Per-website authentication The web from a security perspective Many web sites implement their own login systems SQL injection ✰ If users pick unique passwords, little systemic risk ✲ Inconvenient, many will reuse passwords ✲ Lots of functionality each site must implement correctly Announcements intermission ✲ Without enough framework support, many possible pitfalls Web authentication failures Building a session Session ID: what Must not be predictable HTTP was originally stateless, but many sites want Not a sequential counter stateful login sessions Should ensure freshness Building by tying requests together with a shared E.g., limited validity window session ID If encoding data in ID, must be unforgeable E.g., data with properly used MAC Must protect confidentiality and integrity Negative example: crypt(username ❦ server secret) Session ID: where Session management Session IDs in URLs are prone to leaking Create new session ID on each login Including via user cut-and-paste Invalidate session on logout Usual choice: non-persistent cookie Invalidate after timeout Against network attacker, must send only under HTTPS Usability / security tradeoff Because of CSRF (next time), should also have a Needed to protect users who fail to log out from public non-cookie unique ID browsers

Account management Client and server checks Limitations on account creation For usability, interface should show what’s possible CAPTCHA? Outside email address? But must not rely on client to perform checks See previous discussion on hashed password Attackers can read/modify anything on the client storage side Automated password recovery Easy example: item price in hidden field Usually a weak spot But, practically required for large system Direct object references Function-level access control Seems convenient: query parameter names resource directly E.g. pages accessed by URLs or interface buttons E.g., database key, filename (path traversal) Must check each time that user is authorized Easy to forget to validate on each use Attack: find URL when authorized, reuse when logged off Alternative: indirect reference like per-session table Helped by consistent structure in code Not fundamentally more secure, but harder to forget check