1. Workshop 3 Web Application Security Li Weichao March 14 2014

2. Objectives Understand the foundational principles of web application security. Understand the top ten security risks and how to prevent them. Obtain hands-on experience for some of the attacking methods, such as SQL injection, cross-site scripting.

3. Web application security A branch of Information Security that deals specifically with security of websites, web applications and web services (from Wikipedia) The Open Web Application Security Project (OWASP) – An open-source web application security project – The community includes corporations, educational organizations, and individuals from around the world – Works to create freely-available articles, methodologies, documentation, tools, and technologies – https://www.owasp.org/index.php/Main_Page https://www.owasp.org/index.php/Main_Page

4. Background knowledge Web – Abbreviation of “World Wide Web (WWW)”, an Internet system based on hypertext Web application and service – The application software or communication method over the WWW – Usually runs in or is supported by a web browser

5. Characteristics of modern web system Typical client/server model (B/S model) The messages are encapsulated by hypertext languages, e.g., HTML, XML, … Evolves from static web to dynamic web Stylesheets, scripting languages, third-party pluggins are allowed to improve user experience

6. Characteristics of modern web system (cont’d) The modern web server is usually not a standalone server, but a server farm that consists of multiple servers, such cache server, front-end server, database server, … Many languages can be used for developing a web system, e.g., PHP, Perl, Java, Ruby, …

7. Top 10 security risks (2013) Injection Broken authentication and session management Cross-site scripting (XSS) Insecure direct object references Security misconfiguration

8. Top 10 security risks (2013) (cont’d) Sensitive data exposure Missing function level access control Cross-site request forgery (CSRF) Using components with known vulnerabilities Unvalidated redirects and forwards For more details, please refer to http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20- %202013.pdf http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20- %202013.pdf

9. Injection Changes the normal execution by appending code into the program Can trick the interpreter into executing unintended commands or accessing data without proper authorization Can be found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers; …

10. SQL injection Structure Query Language (SQL) – Designed for managing data held in a relational database management system (RDBMS) SQL injection – Insert malicious SQL statements into an entry field for database execution (e.g., dump the database content to the attacker)

11. Example attack scenarios Suppose a URL to accept the user inquiry: http://example.com/app/accountView?id=1 The web system parse the inquiry and generate a SQL statement to query the database: SELECT * FROM accounts WHERE custID=‘1’ If the attacker request: http://example.com/app/accountView?id=1’ or ’1’=‘1 The SQL statement will be changed to: SELECT * FROM accounts WHERE custID=‘1’ or ’1’=‘1’, equivalent to SELECT * FROM accounts WHERE 1 All the records in the table “accounts” will be shown

12. Defenses Prepared statements (parameterized queries) – Developer first defines the SQL code as a template (prepare) – When performing query, the constant values in the template are substituted by the entire inputs (execute) – Supported by many languages(e.g., PHP PDO) Stored procedures – Similar to prepared statement – The template is stored in the database itself Escaping all user supplied input – Encode and replace (escape) some vulnerable characters before pass them in the SQL statement – Frailer than the previous two methods For more details, please refer to https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

13. Cross-site scripting (XSS) Same-origin policy – An important concept in the web application security model – Permits scripts running on pages originating from the same site (a combination of scheme, hostname, and port number) to access each other's DOM with no specific restrictions, but prevents access to DOM on different sites – E.g., it is not allowed for the script in the page “http://example.com/index.htm” to access the link “http://www.facebook.com”

14. Cross-site scripting (XSS) (cont’d) Attackers inject client-side script into Web pages and bypass the same-origin access controls XSS attacks can be carried out by using HTML, JavaScript, VBScript, ActiveX, Flash, … Can result in account hijacking, changing of client settings, cookie theft/poisoning, false advertising, …

15. High level view (From https://www.acunetix.com/websitesecurity/xss/)https://www.acunetix.com/websitesecurity/xss/

16. Example attack scenarios A web page will accept a URL parameter “CC” and process it in this way (without validation or escaping): The attacker modifies the ‘CC’ parameter in his browser to: This causes the victim’s session ID to be exposed: (String) page += " "; '> alert(document.cookie) ' (String) page += " alert(document.cookie) '") + "'>";

17. Type of XSS attacks Stored – The injected script is permanently stored on the target server (e.g., via forum or blog posts) Reflected – The script is not stored on the target server – Attacker usually needs to construct a malicious URL DOM based – Attacker also needs to construct a malicious URL – But the parameter of this URL is not processed by the web server, but executed by the browser directly

18. Defenses Never insert untrusted data except in allowed locations Character escape – HTML, attribute, JavaScript, CSS, URL, … Sanitize HTML markup with a library designed for the job Prevent DOM-based XSS by using HTTPOnly cookie flag and implementing content security policy For more details, please refer to https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

19. Exercise - WebGoat Download and extract WebGoat: https://webgoat.googlecode.com/files/WebGoat-5.4- OWASP_Standard_Win32.zip https://webgoat.googlecode.com/files/WebGoat-5.4- OWASP_Standard_Win32.zip Or http://www4.comp.polyu.edu.hk/~oneprobe/ta/WebGoat- 5.4-OWASP_Standard_Win32.ziphttp://www4.comp.polyu.edu.hk/~oneprobe/ta/WebGoat- 5.4-OWASP_Standard_Win32.zip Run “webgoat.bat” and visit http://localhost/WebGoat/attackhttp://localhost/WebGoat/attack Or run “webgoat_8080.bat” and visit http://localhost:8080/WebGoat/attack http://localhost:8080/WebGoat/attack Username & PW: “guest” Official site of WebGoat project: https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

20. Exercise - WebScarab A tool for analyzing applications that communicate using the HTTP and HTTPS protocols Download the installation file: http://www4.comp.polyu.edu.hk/~oneprobe/ta/ webscarab-installer-20070504-1631.jar http://www4.comp.polyu.edu.hk/~oneprobe/ta/ webscarab-installer-20070504-1631.jar Make sure you have installed JRE or JDK Double click the jar file and install the tool Run the tool and set the proxy of browser to “localhost” and port “8008” Official site of WebScarab: https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

21. Questions Visit the vulnerable site http://158.132.255.33/ (or http://158.132.255.33:25008/ from outside of the campus)http://158.132.255.33/ http://158.132.255.33:25008/ 1.Log into the system as an existing user by using SQL injection (10 marks) 2.Register a new user (with your student ID), and use that account to perform a stored XSS attack (10 marks) 3.Construct a URL and perform a reflected XSS attack (10 marks) 4.If you have successfully stolen the secret information, how can you sent it to your own web site? (10 marks)

22. Q & A