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.
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.
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
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
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
<script>alert(1)</script>
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
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
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