Web sites expose selves to attack

Source: http://www.msnbc.com/news/420137.asp?0a=2202343-&cp1=1

Web sites expose selves to attack
Customer information might not be as safe as you think

By Bruce Kratofil - BUGNET

June 13 -- It's always nice when a Web site says "Hello". Unless, of course, the Web site should be doing something else. Many large e-commerce Web sites are susceptible to a bug that would allow someone to exploit the site's user input fields to run malicious JavaScript. While our example below only causes a "Hello" message to be displayed, you could easily construct other scenarios that would allow a malicious user to steal cookie data. This is a potential threat to you, since some Web sites use cookies t o store usernames, passwords, and other critical information.

BUGNET READER GRAYDON MILES passed along this information to BugNet. He discovered that on many Web sites the user input fields do not correctly screen out JavaScript commands that a user may enter. To see if a Web site is vulnerable, here is a non-damaging example phrase that you can enter into a Web site's user input field (please remove all spaces from the phrase before using to test):

< script >alert('Hello')< /script >

http://www.gate.net/~bridget/nowonde...s/js_hello.jpg

If the security is lax, and you have JavaScript running, you should see a window like the one shown here pop up, giving you a friendly greeting. This bug is universal. Microsoft Internet Explorer 5 generated that message, but the same results occur with Netscape Navigator. (Note: Microsoft is a partner in MSNBC.) It also does not matter which Web server is being used. Testing at KeyLabs exposed the vulnerability on over 20 of the biggest and most well-known Web sites on the Internet.

It's no big deal to trigger a "Hello" message this way. But there are many other JavaScript commands available that could be used with this exploit, which might make this a big deal. Some of these JavaScript commands can be used to get or retrieve cookie data. A URL conceivably could be constructed that fetches the contents of a cookie an e-commerce site stored on your computer. If this cookie held your user name and password, the hacker could possibly impersonate you at that site, and see a stored credit c ard number.

WHAT CAN YOU DO?
This is only the latest string of reported JavaScript problems. While Web sites will patch this, other problems will pop up. You can guard against rogue JavaScripts by turning off the JavaScript capabilities in your browser. In Netscape Navigator, click Edit, Preferences, and then click Advanced in the left panel. Uncheck Enable JavaScript. In Microsoft Internet Explorer 5, click Tools, Internet Options, then go to the Security tab. Select Internet Zone, and click Custom Level. Disable active scripting, as well as any other technologies, such as ActiveX, that worry you. With Internet Explorer, you have another option. If you feel that you are safe from this bug at a particular site, you can add that site to your list of Trusted Sites. Make security less stringent for these sites, while maintaining tight security on the others.

Also, think about your use of cookies. Many Web sites store username and password information in cookies. As more and more ways are found to steal cookie data, you may decide that you don't want to use them. Turn off cookies in your browser at the same dialog used to turn off JavaScript (as shown above.) You can also delete the cookies you've already accumulated. For Microsoft Internet Explorer, running on Windows 95 or 98, cookies are kept in the Windows\Cookies folder. In a clean install of Windows 2000, they are stored in the \Documents and Settings folder. In Netscape Navigator, cookies are stored in a file called cookies.txt, which is found in your Netscape\Users\username folder.

Note that when you turn off browser features like JavaScript and cookies, you will lose some functionality at Web sites and often be inconvenienced. But with a growing number of security threats facing Web browsers, maybe a little inconvenience is necessary. After all, it's inconvenient to stop and lock or unlock the front door to your house, but it is usually better than the alternatives.

WEB SOLUTION
Even though there are things you can do as an Internet user, the real solution rests squarely on the Web site developer. As a Web developer, you must validate user input. Failing to do so will expose your site and your company to litigation. Imagine how devastating it would be to have your customers sue you for not adequately protecting their credit card numbers. O'Reilly has a site with good information on protecting your Web site: The World Wide Web Security FAQ http://www.perl.com/pub/doc/FAQs/cgi...urity-faq.html contains practical steps on protecting your site against this kind of attack.

This security vulnerability is not a problem with the browsers or with the Web server software. The bug is in the implementation of the Web site, and specifically in the way the site validates user input. Before venturing into a cyber store front, you might want to consider the saying "caveat emptor" ("buyer beware"). And that not only goes for the item being purchased, but also for the store where you purchase it. If the e-business can't or won't protect your confidential information, you are better served going somewhere else.