Problems with parameters b sides-msp
39
Mike Saunders Principal—Hardwater Information Security
-
Upload
mike-saunders -
Category
Technology
-
view
124 -
download
1
description
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.
Transcript of Problems with parameters b sides-msp
Mike Saunders Principal—Hardwater Information Security
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
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
The Web is a target-rich environment ◦ “[N]early half of all reported vulnerabilities exist in
Web applications” (TippingPoint DVLabs, 2010)
4
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
We open the door to web apps to enable business!
6
http://www.pressofatlanticcity.com
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
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
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
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
Javascript, VBScript, Silverlight
“Deface” websites
Steal session cookies
Install keyloggers/trojans/malware
Take screenshots
Exfiltrate data
CSRF
SHELLS!
11
12
Vulnerable Parameter: trkid Attack string: <script>alert(document.cookie)</script>
Vulnerability was responsibly disclosed to Netflix and has been remediated.
Attacker sends input which is interpreted as a DB command
13
SHELLS!
Stored XSS to attack site visitors
Steal database contents ◦ Usernames and passwords
◦ Account info
◦ CC#
Alter/delete DB contents
14
Time-based blind SQLi = database dumped!
15
Attacker input results in execution of commands in web server OS
Input is included as part of shell command executed by web app
16
SHELLS!
Install backdoors
Exfiltrate data
Pivot to other systems
17
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
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
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
“If builders built buildings the way programmers built programs, the first woodpecker to come along would destroy civilization.”
- Gerald Weinberg
21
22
http://www.panoramio.com/photo/10984427
23
http://www.pinterest.com/pin/345299496399829978/
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
(IDC, 2011)
25
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
Use available tools to your advantage ◦ BurpPro—Almost free
◦ OWASP ZAP Proxy
◦ OWASP Xenotix
◦ SoapUI test suite
◦ SANS SWAT Checklist
27
28
http://i9.photobucket.com/albums/a81/kos102/2009/Other/tin-foil-cat.jpg
http://demonarex.files.wordpress.com/2011/03/house-everybody-lies2.jpg
29
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
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
Set cookies using HttpOnly
Content-Security-Policy header ◦ https://www.owasp.org/index.php/Content_Securit
y_Policy
32
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
.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
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
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
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
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
@hardwaterhacker
Blog: http://hardwatersec.blogspot.com/
39
