1. Application Security Positively False
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)
Georgia Department of Audits and Accounts 2008

2. OWASP Top 10
Web Site:
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.

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

4. OWASP Top 10
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.

5. OWASP Top 10
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.

6. OWASP Top 10 EXAMPLE: RIAA web site cleared WHID 2008-04:
Reported: 22 January 2008 Occurred: 20 January 2008
Classifications:
Attack Method: Cross Site Scripting (XSS)
Attack Method: SQL Injection
Attack Method: Denial of Service
Country: Global
Country: USA
Outcome: Defacement
Outcome: Downtime
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.

7. OWASP Top 10
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.

8. OWASP Top 10
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.

9. OWASP Top 10
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.

10. OWASP Top 10 EXAMPLE: hacker steals user information
WHID : Chinese hacker steals user information on 18 MILLION online shoppers at Auction.co.kr
Reported: 12 February 2008 Occurred: 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)

11. OWASP Top 10
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.

12. EXAMPLE: Information stolen
OWASP Top 10
EXAMPLE: Information stolen
WHID : Information stolen from geeks.com
Reported: 08 January 2008 Occurred: 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, 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.

13. OWASP Top 10
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.

14. OWASP Top 10 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: Note 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.

15. OWASP Top 10
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.

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

17. OWASP Top 10 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.

18. OWASP Top 10
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.

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

20. Developer real world mistakes
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!";
Answer : User name and Password are always the same.

21. Developer real world mistakes
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 ResultSet authorised = statement.executeQuery( "SELECT id FROM table_name_redacted WHERE " + "username='"+username +"' AND password='"+password+"';");
Answer: doesn't quite fool the hacker who uses the "'; --"

22. Developer real world mistakes
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)
Answer: the 'password' field holds the password in plaintext

23. Developer real world mistakes
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=' }}  
Answer: Code injection by a developer to show picture or funny subject matter to friends.

24. Developer real world mistakes
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
Answer: User can view source on HTML page and manipulate database strings

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

26. Security assessment questions?
How can I tell if the developers know anything at all about security ?
Management – on time
Development + more time

27. Security assessment questions?
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 ?

28. Security assessment questions?
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 ?

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

30. What we are doing to stay ahead
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.

31. What we are doing to stay ahead
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

32. The Rise of the Web Application Fire Wall
“Please protect me from my developers”
Web Server
Application server
Web Applications
HTTP Requests

33. The Rise of the Web Application Fire Wall
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.

34. The Rise of the Web Application Fire Wall
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)

35. The Rise of the Web Application Fire Wall
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.

36. The Rise of the Web Application Fire Wall
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.

37. The Rise of the Web Application Fire Wall
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

38. The Rise of the Web Application Fire Wall
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

39. The Rise of the Web Application Fire Wall
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

40. The Rise of the Web Application Fire Wall
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.

41. References: www.owasp.org www.webappsec.org http://www.sans.org
- WAF check list
-- National Vulnerability Database  

42. Questions ?