Web Application Security By Wilson Wong

Introduction

In the past, security measures were often focused on the system level (which included networks, operating systems, web servers, and database servers). People may think their websites are safe from hackers if they have a "perfectly" secured system. This may be true if their websites provide only static information without accepting any input from users.

As you may know, most websites (or web servers) today provide dynamic contents, that is, the web applications run on these websites accept and process users' input, upon which web contents, consisting of both executable codes (script) and/or data, will be generated dynamically on-the-fly and sent to clients' web browsers for execution and/or display. And, most of the time, these executable codes work with backend database server to provide dynamic contents. Then what are some common web application security flaws under these kinds of environments?" Can a hacker use these security flaws to fool the web application on a web server to delete all the data of its database or implant some codes in the web server to infect the users' PCs or to trick the users at the client browsers to send in their bank accounts and passwords? We will try to answer these questions below. It is suffice to say here that even though one can perfectly secure his/her website at the system level yet if security loopholes exist at the web application level, it is still relatively easy for hackers to perform the forgoing damages.

The awareness of web application security is increasing as more and more security incidents have been reported at the web application level. Several technical initiatives, such as OWASP, OASIS, and WASC, have been formed to address the causes of insecure web applications and to establish an open standard for web application security.

Web Application Vulnerabilities

There are over 300 issues that affect the overall security of a web application. These 300+ issues are detailed in the OWASP Guide. But in short, the root cause that leads to web application security problems is poor web application design and programming approach. With the rapid change of the internet world, developers are usually urged to finish programming in a short period of time. Coding that handles security issues are often overlooked. Furthermore, the occurrences of programming errors may also increase with the growing demand on the functionalities of websites, to which a variety of new services are constantly sought to be added.

Knowing the vulnerabilities and their causes are important for developers and content managers to maintain secure websites. We will briefly discuss two of the top web application vulnerabilities here. Interested users may also refer to the OWASP website where the topic is discussed in great depth.

1. Cross-site scripting (XSS)

The first vulnerability we are going to discuss is called Cross-site Scripting (XSS). It is in fact an HTML code (in most cases are codes with JavaScript) injection. XSS vulnerabilities are found in web applications that accept users' input to generate HTML pages dynamically for the client browser without first filtering illegal input or without properly encoding the input to prevent the client browser from interpreting them as executable codes. Thus one way to allow hackers to make use of XSS vulnerability to embed malicious scripts into the generated web page is through injecting the data input with executable codes rather than pure non-executable data. Once people visit the page, the data, which in fact are scripts, will be executed on their workstations where the client browsers reside.

XSS can generally be divided into two categories: reflected and stored attacks. Reflected XSS is found on a page which reflect a user's input string directly back to the user. Take ASP as an example, such page usually contains a line of code like

Response.write Request("user_input")

Consider if one enter a string of JavaScript, like

<script>alert('XSS has been found');</script>

The generated page will contain the JavaScript and will be executed on the user's web browser. Via a malicious link within a malicious email, say, people may unintentionally visit the link and execute the injected malicious scripts on their workstations.

By inserting appropriate codes, hackers may do the followings:

• Account hijacking — Hackers can hijack a user's session before the session cookie expires and take actions with the privileges of the user who accessed the URL, such as issuing database queries and viewing the results.
• Worm propagation — With Ajax applications, XSS can propagate somewhat like a virus. The XSS payload can autonomously inject itself into pages, and easily re-inject the same host with more XSS, all of which can be done without hard refresh. Thus, XSS can send multiple requests using complex HTTP methods to propagate itself invisibly to users.
• Information theft — Via redirection and fake sites, hackers can connect users to a malicious server and capture information entered by users.
• Denial of Service — By using malformed display requests on sites that contain XSS vulnerabilities, hackers can cause a denial of service by causing the host site to query itself repeatedly.
• Manipulation of user settings — Hackers can change user settings for nefarious purposes.

Stored XSS is quite similar but users' inputs are stored in files or databases and at a later stage, they are extracted and used for generating web contents. Typical examples are blogs and forums, where a large number of users may view the input of other participants.

In summary, the XSS attack, as one of the security experts puts it: " is a privacy violation that allows an attacker to acquire a legitimate user's credentials and to impersonate that user when interacting with a specific website. The attack hinges on the fact that the web site contains a script that returns a user's input (usually in the form of parameter values) in an HTML page, without first sanitizing the input. This allows an input consisting of JavaScript code to be executed by the browser when the script returns this input in the response page. As a result, it is possible to form links to the site where one of the parameters consists of malicious JavaScript code. This code will be executed (by a user's browser) in the site context, granting it access to cookies that the user has for the site, and other windows in the site through the user's browser."

XSS attacks can be avoided by carefully validating and encoding users'  input. Allowing only a strict pattern of input from users is an important key to secure web applications. Developers should also encode users' input in order to ensure any scriptable contents are converted to plain text when used for generating web contents. Encoding users’ input can be done by using standard controls of the corresponding language. Take VB.NET as an example, encoding can be done by the function HttpUtility.HtmlEncode. (Sample codes are shown below.)

Dim encoded_input As StringBuilder = New StringBuilder( _
    HttpUtility.HtmlEncode(user_input))
encoded_input.Replace("&lt;b&gt;", "<b>")
encoded_input.Replace("&lt;/b&gt;", "<b>")
encoded_input.Replace("&lt;i&gt;", "<i>")
encoded_input.Replace("&lt;/i&gt;", "</i>")
Response.Write(encoded_input.ToString())

2. SQL Injection

Another software vulnerability is called SQL injection. It is a method of attack which uses invalidated input data to exploit vulnerable codes of a web application to extract, modify, and/or damage the database that is connected with the web application.

Consider a login form of a website and its application behind is making use of users’ input to build a dynamic SQL statement without input validation. The web application will have a line of code looks like:

sqlcommand = "SELECT * FROM users WHERE username = '" +
    form.username + "' AND password = '" + form.password + "'"

The above statement will work without problems for a normal user who input his/her username and password in the form. But what if a hacker input your username, say "paul_chan", to the username field and input a string like

0' or '1' = '1

to the password field?

The SQL statement above will become

SELECT * FROM users WHERE username = 'paul_chan' AND
    password = '0' or '1' = '1'

Execution of this SQL statement will return the record of "paul_chan", allowing the hacker login to your account successfully without knowing your password. In certain circumstances, SQL Injection can even be used to take complete control of a system!

To prevent from SQL Injection attacks, the best practice is to make use of parameterized queries. Take VB.NET as an example again, the code should look like:

Dim sqlCmd As SqlCommand = New SqlCommand( _
    "SELECT * FROM users WHERE username=@uid _
    AND password=@pwd", conn)
Dim param_uid As SqlParameter = New SqlParameter( _
    "@uid", SqlDbType.VarChar, 50)
Dim param_pwd As SqlParameter = New SqlParameter( _
    "@pwd", SqlDbType.VarChar, 50)
param_uid.Value = Request.QueryString("username")
param_pwd.Value = Request.QueryString("password")
sqlCmd.Parameters.Add(param_uid)
sqlCmd.Parameters.Add(param_pwd)

In this way, users’ input will not be used to construct the SQL command. Any string that a hacker input will be completely inserted as a parameter. An error would still be generated, but it would be a simple data-type conversion error, and not something that a hacker could exploit. Developers can even insert simple error exception checking statements to prevent error messages from displaying on the web.

The Solution: A Web Application Scanner

Three approaches are required for maintaining secure web applications: Web application scanner to find out embedded vulnerabilities, web application firewall to protect web security real-time and web application code scanner for developers to develop safe web applications. Below is a description of one of the approaches CityU has employed to improve web security.

Although good programming practices can greatly improve application security, it is still hard to guarantee that an application is completely free of software vulnerabilities. Furthermore, a large number of web-based applications and the software libraries they use were written years ago. It is difficult to ask the original developers to check and see if the codes are secure. If employing other programmers to do the job, they may need to trace all the codes from the beginning to end in order to search for security loopholes. The manpower involved is enormous. Besides, many of CityU’s departmental web applications were written by research assistants or even students. Most of them have already left CityU.

Fortunately, with the help of a scanning tool, we can easily check for software vulnerabilities within web applications, pin-point them and fix them. This is where web application scanners come into play.

A web application scanner is a kind of "hacker-in-a-box" which sends messages (or harmless attacks) to target websites and listens for responses. The scanner will then search for possible security vulnerabilities by analyzing the responses. A report will usually be generated to allow developers and system administrators to identify and fix the security vulnerabilities. A good application scanner can check web applications for all the known security problems, and thus further improve application security.

As always, there can never be a perfect web application scanner and prevention is better the cure, the web application thus must be designed and written with security-at-its-core in mind.

There are many scanning tools in the market, such as WebInspect from SPI Dynamics (recently acquired by Hewlett-Packard) and AppScan from Watchfire (recently acquired by IBM). In the past few months, the Computing Services Centre (CSC) had evaluated some of these scanning tools and tested them by performing security scanning on a few systems of our own. When the CSC has fully mastered the tools, we will provide the web application vulnerabilities scanning service to departments.