Problems with parameters b sides-msp

Post on 11-Nov-2014

124 views 1 download

Tags:

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

&lt;script&gt;alert(1)&lt;/script&gt;

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

msaunders.sec@gmail.com

@hardwaterhacker

Blog: http://hardwatersec.blogspot.com/

39