Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Problems with parameters b sides-msp

442 views

Published on

Problems With Parameters - A high-level overview of common vulnerabilities identified in web applications, techniques to mitigate these vulnerabilities, and thoughts on incorporating secure webapp development practices into your organization's development culture.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Problems with parameters b sides-msp

  1. 1. Mike Saunders Principal—Hardwater Information Security
  2. 2.  In IT for about 20 years, full-time for 16  *NIX/Windows/Net admin, security engineer, architect, and developer in previous life  Currently performing pen tests full time  CISSP, GWAPT, GPEN, GCIH 2
  3. 3.  Seeing the same issues over and over in internally developed, outsourced dev, business partner/vendor and big software vendor apps  Some success with internal teams in improving app security 3
  4. 4.  The Web is a target-rich environment ◦ “[N]early half of all reported vulnerabilities exist in Web applications” (TippingPoint DVLabs, 2010) 4
  5. 5.  In the past, perimeters were porous at best  Hardened perimeters today ◦ Firewalls are better controlled now ◦ Better patching programs ◦ Better server hardening (STIGS, CIS, etc.) 5
  6. 6.  We open the door to web apps to enable business! 6 http://www.pressofatlanticcity.com
  7. 7.  52% of all breaches were the result of hacking ◦ 22% of all hacking attacks were against web apps (Verizon, 2012)  65% of organizations surveyed experienced SQLi attack in the past 12 months (Ponemon, 2014)  SQL Injection and Cross-Site Scripting (XSS) are the most common attacks 7
  8. 8.  Web apps receive input through parameters  Malicious input can result in server-side injection attacks (SQLi, command injection, Xpath injection, ...) or client-side attacks (XSS, CSRF, ...) 8
  9. 9.  2011 SANS/MITRE Top 25 ◦ Three of top four are injection vulnerabilities 1) SQLi 2) Command Injection 4) XSS 12) CSRF—leverages XSS http://www.sans.org/top25-software-errors/ 9
  10. 10.  Occurs when a web app uses input from a user within the output it generates, without validating or encoding it (OWASP)  Client browser interprets server response as a script instead of rendering ◦ Reflected XSS through a malicious URL ◦ Persistent XSS—forum post or profile; injected into content database ◦ DOM-based 10
  11. 11.  Javascript, VBScript, Silverlight  “Deface” websites  Steal session cookies  Install keyloggers/trojans/malware  Take screenshots  Exfiltrate data  CSRF  SHELLS! 11
  12. 12. 12 Vulnerable Parameter: trkid Attack string: <script>alert(document.cookie)</script> Vulnerability was responsibly disclosed to Netflix and has been remediated.
  13. 13.  Attacker sends input which is interpreted as a DB command 13
  14. 14.  SHELLS!  Stored XSS to attack site visitors  Steal database contents ◦ Usernames and passwords ◦ Account info ◦ CC#  Alter/delete DB contents 14
  15. 15.  Time-based blind SQLi = database dumped! 15
  16. 16.  Attacker input results in execution of commands in web server OS  Input is included as part of shell command executed by web app 16
  17. 17.  SHELLS!  Install backdoors  Exfiltrate data  Pivot to other systems 17
  18. 18.  Command injection: `ping –c 20 127.0.0.1` ◦ Input passed to external program, interpreted as shell command ◦ Additional command injection mails password file to attacker 18
  19. 19.  80% of web apps vulnerable to XSS  More than 45,000 reported XSS @ xssed.com  26% of 2013 breaches caused by SQLi (Trustwave, 2013) 19
  20. 20.  2014—Tweetdeck retweet XSS ◦ More than 38,000 retweets in an hour  Hold Security announces 1.2 billion records stolen from 420,000 sites via SQLi (Hold Security, 2014) 20
  21. 21. “If builders built buildings the way programmers built programs, the first woodpecker to come along would destroy civilization.” - Gerald Weinberg 21
  22. 22. 22 http://www.panoramio.com/photo/10984427
  23. 23. 23 http://www.pinterest.com/pin/345299496399829978/
  24. 24.  Don’t bolt on security as an afterthought  Integrate security into development process  Repairs = much higher costs  15× more expensive to repair at testing phase  Up to 100× more expensive after deployment (Jones, 1996) 24
  25. 25. (IDC, 2011) 25
  26. 26.  Peer code reviews  Involve developers in testing code before release ◦ OWASP Testing Guide ◦ OWASP XSS Filter Evasion Cheat Sheet ◦ Testing for SQL Injection (OWASP-DV-005) ◦ Code analysis tools 26
  27. 27.  Use available tools to your advantage ◦ BurpPro—Almost free ◦ OWASP ZAP Proxy ◦ OWASP Xenotix ◦ SoapUI test suite ◦ SANS SWAT Checklist 27
  28. 28. 28 http://i9.photobucket.com/albums/a81/kos102/2009/Other/tin-foil-cat.jpg
  29. 29. http://demonarex.files.wordpress.com/2011/03/house-everybody-lies2.jpg 29
  30. 30.  Never trust input from client! ◦ Even if it’s provided automatically by browser  Validation is key ◦ Whitelist – define what’s good, drop everything else  Ex: SSN / Phone / CC# should only be digits  See OWASP XSS & SQLi Prevention Cheat Sheets  Always validate server-side ◦ Client side is easily bypassed 30
  31. 31.  Escape untrusted input ◦ If you must accept untrusted input, make sure you render it inert by escaping ( ‘ -> ‘ )  Encode untrusted input before returning to client ◦ <script>alert(1)</script> becomes &lt;script&gt;alert(1)&lt;/script&gt; 31
  32. 32.  Set cookies using HttpOnly  Content-Security-Policy header ◦ https://www.owasp.org/index.php/Content_Securit y_Policy 32
  33. 33.  Again, never trust input from client, always validate  Always escape or encode dangerous characters if required to process “ - ‘ -- ; ”  Use prepared statements whenever possible  Escape everything!  OWASP SQLi Prevention Cheat Sheet 33
  34. 34.  .NET platform ◦ Microsoft Anti-Cross Site Scripting Library  ASP.NET Framework ◦ ValidateRequest()  Java ◦ OWASP ESAPI ◦ OWASP Java Encoder Project  OWASP Encoding Project ◦ Multi-platform: Java, .NET, PHP, Perl, Python, Javascript, ASP, Ruby 34
  35. 35.  Secure AppDev starts before code is written  Grow secure developers—peer reviews, cross-training, mentoring  Be Paranoid! Never trust input ◦ Validate, escape, encode  Use available security resources (OWASP, SANS, etc.) 35
  36. 36.  SANS Securing Web Application Technologies Checklist ◦ http://www.securingthehuman.org/developer/swat  SANS/MITRE Top 25 Software Errors ◦ http://www.sans.org/top25-software-errors/  OWASP XSS Prevention Cheat Sheet ◦ https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_ Cheat_Sheet  OWASP DOM-based XSS Prevention Cheat Sheet ◦ https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sh eet  OWASP SQLi Prevention Cheat Sheet ◦ https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet  OWASP XSS Filter Evasion Cheat Sheet ◦ https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet  OWASP Cheat Sheets ◦ https://www.owasp.org/index.php/Cheat_Sheets 36
  37. 37.  Google Application Security Library – XSS ◦ http://www.google.com/about/appsecurity/learning/xss/  Testing for SQL Injection (OWASP-DV-005) ◦ https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)  Microsoft Anti-Cross Site Scripting Library ◦ http://wpl.codeplex.com/  OWASP Enterprise Security API ◦ https://www.owasp.org/index.php/ESAPI  OWASP Encoding Project ◦ https://www.owasp.org/index.php/Category:OWASP_Encoding_Project  Ruby on Rails Security Basics ◦ https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/  Developing Secure Web Application – Cross-Site Scripting ◦ http://www.slideshare.net/codecampiasi/developing-secure-web-application- crosssite-scripting-xss  XSSing Your Way to Shell ◦ https://speakerdeck.com/varbaek/xssing-your-way-to-shell 37
  38. 38.  Greenberg, A. (2013, July 31). SQL injection attacks still enable breaches, all these years later. SCMagazine. Retrieved from http://www.scmagazine.com/sql-injection-attacks-still-enable-breaches-all-these-years- later/article/305433/  Hold Security (2014, August 5). You Have Been Hacked Retrieved from http://www.holdsecurity.com/news/cybervor-breach/  IDC. (2011). The Case for Building in Web Application Security from the Start. [White paper]. Retrieved from http://resources.idgenterprise.com/original/AST- 0048510_The_case_for_building_in_web_application_security_from_the_start.PDF  Jones, C. (1996). Applied Software Measurement: Assuring Productivity and Quality. Mcgraw-Hill  Ponemon Institute. (2014) The SQL Injection Threat Study. Retrieved from: http://www.dbnetworks.com/contact/PonemonSQLInjectionThreatSurveyDownload.htm  TippingPoint DVLabs. (2011) 2010 Full Year Top Cyber Security Risks Report. Retrieved from http://dvlabs.tippingpoint.com/img/FullYear2010%20Risk%20Report.pdf  Trustwave. (2013) 2013 Global Security Report. Retrieved from http://www2.trustwave.com/rs/trustwave/images/2013-Global-Security-Report.pdf  Verizon. (2013) 2012 Data Breach Investigations Report. Retrieved from http://www.verizonenterprise.com/resources/reports/rp_data-breach-investigations-report-2012- ebk_en_xg.pdf 38
  39. 39.  msaunders.sec@gmail.com  @hardwaterhacker  Blog: http://hardwatersec.blogspot.com/ 39

×