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.

1. Mike Saunders
Principal—Hardwater Information Security

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.  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.  The Web is a target-rich environment
◦ “[N]early half of all reported vulnerabilities exist in
Web applications” (TippingPoint DVLabs, 2010)
4

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.  We open the door to web apps to enable
business!
6
http://www.pressofatlanticcity.com

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.  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.  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.  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.  Javascript, VBScript, Silverlight
 “Deface” websites
 Steal session cookies
 Install keyloggers/trojans/malware
 Take screenshots
 Exfiltrate data
 CSRF
 SHELLS!
11

12. 12
Vulnerable Parameter: trkid
Attack string:
<script>alert(document.cookie)</script>
Vulnerability was responsibly disclosed to Netflix and has been
remediated.

13.  Attacker sends input which is interpreted as a
DB command
13

14.  SHELLS!
 Stored XSS to attack site visitors
 Steal database contents
◦ Usernames and passwords
◦ Account info
◦ CC#
 Alter/delete DB contents
14

15.  Time-based blind SQLi = database dumped!
15

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.  SHELLS!
 Install backdoors
 Exfiltrate data
 Pivot to other systems
17

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.  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.  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. “If builders built buildings the way
programmers built programs, the first
woodpecker to come along would destroy
civilization.”
- Gerald Weinberg
21

22. 22
http://www.panoramio.com/photo/10984427

23. 23
http://www.pinterest.com/pin/345299496399829978/

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. (IDC, 2011)
25

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.  Use available tools to your advantage
◦ BurpPro—Almost free
◦ OWASP ZAP Proxy
◦ OWASP Xenotix
◦ SoapUI test suite
◦ SANS SWAT Checklist
27

28. 28
http://i9.photobucket.com/albums/a81/kos102/2009/Other/tin-foil-cat.jpg

29. http://demonarex.files.wordpress.com/2011/03/house-everybody-lies2.jpg
29

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.  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.  Set cookies using HttpOnly
 Content-Security-Policy header
◦ https://www.owasp.org/index.php/Content_Securit
y_Policy
32

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.  .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.  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.  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.  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.  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.  msaunders.sec@gmail.com
 @hardwaterhacker
 Blog: http://hardwatersec.blogspot.com/
39