Web Application Security (and why it matters to YOU!) -Remix-

1. Web Application Security(and why it matters to YOU!)-Remix- By Mark Bristow and Doug Wilson Mark.bristow@gmail.com DougWilsonMoo@gmail.com

2. Your presenters today are • Doug Wilson • Senior Application Engineer at SAIC • Mark Bristow • Information Assurance Engineer at SRA International

3. Why are we here?

4. A brief discussion on • What is Web Application Security? • and why does it matter? • A look at the top problems on the web today • And what you can do to remediate them. So, what is web application security?

5. Web application security is . . . An overall process that • Starts in the initial planning stages • Continues through coding, testing, and deployment • Doesn’t finish until the lifecycle is completely finished

6. But why does this matter to me? Overcoming Denial • No one would ever bother with my web site. • We already have “security” • We use open source • We use “that” vendor • We keep up on patches • “So we have a firewall, an IDS, an IPS, and use SSL . . . we’re covered . . . right?”

7. No, you are probably NOT ok . . . • The web was designed as a trusted environment. It is NOT that anymore. • Web applications are still “emerging technologies” for most organizations. • The drive to stay competitive results in unrealistic expectations and unsafe practices.

8. Looking at Some Recent IT nightmares • VA and other government agencies • Personally Identifiable Information (PII) for 26.5 million veterans • TJ Maxx and credit card processing • 45 million credit card numbers • AOL and User Data • 19 million queries from 650,000 subscribers • PaineWebber logic bomb • 2000 servers, over $3.1 million just to restore

9. Web App specific numbers • Symantec ISTR Jan-Jun 2007 (from September 2007) • “61 percent of all vulnerabilities disclosed were Web application vulnerabilities.” • “users . . . can no longer place their trust in well known sites.” • CIO Magazine interviews Jeremiah Grossman (5/07) • Vulnerabilities in 80% of websites analyzed • Remaining 20% are mostly static sites • Most C-level execs they talk to think firewalls protect against web application attacks -- THIS IS NOT TRUE!!!

10. The bottom line? -- Liability • Liability is not only costly financially, it can damage intangibles beyond repair. • Even if you can afford to lose money, how much is your reputation worth? • Regardless of the who broke it, the liability lies with the people who create and maintain these systems and their management.

11. So, how can we fix this?

12. OWASP -- what is that? Open Web Application Security Project www.owasp.org • Top Ten • “Guides” • Building secure web apps and services • Application testing • Code review • Code projects • Local Chapters, meetings, and conferences

13. OWASP Top 10 – err . . . Top 5? • Cross Site Scripting (XSS) • Injection Flaws • Malicious File Execution • Insecure Direct Object Reference • Cross Site Request Forgery (CSRF)

14. Cross Site Scripting (XSS) • What is Cross Site Scripting? • Occurs when an application takes user supplied data and sends it to a web browser without validating or encoding that content • In English: Can be anywhere you echo user input • Getting the user to execute arbitrary code in their web browser • XSS is everywhere, if you don’t find it, are you doing something wrong?

15. Why is XSS so dangerous? • Compromise victim computer • Can steal user’s authentication credentials • Intranet Port scanning • Stealing Sensitive Data • Key/Mouse logging • WebWorms

16. XSS Demo

17. Injection Flaws • Occurs when user supplied data is sent to an interpreter as part of a command or query • Comes in many flavors: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection, and more

18. Injection Flaws – SQL Injection So, most people here have probably heard of . . . SQL Injection • Injecting code to modify the intent of a SQL query • What can I do with SQL Injection? • Break or bypass Authentication • Has the potential to expose your database data to an attacker • Attacker can potentially modify your database structure and data Select * from users where uname =‘’ and pw=‘’OR ‘Z’=‘Z’

19. SQL Injection Demo

20. Fixing Injection Flaws • The top two flaws are based on Injection • Most of these are easily solved by following a few simple concepts religiously, in the way that works for your environment. • Don’t trust ANYTHING that comes from the client. Ever. • Validate and type all input as strictly as you can. • Encode and control all output as strictly as you can.

21. Input Validation • Client side -- doesn’t really do anything for security, though it still has its uses • Server side – The only place where your validation provides security • Regex – Your new best friend

22. Mechanics of good Validation • White listing – Pass only when content contains only known good input • Black Listing – Fail when a known bad is detected • Sanitization – “Clean” data before using it based on Black or White List

23. Sanitization Issues • Lets sanitize the name field against script injection • String name = request.getParameter( "name" ); • name.replaceALL(“script”, “”); • out.println(name); • Test cases • Name = “<script>alert(‘I pwnt j00’);</script>” • Result: <>alert(‘I pwnt j00’);</> • Name = “<scrscriptipt>alert(‘I pwnt j00’);</scrscriptipt>” • Result: <script>alert(‘I pwnt j00’);</script> • Sometimes this is a necessary evil

24. Output Encoding • Output should be encoded to match the delivery medium • If it will be HTML, HTML encode. • Ex: < becomes &lt; • HTML Entity encoding will stop 99% of XSS attacks

25. Implementing Input Validation • We are going to implement a white list validation for the username field • What charecters are allowed in usernames? • A-Z upper and lower case • Integers • What regular expression matches this criteria • [a-zA-Z0-9] • How would we implement it in PHP • if (preg_match('/[^a-zA-Z0-9]/', $username)){ *FAIL* }

26. Implementing Input Validation

27. Now, back to our top 10 . . . or 5 . . .

28. Malicious File Execution • Occurs when developers use user input directly in file or stream functions, or improperly trust uploaded content • Can lead to rootkit installs and server compromise • Many sites allow you to upload images or documents. The demo site allows you to submit reports. • If this report submission is unfiltered you may be able to upload code to the website

29. Malicious File Execution Demo

30. Insecure Direct Object Reference • A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. • Resource authorization checks should be conducted when the resouce is requested • Common Examples • User ID on query string: showAccount.php?id=2345 • Session ID on query String: index.php?PHP_SESSID=51h3nrstvi0mm60k2j179iqtg6 • Directory Traversal

31. Directory Traversal Demo

32. Fixing Object Access Flaws • Don’t trust ANYTHING that comes from the client. Ever. • Validate and type all input as strictly as you can. • Encode and control all output as strictly as you can. • Do you sense a trend here? • Perform authorization checks every time a resource is requested

33. Cross Site Request Forgery (CSRF) • When an attacker forces a victim’s browser to submit a request the victim did not intend to submit • Also known as a “One click attack”, session riding or XSRF • Exploits pre-established trust relationship (session) to force authorization • High remediation costs • Malicious requests and legitimate requests are indistinguishable. • Originally dates to 1998 but is just becoming well understood

34. CSRF DEMO

35. Fixing CSRF • CSRF is often labeled as “unfixable,” it’s inherent in how the web works. But you can take steps to help. • Problems and safeguards • Data returned as javascript (Gmail) -- fixed by while(); loop • Digg article -- fix: secret tokens (a.k.a. Nonces) • Amazon One-Click -- fix: Password re-entered • Fixes work -- unless you combine with XSS. Then the rules change, and some standard fixes go out the window (like secret tokens)

36. The rest of the OWASP Top 10 • Information Leakage • Error messages provide vital tools to an attacker • Broken Session Management • Insecure Cryptographic Storage • Insecure Communications • SSL is a web attacker’s best friend • Failure to restrict URL access • What happens when I request an admin page directly without logging in first?

37. The AJAX question • Does AJAX and other similar technologies make for “worse” application security? What about web services? • Asynchronous applications and web services aren’t innately more “insecure,” but greatly increase complexity and attack surface. • Both Asynchronous and Web Service style applications have the potential to reintroduce a lot of old problems. • Minimalist approach is best

38. Is the Sky Falling? • The sky is NOT falling! • All of the vulnerabilities mentioned here can be fixed • Developer education and a robust software security program can help mitigate these issues • Educate yourselves • Educate your customers

39. How do I get started? • LEARN! What threats are out there and how they apply to your organization? • Classify what data is most important to your organization • Identify all of your web applications and assign them criticalities based on business needs and data classification • Perform vulnerability assessments to determine how big the problem is • “Bake security in” to your SDLC

40. Resources • Sites • http://www.owasp.org • http://www.webappsec.org/ • http://ha.ckers.org • http://www.sans-ssi.org/ • Books • How to Break Web Software • Hacking Exposed : Web Applications • XSS ATTACKS • Training • Certified Ethical Hacker (CEH) • Foundstone Ultimate Web Hacking • SANS Training • Securing Critical Web Applications and Web Services (Aspect Security) • Writing Secure Web Applications: Developer Training

41. Questions? stop by onelittlewindow.org