Defcon 9 Web Application Security “In theory & practice” Presenters: Jeremiah Grossman & Lex Arquette Copyright 2001 WhiteHat Security All Rights Reserved
What is Web Application Security? Web Applications exist in many forms. Some search, some count, others even transfer money within your bank accounts. Web Applications are employed to carry out many mission-critical tasks and if anything on the web is certain, our reliance upon web applications will continue to grow. Simply, the securing of web applications.
Why is web application security important? Before software functionality was capable of being delivered via the web, software developers security concerns were relatively given: that their user-base was limited to internal or wan networks. All this has now changed. Web developers now create software that runs upon web servers accessed by anyone, anywhere. The scope and magnitude of their software delivery has increased exponentially and in so doing, security issues have also risen. - Browser Hi-Jacking - Cookie Theft - Server & Client Compromise - Denial of Service - Abuse - User Privacy Invasion
Accessing the DOM & Outside the DOM Document Object Model (DOM) Client-Side languages possess an enormous amount of power to access and manipulate the DOM within a browser. Complex & diverse interconnections create an increased the level of access within the DOM. Increased level of access to read & modify DOM data ranging anything from background colors, to a file on your systems, and beyond to executing systems calls.
Input Data Validation & Filtering Most web applications take in some amount or some type of user input to process a task, then direct the results back to the client. This user input is the source of many security issues. Again, NEVER TRUST CLIENT-SIDE DATA. Escape, validate, parse, filter and sanity check all the data. With client-side data you can never be to paranoid. Common input validation methods & mistakes...
Sanity Checking Sanity check all input for what information you are expecting to receive. If an input is only supposed be received as YES or NO, then drop any other responses. If an input is supposed to be numeric within certain constraints, check for these restrictions and drop the inputs that don't meet these requirements. The same goes for filenames and paths. Don't parse and especially don't use what you don't know.
Escape Special Characters Escape all input special characters. If special characters in strings are not allowed as input, strip the characters, or at the very least escape them. Mishandling special characters is a main source of system compromise via web applications. Special characters can cause illegal systems calls, file globbing, directory traversal, etc. Null characters should all be removed. * VERY IMPORTANT *
HTML Character Filtering If you web application has no need for HTML, substitute the following characters before they are echoed back to the screen. > => > < => < " => " & => &
Other Character Sequences Further data input to be wary of: ../ (Directory Transversal) (*, ?, +) (file globbing characters) ";" (Command Appending) ">" "<" "|" (Data Piping & Re-Directs) " and ‘ (Input String & Command Manipulation)
Output Filtering When, for example, querying data from a database destined for a user, it is a good idea to filter and replace HTML characters that may cause security problems as described above in HTML Character Filtering.
Further CGI Input information RFP2K01: "How I Hacked PacketStorm" (wwwthreads advisory) http://www. wiretrip .net/ rfp /p/doc .asp?id=42&iface=2 Phrack 55: Perl CGI problems http://www.wiretrip.net/rfp/p/doc.asp?id=6&iface=2 David A. Wheeler http:// dwheeler .com/secure-programs/Secure-Programs-HOWTO/input.html
HTML Allow Lists HTML is dangerous! Any web application allowing HTML is at risk. Even when proper precautions are taken, this is not something you can get around. As in all security access control, "ALLOW|PERMIT" lists are the safest way to go. If you must allow HTML from users into your environment, such as WebMail, Message Boards, Chat, then stick to these guidelines: - Know which tags you want to allow. Keep them strict and limited. - Of your HTML allow list, understand and limit what HTML Tag attributes you want to allow. - Know what tags and attributes are known to be harmful.
Dangerous HTML <APPLET> <BASE> <BODY> <EMBED> <FRAME> <FRAMESET> <HTML> <IFRAME> <IMG> <LAYER> <META> <OBJECT> <P> <SCRIPT> <STYLE> ATTRIBUTE DANGER LIST (Any HTML Tag that has these attributes) STYLE SRC HREF TYPE
User Authentication Many web applications such as Bulletin Boards, WebMail, Chat, On-Line Banking, Auctions and others have the need to validate their users.
Passwords Passwords are your systems' and your users' weakest link. -NEVER store passwords in plain text. -Aging -Password Restrictions General Guidelines: Password 6 letters in length, does not match username or partial username, not a common easy password (get a list), Contains 1 capital letter. Password 6 letters in length, cannot match username or part, cannot be a common easy password on a list, MUST contain 1 capital and one special character. Let your paranoia be your guide.
Passwords: What Not To Do - Place a maximum password length restriction. - Allow passwords to be changed into the original password. - Echo the new password over a non-SSL connection. - Make password restrictions too high.
Brute Force & Reverse Brute Force When brute forcing a web account, there are 2 main attack types. - Brute Force One username against many passwords. - Reverse Brute Force One password against many usernames. Each attack can be very effective and both must be defended against.
Defending Web Apps Against Brute Force Set an acceptable threshold on the amount of failed attempts a single account can receive before that offender is blocked (by IP) and the account itself is locked. Set an acceptable threshold on the amount of failed attempts a single IP Address can issue. Then block the offending IP for a specified amount of time.
DoS attacks against Anti-Brute Force As a result of Account Blocking, if an attacker wanted to prevent a legitimate user from logging in, the attacker would do so by tripping the brute force threshold on an account, causing the account to lock. A result from IP Blocking from failed attempts, the risk of blocking out HTTP proxied users such as AOL is apparent. Possible Solutions: When blocking an account, log the offending IP with the account block. If the legitimate user sign's on to the account with a differing IP than the offending logged IP, they would be allowed to proceed with a limited amount of possible failed login attempts. This prevents the account from being DoS'd, yet protects the account from brute force attempts. Use IP Blocking with care. Know your users and test.
Cookies Authentication In many circumstances, Cookies are used to identify and authenticate a user to a web application. There are many ways to implement this authentication depending what the needs consist of. There are however, some very important security precautions & considerations that must be met when implementing Cookie based authentication.
Cookies Authentication Guidelines -Use SSL for username/password authentication. -DO NOT STORE A PLAIN TEXT OR WEAKLY ENCRYPTED PASSWORD IN A COOKIE. Cookies are going to get stolen! If a Cookie is compromised, 2 things should NOT happen: a. The Cookie cannot be re-used or re-used easily by another person. b. The password or other confidential information should not be able to be extracted from the Cookie. - Cookie Timeout Cookie authentication credentials should NOT be valid for an over extended length of time.
Increased Cookie Security 1) Tie cookie authentication credentials to an IP address. Business Intranet: -Use complete 32-bit IP address. Entire Web: -Use a portion of the IP address. (16-bits of a 32-bit IP) 2) Tie cookie authentication credentials to HTTP Client Headers. As an experimental security practice, adding salt to your cookie authentication by hashing in some client sent HTTP headers. -User-Agent -Accept-Language Any header that stays constant with a browser such as Netscape or Internet Explorer. This will further prevent re-use of authentication cookies after they have been compromised.
Further Authentication Methods An excellent resource for example on real world Cookie authentication practices: Do's and Don'ts of Client Authentication on the Web by Kevin Fu, Emil Sit, Kendra Smith, and Nick Feamster. http://cookies. lcs . mit . edu /pubs/ webauth .html WhiteHat Security http://www. whitehatsec .com 2001(c)WhiteHat Security
Session Tickets/Passwording In many situations it is important that the data being sent from a web page to a web application has not been tampered with or has not been sent fraudulently on behalf of a user. Some actions performed by web application can have severe consequences if not validated properly.
Re-Password Authentication When performing a particularly critical action: -Use password re-confirmation before action is carried out. -YES or NO button if the action requested is what was intended. This prevents malicious scripts from quickly sending a CGI request and have an entire database cleared of it contents.
HTTP Referer Checking HTTP Referer Header checks may also provide some good safe guards against malicious script attacks. NOT Recommended: - Not to mention Referer's can be forged (DO NOT TRUST CLIENT-SIDE DATA). - Proxy services may strip out referers before sending HTTP requests to the destination. - If you know your users and their settings, HTTP Refers can be of added protection. As always, test, test, test.
GET vs POST If a web applications expected input is supposed to be received by a POST request, then allow only POST. This will help prevent many quick malicious client-side script attacks from succeeding.
Off Domain User Data Hosting When storing client side data such as web pages, text strings, images and other data used by your users, many cross-scripting issues are apparent. To protect against this danger, consider hosting your users data under another domain. For instance, your authentication cookies are issued from acme.com, then host your user data from acme.net. This will help prevent cookies landing in unauthorized hands. Do not host uncontrolled data on a protected domain.
Alternate Caps Description: The use of alternating caps within a line may cause the executable code to pass through due to case sensitivity within pattern matches. ** Use with all above filter-bypass methods ** Solution: Make sure all pattern match filter are case-insensitive.
Error Handling Common cause of cross-scripting and Cookie theft exploits: - Echoing user input from request errors exp.This includes 404 HTTP Responses. If you must echo error data, make sure to filter the data before being received by the user. Intuitive application error messages are very useful when debugging code, however, these messages can also lead to system enumeration or compromise due to their specifics. Do not tell a user that they have a valid username, but their password wrong when logging in. Tell them either one may be wrong.
Logging Out When a user initiates a session using Cookie as authentication or some other means, it is considered a good security practice to provide the availability of logout functions before timeout occurs later. These logout functions should serve to invalidate a user's session authentication information by modifying or erasing a session cookie in the event that users may have their cookies stolen and/or use a shared workstation terminal.
The future of web application security
<XML> Security What a hacker can do if XML security is breached:
- All non-XML related exploits mentioned
Vandalize web pages
Complete web page takedown
<XML> Allows applications to talk with other applications by providing a universal data format, which allows data to be easily adapted or transformed. XML is a set of guidelines and conventions for designing mark-up languages to describe data.
XML syntax is very strict.
A malformed XML page will not be processed.
HTML is very forgiving in comparison.
Example of an XML document
Users ‘recipes.xml’ is converted to HTML
server-side to support browser incompatibility.
All recipes entered also get added to the public
site for comments and review.
Public users searching for recipes may comment on a
Comments get added to the recipe owners recipes.xml file next
to the given recipe.
XML Security Issues Instead of comments, hacker adds XML tags, which get directly injected to a private users “recipes.xml” file. When a private user views their recipes, the XML tags get processed.
XML Security Issues
XML Tag Insertion
a) Add recipes to their recipes.xml file
b) Style Sheet referencing
c) DOS attacks
d) Malformed XML tags
e) Processing Instructions
XML Security Issues XML specification allows the creation of tags that execute applications. For example: An application that could tell me weather a fruit or vegetable was in season or not. Embed an XML processing instruction to execute this application and show me weather my recipe ingredients were in season or not when I viewed my recipe book. Depending on what the process was running as, a hacker could embed a processing instruction tag to execute applications or their choice. Hack that monkey:
DTD Implementation Document Type Definitions describe the structure and semantics of an XML markup language. By using a DTD you can have an XML application compare a given XML document to a DTD. If an illegal tag is recognized, the XML processor will error the application.
Web Services Web services allow applications to communicate regardless of operating system or programming language via the web. Web Services are XML based. WhiteHat Security http://www. whitehatsec .com 2001(c)WhiteHat Security
The Life of an HTML document + .HTML Web Browser Document Application
The Life of an XML document + .XML Document Applications