January 09, 2014

3.2.18 Client-Side Attacks

Client-side attacks

Because that’s where the money is. – Quote apocryphally attributed to bank robber Willie Sutton when ask why he robbed banks.

People create structures to provide security from attack for their persons and property. As with most security mechanisms, it becomes an “arms race”; the attacker devising increasingly sophisticated measures to penetrate the defense and the defenders improving their security profile to repel the penetration attempts.

Nomadic humans first formed camps as a way leverage resources and protect each other from attacks by marauders and other hostile forces. As the attacks against the camps became more sophisticated, the protections evolved to repel the threat. The camps evolved into forts, forts became castles, castles grow into fortified towns, etc. At each stage, the strength of the fortification becomes a deterrent to the attacker who then cast about for more effective penetration techniques or an easier target.

In computing, the server is the fortified structure created to serve and protect data and services. As the target of attacks, it may be initially vulnerable, however it eventually improves defenses enough that most attackers begin looking for easier targets.

Using a castle analogy, if one cannot breach the castle walls to plunder its resources, the next best thing is to intercept it before it reaches the castle. This is the equivalent of the client-side attack.

As server-side resources, i.e. resources stored on the server, become increasingly difficult to access due to improved processes and security advances, malicious users instead direct their attacks against the less well-defended client devices and applications. I.e. they moved from attacking the server to attacking the client.
An Exaggerated View of Server-Side & Client-Side Security
A client can be a standard web browser such as Internet Explorer or Google Chrome or it can be an embedded browser object in an application such as an email client, media players, e-book reader, etc.

Servers are juicier targets for the malicious user as they contain the data sought by the malicious user and because servers are naturally designed to make information available to users.

Web servers, database servers, mail servers, streaming video servers, etc. all contain data they want to make available to users. The trick is to increase the defenses of the server enough that the strategic value of the data is less than the cost of measures needed to penetrate it.

Servers are improving their defenses, encouraging attackers to turn increasingly to client-side attacks.

Two reasons why client applications are more inviting targets for attackers include:
  • Clients generally undergo less rigorous security testing than server applications
  • Clients are more difficult to patch due to the diverse range of client versions, owners and environments
Executing code at the client, such as by embedding JavaScript in HTML pages, makes dynamic and interesting content possible. An example is the page interactivity possible in Google Maps. However these capabilities add complexity and introduce the potential for security vulnerabilities into the application.

“Cross-site scripting (XSS) is a vulnerability that permits an attacker to inject code (typically HTML or JavaScript) into contents of a website not under the attacker's control. When a victim views such a page, the injected code executes in the victim's browser.”‡

Cross-site scripting or XSS is a type of client-side attack. XSS takes advantage of interactions between the client and server to exploit any resulting vulnerabilities.

What does the “cross-site” in cross-site scripting mean? A good explanation is the one from apache.org, “It was coined earlier on when the problem was less understood, and it stuck.”

Cross-Site Scripting is an attack technique that embeds malicious code into a user’s browser instance. When the malicious code is triggered, it executes on the client-side (i.e. in the user’s browser) and is generally used to add, modify or delete data. The malicious code can be in one of various script languages including Java, JavaScript, VBScript, ActiveX.

When running in the local browser instance, the malicious code the privileges of the user, as such it has the ability to access and modify potentially sensitive local user data. Via XSS a malicious user can take control of the session between the browser and a website, and access sensitive data or redirect the browser to a malicious web site.

Categories of XSS

There are several recognized categories of XSS attacks including: Stored XSS, Reflected XSS, Cross Site Request Forgery (CSRF), Cross-Site Tracing (XST) and DOM-based XSS. In this article we will look at Stored and Reflected XSS.

XSS vulnerability is introduced when a web site accepts input from the client without first validating that the data is “clean”, i.e. in the format it was expecting and also when the web site outputs data to the web client without sanitizing it, i.e. removing or masking any potentially dangerous code.

When an attacker discovers a server that is not validating or sanitizing data, it will send the server malicious data, e.g. by filling out a form with input that is a script instead of simply text. Since the server is not doing input validation, it either incorrectly stores the script in its database where it gets executed by the next user accessing the database or it gets reflected back to the browser.

Stored XSS Attacks – are those where the code to exploit the vulnerability is permanently stored on the target servers (typically in a database) and can be retrieved to create pages sent to any user visiting the site. The victim retrieves the injected script from the server when it requests the stored information.

Forums and blogs that allow the use of HTML and that store information in databases are potentially vulnerable to this form of exploit. Protecting against stored XSS exploits involves input validation and output sanitization, i.e. translating the elements such that it will not be interpreted by the browser as code.

Stored Cross-Site Scripting is also known as Persistent Cross-Site Scripting.

Reflected XSS Attacks – are those where the attack is in the request itself and the vulnerability occurs when data submitted by the client is processed by the server and sent back (reflected) to the browser without first being properly encoded or sanitized. The Reflected XSS attack begins when a victim visits a URL with the embedded malicious script. The malicious URL can be distributed in the form of an email sent by the attacker. An exploit is successful when the:
  • victim loads the malicious code in his/her browser
  • code gets sent to the server listed in the URL
  • server “reflects” the malicious code back to the browser embedded in the response, (such as an error message or search result)
  • browser dutifully renders the malicious code (as it came from a “trusted” web site)
  • malicious code does its work
Step #0 of this exploit is finding a web server that processes raw HTML on input without scrubbing or filtering and on output without encoding or sanitization.

XSS exploits can perform various malicious activities for the attacker, including:
  • steal information in script variables
  • set or read information in cookies
  • send requests to a server as the user
  • redirect to another site
  • modify displayed content
  • send captured data to another site
  • log keystrokes, capture camera data, etc.
Unlike with Stored XSS where the malicious code is persistently stored on the server and activated by any visitor to that page, the Reflected XSS is commonly delivered via phishing attacks or via a compromised web site.

The attacker may attempt to evade detection by encoding portions of the malicious script in hexadecimal characters, making it less like a script and less suspicious.

A Cross-Site Scripting (XSS) vulnerability arises when Web applications take data from users and dynamically include it in Web pages without first properly validating the data.†

Minimizing the vulnerability of Stored and Reflected XSS involves following web good coding practices such as validating, filtering or scrubbing input at the server-side and by sanitizing or encoding output before execution at the browser-side. If input data is not validated, malicious script can be inserted into the page that is sent back to the browser where it runs in a trusted context.


No comments:

Post a Comment