[Image] [Image][Image] [Image][Image][Image][Image][Image][Image][Image] [Image][Image][Search] [Image] [Image] Bugtraq | Mailing Lists | Library [Image][Image][Image] [Image][Image][Image][Image][Image][Image] [Image] [Image][Image][Image] WWW MOBILE CODE SECURITY ARCHIVE [Image] About this List [Image] --------------- [Image] Other Lists: [ Message Index ] [ Thread Index ] [ Reply ] [Image] [ prev Msg by Date ] [ next Msg by Date ] aris users bugtraq To: WWW Mobile Code Security bugtraq-es Subject: On web application audits bugtraq-jp Date: Sep 22 2001 12:05PM cisspstudy focus-ids Author: Sverre H. Huseby focus-ih Message-ID: <20010922120507.G1562@thathost.com> focus-linux focus-ms As I find the ongoing discussion about web application audit focus-sun interesting, I decided to write down some of the stuff I normally have focus-virus in my head. Comments are welcome! forensics incidents linux-secnews Things to look for when doing a web application audit ms-secnews ===================================================== pen-test secprog Input Validation/Washing security-basics ------------------------ security jobs sf news Often used examples include data driven attacks against SQL databases, vpn or OS command insertion to Perl CGI scripts. vuln-dev www-mobile-code * Identify sources of input. If input washing is done, it is typically done on obvious inputs: Forms and URL parameters. [ more . . . ] * People tend to forget that eg. cookies also may be changed to contain malicious input, depending on how the cookies are used in the application. * They also forget that input may originate in their own database. They may do washing eg. when the user registers for a service, but forget to do it when they pick those data from a database to build new queries later on. * In multi tier applications, data sent from one tier to another should ideally be validated as if it came directly from the outside. Output Washing -------------- Is it possible to insert script tags in any output from the service? In that case it is simple to craft scripts that will eg. steal session ids. * How is the washing of output done? Anything else than totally removing less/greater than, ampersand and semicolon may be trickable. Correctly washing output is extremely hard if one wants to allow some tags. * Is washing done everywhere? People tend to be good at washing output that they know come from users (eg. from a database), but they often forget to wash output they generate themselves. A typical example is a general purpose error message script: http://example.com/error.asp?msg=Some+error+message If the message is not washed, bad guys may insert a script, and eg. send this URL in mail to users of the service, thereby stealing session ids. Off-site Trickery / Client Side Trojans --------------------------------------- This is a hard one, and I guess a great number of critical web services are vulnerable. The Client Side Trojan problem was addressed in the Zope community in May 2000. The problem is that someone may fool others (or their browsers) to perform the final step in an operation just by sending a mail or embedding URLs or scripts in web [Image] pages that are not connected to the site in question. [Image] Example: I know a user is logged in to his bank. What happens if I send him an HTML mail (that will be rendered by an Internet Explorer component if the victim uses Outlook), or points him to a web page containing the following:
The browser is already authenticated, and if the bank has not taken steps to protect against this kind of trickery, money will be transferred to MY.ACCOUNT. * Does the web site contain protection against Client Side Trojans? Protective measures include making sure that the action the user takes is an action that our web site, and not some nasty guy, offered him to do. (Using some kind of "tickets" may do the trick: Associate an offer to do something with a ticket, and also store the ticket in the user's session. If tickets match, we know that _we_ gave the offer.) Lack of Authorization Tests --------------------------- Developers tend to be good at authenticating users, but they often forget to check that users are allowed to do what they attempt to do. * Does every action in the application start with an authorization test? It should. * Authorization often needs to be repeated: A bank offering a user to select one of his accounts for viewing, will first check what accounts this user is supposed to see, and create a web page that lets the user select one of them. When the user selects one, the bank will have to test again, to make sure the user didn't change the valid accounts on his side. (Of course, a better measure is to not pass account numbers from the client side at all, but rely on values in the session object, and let the client side pass pointers to these values.) False Security -------------- Developers tend not to understand security very well, as it is seldom a part of our education (at least in Norway. If security is at all included, it typically is about firewalls and encryption.) * Are security measures left to the client side? Using JavaScript for input validation is common, but stupid. * Is the Referer header used for security? * Are IP addresses used for authentication? * Is encrypted input (eg. credit card numbers over HTTPS) later passed in the clear (eg. credit card numbers in a confirmation E-mail)? * How are users' password stored in the database? Surprisingly many developers do not know that clear text passwords are bad, and that they are, in fact, not needed at all. Sverre. -- shh@thathost.com Try my Nerd Quiz at http://shh.thathost.com/ http://nerdquiz.thathost.com/ Privacy Statement Copyright © 1999-2001 SecurityFocus [Image]