In association with heise online

21 February 2007, 15:31

Christiane Rütten, Tobias Glemser

Healthy suspicion

Web application security

Every website owner needs to reckon with attackers who may try to misuse their site for spam, phishing or other purposes. Web applications which use PHP or other scripting languages are especially vulnerable. Familiarity with common security vulnerabilities and attack methods can, however, help you fend off the bad guys.

Sub-topic: The PHP dilemma
Sub-topic: The most important security options in php.ini

It's not just operators of online shops and banking portals who need to worry about web application security. Smaller or private websites are increasingly becoming the targets of nefarious attackers on the internet. Not necessarily because there's money or confidential information to be had, but rather in order to misuse captured servers for their own purposes. They can be used to archive and swap pirated software, prepare distributed denial of service attacks or send out spam. Or attackers may manipulate web pages to infect other internet users with dialers or spyware.

Users who administer their own servers, for example who operate a root server, must ensure that they keep their server up to date and fix security vulnerabilities as they arise. But even users who have just rented a little webspace to share their photos with a few friends may be vulnerable. Image galleries, blogs or guestbooks - any type of dynamic content, whether it is programmed in PHP, Perl, Ruby or any other language, is a potential point of entry.

Cross-site scripting

The most common form of attack is called cross-site scripting (XSS). This involves an attacker attempting to manipulate a web application so that it embeds malicious script code in the page displayed to the user. The browser then processes the injected code as if it were legitimate content of the web page - with the corresponding security permissions. An attacker can, for example, use the embedded malicious code to pass off misinformation as real content on the web page being attacked, in order to steal passwords or account information (phishing).

image 1 [350 x 253 Pixel @ 38,3 KB]
The hacked Web application embeds the attacking code from the URL into their inquiry and "reflects" it back to the user.

There are three main types of XSS, depending on the way in which malicious code finds its way into the web page displayed by the browser. The most commonly encountered is called reflected XSS. This requires the attacker to persuade the victim to click on a prepared URL. The attacker conceals code in the variable parameters of this URL, which the vulnerable application receives server-side and embeds in the web page as apparent user names, e-mail addresses or search expressions. Almost all of the examples from bank and financial institution websites shown on hacker group Electrical Ordered Freedom's Phishmarkt website are current and of this type [1].

Also very common is stored or persistent XSS. Similar to reflected XSS, the server reflects the malicious code from the URL back to the browser as web content, but this time with a stop-over in the server database. The server may thus deliver the malicious code to other users, who have not clicked on a manipulated link - examples might include forum entries with embedded JavaScript. In this type of XSS, it is usually the attacker who only needs to click on a manipulated link once to upload malicious code onto the server.

image 2 [350 x 252 Pixel @ 46,7 KB]
If the attacking code reaches the server data base first, the victim does not even have to click on a manipulated link

In both reflected and persistent XSS, the flawed code that actually embeds the malicious code, runs on the server. In contrast, when the entire attack - from clicking on a manipulated URL to the embedding of malicious code in the web page - occurs on the user's computer, the attack is an example of local XSS. Web 2.0 applications, which shift a significant part of their functionality onto the user's browser as Java or JavaScript, are especially vulnerable to this third main type.

image 3 [350 x 252 Pixel @ 46,4 KB]
Particularly with Web-2.0 applications the entire attack can take place on the users computer. The server supplies the Browser only with the incorrect script, but not the attacking code.

The tree-like Document Object Model (DOM), which represents the complete website in the web browser, plays a special role, which is why this is also known as "DOM-based XSS". By accessing the DOM tree, an application can make dynamic changes to the web page being displayed, for instance, for interactive web applications. In DOM-based XSS, a flawed browser-side application script copies the malicious code directly from the URL by accessing the DOM in the web page being displayed. In principle, this dispenses with going through the server, which merely supplies the HTML and the flawed application code.

Print Version | Permalink:
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit