Security Testing for Web Developers - Geekup Liverpool - 26/06/2012

1. Matthew Hughes

2. Who am I?
 Pen tester
 Coder
 Blogger
 All around nice guy.

3. Who am I?
 Ethical Hacking for Computer Security BSc 2009 - 2011
 Internship at Mad Security 2010-2011
 Internship at St Noble/MMV – 2011
 Developer at CIC 2011-2012
 Unemployed “Entrepreneur” – Current

4. What is this all about then?
 Most web applications are insecure.
 Secure coding is hard.
 Developers generally don’t know how to test their own
sites.
 Insecure web applications are generally bad.

5. Why should you care?
 Security breaches are very expensive.
 Security breaches make you look like a moron.
 It’s fairly easy to mitigate against them.
 Hacking is fun.
 Security consultants are fucking expensive.

6. What will this talk cover?
 This talk is not exhaustive. It will only cover a fraction
of the basics.
 It will discuss various kinds of attack you can expect
your application to endure.
 It will give you an understanding of how to test for
security vulnerabilities in your application.

7. What will this talk cover?
 Detection
 Reflected XSS
 Stored XSS
 XSRF
 SQLi
 Mitigation
 Vulnerability disclosure

8. What will this talk cover?
 This talk is an introduction. It won’t cover everything.
 Web application security is a HUGE domain.

9. A bit of history…
 1995 – Most websites tended to be static pages coded
in pure HTML.
 1999 – Perl and PHP gain popularity, and their relative
ease of use allow for beginners to make web apps.
 And it sorta goes downhill from there…

10. So, what happened next?
 Nobody really understood the risks involved with
dynamic websites.
 More and more companies began to rely on web apps.
 More and more companies experienced security
breaches…
 Which for the most part has been fun to watch…

11. Notable examples
 Sony PSN Hack
 77 million pieces of personally information were leaked
via SQLi.
 Biggest leak in history.
 Outage lasted for 24 days.
 Total costs were $171 Million USD

12. Notable Examples
 TJX Hack
 45 million pieces of credit card information were leaked.
 Attacker used SQLi and sniffed traffic.
 Breach cost $200 million

13. Notable Examples
 Samy worm
 Samy Kamkar used an XSS vulnerability in MySpace to
get anyone who viewed his profile to friend request him,
and add “and most of all, Samy is my hero” and the
exploit code to their profiles.
 Within 20 hours, over 1,000,000 had their pages
compromised.

14. What conclusions can we draw?
 Security breaches can happen to large corporations
with huge amounts of resources.
 Security breaches are expensive. Really expensive.
 They can also be pretty funny.

15. Cross Site Scripting (XSS)
 XSS happens when an input isn’t correctly sanitized
and is either reflected in the page (reflected XSS) or
stored within the application and rendered for each
subsequent user (stored XSS).
 Whilst XSS attacks may seem harmless, they can be
the precursor to social engineering attacks, XSRF
attacks and can be used to steal cookies.

16. Cross Site Scripting (XSS)
 <script>alert(‘xss’)</script>
 Some sites in order to mitigate against XSS attacks
forbid the usage of ‘alert’… This doesn’t really mitigate
against XSS. Just use ‘prompt’. As we will see in the
next slide…
 Tags with attribute values can be mitigated by crafting
your attack string with “> at the front.
 “><script>alert(‘xss’);</script>

17. Cross Site Scripting (XSS)

18. Cross Site Scripting (XSS)

19. SQL Injection
 Generally, most dynamic websites contain a data store.
 These are generally interacted with using SQL.
 SQL is standardized, meaning that the attack syntax
generally works an all DBMS’
 ORM and NoSQL databases are vulnerable to injection
attacks. Just not SQL attacks.

20. SQL Injection
 Consider the following SQL query
 “Select * from users where username = @param;”
 What would happen if we were to put in the following
parameter.
 “dave’ or ‘1’ = 1”
 Since one does equal one, it will return all values.
 With union queries, one can add data into other
tables, creating the potential to create new accounts.

21. SQL Injection
 SQL Injection can also be used to bypass
authentication.
 Consider the following SQL query
 “Select * from users where username = @params and
passworld = @params”.
 What would happen if you were to pass it the
following
 Admin ‘ ---
 You can now authenticate against any account without
knowing the password…

22. Cross Site Request Forgery (XSRF)
 Consider the following URL:
 http://bankofliverpool.com/transfer?acount=purpleak
i&amount=9001&for=JenniferEllison
 If the user is authenticated and the site is vulnerable to
XSRF, then Jennifer Ellison is about to get over nine
thousand pounds from Purple Aki
 “But surely this is just a browser/local user issue?”

23. Cross Site Request Forgery (XSRF)
 Well, yes and no…
 The user has to be authenticated on their local
machine and have a valid cookie.
 But… consider the following code.
 <img
href=http://bankofliverpool.com/transfer?acount=pur
pleaki&amount=9001&for=JenniferEllison>
 Now, this isn’t a valid image… But the browser will still
call that URL.

24. Going on from here…
 This is going to be the last I’m going to talk about
when it comes to vulnerability discovery…
 It’s a huge field.
 Web Application Hackers Handbook is a good place to
start…
 DVWA is a great sandboxed environment where you
can use offensive security testing techniques.
 A lot of testing can be automated and there are various
firefox/Chrome plugins which do a lot of the legwork.

25. Going on from here
 OWASP is a group dedicated to web app security.
 They meet fairly often in these parts and entrance is
free.
 Read the OWASP Top 10. Just do it.

26. Another valid point…
 It’s generally frowned upon to test systems that don’t
belong to you.
 Don’t do it, unless you have permission, or you like
prison food.

27. Mitigation
 A good offense is generally the best defence…
 Your best is often not good enough, especially against a
really motivated hacker.
 Web Application firewalls are a solid line of defence
against many attacks.
 Trustwave’s ModSecurity is very, very good.

28. Mitigation
 There’s no point reinforcing a door if you’re going to
leave the windows open.
 Ensure that the underlying infrastructure is regularly
patched, you have an IDS (Snort is free and very, very
good) and you reduce the surface of attack by turning
off services you don’t need and running a firewall.

29. Responsible vulnerability
disclosure…
 We’re all geeks. We’re curious. I know some of you will
discard my valid point I made earlier.
 Full Disclosure is bad. Very bad.
 Responsible disclosure is good. Very good.
 Upsploit.com is a good resource for handling
vulnerability disclosure.

30. Keep in touch?
 Twitter.com/matthewhughes
 me@matthewhughes.co.uk
 Facebook.com/matthewjhughes
 Matthewhughes.co.uk

31. Thank you!
 Any questions?