Application Security Positively False

1. OWASP top 10 with real world examples Developer real world mistakes Developer security assessment questions What we are doing to try and stay ahead The rise of the web application fire wall (WAF) Application Security Positively False Georgia Department of Audits and Accounts 2008

2. Web Site: www.OWASP.org The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. OWASP Top 10

3. OWASP has much more: • Publishes Guides • Secure software and best practice • Code review and Testing • And more… • Free Tools • Code Analysis • Web traffic inspection • And more… OWASP Top 10

4. A1 - Cross Site Scripting (XSS) XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc. OWASP Top 10

5. A2 - Injection Flaws Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data. OWASP Top 10

6. EXAMPLE: RIAA web site cleared WHID 2008-04: • Reported: 22 January 2008Occurred: 20 January 2008 • Classifications: • Attack Method: Cross Site Scripting (XSS) • Attack Method: SQL Injection • Attack Method: Denial of Service • Attack Method: SQL Injection • Country: Global • Country: USA • Outcome: Defacement • Outcome: Downtime • Outcome: Defacement • Vertical: Entertainment The web site of RIAA, the Recording Industry Association of America was attacked twice using SQL injection over the weekend. First a query that takes particularly long time was posted on a social network web site causing a distributed denial of service attack against the site. Later on hackers found and abused additional SQL injection and XSS vulnerabilities resulting in major defacement of the site. OWASP Top 10

7. A3 - Malicious File Execution Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users. OWASP Top 10

8. A4 - 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. Attackers can manipulate those references to access other objects without authorization. OWASP Top 10

9. A5 - Cross Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks. OWASP Top 10

10. EXAMPLE: hacker steals user information WHID 2008-10: Chinese hacker steals user information on 18 MILLION online shoppers at Auction.co.kr • Reported: 12 February 2008Occurred: 10 February 2008 • Classifications: • Attack Method: Cross Site Request Forgery (CSRF) • Country: Korea • Origin: China • Outcome: Downtime • Outcome: Leakage of Information • Vertical: Retail A Korean e-commerce site was hacked and a staggering number of records, 18 million, where stolen. In the US this would be front news. We don't know if it was front news in Korea, but did not get to the international media. The attack description is vague but can be best described as session hijacking. This incident is a great example of the lack of sufficient international coverage at WHID. Help us by sending us non English incidents! After all, it is not English speakers only that get hacked, but rather us, the WHID maintainers that speak only this language. *Web Hacking Incidents Database (WHID) OWASP Top 10

11. A6 - Information Leakage and Improper Error Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks. OWASP Top 10

12. EXAMPLE: Information stolen WHID 2008-01: Information stolen from geeks.com • Reported: 08 January 2008Occurred: 05 January 2008 • Classifications: • Attack Method: Unknown • Country: USA • Outcome: Leakage of Information • Vertical: Retail Very detailed records of geeks.com customers were stolen from the site. The records included name, address, telephone number, e-mail address, credit card number, expiration date, and most notoriously, card verification number (CVV). The interesting part is that the site had a Hacker Safe seal. The seal was revoked twice last year due to vulnerabilities, but restored after they where patched. It seems that this time the hack preceded the scan or the scan missed the vulnerability. So much for application scanning and vulnerability assessment.... And don't take it lightly as a geeks site. Geeks.com is a $150M/year business. OWASP Top 10

13. A7 - Broken Authentication and Session Management Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities. OWASP Top 10

14. EXAMPLE: Single Sign on vulnerability Google SAML Single Sign on vulnerability Overview • The SAML Single Sign-On (SSO) Service for Google Apps contained a vulnerability that could have allowed an attacker to gain access to a user's Google account. I. Description • The Security Assertion Markup Language (SAML) is a standard for transmitting authentication data between two or more security domains. In SAML language, XML security packets are called assertions. Identity providers pass assertions to service providers who allow the requests. In the Google Single Sign on (SSO) implementation, the authentication response did not include the identifier of the authentication request or the identity of the recipient. This may allow a malicious service provider to impersonate a user at other service providers. • More technical information about this issue is available in the Formal Analysis of SAML 2.0 Web Browser Single Sign-On: Breaking the SAML-based Single Sign-On for Google Apps whitepaper which is available here: http://www.ai-lab.it/armando/GoogleSSOVulnerability.htmlNote that to exploit this vulnerability, the attacker would have to convince the user to login to their site. II. Impact • A malicious service provider might have been able to access a user's Google Account or other services offered by different identity providers. OWASP Top 10

15. A8 - Insecure Cryptographic Storage Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud. OWASP Top 10

16. A9 - Insecure Communications Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. OWASP Top 10

17. EXAMPLE: Best Buy closes wireless registers Security researchers who study wireless networks have found another embarrassing information leak, this one involving well-known retail giants. Some stores use cash registers with wireless networks that beam data — including credit card numbers — to a central computer elsewhere in the store. But a hacker can sit in a store’s parking lot and “listen in” to the data. Indeed, consumer electronics retailer Best Buy Co. shut off wireless cash registers at its stores after being alerted to the potential problem. OWASP Top 10

18. A10 - Failure to Restrict URL Access Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. OWASP Top 10

19. My Developers know application security ! Developer real world mistakes

20. Authentication Example to verify User login: while($q->next_record()) { $chumbawumba = $q->f("username"); } if ($password == $chumbawumba) { header("Location: index.php?session=".$session); } else { $errorMsg = "Wrong Password. Please Try again!"; } Developer real world mistakes Answer : User name and Password are always the same.

21. Example : SQL injection Prevention Code. !if (username.indexOf("';--")!=-1) { throw new AuthorisationException(username +" given as login name contains ';--, this is bad for SQL!"); }  // Get the (hopefully single) id of the player with // this name and password ResultSetauthorised = statement.executeQuery( "SELECT id FROM table_name_redacted WHERE " + "username='"+username +"' AND password='"+password+"';"); Developer real world mistakes Answer: doesn't quite fool the hacker who uses the "'; --"

22. Example: Yes Our secure data is encrypted ! "There's a database of users who can log in. Now, we all know that you always store the password encrypted, right? Perfect, it's stored as MD5. Here's the three relevant fields in the database: username VARCHAR(32), password VARCHAR(32), password_md5 VARCHAR(32) Developer real world mistakes Answer: the 'password' field holds the password in plaintext

23. Example: Code Injection by developers JavaScript issues on Houston Chronicle's site and took a peek at the source code. At the bottom of their utils.js, he noticed this... setTimeout(check4Dave,2000);function check4Dave() { if (document.cookie.match('ImDaveOhYeah')) { s=document.body.appendChild(document.createElement('script')); s.id='fs'; s.language='javascript'; s.src='http://www.chron.com/apps/emdjcs/specialDave.js'; }}   Developer real world mistakes Answer: Code injection by a developer to show picture or funny subject matter to friends.

24. Example: Database Visible Script code to any client set dbconn= CreateObject("ADODB.Connection") set dbRS = CreateObject("ADODB.Recordset") dbconn.Open "Driver={REMOVED};server=CHECKING;uid=ADMIN;Password=CONNECTION; Database=STRING;dsn=;" 'SQL = "SELECT Key, Category, Desc FROM KSB WHERE Category = " & categoryValue & " ORDER BY KSBDesc" SQL = "select ksb.*, cardversion.*, carddetail.* , categories.* " SQL = SQL & " from ksb, cardversion, carddetail , categories " SQL = SQL & " WHERE CARDVERSION.CARDACTIVE = 1 " SQL = SQL & " AND Cardversion.cardid = carddetail.detailcard " SQL = SQL & " and carddetail.detailksb = ksb.ksbkey " SQL = SQL & " and ksb.ksbcategory = categories.categoryKey " SQL = SQL & " and ksb.ksbcategory = " & categoryValue SQL = SQL & " order by carddetail.detailline " dbRS.open SQL, dbconn, 1 Developer real world mistakes Answer: User can view source on HTML page and manipulate database strings

25. Example: Dead Code Left Runnable <cfifstoredProcs> <cfquery name="get_products" ds="#datasource#> select * from products where customer_id=#customer_id# and status = 1 </cfquery><cfelse> <cfquery name="get_products" ds="#datasource#> select * from products where customer_id=#customer_id# </cfquery></cfif> Developer real world mistakes Answer: Two code paths left in application, which one gets executed. (over time no one knows for sure)

26. How can I tell if the developers know anything at all about security ? Security assessment questions?

27. What is the process to develop applications? (software development life cycle) • Is there a security awareness program for the developers ? • How are the application logs monitored ? • Do you have an incident response plan ? • How old are the applications in question ? • How many revisions ? Security assessment questions?

28. What Secure Programming Techniques are being used? • Security does not stop at HTTPS: (most common answer by developers) • Handling Exceptions properly within coding • Is the technology exposed? • File extension ? aspx, ASP, JSP, PHP • Using URL rewriting. – hiding what your URLs are doing. • Is form field validation on the client side or server side ? • How are the Permissions handled • Authentication vs Authorization • Where is it challenged or checked ? (show vs. don’t show) • Is your Source code under version control ? • Are you using any frame works • Fame works are good and bad • Developers sometimes don’t know if they are protected or how • Home grown vs open source vs boxed • Do you patch or upgrade the underlying technologies ? Security assessment questions?

29. We believe Application Security is a continuous improvement process which involves several key groups within our organization. What we are doing to stay ahead

30. We have a secure programming class for our developers • We Analyze our code base looking for • Bad coding techniques • Dead code • Bad logic • We take a layered approach to services and security (end to end) • We separate our applications from third party applications not only in our application container environment but also within our databases • We separate our unauthenticated applications from our authenticated applications both in the container and database • Moving to a full n-tier solution allowing one controlled layer to access the database • We frequently scan the operating systems and our applications using tools • We constantly review our security posture trying to make improvements • We encrypt all confidential data within the database and never allow the applications to decrypt. What we are doing to stay ahead

31. Technologies • Java JEE Technologies • Sand box within a virtual machine • Using Proven Frameworks • We are using a persistence frame work for mapping our database. • No direct SQL code within applications • In other words developers don’t make calls to the database • Struts2 - view layer • Spring backend • We are using Spring which provides flexible code injection for retro fitting older application systems What we are doing to stay ahead

32. “Please protect me from my developers” The Rise of the Web Application Fire Wall

33. What are they ? Web application firewalls (WAF) are a new breed of information security technology designed to protect web sites from attack. WAF solutions are capable of preventing attacks that network firewalls and intrusion detection systems can't, and they do not require modification of application source code. The Rise of the Web Application Fire Wall

34. What Another Firewall ? • OS firewall • Traditional IDS / IPS (detection /prevention) Both work great at the network level but as soon as I open up a port and allow HTTP traffic these systems can no longer detect misuse of a trusted web application. You should verify if the Firewall / IPS is "application aware"  (SQL injection and XSS prime examples) The Rise of the Web Application Fire Wall

35. New Standards PCI section 6.6. It states that companies will need to do one of the following two things: • Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security • Installing an application layer firewall in front of web-facing applications. The Rise of the Web Application Fire Wall

36. What is PCI ? The PCI Security Standards Council is an open global forum for the ongoing development, enhancement, storage, dissemination and implementation of security standards for account data protection. The PCI Security Standards Council’s mission is to enhance payment account data security by driving education and awareness of the PCI Security Standards. The organization was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc. The Rise of the Web Application Fire Wall

37. Why do I need one ? • Protects Third Party Applications • Protect in house applications • Protects Services (web / application servers) • Gives you a window of change management • Centralizes logging for security • Allows for separate roles for security officers The Rise of the Web Application Fire Wall

38. How to audit or review • Same problems exist with current IDS systems • How often does it get updated • Attack patterns • Known vulnerabilities • Has it been configured properly • Must be tuned to your applications • How is it monitored ? • Risk of blocking good transactions The Rise of the Web Application Fire Wall

39. Web Application Firewall Evaluation Criteria 1. Deployment Architecture 2. HTTPS Support 3. Detection Techniques 4. Protection Techniques 5. Logging 6. Reporting 7. Management 8. Performance 9. Protection of XML Web Services The Rise of the Web Application Fire Wall

40. So what does all this mean ? Web Application Security Consortium says that in-depth manual and automated assessments found nearly 97 percent of sites carry a severe vulnerability. As companies try to find the cost effective fix for poor coding and management driven timelines; they will use WAF for the short term protection while a new breed of security companies fills the gap with auditing code and compliance, the successful companies will continue to invest more in security professionals at the core of their development process ensuring adoption of secure coding techniques. The Rise of the Web Application Fire Wall

41. www.owasp.org • www.webappsec.org • http://www.webappsec.org/projects/wafec/ - WAF check list • http://www.sans.org • http://cve.mitre.org/ • http://nvd.nist.gov/ -- National Vulnerability Database • http://www.us-cert.gov/cas/bulletins/SB08-259.html • http://www.modsecurity.org/ • https://www.pcisecuritystandards.org/ • www.dilbert.com • http://www.msnbc.msn.com/id/3078572/ References:

42. Questions ?