This shortcoming is exploited by cross-site scripting attacks (XSS) . Such an
attack uses a ‘trusted’ server, i.e. a server with more access rights than those
granted to the attacker, as a stepping stone. A malicious script might be placed
directly in a page on the trusted server (stored XSS, e.g. via a bulletin board). In
another version of XSS the script is hidden in a form in a page on the attacker’s
server. When a victim visits this page a request that contains the hidden script
as a query parameter is automatically sent to the trusted server. Should the
server mirror this query parameter back to the victim (e.g. in a response to a
search) the script is executed in the victim’s browser with the access rights of the
trusted server (reflected XSS). XSS can be used, for example, to steal cookies
from the client.
Authentication of origin has failed as it did not correctly capture the true
origin of the attacker’s contribution to the page received from the server. Crosssite
request forgery attacks targeting a server follow a similar principle [4]. The
server has to ‘trust’ a client, i.e. there has to be an authenticated session (more
on this in section 5) where the client has more access rights than those granted
to the attacker. The attacker manages to send actions to the server within this
session, which are then executed with the access rights of the client.
Client and server could perform authentication at the application layer to
defend against this type of attack, rather than relying on the infrastructure
provided by browsers and web servers. So-called XSRF prevention tokens are
message authentication codes for actions computed from a shared secret that
had been established when the session was created. It is essential to store this
secret at the client side in a place out of reach for an attacker able to circumvent
the browser’s origin based security policies. Once more, the application takes care
of security and does not rely on a security service provided by the infrastructure.
