Web Security Thierry Sans Securing the web architecture means securing ... • The network (DMZ configuration) • The operating system • The web server (Apache for instance) • The database (Oracle for instance) • The administration server (SSH for instance) • The web application Our focus here! Average Number of Vulnerabilities (based on 7000 websites) source “WhiteHat Website Security Statistics report 2012” from WhiteHat Security Anatomy of a web application Anatomy of a web application Anatomy of a web application id=scACRSm... <!DOCTYPE html><html><... HTML PHP Java ASP/.Net Ruby Python Server JS Dynamic Webpage Content Ajax - fetching data without refreshing the page id=scACRSm... Ajax Javascript anything HTML PHP Java ASP/.Net Ruby Python Server JS Attacks on web applications The most widespread vulnerabilities in web applications source “WhiteHat Website Security Statistics report 2012” from WhiteHat Security Information Leakage Information Leakage “AT&T Inc. apologized to Apple Inc. iPad 3G tablet computer users whose e-mail addresses were exposed during a security breach disclosed last week.” source Business Week - June 14 2010 “There’s no hack, no infiltration, and no breach, just a really poorly designed web application that returns e-mail address when ICCID is passed to it.” source Praetorian Prefect - June 9 2010 Solution ✓ Authentication • ✓ Who are the authorized users? Authorization • Who can access what and how? The simple recipe for user authentication 1. Ask the user for a login and password and send it to the server (HTTP/POST request) 2. Verify the login/password based on information stored on the server (usually in the database) 3. Start a session once the user has been authenticated 4. Grant access to resources according to the session The big picture Client Side session id Server Side HTTP request HTTP response HTTP request HTTP response Web Browser Web Server key/value pairs data The concept of session There is a session id (aka token) between the browser and the web application • This session id should be unique and unforgeable (usually a long random number or a hash) ➡ Stored in the cookie • The session id is bind to key/value pairs data ➡ Stored on the server • Hacking sessions The user can create, modify, delete the session ID in the cookie But cannot access the key/value pairs stored on the server Do you trust the network? interesting! id=scACRSm... <html><... Do you really trust the network? id=scACRSm... <html><... I am Problem ๏ An attacker can eavesdrop messages sent back and forth ๏ An attacker can tamper with messages sent back and forth Confidentiality and Integrity Confidentiality: how do exchange information secretly? ✓ Encryption Integrity: How do we exchange information reliably? ✓ Digital Signature Generic solution - HTTPS ➡ SSL provides • end-to-end secure channel (confidentially) • authentication handshake (integrity) ✓ HTTPS = HTTP + SSL Self-signed certificate Step 1 Show me who you are? Step 2 Here is my certificate? Step 0 Generate the certificate Do I trust this certificate? Your browser cannot verify the certificate Certificate Authority (CA) Step 1 Show me who you are? Step 2 Here is my certificate? Step 0 Generate the certificate Do I trust this certificate signed by Thawte? Your browser trusts some CA by defaults When to use HTTPS? We need to protect • Login and password • Session ID ✓ HTTPS must be used during the entire session Authorization ➡ Define a security policy and enforce permissions on each url (including media files) ✓ based on what you know about the user (session) ๏ but not on what the user claims (query string, cookie) SQL Injection SQL Password Checking Attack loginPage.html 123456 OR 1=1 name=Alice&pwd=123456 checkPassword.php <?php $uid = SQLQuery("SELECT uid FROM LoginTable WHERE login=" . $_POST['name'] . "AND password =" . $POST['pwd ']); Access Deny! Access Granted! if ($uid) echo "Access Granted"; else echo "Access Denied"; ?> Problem ➡ An attacker can inject SQL code ๏ Retrieve, add, modify, delete information ๏ Bypass authentication Generic Solution ✓ Escape all special SQL parameters according to the quoting conventions of the database server you are using Content Spoofing Content Spoofing GET /?videoid=527 <html ... comment = “<a href=”myad.com”>Fun stuff ... GET /?videoid=527 <html ... The page contains the attacker’s ad. * Notice that Youtube is not vulnerable to this attack Problem ➡ An attacker can inject HTML tags in the page ๏ Add illegitimate content to the webpage (ads most of the time) Cross-Site Request Forgery GET View/?profileid=53 <img src=”www.alice.com/profilepic GET profilepic www.alice.com www.badwebsite.com GET Delete/?profileid=53 ??? ...... GET setProfile/?url=Delete/?profileid=53 Done! profileid=86 Hey Alice, check my profile GET View/?profileid=86 <img src=”Delete/?profileid=53 GET Delete/?profileid=53 id url name 53 www.alice.com/ profilepic Alice 86 www.badwebsite.com/ Delete/?imageid=53 Charlie Problem ➡ An attacker can call do HTTP request by injecting url-based HTML tags in the page that the browser will retrieve automatically ๏ Inject an image content ๏ Insert any HTML content for which the CSS image background can be defined Cross-Site Scripting (XSS) Cross-Site Scripting Attack (XSS attack) “Hello <script language="javascript">alert(“XSS attack”);</script>!” “Hello CMU!” name=CMU name=<script language="javascript">alert(“XSS attack”);</script> XSS Attack = Javascript Code Injection Problem ➡ An attacker can inject arbitrary javascript code in the page that will be executed by the browser Inject illegitimate content in the page (same as content spoofing) ๏ Perform illegitimate HTTP requests through Ajax (same as a CSRF attack) ๏ Steal Session ID from the cookie ๏ Steal user’s login/password by modifying the page to forge a perfect scam ๏ Forging a perfect scam GET /?videoid=527 <html ... comment = “<script> ... GET /?videoid=527 <html ... login=Alice&password=123456 The script contained in the comments modfies the page to look like the login page! * Notice that Youtube is not vulnerable to this attack It gets worst - XSS Worms • Spread on social networks • Samy targeting MySpace (2005) • JTV.worm targeting Justin.tv (2008) • Twitter worm targeting Twitter (2010) XSS attacks are widespread Generic solution for injection-based vulnerabilities ✓ Always escape tainted data i.e. data that comes from (or derived from) user inputs Conclusion You have absolutely no control on the client Client Side Web Browser Server Side Web Server Database References • Mozilla Secure Coding Guideline https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines • Ruby on Rails Security Page http://guides.rubyonrails.org/security.html • Django Security Page https://docs.djangoproject.com/en/dev/topics/security/ • PHP Security Pages http://php.net/manual/en/security.php http://phpsec.org/projects/guide/