outline
play

Outline SSL/TLS DNSSEC CSci 5271 Introduction to Computer - PDF document

Outline SSL/TLS DNSSEC CSci 5271 Introduction to Computer Security Announcements intermission Day 19: Web security, part 1 The web from a security perspective Stephen McCamant University of Minnesota, Computer Science & Engineering SQL


  1. Outline SSL/TLS DNSSEC CSci 5271 Introduction to Computer Security Announcements intermission Day 19: Web security, part 1 The web from a security perspective Stephen McCamant University of Minnesota, Computer Science & Engineering SQL injection Web authentication failures But wait, there’s more! CA vs. leaf checking bug Two recent problems, with cute names: Certs have a bit that says if they’re a Heartbleed CA Information-disclosure implementation bug All but last entry in chain should have it in OpenSSL set Buffer over-read Browser authors repeatedly fail to POODLE: “Padding Oracle On check this bit Downgraded Legacy Encryption” Padding oracle in SSL 3.0 returns when a Allows any cert to sign any other cert MITM forces downgrade MD5 certificate collisions CA validation standards MD5 collisions allow forging CA certs CA’s job to check if the buyer really is ❢♦♦✳❝♦♠ Create innocuous cert and CA cert with Race to the bottom problem: same hash CA has minimal liability for bad certs Requires some guessing what CA will do, Many people want cheap certs like sequential serial numbers Cost of validation cuts out of profit Also 200 PS3s “Extended validation” (green bar) certs Oh, should we stop using that hash attempt to fix function?

  2. HTTPS and usability Outline SSL/TLS Many HTTPS security challenges tied DNSSEC with user decisions Announcements intermission Is this really my bank? Seems to be a quite tricky problem The web from a security perspective Security warnings often ignored, etc. SQL injection We’ll return to this as a major example later Web authentication failures DNS: trusted but vulnerable DNSSEC goals and non-goals Almost every higher-level service ✰ Authenticity of positive replies interacts with DNS ✰ Authenticity of negative replies UDP protocol with no authentication or crypto ✰ Integrity Lots of attacks possible ✲ Confidentiality Problems known for a long time, but ✲ Availability challenge to fix compatibly First cut: signatures and certificates Add more indirection Each resource record gets an ❘❘❙■● signature DNS needs to scale to very large flat E.g., ❆ record for one name ✦ address domains like ✳❝♦♠ mapping Observe: signature often larger than data Facilitated by having single ❉❙ RR in Signature validation keys in ❉◆❙❑❊❨ parent indicating delegation RRs Chain to root now includes ❉❙ es as well Recursive chain up to the root (or other “anchor”)

  3. Negative answers Preventing zone enumeration Also don’t want attackers to spoof Many domains would not like people non-existence enumerating all their entries Gratuitous denial of service, force fallback, DNS is public, but “not that public” etc. Unfortunately ◆❙❊❈ makes this trivial But don’t want to sign “ ① does not Compromise: ◆❙❊❈✸ uses exist” for all ① password-like salt and repeated hash, Solution 1, ◆❙❊❈ : “there is no name allows opt-out between ❛❝❛❝✐❛ and ❜❛♦❜❛❜ ” DANE: linking TLS to DNSSEC Signing the root Political problem: many already distrust “DNS-based Authentication of Named US-centered nature of DNS Entities” infrastructure DNS contains hash of TLS cert, don’t Practical problem: must be very secure need CAs with no single point of failure Finally accomplished in 2010 How is DNSSEC’s tree of certs better Solution involves ‘key ceremonies’, than TLS’s? international committees, smart cards, safe deposit boxes, etc. Deployment Outline SSL/TLS Standard deployment problem: all cost DNSSEC and no benefit to being first mover Announcements intermission Servers working on it, mostly top-down Clients: still less than 10% The web from a security perspective Will be probably common: insecure SQL injection connection to secure resolver Web authentication failures

  4. Upcoming assignments Outline SSL/TLS Exercise set 3 due tonight DNSSEC HA2 Q1-2 readable now Announcements intermission HA2 materials coming probably Friday The web from a security perspective or over weekend Exercise set 4 posted soon, due 11/20 SQL injection Web authentication failures 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 , Perl, Ruby, etc.

  5. 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 Relational model and SQL SSL/TLS Relational databases have tables with DNSSEC rows and single-typed columns Announcements intermission Used in web sites (and elsewhere) to provide scalable persistent storage The web from a security perspective Allow complex queries in a declarative SQL injection language SQL Web authentication failures

  6. 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

  7. 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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend