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. TJX Hack 45 million pieces of credit card information were leaked. Attacker used SQLi and sniffed traffic. Breach cost $200 million Notable Examples

13. 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) alert(‘xss’) 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. “> alert(‘xss’);

17. 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 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. 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?