This section deals with the web browser and the securing/hacking thereof.
There are two main areas regarding security around a browser -- reading your private files and manipulating you into a compromising situation.
Just a few files can provide a lot of information about yourself. These include cache files, the history file, and your bookmarks. Usually, if you are a typical home user, this is not a problem. But if your browser directory is stored on a server, the server could be compromised and then anything in the cache and history is in the hands of someone else. Every access and submitted form, including those to change passwords on servers whose service you are paying for.
Being manipulated is the other hot area. You can be tricked into supplying user IDs and passwords, revealing personal information like Social Security and credit card information, or even be presented with misinformation to cause you to act in a way to cause a vulnerability to arise. If your browser supports HTML extensions and/or Java, your history file, cache, and other files could be plucked from your hard drive. Your machine could be used as a mechanism to attack other resources behind your firewall, sending critical information to an offsite hacker. And while vulnerabilities in most mainstream browsers are constantly patched to prevent this type of behavior, certain hackers are constantly finding new holes.
Check out Georgi Guninski's home page for a good example of browser problems in the Internet Explorer and Netscape sections.
We'll cover all three. First the history file.
For most browsers, the default color for a clickable link is blue. Once you've clicked on it and visited the link, it changes purple. While the colors may be different depending on the page design, the way your browser keeps track of this information is via the history file.
Again, for most browsers, the default is 30 days to expire a link, making it possible to see the last 30 days worth of web surfing by examining the history file. "Hmm, Fred keeps looking at a particular set of stocks. Does he know something I don't? Hey, Martha keeps looking at lesbian sites. What would her homophobic boss say about that?" Get the idea?
Here's a formatted example:
http://www.google.com/search?q=microsoft+stock+price+takeover+rumor+apple http://www.google.com/search?q=apple+macintosh+hack http://www.google.com/search?q=audit+trail+hide
If this were from the history file of someone at Microsoft, it might be quite interesting, even valuable.
Bookmarks are a problem for the same reason: it shows what sites you regularly browse. If you are bookmarking sites which require passwords to enter, a quick look your the cache will possibly reveal those passwords, or at least your account IDs.
The cache is your browser's way of making things a little easier on your access time, the server you're accessing, and the network in general. What happens is that when you access a web page, a copy of the page and any graphics used on that page are stored locally. That way, if access the page again, your browser can pull up the local copy instead of accessing the network. This saves time and bandwidth. When you reload, your browser compares the cached file to the one on the server you are accessing and pulls down the latest one. Most browsers will also cache queries and form submissions, as well.
If you are looking for dirt on someone, looking for credit card information, or just want to find out what someone's been up to, check their cache. Every query to a search site like Google is stored in cache. Typically, every form submission including browsing pages that require an ID and password will be there, unless a site has tagged a HTML document to not be cached.
The cache is typically located in a subdirectory underneath the browser's working directory , usually with the word "cache" in the directory name, depending on your OS and browser version. Otherwise, it may be stored in a temporary directory. For example, IBM's Web Explorer for OS/2 will store its cached files in C:\TCPIP\TMP, and is flushed before each run of the program.
Here is a formatted example from a cache's index file on a Unix workstation, with names changed to protect the not-so-innocent ;-)
n b <http://altavista.digital.com/cgi-bin/query?pg=q=web=> 10=.=%2bhack+%2bnt+%2bserver E1 00/cache31DF458002EC693.cgi text/html 4 ( <http://www.example.com/user/register.cgi> (r) rE1 10/cache31DF457002CC693.html text/html . " <http://www.example.com/use> r/welcome.html *1 J 14/cache31DF18940 27C693.html text/html J
Here are three entries. In the first, the user is trying to get NT hacking information from AltaVista. In the second, the user is trying to get signed onto a site called www.example.com, and finally it looks like the user got in. The three cache files are:
You could view these files with a browser, since they're just local copies of the web pages. If 31DF457002CC693.html had a password in it and it was unreadable, you could still do the following:
Access the site yourself and try to login. Check your own cache and replace your cached file with the file 31DF457002CC693.html, renaming it to what your cache file was, and then resubmit the form. If the site is doing only password security, you might get in. If you still don't get in, try substituting the cookie file, as well (in the next section).
The information gained from these sources can also be quite useful for social engineering purposes. For example, you could determine the user was interested in aquariums and rare fish, and use that to assist in guessing a password.
The cookie file (typically named 'cookie.txt') is a file used to store persistent information about your browser and Web server connection. Since HTTP requests are "connectionless" - one connection for every request - the cookie file is used to track information about the whole session with a server. This way a server can track information about you during your visit, by giving you a cookie. The cookie might typically track info such as which page you've been to or how you answered a question on a previous form. And due to the connectionless protocol, it keeps the cookie on the client.
This might not seem like a problem, but since Javascript can write information to the cookie file before it is sent to the server, limited information can be gathered about a user - typically, the email address. So, occassionally, the cookie.txt file will contain interesting information, usually not.
Here's an example of how the cookie file could be used here:
A user loads a page. It checks for its cookie in the cookie.txt file. If the cookie is there, the state the user left the page in last visit is restored (and we can jump to the last step). If no cookie is present, it is assumed the cookie is expired or it's the user's first visit. A default page is built for the user. The user clicks and selects stuff on the page. The user leaves the page. The cookie is updated with the changes made to the page.
The other important file is that pull-down menu in Netscape that showed the last 10 or so sites you've visited. This is typically located in the netscape.ini file in the [URL History] section. A clever Java applet could grab this information and ship it offsite, or if you've compromised a server where everyone has their config files in user directories, you can get to this information.
A couple of other directories that contain interesting files are the MAIL and NEWS subdirectories for Netscape. The MAIL directory will, of course, contain not only your inbox if you're using Netscape as your email application, but log every email sent out from your browser whether you are using Netscape for email or not. The file is typically called Sent, and is turned on for logging by default.
It is interesting to note that, while it is trivial to send fake email via Netscape (simply make the changes to the return address and send), the outgoing message is stored in the MAIL directory by default in most browsers. While fake email is still pretty easy to track down, having a copy of the message on your machine that you don't know about can be pretty damning evidence.
As stated in the previous section, the cookie file, "cookie.txt", is a file used to store information about your browser and Web server connection.
The limits (last time I checked, and I checked Netscape only) are as follows - you can only have 300 cookies total, each cookie has a limit of 4KB (which works out to about 1.2MB), a single site can only have a max of 20 cookies in your cookie.txt file, and a web server can only access a user's cookie if that cookie.txt entry contains the web server's domain.
A cookie entry has the following in it -
NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
The name is the name of the cookie, and the value is the value of the cookie itself. The expires date, if present, is when the cookie expires. If there is no expiration date then the cookie is only kept on the client during the current session. The path and domain indicate which URLs can access certain cookies, and the secure keyword is used when a cookie needs to be sent over a secure link.
So how do we access this info? Using Java (these examples will not work alone, call from your own Java program).
First let's retrieve a cookie by name:
// This function is used by the GetCookie function...
function getCookieVal (offset) {
var endstr=document.cookie.indexOf(";", offset);
if (endstr==-1)
endstr=document.cookie.length;
return unescape(document.cookie.substring(offset, endstr));
}
// ...and this function returns the requested cookie.
function GetCookie (name) {
var arg = name + "=";
var alen = arg.length;
var clen = document.cookie.length;
var i = 0;
while (i < clen) {
var j = i + alen;
if (document.cookie.substring(i, j) == arg)
return getCookieVal (j);
i = document.cookie.indexOf(" ", i) + 1;
}
return null; // return null if no cookie by that name
}
Now to set cookie information with this function:
// The first 2 args are used, the rest are optional. If you skip an
// arg give it a null value.
function SetCookie (name;value) {
var argv = SetCookie.arguments;
var argc = SetCookie.arguments.length;
var expires = (argc > 2) ? argv[2] : null;
var path = (argc > 3) ? argv[3] : null;
var domain = (argc > 4) ? argv[4] : null;
var secure = (argc > 5) ? argv[5] : false;
document.cookie = name + "=" + escape (value) +
((expires == null) ? "" : ("; expires=" + expires.toGMTString())) +
((path == null) ? "" : ("; path=" + path)) +
((domain == null) ? "" : ("; domain=" + domain)) +
((secure == true) ? "" : "; secure" + "");
}
Finally let's delete a cookie by name:
// This function uses the GetCookie function above.
function DeleteCookie (name) {
var exp = new Date();
exp.setTime (exp.getTime() -1); // set cookie to expire and browser will
// remove it at end of session
var cval = GetCookie (name);
document.cookie = name + "=" + cval + "; expires=" + exp.toGMTString();
}
Well, you could disable cache (or set its size to zero) but that would certainly hurt performance. Usually flushing your cache at the end of a session or before visiting a site that's unknown would be good. Setting your history file preference to zero or wiping the file at the end of the session is also okay.
Don't put stupid stuff in your bookmark file ;-)
You can edit your cookie.txt file, removing any cookies and then using your local operating system make the cookie.txt file read only.
Disable the logging of outgoing email messages, unless you don't have a problem with anyone reading them.
A site can learn a lot about you, even without Netscape or Java. Take a look at Anonymizer Privacy Analysis. With extra logging options, a site can log your OS, browser, e-mail address, hostname, and last site visited. This isn't using JavaScript, either. Some companies use this info to build mailing lists, and track all of this info. To prevent this, you could use Anonymizer's site as a "proxy" to surf anonymously. Instructions are at the anonymizer site, and it currently offers limited free service.
If most of this is Greek to you, and you simply read this FAQ because you are afraid of computer bad guys, go to Download.com and look for a product called Cookie Monster. This product allows you to clean up any or all of these files, and is fairly easy to use (some of us actually use Windows clients here).
Once again, review the Anonymizer web site at www.anonymizer.com.
If that does not convince you, check out the following web site:
http://www.iptvreports.mcmail.com/interception_capabilities_2000.htm
People *do* watch you.
Top | Next: Web Browser as Attack Tool | Previous: Miscellaneous Basics | Table of Contents