1 / 88

Joe Yeager, Security Engineer SPI Dynamics, Inc. – London, England

Joe Yeager, Security Engineer SPI Dynamics, Inc. – London, England. Overview. Background Secure Software Forum (SSF) SPI Dynamics Web applications and their vulnerabilities Offense Case studies Examples Cross Site Scripting (XSS) Cross Site Request Forgery (CSRF) SQL Injection

talasi
Download Presentation

Joe Yeager, Security Engineer SPI Dynamics, Inc. – London, England

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Joe Yeager, Security Engineer SPI Dynamics, Inc. – London, England

  2. Overview • Background • Secure Software Forum (SSF) • SPI Dynamics • Web applications and their vulnerabilities • Offense • Case studies • Examples • Cross Site Scripting (XSS) • Cross Site Request Forgery (CSRF) • SQL Injection • Blind SQL Injection • Defense • Trustworthy Computing – Security Development Lifecycle • Application Security Assurance Program (ASAP)

  3. Secure Software Forum (SSF) • Started February 2005 • Annual education series dedicated to secure software • Leading security experts collaborate on education initiatives • Yearly programs include: • February kick-off event at RSA • Free workshop series • Executive dinner series • http://www.securesoftwareforum.com/

  4. SPI Dynamics Overview • Founded January 2000 by Web application and security experts • The leader in Web application security assessment throughout the lifecycle • Eight patents pending or issued • 1000+ customers all over the World • Strong in F500, all industries and government • 2006 Inc. 500 list of fastest-growing private companies • 2005 Deloitte Technology Fast 500 • 2005 Deloitte Georgia Technology Fast 50 Annual Revenue

  5. History of Application Security

  6. The Evolution of Web Applications Static web Page • A typical web application in 2000: • Basic static HTML pages • Informational applications • Not mission critical functions Static web Page Static web Page Static web Page Static web Page

  7. The Evolution of Web Applications Simple, single server solutions Browser Web Server

  8. Web Application Architecture of Today Web Services Database Server Customer Identification Access Controls Transaction Information Core Business Data Application Server Business Logic Content Services Web Servers Presentation Layer Media Store Wireless Browser

  9. Web Applications Breach the Perimeter Trusted Inside Internet DMZ IIS SunOne Apache ASP .NET WebSphere Java SQL Oracle DB2 Corporate Inside HTTP(S) Firewall only allows PORT 80 (or 443 SSL) traffic from the Internet to the web server. Any – Web Server: 80 Firewall only allows applications on the web server to talk to application server. Firewall only allows application server to talk to database server. IMAP FTP SSH TELNET POP3

  10. OS Attacks Web Server Attacks Web Application Attacks Network Attacks Layered Model of Security Web Application Code - Content - Implementation Web Server Known Vulnerabilities - Misconfigurations Operating System Known Vulnerabilities - Misconfigurations Network Layer Exposed Hosts/Protocols

  11. Vulnerability Characteristics • Extremely easy to exploit • Sometimes requires nothing more than a Web browser • Orders of magnitude easier than buffer overflows • Difficult to deal with at the perimeter • SSL Encrypted Traffic, huge volume • Rules granular to each input on each page, change as app changes

  12. Vulnerability Remediation Global Notification Uniform Vulnerabilities No Notification Custom Vulnerabilities Single Source Fix Standardized Testing Custom Testing Custom Fix

  13. Current State of the Industry

  14. Compelling Evidence “Over 70 percent of security vulnerabilities exist at the application layer, not the network layer” Gartner “The battle between hackers and security professionals has moved from the network layer to the Web applications themselves“ Network World “64 percent of developers are not confident in their ability to write secure applications” Microsoft Developer Research “Hacking has moved from a hobbyist pursuit with a goal of notoriety to a criminal pursuit with a goal of money” Counterpane Internet Security

  15. Prevalence of Web App Vulns

  16. Mitre CVE Statistics

  17. 'Phishing' scams on the rise, survey finds Study Find Flaws on Web Sites of Major Banks Internet security experts have long known that simple passwords do not fully defend online bank accounts from determined fraud artists. By Brad Stone, NYTFebruary 5, 2007, Monday Criminals are able to dodge spam filters and other defensive tactics Reuters Updated: 2:20 p.m. ET Sept. 25, 2006 MySpace Sues Spammer Lawsuit claims Richter spoofed login pages to steal usernames and passwords in a "phishing" scam. The State of Application Security POSTED: 9:56 a.m. EST, January 23, 2007

  18. Web ApplicationVulnerability Overview

  19. Administration Platform Application Web Application Vulnerabilities Web application vulnerabilities occur in three major areas:

  20. Platform Web Application Vulnerabilities • Platform • Known vulnerabilities can be exploited immediately with a minimum amount of skill or experience – “script kiddies” • Easiest to defend against among web application vulnerabilities • Must have streamlined patching procedures • Must have inventory process Examples: • IIS UNICODE • Apache chunked encoding

  21. Administration Web Application Vulnerabilities • Administration • More difficult to correct than known issues • Require increased awareness • Remnant files can reveal applications and versions in use • Backup files can reveal source code and database connection strings Examples: • Extension Checking • Common File Checks • Data Extension Checking • Backup Checking • Directory Enumeration • Path Truncation • Hidden Web Paths • Forceful Browsing

  22. Application Web Application Vulnerabilities • Application • Coding techniques do not include security • Input is assumed to be valid, but not tested • Inappropriate file calls reveal source code & system files • Unexamined input from a browser can inject scripts into page for replay against later visitors • Unhandled error messages reveal application and database structures • Unchecked database calls can be ‘piggybacked’ with a hacker’s own database call, giving direct access to business data through a web browser • SQL Injection • Hidden Web Paths • Forceful Browsing • Custom Application Scripting • Parameter Manipulation Examples: • Application Mapping • Cookie Manipulation

  23. Cross Site Scripting (XSS)

  24. Google fixes security flaw in Reader By Elinor Mills Staff Writer, CNET News.com Published: July 5, 2006, 5:36 PM PDT 03:00 PM PDT Google said it fixed a security flaw in Google Reader on Wednesday that could have allowed a hacker to steal sensitive information from Web surfers. A Google RSS feed addition tool was vulnerable to a cross-site scripting attack, a poster to the Ha.ckers.org blog wrote on Tuesday. Such attacks involve an attacker embedding HTML scripts in Web postings or input fields on a Web site. "What are the implications of this attack for Google?" the blog posting asked. "Well, for starters, I can put a phishing site on Google. 'Sign up for Google World Beta.' I can steal cookies to log in as the user in question...I can steal your phone number from the /sendtophone application...get your address because maps.google.com is mirrored....The list of potential vulnerabilities goes on and on. The vulnerabilities only grow as Google builds out their portal experience." Case Study - Google Impact Cause Fix References Case Study Demo

  25. Case Study - Google Impact Cause Fix References Case Study Demo

  26. Case Study - Google Impact Cause Fix References Case Study Demo

  27. Case Study - PayPal Impact Cause Fix References Case Study Demo Phishing Scam Uses PayPal Secure Servers Scripting flaw makes fake page with valid security certificate possible. Peter Sayer, IDG News Service Friday, June 16, 2006 03:00 PM PDT A cross-site scripting flaw in the PayPal Web site allows a new phishing attack to masquerade as a genuine PayPal log-in page with a valid security certificate, according to security researchers. Fraudsters are exploiting the flaw to harvest personal details, including PayPal log-ins, Social Security numbers, and credit card details, according to staff at Netcraft, an Internet services company in Bath, England. The PayPal site, owned by eBay, allows users to make online payments to one another, charged to their credit cards, and log-in credentials for the service are a prized target of fraudsters.

  28. Case Study - PayPal Impact Cause Fix References Case Study Demo

  29. XSS Demo Overview Impact Cause Fix References Case Study Demo • Definition • Client side scripting languages injected into web page • HTML • JavaScript • VBScript • Facilitators • URL spoofing • URL obfuscation • Mitigating factors • Social engineering

  30. XSS Demo Impact Cause Fix References Case Study Demo

  31. URL Obfuscation Impact Cause Fix References Case Study Demo • Dotted Decimal IP addresses • URL – http://www.google.com • IP – http://216.239.51.99 • Decimal - http://3639554915 • 216 * 2563 + 239 * 2562 + 51 * 2561 + 99 • Octal - http://0330.0357.0063.0143 • Hexadecimal - http://0xd8ef3363 • Hexadecimal encoded • http://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D • URLomatic (http://www.samspade.org/t/url) • TinyURL (eg. http://tinyurl.com/y8pgom)

  32. Phishing Attack Impact Cause Fix References Case Study Demo • Cross-Site-Scripting attack via emailed vector. • Innocent-looking link has embedded client side script

  33. Phishing Attack No Alarms and No Surprises • Original legitimate website • No login errors, no changes, user works normally • UserID and Password quietly handed off to remote website • No “<script>” injected

  34. Reflected vs. Persistent XSS Impact Cause Fix References Case Study Demo Reflected • Embedded script forwarded to victim, generally via email with script contained in obfuscated URL Persistent • Permanently embed script into web applications • Blogs • Shared Calendars • Message Boards • Web Forums • System logs • Convince victim to visit vulnerable web page

  35. XSS Cause Impact Cause Fix References Case Study Demo Cause • Unfiltered user input is embedded in web page Example • Request • http://www.example.com?name=joe&password=secret • Response • ASP • Welcome back <% Response.Write(request.querystring("name")) %> • PHP • Welcome back <?php echo $_GET[“name"]; ?>

  36. XSS Fix Impact Cause Fix References Case Study Demo • Filter user input • Whitelist • Blacklist • HTML encode user supplied data prior to inclusion in a web page • ASP/ASP.Net • Server.HTMLEncode (strHTML String) • PHP • string htmlspecialchars (string string [, int quote_style])

  37. XSS References Impact Cause Fix References Case Study Demo Whitepapers • http://www.spidynamics.com/spilabs/education/whitepapers/ CrossSiteScripting.html FAQs • http://www.cgisecurity.com/articles/xss-faq.shtml • http://www.owasp.org/index.php/XSS Cheat Sheet • http://ha.ckers.org/xss.html

  38. Cross Site Request Forgery (CSRF)

  39. Case Study - Google Impact Cause Fix References Case Study Demo

  40. CSRF Demo Overview Impact Cause Fix References Case Study Demo • Definition • An attack that tricks a victim into loading a page that contains a malicious request • Exploits the trust established between a web browser and web app • Performs actions on behalf of the victim • Targets functions that cause a state change on the server • Synonyms • XSRF, Session Riding, Cross-Site Reference Forgery, Hostile Linking, One-Click attack (Microsoft) • Facilitators • Persistent session credentials • Mitigating factors • Social engineering

  41. From: Richard M Scheister To: Michael Sutton Subject: HackTel - Final Notification - Service to be Discontinued Dear Customer, Due to a missed payment on your account, we are going to be forced to disable your internet access. We trust that this is a simple oversight on your part and would strongly encourage you to visit our customer service center immediately to resolve this matter and continue to remain in good standing. Regards, Richard M. Scheister, VP Customer Service HackTel Communications Inc. CSRF Demo Impact Cause Fix References Case Study Demo

  42. CSRF Impact Impact Cause Fix References Case Study Demo • Actions are performed on behalf of the victim which were not intended • Posting to message board • Transferring funds • Changing password • Etc. • Non-repudiation – victim cannot prove that the actions were not performed intentionally

  43. CSRF Cause Impact Cause Fix References Case Study Demo • Cause • Actions are performed without forcing human intervention or • Source of request not confirmed • Example • GET http://site.com/trade?stock=goog&no=500&action=sell or • POST /trade HTTP/1.1 Host: site.com ... Cookie: SessionID=w5l3xp55viao1455aqkqsaji stock=goog&no=500&action=sell

  44. CSRF Fix Impact Cause Fix References Case Study Demo • Countermeasures that do NOT work • Secret cookies • All cookies are transmitted when requests are made • Using POST instead of GET request • Numerous options for crafting POST requests • Countermeasures that do work • Server side • Per-request nonce for URLs/forms • ASP.Net - <%@ Page EnableEventValidation="true"%> • J2EE – CSRF Guard (http://www.owasp.org/index.php/CSRF_Guard) • PHP CSRF Guard (http://www.owasp.org/index.php/PHP_CSRF_Guard) • Force human intervention • Secondary login • Confirmation email or SMS message • CAPTCHA • Client side • Always log out of applications when finished

  45. CSRF References Impact Cause Fix References Case Study Demo Whitepapers • http://www.isecpartners.com/files/XSRF_Paper_0.pdf FAQs • http://www.cgisecurity.com/articles/csrf-faq.shtml • http://www.owasp.org/index.php/CSRF • http://www.owasp.org/index.php/Testing_for_CSRF

  46. SQL Injection

  47. Hackers steal credit card info from R.I. Web site Dibya SarkarPublished on Jan. 27, 2006 A Russian hackers broke into a Rhode Island government Web site and allegedly stole credit card data from individuals who have done business online with state agencies. The story was first reported by The Providence Journal this morning and comes two days after state and local government officials released national surveys indicating they need more cybersecurity guidance and help in strengthening their systems. Case Study - RI.gov Impact Cause Fix References Case Study Demo

  48. Case Study - RI.gov Impact Cause Fix References Case Study Demo

  49. Credit card breach exposes 40 million accounts By By Joris Evers Staff Writer, CNET News.comPublished: June 17, 2005, 4:38 PM PDT In what could be the largest data security breach to date, MasterCard International on Friday said information on more than 40 million credit cards may have been stolen. A Of those exposed accounts, about 13.9 million are for MasterCard-branded cards, the company said in a statement. Some 20 million Visa-branded cards may have been affected and the remaining accounts were other brands, including American Express and Discover. MasterCard and Visa both say they have notified their member banks of the specific accounts involved so the banks can take action to protect cardholders. "In sheer numbers, this is probably one of the largest data security breaches," said James Van Dyke, principal analyst at Javelin Strategy & Research in Pleasanton, Calif. Case Study - CardSystems Impact Cause Fix References Case Study Demo

  50. Impact Cause Fix References Case Study Demo Case Study - CardSystems

More Related