[WEB4LIB] Re: "Hijacking" Websites

Shirl Kennedy skenned1 at tampabay.rr.com
Thu Sep 23 22:44:03 EDT 1999


http://www.w3.org/Security/Faq/wwwsf7.html#Q68
WWW Security FAQ
Q68: Can one Web site hijack another's content?

There are many variants of this question, and the answer to them all is yes.
If a site publishes public (not password-protected) pages on the Web, there
is nothing to stop anyone who wants to from copying the entire site and
setting up a server that uses the pirated content. It is surprisingly easy
to do this; there are many Perl "spiders" that will copy an entire site with
a single command, and even Internet Explorer has a simple built-in spider.
Sometimes this activity is legitimate, such as when someone sets up a mirror
site of a public document (for example, the the WWW Security FAQ is mirrored
in this way), but sometimes it is out-and-out piracy.

The implication of this is that you should be a little careful about
trusting what you see on the screen. Popular sites often are surrounded by
non-affiliated sites with similar names that exploit peoples' tendency to
make typographical errors when entering URLs. For example, try
http://www.nescape.com or http://www.mcrosoft.com/. Always check
double-check the URL of the site you are accessing before submitting
personal or confidential information to it.

Although difficult, it is possible in some cases for a site to temporarily
"spoof" the domain name system so that a URL points to the wrong server. In
this case both the URL and the content will like right, but the server you
are communicating with is not the one you think it is. If the site uses SSL,
one way to confirm its identity is to check the site's digital certificate
as described in Q58. If the site is supposed to be using SSL, but isn't,
this is a cause for suspicion.

However, even when the URL and certificate agree you cannot always be sure
that a page contains the content approved by the Web site. In November 1998,
a breathtaking flaw came to light in the implementation of frames in recent
versions of Netscape Navigator and Microsoft Internet Explorer. By
exploiting this bug, a malicious Web site can insert its own content into
one or more frames of a trusted Web site. This will make the content appear
to be coming from the trusted site, but in actually it comes from a
untrusted third party. The URL will appear to be correct, and not even the
digital certificate can be used to tell otherwise! This bug is described in
the following URLs:

http://tbtf.com/archive/11-17-98.html
http://www.securexpert.com/framespoof/index.html
http://www.securexpert.com/framespoof/start.html
http://www.securexpert.com/framespoof/tech.html

A related question frequently asked by Webmasters is how to prevent their
material from being hijacked. If the concern is that someone will copy a
public document across the Internet and then uses it for their own ends, the
sad answer is that there is no way to avoid this. However, there are a
number of techniques for digitally "watermarking" copyrighted images, sound
samples, and other binary formats in order to discourage their use and to
prosecute offenders. For collections of links to products that offer this
technology, see the Bilderbank digital watermarking pages, and Alessandro
Piva's digital watermarking pages.

If, on the other hand, the concern is that unscrupulous sites are linking to
your CGI scripts and images without authorization, essentially freeloading
on your site, then you may be able to prevent this by using the Referer
field to restrict access. This requires you to have a Web server that can
filter requests based on arbitrary HTTP request fields. You will want to
allow requests by older clients that have no Referer field defined, and
those whose Referer field points back to one of your site's pages. Clients
whose Referer field is from an unrelated site are refused acccess. This will
prevent remote sites from using your site as the target of their <IMG> and
<FORM> tags.

The Apache Web server, when equipped with the optional mod_rewrite module,
can accomplish this with the following series of directives:

RewriteCond %{HTTP_REFERER} !^$                        # Referer field
exists
RewriteCond %{HTTP_REFERER} !^http://my.site.com/ [NC] # and not my site
RewriteRule [^/]+\.(gif|jpg)$   -                 [F]  # No access to images
RewriteRule ^/cgi-bin/.+$       -                 [F]  # No access to
CGIs

See your vendor's documentation to determine whether the Web server you use
provides this capability.

Shirl Kennedy
Web Doyenne
City of Clearwater (Florida)
http://www.clearwater-fl.com

We are not afraid to entrust the American people
with unpleasant facts, foreign ideas, alien philosophies,
and competitive values. For a nation that is afraid
to let its people judge the truth and falsehood in an
open market is a nation that is afraid of its people.
     -- John F. Kennedy








More information about the Web4lib mailing list