Web Application Security

Transcription

1 Web Application Security John Zaharopoulos ITS - Security 10/9/2012 1

2 Web App Security Trends Web 2.0 Dynamic Webpages Growth of Ajax / Client side Javascript Hardening of OSes Secure by default Auto-patching and Auto-updating 10/9/2012 2

3 Recent Successful Attacks Sony Pictures Stolen admin details and passwords 75,000 music codes LinkedIn 6 million password hashes eharmony 1.5 million password hashes Yahoo 450K passwords 10/9/2012 3

4 OWASP Top 10 Threats 10/9/2012 4

5 SQL Injection A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. 10/9/2012 5

6 SQL Injection Example 1 Code: $password = mysql_query("select password FROM users WHERE password = '". $pass. "';"); Attacker sends: ' OR 1 = 1 /* Result: SELECT password FROM users WHERE password = '' OR 1 = 1 /* 10/9/2012 6

7 SQL Injection Example 2 Code: statement := "SELECT * FROM userinfo WHERE id = " + a_variable + "; Attacker sends: 1;DROP TABLE users Result: SELECT * FROM userinfo WHERE id=1;drop TABLE users; 10/9/2012 7

8 SQL Injection Defense Prepared Statements (Parameterized Queries) - Parameterized queries force developers to define all the SQL code, then pass in each parameter to the query, which allows the database to distinguish between code and data, regardless of what input is supplied. Stored Procedures - a stored procedure is defined and stored in the database itself, and then called from the application rather than something that a user is allowed to enter. Escaping all User Supplied Input - Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities. Least Privilege or minimizing the privileges assigned to every database account, so that users have enough permission to do their job, but no more. White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack 10/9/2012 8

9 Cross Side Scripting (XSS) Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web site. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. 10/9/2012 9

10 XSS Example 1a Non-persistent / Reflected: Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information. Mallory observes that Bob's website contains a reflected XSS vulnerability. Mallory crafts a URL to exploit the vulnerability, and sends Alice an , enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website (either directly or through an iframe or ajax), but will contain Mallory's malicious code, which the website will reflect. Alice visits the URL provided by Mallory while logged into Bob's website. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc.) without Alice's knowledge. 10/9/

11 XSS Example 1b 10/9/

12 XSS Example 2 Persistent attack: Mallory posts a message with malicious payload to a social network. When Bob reads the message, Mallory's XSS steals Bob's cookie. Mallory can now hijack Bob's session and impersonate Bob. 10/9/

13 XSS Defense Escaping transforming the data in such a way that the browser will not interpret it as code characters like "<" and "&" should be rewritten as HTML entities -- "<" and "& Validation and filtering disallow users from entering special characters like <, or filter out those characters. 10/9/

14 Additional Resources OWASP SANS Institute 10/9/

15 Questions? 10/9/