This chapter is from the book

This chapter is from the book

Client-Side Attacks

The Client-Side Attacks section focuses on the abuse or exploitation of a web
site’s users. When a user visits a web site, trust is established between
the two parties both technologically and psychologically. A user expects web
sites they visit to deliver valid content. A user also expects the web site not
to attack them during their stay. By leveraging these trust relationship
expectations, an attacker may employ several techniques to exploit the user.

Content Spoofing

Content Spoofing is an attack technique used to trick a user into believing
that certain content appearing on a web site is legitimate and not from an
external source.

Some
web
pages
are
served
using
dynamically
built
HTML
content
sources.
For
example,
the
source
location
of a
frame
(<frame
src="http://foo.example/file.html">)
could
be specified
by a
URL
parameter
value
(http://foo.example/page?frame_src=
http://foo.example/file.html).
An attacker
may
be able
to replace
the frame_src parameter
value
with frame_src=http://attacker.example/spoof.html.
When
the
resulting
web
page
is served,
the
browser
location
bar
visibly
remains
under
the
user-expected
domain
(foo.example),
but
the
foreign
data
(attacker.example)
is shrouded
by legitimate
content.

Specially crafted links can be sent to a user via email, instant messages,
left on bulletin board postings, or forced upon users by a Cross-site Scripting
attack. If an attacker gets a user to visit a web page designated by their
malicious URL, the user will believe he is viewing authentic content from one
location when he is not. Users will implicitly trust the spoofed content since
the browser location bar displays
http://foo.example,
when in fact the underlying HTML frame is referencing
http://attacker.example.

This attack exploits the trust relationship established between the user and
the web site. The technique has been used to create fake web pages including
login forms, defacements, false press releases, and so on.

Content Spoofing Example

Let's
say
a web
site
uses
dynamically
created
HTML
frames
for
their
press
release
web
pages.
A user
would
visit
a link
such
as http://foo.example/pr?pg=http://foo.example/pr/01012003.html.
The
resulting
web
page
HTML
would
be

The pr web application in the preceding example creates the HTML
with a static menu and a dynamically generated FRAME SRC. The
pr_content frame pulls its source from the URL parameter value of
pg to display the requested press release content. But what if an
attacker altered the normal URL to
http://foo.example/pr?pg=http://attacker. example/spoofed_press_release.html?
Without properly sanity checking the pg value, the resulting HTML would
be

To
the
end
user,
the attacker.example spoofed
content
appears
authentic
and
delivered
from
a legitimate
source.

Apache Countermeasures Against Content Spoofing

In order to properly validate the "pg" value shown in the preceding
example, we can create an inverted Mod_Security filter to deny all URLs
that are not referencing data from our own site. The following filter will
accomplish this task:

SecFilterSelective Arg_pg "!^http://foo.example"

References

Cross-Site Scripting

Cross-site Scripting (XSS) is an attack technique that forces a web site to
echo attacker-supplied executable code, which loads in a user’s browser.
The code itself is usually written in HTML/JavaScript, but may also extend to
VBScript, ActiveX, Java, Flash, or any other browser-supported technology.

When an attacker gets a user’s browser to execute his code, the code
will run within the security context (or zone) of the hosting web site. With
this level of privilege, the code has the ability to read, modify, and transmit
any sensitive data accessible by the browser. A Cross-site Scripted user could
have his account hijacked (cookie theft), his browser redirected to another
location, or possibly shown fraudulent content delivered by the web site he is
visiting. Cross-site Scripting attacks essentially compromise the trust
relationship between a user and the web site.

There are two types of Cross-site Scripting attacks: non-persistent and
persistent. Non-persistent attacks require a user to visit a specially crafted
link laced with malicious code. Upon visiting the link, the code embedded in the
URL will be echoed and executed within the user’s web browser. Persistent
attacks occur when the malicious code is submitted to a web site where
it’s stored for a period of time.

Examples of an attacker’s favorite targets often include message board
posts, web mail messages, and web chat software. The unsuspecting user is not
required to click on any link, just simply view the web page containing the
code.

Cross-Site Scripting Examples

Persistent Attack

Many web sites host bulletin boards where registered users may post messages.
A registered user is commonly tracked using a session ID cookie authorizing them
to post. If an attacker were to post a message containing a specially crafted
JavaScript, a user reading this message could have their cookies and their
account compromised. This is shown in the following cookie-stealing code
snippet:

Non-Persistent Attack

Many web portals offer a personalized view of a web site and greet a
logged-in user with "Welcome, <your username>." Sometimes the
data referencing a logged-in user are stored within the query string of a URL
and echoed to the screen. Here is a portal URL example:

?http://portal.example/index.php?sessionid=12312312&username=Joe

In the preceding example, we see that the username Joe is stored in
the URL. The resulting web page displays a "Welcome, Joe" message. If an
attacker were to modify the username field in the URL, inserting a
cookie-stealing JavaScript, it would be possible to gain control of the
user’s account.

A large percentage of people will be suspicious if they see JavaScript
embedded in a URL, so most of the time an attacker will URL encode his malicious
payload similar to the next example. The following is a URL-encoded example of a
cookie-stealing URL:

Apache Countermeasures for Cross-side Scripting Attacks

Client-side attacks such as XSS are extremely difficult to fully prevent from
the web server side. This is the old chicken or the egg debate with regard to
diagnosing who is responsible for a successful XSS attack. In order to be
successful, both the web server and the client browser play a critical role.
From the web server’s perspective, they are responsible for the portion of
this attack that allows an attacker to submit XSS data and then submit it back
to other clients. So, we can help to mitigate the effectiveness of most XSS by
identifying and blocking the attacker’s attempts to upload the XSS data.
As mentioned in a previous section, we can implement different
Mod_Security filters to identify XSS data being uploaded to the server.
Here are some additional filters:

Although these filters will detect a large number of XSS attacks, they are
not foolproof. Due to the multitude of different scripting languages, it is
possible for an attacker to create many different methods for implementing an
XSS attack that would bypass these filters.