Outline SSL/TLS (leftovers) The web from a security perspective - PDF document

Outline SSL/TLS (leftovers) The web from a security perspective CSci 5271 Introduction to Computer Security Announcements intermission Day 18: Web security, part 1 SQL injection Stephen McCamant Web authentication failures University of Minnesota, Computer Science & Engineering Cross-site scripting CA validation standards HTTPS and usability CA’s job to check if the buyer really is Many HTTPS security challenges tied ❢♦♦✳❝♦♠ with user decisions Race to the bottom problem: Is this really my bank? CA has minimal liability for bad certs Many people want cheap certs Seems to be a quite tricky problem Cost of validation cuts out of profit Security warnings often ignored, etc. “Extended validation” (green bar) certs We’ll return to this as a major example later attempt to fix Outline Once upon a time: the static web SSL/TLS (leftovers) HTTP: stateless file download protocol The web from a security perspective TCP , usually using port 80 Announcements intermission HTML: markup language for text with formatting and links SQL injection All pages public, so no need for Web authentication failures authentication or encryption Cross-site scripting

Web applications Server programs The modern web depends heavily on Could be anything that outputs HTML active software In practice, heavy use of databases and Static pages have ads, paywalls, or frameworks “Edit” buttons Wide variety of commercial, Many web sites are primarily forms or open-source, and custom-written storefronts Flexible scripting languages for ease of development Web hosted versions of desktop apps PHP , Ruby, Perl, etc. like word processing Client-side programming JavaScript and the DOM Java: nice language, mostly moved to JavaScript (JS) is a dynamically-typed other uses prototype-OO language ActiveX: Windows-only binaries, no No real similarity with Java sandboxing Document Object Model (DOM): lets JS Glad to see it on the way out interact with pages and the browser Flash and Silverlight: most important Extensive security checks for use is DRM-ed video untrusted-code model Core language: JavaScript Same-origin policy GET, POST, and cookies ●❊❚ request loads a URL, may have Origin is a tuple (scheme, host, port) parameters delimited with ❄ , ✫ , ❂ Standard: should not have side-effects E.g., (http, www.umn.edu, 80) P❖❙❚ request originally for forms Basic JS rule: interaction is allowed Can be larger, more hidden, have only with the same origin side-effects Different sites are (mostly) isolated Cookie : small token chosen by server, applications sent back on subsequent requests to same domain

User and attack models Outline SSL/TLS (leftovers) “Web attacker” owns their own site The web from a security perspective ( ✇✇✇✳❛tt❛❝❦❡r✳❝♦♠ ) And users sometimes visit it Announcements intermission Realistic reasons: ads, SEO SQL injection “Network attacker” can view and sniff unencrypted data Web authentication failures Unprotected coffee shop WiFi Cross-site scripting Upcoming assignments Outline SSL/TLS (leftovers) The web from a security perspective Project progress reports due Announcements intermission Wednesday SQL injection Exercise set 3 due Thursday Web authentication failures Cross-site scripting Relational model and SQL Example SQL queries Relational databases have tables with ❙❊▲❊❈❚ ♥❛♠❡✱ ❣r❛❞❡ ❋❘❖▼ rows and single-typed columns ❙t✉❞❡♥ts ❲❍❊❘❊ ❣r❛❞❡ ❁ ✻✵ Used in web sites (and elsewhere) to ❖❘❉❊❘ ❇❨ ♥❛♠❡❀ provide scalable persistent storage ❯P❉❆❚❊ ❱♦t❡s ❙❊❚ ❝♦✉♥t ❂ Allow complex queries in a declarative ❝♦✉♥t ✰ ✶ ❲❍❊❘❊ ❝❛♥❞✐❞❛t❡ ❂ language SQL ✬❏♦❤♥✬❀

Template: injection attacks SQL + injection Why is this named most critical web Your program interacts with an app. risk? interpreted language Easy mistake to make systematically Untrusted data can be passed to the Can be easy to exploit interpreter Database often has high-impact Attack data can break parsing contents assumptions and execute arbitrary E.g., logins or credit cards on commerce commands site Strings do not respect syntax Using tautologies Key problem: assembling commands as Tautology: formula that’s always true strings 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 Escaped data is encoded to match strings language rules for literal SQL mechanism: prepared statement E.g., ❭✧ and ❭♥ in C Original motivation was performance But many pitfalls for the unwary: Web languages/frameworks often Differences in escape syntax between provide other syntax servers Must use right escape for context: not everything’s a string

Lazy sanitization: whitelisting Poor idea: blacklisting Allow only things you know to be Space of possible attacks is endless, safe/intended don’t try to think of them all Error or delete anything else Want to guess how many more Short whitelist is easy and relatively comment formats SQL has? easy to secure Particularly silly: blacklisting ✶❂✶ E.g., digits only for non-negative integer 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 One bit channel you can make yourself: Surmountable obstacle: if (x) delay 10 seconds Guess natural names for columns Trick to remember: go one character at Harvest information from error messages a time Injection beyond SQL Outline SSL/TLS (leftovers) The web from a security perspective XPath/XQuery: queries on XML data Announcements intermission LDAP: queries used for authentication Shell commands: example from Ex. 1 SQL injection More web examples to come Web authentication failures Cross-site scripting

Per-website authentication Building a session Many web sites implement their own HTTP was originally stateless, but many login systems sites want stateful login sessions ✰ If users pick unique passwords, little systemic risk Building by tying requests together with ✲ Inconvenient, many will reuse passwords a shared session ID ✲ Lots of functionality each site must Must protect confidentiality and implement correctly ✲ Without enough framework support, many integrity possible pitfalls Session ID: what Session ID: where Must not be predictable Session IDs in URLs are prone to Not a sequential counter leaking Should ensure freshness Including via user cut-and-paste E.g., limited validity window Usual choice: non-persistent cookie If encoding data in ID, must be Against network attacker, must send only unforgeable under HTTPS E.g., data with properly used MAC Because of CSRF (next time), should Negative example: crypt(username ❦ also have a non-cookie unique ID 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 Invalidate after timeout password storage Usability / security tradeoff Automated password recovery Needed to protect users who fail to log Usually a weak spot out from public browsers But, practically required for large system

Client and server checks Direct object references Seems convenient: query parameter For usability, interface should show names resource directly what’s possible E.g., database key, filename (path But must not rely on client to perform traversal) checks Easy to forget to validate on each use Attackers can read/modify anything on Alternative: indirect reference like the client side per-session table Easy example: item price in hidden field Not fundamentally more secure, but harder to forget check Function-level access control Outline SSL/TLS (leftovers) E.g. pages accessed by URLs or The web from a security perspective interface buttons Must check each time that user is Announcements intermission authorized SQL injection Attack: find URL when authorized, reuse when logged off Web authentication failures Helped by consistent structure in code Cross-site scripting XSS: HTML/JS injection Why XSS is bad (and named that) Note: CSS is “Cascading Style Sheets” ❛tt❛❝❦❡r✳❝♦♠ can send you evil JS Another use of injection template directly Attacker supplies HTML containing But XSS allows access to ❜❛♥❦✳❝♦♠ JavaScript (or occasionally CSS) data OWASP’s most prevalent weakness Violates same-origin policy A category unto itself Not all attacks actually involve multiple Easy to commit in any dynamic page sites construction