1. Web Application Security
Presented By
Allen Brokken
Principal Systems Security Analyst
GSEC, CSDA, CPTS

2. Overview Disclaimer Why Should I Care?
Open Web Application Security Project
OWASP Top Vulnerabilities
Practice Sites
MU SafeWeb Initiative

3. Disclaimer
The information contained in this presentation is intended to be used to educate developers about security vulnerabilities commonly found in Web Applications.
This presentation is not intended as training material for those with malicious intent against information systems.
Exploitation of the vulnerabilities listed in this presentation on systems or applications not owned or developed by the viewer is illegal in jurisdictions worldwide.
It is a violation of the University of Missouri Acceptable Use policy to transmit these exploits across the MU network without explicit permission of the system or application owner they are directed at.
The presenter is a trained professional, don’t try this at home…

4. Why Should I Care? $50,000+ 1,000,000 Profiles 5000+ Credit Card #'s
“[all users] were able to view individual customers' orders for… items of intimate apparel in which the retailer specializes.”
$50,000+
“One clever MySpace user … figured out how to force others to become his friend … In less than 24 hours, "Samy" had amassed over 1 million friends …
1,000,000 Profiles
“… informed its members that their credit card information might have been compromised after a Chicago-based hacker cracked the site's code…”
5000+ Credit Card #'s

5. Why Should I Care? Common Misconceptions
Aren’t I protected by firewalls or something?
I thought you just needed to keep things patched?
I’m not using Microsoft, so I must be secure.
Isn’t keeping me secure your job?

6. The Open Web Application Security Project
The Open Web Application Security Project (OWASP) is dedicated to finding and fighting the causes of insecure software.
They have chapters world wide and manage multiple projects designed to help individuals and organizations increase the level of security of their applications.

7. OWASP TOP 10 #1 Unvalidated Input
Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.
means that the code accepting input from the browser does nothing to check to see if the entry is valid before processing. An example might be asking for a phone number in a certain format, and not checking that it’s being input in that format. However, more often it’s code generated input parameters that get missed. So here’s an example.
The first thing a good hacker does is recon the application manually to see what can be determined by just browsing the site like any casual user might.
So I click Login and notice something interesting on the address bar, page=Login, I also notice that the word Login is repeated with an exclamation point above the User Name/Password fields.
That’s not definitive about anything, so let’s look some more
Register brings up the same behavior
News same deal
Contact Us, same thing
So I wonder what happens if I change the address bar a little and see if I can find a Logout page
The change I made in the parameter writes a page that matches my input as I guessed.
Typically sites that are driven this way are either using a database to do content, or text files. Given this page is a CGI, files are more likely. So let’s see what happens if I enter
Index.cgi
If I view source on this garbage I can get a better feel for what I’ve just pulled up.
For those of you familiar with perl you’ll see the cgi begins at this point.
Since I know that it’s using the page parameter to manipulate things I’ll search for that in the text.
At this point $page is set equal to the parameter page
So now I can look a little farther down and see that this script indiscriminately opens a file with the same name as the page=parameter.
Let’s see if I can open something interesting like /etc/passwd
There are a few dozen ways to solve this particular vulnerability, however the biggest issue here is that the code is accepting any input I might give to it as is.

8. OWASP TOP 10 #2 Broken Access Control
Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.
This often reveals itsself as security by obscurity. At some point in your application you display certain fields or links based on a group membership or id, but don’t check anywhere else after that to make sure that is still correct.
In this website I’ll login as the admin
As you can see logged in as the admin I get a link Admin Tools
Then I get a page that lets me change passwords or delete users.
So the question is, can I get to this page as a normal user?
First I’ll go to the Registration page
Next I’ll create a new user
New
User
New_User
Password
Login
If you notice the Admin tools are not listed
However, all the pages are named something simple Profile, Logout, etc…
I wonder what happens if I change the file to Admin.php
That’s broken access control, I can’t rely on hiding a link to prevent someone from getting access to various tools.

9. OWASP TOP 10 #3 Broken Authentication and Session Management
Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.
The HTTP protocol is inherently stateless. What that means is that every request is treated like a brand new transaction. The server has no idea “who” you might be, even after you just authenticated, without some session management mechanism. Typically that’s handled by maintaining a Session Id of some sort, whether it’s a cookie, a URL parameter, or something hidden on the page. Different languages and web servers handle this differently, however session management is what ultimately identifies each user individually. Without proper session management there is no security.
Login as New_User
Look at Profile
Show Session ID parameter on the URL
Log Out
Hit Back
Click Your Profile
Login Again
Note session_id
Close browser
Login again
Show Profile session_id
Logout
Pick Profile
Replay Admin login
This is broken in a lot of ways, the first is I made this scheme myself. There are plenty of valid ways to deal with sessions. I think .Net does it best since each click validates the old session id used to generate the page by IP, timestamp, and that it hasn’t already been used, then generates a new one which becomes a 128bit hash for the next page load. The lesson here is you need to understand the session management routine you are using inside and out or you have no security.

10. Brute Force Password Statistics
Length
of the
password
Character set
Lowercase
letters
letters and
digits
Both lowercase and
uppercase letters
all printable
ASCII
characters
< = 4
instant
2 min 5
12 min
4 hours 6
10 min
72 min
10 hours
18 days 7
43 hours
23 days
4 years 8
4 days
65 days
3 years
463 years 9
4 months
6 years
178 years
44530 years

11. OWASP TOP 10 #4 Cross Site Scripting (XSS) Flaws
The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user.
Cross Site scripting is a method where an attacker injects script code in a way that alows them to manipulate and ultimately “own” the way your site displays itself and what it does.
Remember that in item 1 we determined that the site was not properly validating certain input. We also saw that whatever was put after page= Would be redisplayed to the screen. So what happends if we try injecting some HTML there?
<script>alert(“This page accepts XSS!”)</script>
Pop up – COOL!
View Source on page
So what if I want to do something more insidious
If the code at is intelligent enough it can attempt to authenticate you to the real application, read that page, then decide to store your username and password or not based on success or failure, then redirect you to a legitimate login failure page so you think you just mistyped things. Unless you are religious about checking history you’d have no idea what happened.

12. OWASP TOP 10
#5 Buffer Overflows
Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

13. Attacker Sends 200 Bytes to Your Code
OWASP TOP 10
#5 Buffer Overflows cont.
100 Bytes of Data
Attack Data
Attack Code
#1148-#1248
#1548-#1568
Attacker Sends 200 Bytes to Your Code
Memory Manager Table
Program Allocation
Your Code #1148-#1248
Explorer.exe #1548-#5548
Memory
Free Memory
Buffer overflows refer to reallocation of memory due to malicious input. Due to time I don’t have the ability to go into all the ins and outs of memory management, and the true complexities of the situation. The most basic of memory management involves the actual memory storage its self and a table of what data is stored where. The Memory Manager table keeps track of what address space and where code is at in the execution process. The memory manager attempts to take data input to it and assign a location in physical memory to be stored.
Due to the way most operating systems work, Memory for operating system components tends to be allocated in a predicatable manner. This means determining the relative location of Operating System memory in both the Memory Manager and the physical memory is fairly easy. When exploiting a buffer overflow the attacker will attempt to send more data to a program than it can handle. If it successfully overflows that program’s allocation the memory manager will then attempt to allocate that input to the next assigned program. If it’s crafted properly it will overwrite memory space in other code allowing elevation of privilege or other advantages for the attacker.
This is generally something that affects structured languages more than scripting languages. There may be a buffer overflow vulnerability in php or perl, that needs to be patched, that your code could be used exploit. However this problem is not inherent to interpreted languages.
Your Code
Explorer.exe

14. OWASP TOP 10 #6 Injection Flaws
Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.
Injection flaws are probably my favorite, because they tend to be some of the most powerful and interesting flaws to exploit. On the other hand they are also the most scary because ultimately we’re talking about attacks that can directly affect the integrity of your database. Most often you will hear about SQL injection, however LDAP injection is also possible. The difference between injection flaws and cross-site scriptiing is that injection flaws actually run on the server rather than in the browser.
The place to start testing for injection flaws is simply by entering ‘ in a form and see what happens
That immediately gives me some more information about the code which we’ll cover later.
This says something about SQL syntax and password. Let’s see what happens if I enter my actual user id and ‘ for the password
Again a syntax error about passwords
The previous text said something about & password = “” So I’ll try some SQL to see if I can trick it out
‘ or 1=1 –
This will say whatever SQL was first ‘’ or 1=1 – and password = “” The – terminates the SQL statement and basically says WHATEVER or TRUE
Since that worked on the password field, maybe I should try it on the username field
Look I’m now the admin. This query is only returning the first row where WHATEVER or TRUE and typically the admin account is the first account in a database.
This is actually a case of a multiple vulnerabilities. The injection flaw wouldn’t be possible if input validation were done properly.

15. OWASP TOP 10 #7 Improper Error Handling
Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.
We already saw an example of this in the injection flaw section. Basically the web-server displayed some key information about the SQL statement being used. We’ll take a minute to look at the errors in detail
In this case the programmer put in some significant debug code, which is often appropriate during development but totally inappropriate during production use.
In this case typing ‘ allows us to see the error in the first place. As an attacker some times it’s more useful to exploit the system as a particular user, rather than as the admin. Since I have admin access I could just reset the password to take over an account. However, resetting the password is problematic since that will be logged somewhere and the user will notice. However, the verbose error reporting gives me some options I wouldn’t have otherwise.
The first thing I get out of this is that the table USERS has columns ID, FIRST_NAME, LAST_NAME, USERNAME, and PASSWORD. A detailed analysis of the site done carefully can reveal a huge amount of data about the data dictionary and how the overall database is structured. By careful injection the ability to harvest any data you like can be accomplished.

16. OWASP TOP 10 #8 Insecure Storage
Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.
In this case we are talking about exactly how the data is transmitted and stored. More often than not this is specifically related to data that no-one should ever be able to read. The most obvious example is passwords. They should never be stored in plain text. Generally storing them using an industry standard hashing algorithm is best. That means no one can “retrieve” their password. However, that is exactly the point.
Let’s look at our application
If I login here I see that it actually displays my password in plain text. That means everyone elses is in plain text as well. Since I know I can login pretty much as whoever I want “illegitimately” it would be nice to be able to appear legitimate. At this point I can attempt a number of existing exploits to get the information I want.
After looking over the directory I’d like to become Jane Smith
jsmith1 and FIRST_NAME=‘Jane’ –
Her password is password

17. OWASP TOP 10 #9 Denial of Service
Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.
Denial of service is probably the lamest of all attacks, because it doesn’t actually have much of a long standing effect for the attacker. Essentially the attacker floods the server with data, or intentionally destroys data that forces an outage of service for the target system. Even a complete drop kicking of the data in the database is not terribly useful, considering backups, and disaster recovery plans. It can have an economic impact for the attacker by the way of extortion. However, that’s a fairly weak method of extortion as an entire industry exists in the security space to protect people from such attacks.

18. OWASP TOP 10 #10 Insecure Configuration Management
Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.
This is last on the list because it has very little to do with the code its self and everything to do with the web server. This can be anything from running the web server as root, to not keeping the patches up to date. This is typically handled by the systems administrator. There are a number of guides for ensuring the web server is configured properly. The simplest example I have here is not securing phpMyAdmin

19. Practice Sites Starfleet Academy HACK This Site
HACK This Site
Next Generation Security Games
WebGoat
Requires a Java Virtual Machine be available on the local machine, and runs from the local machine.
HACME Bank / HACME Books
Note you will have to install these on a system you can run an appropriate web server on.

20. Objectives
Applications development standards with an emphasis on security.
Data classification policies.
Secure server environments that support the defined data classifications.
Auditing policies and processes to insure adherence to the standards.
Minimum training requirements for applications development, database administration and server administration.

21. Activities to date Faculty Collaboration Meeting
Multiple one-off or guest lectures
Multi-Media efforts
Secure Coding Requirement Pilot

28. Report Details Severity File Name(s) Summary Execution Implication Fix
References

29. Management Console Look at Student Learning

30. Q&A SafeWeb Initiative Application Security Software Presenter Contact
Application Security Software
Presenter Contact

31. References Victoria's Secret reveals far too much
Cross-Site Scripting Worm Hits MySpace
Online political warriors savage opposition Web sites