screen. The developer may tack on
file was loaded successfully or contained an error:
If the image file loaded correctly, then
executes. If an error occurred, then
the error function executes. This code
is completely typical and innocuous,
but the same functionality can also be
leveraged for invasive, malicious ends.
Now, let’s say http://coolwebsite/
loaded an image file from http://
someotherwebsite/, but that image file
is accessible only if the user’s browser
is currently logged into http://someo-therwebsite/. As before:
If the user is logged in, then the
image file loads successfully, which
causes the executions of loggedIn.
If the user is not logged in, then not-LoggedIn is executed. The result is
an ability to test easily and invisibly
whether a visitor is logged in to a particular website that a Web developer
does not have a relationship with. This
login-detection technique, which leverages CSRF, can be applied to online
banks, social networks, Web mail, and
basically anything else useful to an
attacker.Th e attacker behind http://
coolwebsite/ just has to find the URLs
that respond in a Boolean state with
respect to login.
Next, consider that a malicious
website owner might want to go one
step further and “deanonymize” a
Web visitor, which is to say, learn the
visitor’s real name. Assume from the
previous example that the attacker
can determine if the visitor is logged
into Twitter, Facebook, Google+,
among others. Hundreds of millions
of people are persistently logged in
to these online services every day.
These websites, and many like them,
are designed that way for convenience purposes.
The next thing an attacker could
take advantage of is those familiar
third-party Web widgets, such as Twit-
ter’s “Follow,” Facebook’s “Like,” and
Google’s “+ 1” buttons.
Depending on the detectable response given from the IP address,
the attacker can use the Web visitor’s
browser to sweep internal private networks for listening IP Web servers.
This sweeping can locate printers, IP
phones, broadband routers, firewalls,
configuration dashboards, and more.
The technique behind browser intranet hacking is similar to the Bool-ean-state detection in the login-detection example. Also, depending on
whether the user is logged in to the IP/
Hostname, this type of attack can force
the visitor’s browser to make configuration changes to the broadband router’s Web-based interface through well-known IPs (192.168.1.1, 10. 10.0.1, and
so on) that can be quickly enumerated.
The consequences of this type of exploitation can be devastating as it can
lead to all traffic being routed though
the attacker’s network first.
Beyond login detection, deanony-mization, and browser intranet hacking are dozens of other attack techniques possible in today’s modern
browsers. For example, IP address geo-location tells, roughly speaking, what
city/town a Web visitor is from. The us-er-agent header reveals which browser
distribution and version the visitor is
Document Object Model) objects make it
trivial to list what extensions and
plugins are available—to hack or fingerprint. DOM objects also reveal
screen dimensions, which provides
demographic context and whether the
user is using virtualization.
The list of all the ways browser security can be bent to a website owner’s
will goes on, but the point is this: Web
browsers are not “safe”; Web browsers are not “secure”; and the Internet
has fundamental flaws impacting user
(personal or corporate) security.
Now here’s the punch line: the only
known ways of addressing this class of
problem adequately is to “break the
Web” (that is, negatively impact the
usability of a significant percentage
of websites). These issues remain because Web developers, and to a large
extent Web users, demand that certain
functionality remain available, and
that functionality is what makes these
Today’s major browser vendors,
whose guiding light is market share,