July 20

Web Security, Part 1 of 3

Last week a friend forwarded me an email about a security hole in Matt's TextCounter, a CGI program I use in the ISPs area. The old version of TextCounter doesn't check to see if a submission contains shell metacharacters, making it possible for a hacker to execute commands on the UNIX host with the same permissions as the web server itself.

There were no such incidents at 56K.COM, but this reminded me that I haven't given as much attention to security as I should have. This weekend I spent some time researching security issues. Today I'll talk about security on the web server itself.

Web server security

Anyone operating a web server should read Lincoln Stein's World Wide Web Security FAQ. Some of the topics covered include server configuration, file and directory password protection, and CGI safety.

CGI is a way for programs running on the web server to interact with the web browser. CGI is a powerful way to add interactivity to your site. On 56K.COM, the survey, search engine, links program, email forms, counters, banner rotator, and other programs are CGIs. The downside to CGI is is that it has the potential to introduce security problems, as happened with TextCounter. cgiwrap is strongly recommended for anyone using CGIs.

The FAQ lists several popular CGIs with known security problems, including TextCounter, Count.cgi, Selena Sol's guestbook, and Excite for Web Servers. In most cases, new versions patch the problem. In the case of TextCounter, the problem was uncovered last month, and Matt promptly released a new version to plug the security hole. Upgrading to the new version took about ten minutes.

Server administrators and webmasters should also visit rootshell.com, a site that clearly demonstrates how to exploit weaknesses in computer security in both servers and user software. The site has been criticized for providing instructions to hackers, but it's just as valuable for server administrators to know that these problems exist. If rootshell.com was forced offline, the information would still be available to hackers, but the good guys would have a hard time finding it.

If your web server runs on a UNIX host, there are additional issues. The various comp.security.unix FAQs may be helpful. UNIX file permissions are tricky to set up, and using them incorrectly can give everyone read or write privileges to your files and directories. Read a tutorial, and use the minimum permissions necessary.

Part 2

On Wednesday, I'll cover web browser security. Find out how web sites can steal your files and email address.

---

July 22

Web Security, Part 2 of 3

On Monday, I talked about security for webmasters and server administrators. Today's topic is security from the client end.

Before we start, a followup to Monday's piece. On the same day I posted that article, Wired magazine ran two stories about hacker break-ins. One group broke into Time Warner Cable in Los Angeles, while another hacker deleted all of the files on Our First Time and replaced it with a message that the site was a hoax.

Web browser security

Stealing your email address
Contrary to widespread belief, the web isn't designed to give your email address to the sites you visit, but there are several exploits that accomplish exactly that. The exploits usually take advantage of bugs in particular browser versions.

The original JavaScript in Netscape 2.0 allowed sites to snag your email address. This was quickly fixed in version 2.01.

There is a bug in JavaScript in Netscape versions 4.0 through 4.04 that allows sites to see your email address, and even your email password, if you have told Netscape to remember your password when checking email. The WWW Security FAQ has more information. Fernand Portela discovered the bug, and shows how it works on his web page. Solution: don't let Netscape remember your email password. Type it in each time you check email.

Another trick that web pages can use doesn't require JavaScript. It depends on the normal behavior of FTP. If you look at the source code of this page, you'll see that images are downloaded with http, like this: <IMG SRC="http://www.56k.com/images/top.gif">. A site can instead specify an ftp:// download. FTP requires a username and password, but most browsers will automatically try an anonymous login: username anonymous, with your email address as the password. I've seen a page which demonstrates this hack, but I couldn't find it in any of the search engines. Email me the address if you know it. To defeat this exploit in Netscape 4.0, go to Preferences and uncheck "Send email address as anonymous FTP password." Netscape will make up a bogus email address for FTP logins.

Stealing files from your hard drive
Internet Explorer 4.0 for Windows 95/NT has a weakness that allows sites to upload the contents of any text, image, or HTML file on your computer. Microsoft has a patch available. More info...

Netscape 2.0, 3.0, 3.01, and 4.0 allows remote sites to retrieve files from your hard drive, but only if the site specifies the name and location of the file. Netscape 4.01 fixes the problem. More info...

Other browser security holes

Among other things, it's possible to retrieve the Windows 95 or NT network login password. This problem exists in most versions of Internet Explorer for these platforms, and in some versions of Netscape for Windows 95 and NT. The explanation is rather long, but it's discussed in WWW Security FAQ.

ICQ

ICQ is a popular chat program with a number of security holes. It's possible to steal ICQ passwords, change ICQ passwords, and spoof messages (make messages appear to originate from one user, when in fact they're coming from another). Search rootshell.com for "icq" to view some of the ready-made hacks. Until AOL/Mirabilis fixes their security problems, don't say anything on ICQ that you wouldn't want known in public.

Part 3

On Friday, we'll look at some things you probably should not be worried about: cookies and HTTP variables.

---

July 24

Web Security, Part 3 of 3

This week we've talked about some real security risks on the Internet. Today I'd like to debunk some fears about cookies and other non-threats.

Environmental variables

You've probably seen sites that used this trick:

Hello, visitor from ! I see you agree that is the best web browser.

When you see this information, it doesn't mean that a hacker has access to your deepest secrets. This information is part of every HTTP request, meaning that it gets sent every time you load a web page from a server. In this case, I'm displaying it with server side includes (SSI). In particular, I'm using <!--#echo var="REMOTE_ADDR"--> and <!--#echo var="HTTP_USER_AGENT"--> in the HTML code. I have a page that shows other SSI codes, though some of them don't work very well.

Cookies: not a security risk

It was Netscape who introduced the idea of cookies to solve a problem facing web authors. As an individual visitor moves through the web site, there was no way to uniquely identify them. Their requests for web pages look like any other visitor's requests for web pages. Imagine that you're writing a shopping cart program that allows users to add items to the shopping cart from any page on the web site. There may be several users shopping on the site at the same time, all of them with their own shopping carts. When a user clicks the "Add Item to Shopping Cart" link, how do you know which shopping cart to add the items to?

Cookies solve this problem and many others by sending the browser a piece of information - the cookie - that the browser stores on your hard drive. In the case of shopping carts, the cookie contains a unique user ID. Each time the person visits a page on the shopping site, the browser sends the ID so that the shopping cart can know which shopping cart to add items to.

Cookies can be used in other useful ways. Some sites require a username and password to log in to a member's area. By setting a cookie, the sites can speed your login. When your browser sends the cookie containing the user ID, the site can bypass the username and password step, because it recognizes you as a registered user. Note that this does not mean the username and password are stored in the cookie. Instead, the user ID is essentially used as a substitute for the username and password.

One of the newsgroups I read has been embroiled in a debate over cookies this past week. The WWW Security FAQ says that cookies are not a security risk, in that they can't be used to steal information. The FAQ does caution that sites using cookies to simplify username/password entry should be careful about assuming a user's identity based on their cookie. It's possible for a cookie to be intercepted. Most sites that use cookies as substitutes for usernames and passwords use them only for free areas that require registration.

What confuses people is that a web site can set a cookie, but it can't read cookies. If the web site can't read cookies, how does the information get back to the web site? Answer: the browser automatically sends the information to the web site that set the cookie.

Here's an example. On the V.90 Upgrades page, I use a JavaScript to warn people not to upgrade to V.90 until their ISP upgrades. The message is purposefully annoying, and I don't want to inflict it on people every time they visit the page, so I set a cookie in their browser that looks like this:

www.56k.com FALSE /links/V90_Upgrades FALSE 908492306 ZZZZZ here

The next time that person visits the V.90 upgrades page on 56K.COM, his browser sends that cookie and the JavaScript knows not to show him the warning. The web browsing software won't send this information to any web site other than 56K.COM.

With cookies, there are potentially some privacy issues, in that a web site can identify you from visit to visit, and potentially compile a dossier of your web browsing habits on their site. However, the web site won't know your actual identity unless you provide it.

In particular, there's no way for a site to get your name or email address from your cookie file. In fact, your email address won't be in your cookie file unless a site set a cookie containing that information. The only way they would know your email address is if you gave it to them at some point.

Previous week