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

Outline The web from a security perspective CSci 5271 Announcements intermission Introduction to Computer Security SQL injection Web security, part 1 Stephen McCamant Web authentication failures University of Minnesota, Computer Science & Engineering Cross-site scripting Once upon a time: the static web Web applications The modern web depends heavily on HTTP: stateless file download protocol active software TCP , usually using port 80 Static pages have ads, paywalls, or HTML: markup language for text with “Edit” buttons formatting and links Many web sites are primarily forms or All pages public, so no need for storefronts authentication or encryption Web hosted versions of desktop apps like word processing Server programs Client-side programming Java: nice language, mostly moved to Could be anything that outputs HTML other uses In practice, heavy use of databases and ActiveX: Windows-only binaries, no frameworks sandboxing Wide variety of commercial, Glad to see it on the way out open-source, and custom-written Flash and Silverlight: most important Flexible scripting languages for ease of use is DRM-ed video development Core language: JavaScript PHP , Ruby, Perl, etc.

JavaScript and the DOM Same-origin policy JavaScript (JS) is a dynamically-typed Origin is a tuple (scheme, host, port) prototype-OO language E.g., (http, www.umn.edu, 80) No real similarity with Java Basic JS rule: interaction is allowed Document Object Model (DOM): lets JS only with the same origin interact with pages and the browser Different sites are (mostly) isolated Extensive security checks for applications untrusted-code model GET, POST, and cookies User and attack models ●❊❚ request loads a URL, may have “Web attacker” owns their own site parameters delimited with ❄ , ✫ , ❂ ( ✇✇✇✳❛tt❛❝❦❡r✳❝♦♠ ) Standard: should not have side-effects And users sometimes visit it P❖❙❚ request originally for forms Realistic reasons: ads, SEO Can be larger, more hidden, have “Network attacker” can view and sniff side-effects unencrypted data Cookie : small token chosen by server, Unprotected coffee shop WiFi sent back on subsequent requests to same domain Outline Note to early readers The web from a security perspective This is the section of the slides most Announcements intermission likely to change in the final version SQL injection If class has already happened, make sure you have the latest slides for Web authentication failures announcements Cross-site scripting

Outline Relational model and SQL The web from a security perspective Relational databases have tables with Announcements intermission rows and single-typed columns Used in web sites (and elsewhere) to SQL injection provide scalable persistent storage Web authentication failures Allow complex queries in a declarative language SQL Cross-site scripting Example SQL queries Template: injection attacks Your program interacts with an ❙❊▲❊❈❚ ♥❛♠❡✱ ❣r❛❞❡ ❋❘❖▼ interpreted language ❙t✉❞❡♥ts ❲❍❊❘❊ ❣r❛❞❡ ❁ ✻✵ Untrusted data can be passed to the ❖❘❉❊❘ ❇❨ ♥❛♠❡❀ interpreter ❯P❉❆❚❊ ❱♦t❡s ❙❊❚ ❝♦✉♥t ❂ Attack data can break parsing ❝♦✉♥t ✰ ✶ ❲❍❊❘❊ ❝❛♥❞✐❞❛t❡ ❂ assumptions and execute arbitrary ✬❏♦❤♥✬❀ commands SQL + injection Strings do not respect syntax Why is this named most critical web Key problem: assembling commands as app. risk? strings Easy mistake to make systematically ✧❲❍❊❘❊ ♥❛♠❡ ❂ ✬✩♥❛♠❡✬❀✧ Can be easy to exploit Looks like ✩♥❛♠❡ is a string Database often has high-impact Try contents ✩♥❛♠❡ ❂ ✧♠❡✬ ❖❘ ❣r❛❞❡ ❃ ✽✵❀ ✲✲✧ E.g., logins or credit cards on commerce site

Using tautologies Non-string interfaces Best fix: avoid constructing queries as Tautology: formula that’s always true strings Often convenient for attacker to see a SQL mechanism: prepared statement 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 Allow only things you know to be prevent an attack safe/intended Escaped data is encoded to match Error or delete anything else language rules for literal Short whitelist is easy and relatively E.g., ❭✧ and ❭♥ in C But many pitfalls for the unwary: easy to secure Differences in escape syntax between E.g., digits only for non-negative integer 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 Often web attacks don’t get to see the Space of possible attacks is endless, program don’t try to think of them all Not even binary, it’s on the server Want to guess how many more Surmountable obstacle: comment formats SQL has? Guess natural names for columns Particularly silly: blacklisting ✶❂✶ Harvest information from error messages

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: Shell commands: example from Ex. 1 if (x) delay 10 seconds More web examples to come Trick to remember: go one character at a time Outline Per-website authentication The web from a security perspective Many web sites implement their own login systems Announcements intermission ✰ If users pick unique passwords, little systemic risk SQL injection ✲ Inconvenient, many will reuse passwords ✲ Lots of functionality each site must Web authentication failures implement correctly ✲ Without enough framework support, many Cross-site scripting possible pitfalls Building a session Session ID: what Must not be predictable HTTP was originally stateless, but many Not a sequential counter Should ensure freshness sites want stateful login sessions E.g., limited validity window Building by tying requests together with If encoding data in ID, must be a shared session ID unforgeable Must protect confidentiality and E.g., data with properly used MAC 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 Usability / security tradeoff under HTTPS Needed to protect users who fail to log Because of CSRF (next time), should out from public browsers also have a non-cookie unique ID Account management Client and server checks For usability, interface should show Limitations on account creation what’s possible CAPTCHA? Outside email address? But must not rely on client to perform See previous discussion on hashed checks password storage Attackers can read/modify anything on Automated password recovery the client side Usually a weak spot But, practically required for large system Easy example: item price in hidden field Direct object references Function-level access control Seems convenient: query parameter E.g. pages accessed by URLs or names resource directly interface buttons E.g., database key, filename (path Must check each time that user is traversal) authorized Easy to forget to validate on each use Attack: find URL when authorized, reuse Alternative: indirect reference like when logged off per-session table Helped by consistent structure in code Not fundamentally more secure, but harder to forget check

Outline XSS: HTML/JS injection The web from a security perspective Note: CSS is “Cascading Style Sheets” Another use of injection template Announcements intermission Attacker supplies HTML containing SQL injection JavaScript (or occasionally CSS) OWASP’s most prevalent weakness Web authentication failures A category unto itself Easy to commit in any dynamic page Cross-site scripting construction Why XSS is bad (and named that) Reflected XSS ❛tt❛❝❦❡r✳❝♦♠ can send you evil JS Injected data used immediately in directly producing a page But XSS allows access to ❜❛♥❦✳❝♦♠ Commonly supplied as query/form data parameters Violates same-origin policy Classic attack is link from evil site to Not all attacks actually involve multiple victim site sites Persistent XSS DOM-based XSS Injected data used to produce page Injected occurs in client-side page later construction For instance, might be stored in Flaw at least partially in code running database on client Can be used by one site user to attack Many attacks involve mashups and another user inter-site communication E.g., to gain administrator privilege