Matthew Hughes
Who am I? Pen tester Coder Blogger All around nice guy.
Who am I? Ethical Hacking for Computer Security BSc 2009 - 2011 Internship at Mad Security 2010-2011 Internship at St N...
What is this all about then? Most web applications are insecure. Secure coding is hard. Developers generally don’t know...
Why should you care? Security breaches are very expensive. Security breaches make you look like a moron. It’s fairly ea...
What will this talk cover? This talk is not exhaustive. It will only cover a fraction  of the basics. It will discuss va...
What will this talk cover? Detection   Reflected XSS   Stored XSS   XSRF   SQLi Mitigation Vulnerability disclosure
What will this talk cover? This talk is an introduction. It won’t cover everything. Web application security is a HUGE d...
A bit of history… 1995 – Most websites tended to be static pages coded  in pure HTML. 1999 – Perl and PHP gain popularit...
So, what happened next? Nobody really understood the risks involved with  dynamic websites. More and more companies bega...
Notable examples Sony PSN Hack    77 million pieces of personally information were leaked     via SQLi.    Biggest leak...
Notable Examples TJX Hack    45 million pieces of credit card information were leaked.    Attacker used SQLi and sniffe...
Notable Examples Samy worm    Samy Kamkar used an XSS vulnerability in MySpace to     get anyone who viewed his profile ...
What conclusions can we draw? Security breaches can happen to large corporations  with huge amounts of resources. Securi...
Cross Site Scripting (XSS) XSS happens when an input isn’t correctly sanitized  and is either reflected in the page (refl...
Cross Site Scripting (XSS) <script>alert(‘xss’)</script> Some sites in order to mitigate against XSS attacks  forbid the...
Cross Site Scripting (XSS)
Cross Site Scripting (XSS)
SQL Injection Generally, most dynamic websites contain a data store. These are generally interacted with using SQL. SQL...
SQL Injection Consider the following SQL query “Select * from users where username = @param;” What would happen if we w...
SQL Injection SQL Injection can also be used to bypass    authentication.   Consider the following SQL query   “Select ...
Cross Site Request Forgery (XSRF) Consider the following URL: http://bankofliverpool.com/transfer?acount=purpleak  i&amo...
Cross Site Request Forgery (XSRF) Well, yes and no… The user has to be authenticated on their local  machine and have a ...
Going on from here… This is going to be the last I’m going to talk about    when it comes to vulnerability discovery…   ...
Going on from here OWASP is a group dedicated to web app security. They meet fairly often in these parts and entrance is...
Another valid point… It’s generally frowned upon to test systems that don’t  belong to you. Don’t do it, unless you have...
Mitigation A good offense is generally the best defence… Your best is often not good enough, especially against a  reall...
Mitigation There’s no point reinforcing a door if you’re going to  leave the windows open. Ensure that the underlying in...
Responsible vulnerabilitydisclosure… We’re all geeks. We’re curious. I know some of you will  discard my valid point I ma...
Keep in touch? Twitter.com/matthewhughes me@matthewhughes.co.uk Facebook.com/matthewjhughes Matthewhughes.co.uk
Thank you! Any questions?
Upcoming SlideShare
Loading in …5
×

Security testing for web developers

828 views
751 views

Published on

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

Published in: Technology
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
828
On SlideShare
0
From Embeds
0
Number of Embeds
92
Actions
Shares
0
Downloads
17
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Security testing for web developers

  1. 1. Matthew Hughes
  2. 2. Who am I? Pen tester Coder Blogger All around nice guy.
  3. 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. 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. 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. 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. 7. What will this talk cover? Detection  Reflected XSS  Stored XSS  XSRF  SQLi Mitigation Vulnerability disclosure
  8. 8. What will this talk cover? This talk is an introduction. It won’t cover everything. Web application security is a HUGE domain.
  9. 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. 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. 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. 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. 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. 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. 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. 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. 17. Cross Site Scripting (XSS)
  18. 18. Cross Site Scripting (XSS)
  19. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 29. Responsible vulnerabilitydisclosure… 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. 30. Keep in touch? Twitter.com/matthewhughes me@matthewhughes.co.uk Facebook.com/matthewjhughes Matthewhughes.co.uk
  31. 31. Thank you! Any questions?

×