“A Man’s Home (Page) is His Castle”
By: Carlisle Adams
November 28, 2006
Many of us have probably heard the saying “a man’s home is his
castle”. (By way of parenthetical footnote, let me just mention that I
could not find an elegant way to make this old adage gender-neutral:
“an [(unspecified gender) entity]’s home is [(unspecified gender)
possessive pronoun] castle”. Therefore, for the purposes of this
article, I will just state up front that “man” and its variations
should be taken to mean “man or woman” and their corresponding
variations, and hope that this satisfies any sensitivities in this
area.) This saying has been around for quite some time and most people,
I think, would probably have some intuitive understanding of its
meaning upon hearing or seeing it. However, given some of the new
terminology with which we have become accustomed in our Internet age
(particularly, “home page”), it may be interesting to explore whether
this saying has any relevance in our digital virtual world.
Traditionally, a castle (the residence of a king) has been
associated with at least four concepts: protection; identity; privacy;
and control. With respect to “protection”, the castle provides a
fortress, a stronghold, security from invaders of all kinds. “Identity”
suggests ownership, permanence and, at least at some level, a way of
authenticating oneself (“I am the king because I have the key to the
drawbridge, or because the guard will let me in when I show up”). In
terms of “privacy”, the castle is a means of keeping its inhabitants
and their discussions away from prying eyes and ears, so that secrets
are prevented from flowing out to the general public. The castle also
gives a sense of “control” in that the king has ultimate authority over
certain aspects of the domain (e.g., the power to decide content and
activity within the walls).
When it is said that a man’s home is his castle, the analogy is
clear: with his home, the man gets – or at least expects – a measure of
protection, a sense of identity, some level of privacy, and a degree of
control. So now, out of curiosity if nothing else, one can ask, when we say today that a man has a home page, is the analogy as clear, or is it stretched so thin as to be fragile and useless?
Let’s consider the above four associations with the term “castle” to
see how well they apply to our digital (rather than physical) homes.
Protection. When Bob sets up a Web server and
creates on that server a home page for himself, does he have the
security from invaders that a castle might provide? Even a superficial
awareness of security issues with websites over the past few years will
confirm that the answer is “no”: attackers break into websites every
day all over the world to enter, change, or steal data. Well-known
buffer overflow or SQL injection attacks are commonly used to break
into websites to cause damage. If a website is expecting some user
input (such as a username and password), the attacker may send far more
data than the buffer allocated to receive this data can hold (a
password of 10,000 characters, for example). This input data may “spill
over” beyond the buffer into another area of memory. If the overflow
area is a place where instructions are executed, and if the overflow
characters are carefully constructed to be valid executable
instructions, then this attacker will have succeeded in having
arbitrary code of his choosing run on Bob’s machine. This is the
essence of a buffer overflow attack. With SQL injections, the attack is
similar in that data input by the user contains some extra, unexpected
characters and these characters are treated as commands to the SQL
database that sits behind Bob’s webpage.
If Bob has routines that do proper input data validation (e.g., make
sure that the username that has been entered is really a username and
is not longer than a specified value), he may be able to avoid some of
these attacks, but it is not always easy to distinguish an attack
script from valid data. Unfortunately, the conclusion is that unless he
puts extensive effort into setting up particular safeguards, Bob’s home
page gives him very little protection from the malicious entities that
live outside his “virtual walls”.
Identity. Is Bob’s home page a valid mechanism for
showing ownership and authenticating himself? The answer to this
question is also negative. Webpage spoofing attacks are not very
difficult to perform and can be fairly successful. Making an identical
copy of an existing webpage is almost trivial (it is essentially a
copy-and-paste operation to move every image, every piece of text,
every logo, etc., from one webpage to another. The (slightly trickier)
step is to get other people to go to the new site while thinking that
they’re going to the old one. This can be accomplished using a
technique called DNS cache poisoning. The Domain Name Server (DNS) is a
machine that performs an important service on the Web: you give it a
host name (such as bob.com) and it gives you back the IP
address of that host machine (such as 192.12.567.30). This way, your
computer can communicate with that machine using the Internet Protocol
(IP). The data pair {bob.com, 192.12.567.30} is stored in the
DNS cache (a fast portion of its memory). Cache poisoning is an attack
in which that the attacker changes the data pair so that bob.com is
instead associated with a different (i.e., the attacker’s) IP address
in the DNS cache. Now everyone that wants to go to Bob’s machine will
send bob.com to DNS, get back the attacker’s IP address, and
then go to the attacker’s website, which has been made to look
identical to Bob’s site. Thus, the attacker gets Bob’s customers (their
money, or their personal data), and Bob has no way of knowing that this
has occurred.
If Bob’s machine is a Web server, technologies such as SSL server
authentication can help, but they provide no guarantee: users often do
not check that the certificate of the site they have reached is the one
they’re expecting, and often ignore warnings in pop-up windows even if
they do check. In general, website spoofing means that Bob’s home page
is not sufficient to prove ownership or to validate or authenticate Bob
in any way.
Privacy. Does Bob’s home page give him a private
place to store his personal and confidential information? At first
glance, this seems like an odd question to even be asking: the Internet
is a public space and Internet search engines (such as Google) will
find a website once it exists (this is what they were invented to do).
The idea of putting something on a website and expecting it to be
private is a bit like building a house with glass walls and expecting
that others will not see what goes on inside. However, it is possible
to create private spaces within a website; typically, these are
password-controlled areas (anyone with the password can view the page,
and all others are redirected to another page telling them that they
are not authorized to see the contents). But the problems with
passwords as an authentication mechanism are extremely well-known and
well-documented. Compounding this is the fact that the site owner
usually wants a number of people to access these areas (friends,
family, students in a course, etc.) and so will deliberately choose a
password that will be easy for that group of people to remember. It may
therefore be conjectured that the passwords used to protect these areas
are probably even weaker than typical passwords, which are notoriously
weak in many cases.
It is unlikely to be the case that Bob’s home page will be a safe place for his private data.
Control. Does Bob have authority over his home
page? Does he have the power to decide content and activity? Again we
see that the answer to this question is negative. Website defacement
(in which a hacker changes the content or appearance of a target
website, altering or inserting messages, pictures, or other data) shows
that owners do not really have complete power over the content on their
sites. Furthermore, session hijacking attacks (in which a hacker takes
over an active session and begins interacting with the server as if he
was the original client, or interacting with the client as if he was
the original server), buffer overflow attacks, SQL injection attacks,
and so on, demonstrate that the site owner may also have little power
over the activities that take place on his site.
Integrity detection / protection mechanisms, intrusion detection /
protection mechanisms, and good session management practices can all
help but these are hard to do well and, again, unless Bob takes
extensive efforts to defend his website, he will not have the control
over content and activity that he might wish to have.
Where do we go from here?
OK, so home pages don’t really have any of the properties we might
associate with homes. But “home” and “home page” are just names; what
difference does any of this make? At this point, it may be tempting to
pull out another old saying: What’s in a name? That which we call a rose by any other name would smell as sweet
[1]. There may be much truth in this (after all, Shakespeare was right
about a great many things!), but we need to exercise a little caution.
The danger lies not in using two different names for the same thing,
but rather in using the same name (or very similar names) for two
different things: “home” and “home page”. All the security (i.e.,
protection, privacy, identity, and control) we associate with our home
does not translate immediately to our home page. Although there are
some similarities (locking the front door with a key is something like
password-protecting the website), there are some major differences as
well (for example, website spoofing: the attacker makes an exact
replica of your house and fools your family and friends into going
there when they want to visit you? Nothing in the real world (outside
the “twilight zone” [2]) corresponds to this). Using essentially the
same term (“home” and “home page”) could lead the unsuspecting user to
think that similar behaviour – both precautions and activities – are
appropriate, when in fact this is not the case.
I am not advocating that we should call home pages something else
(it’s far too late for that sort of change, although “start page” might
have been a good choice that is free of other associations). But I am
suggesting that this could serve as a reminder to us that we need to be
careful when naming things in our created virtual worlds. Choosing
names that are familiar (so that people will more readily identify with
the technology and feel comfortable using it) can have unintended
consequences (including behaviour that is inappropriate because the
technology is not as much like its real-world name-sake as the
appellation might imply). Let this be a lesson to us: choosing names
for concepts should not be taken lightly; we need to think through the
connotations of the names we pick and consider whether this may lead to
security or privacy problems down the road.
So, a man’s home (page) is his castle? Not really; not in the new Wild West of cyberspace…
References
[1] Romeo and Juliet, Act II, Scene 2.
[2] http://www.scifi.com/twilightzone/
|