Web Application Vulnerabilities Commonly Found

Knowing the vulnerabilities and fix them as soon as possible are important for developers and content managers to maintain secure websites. The following four web application vulnerabilities were commonly found in our environment and we will briefly discuss each in turn.

1. Cross-site scripting (XSS)

Cross-site Scripting (XSS) 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 a page usually contains a line of code like

Response.write Request ("user_input")

Consider if one enters 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 the 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( _

2. SQL Injection

Another web application 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 inputs 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")

This way, users’ input will not be used to construct the SQL command. Any string that a hacker input will be considered 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 should insert simple error exception checking statements to prevent error messages from displaying on the web, which will be discussed in the next section.

3. Information Leakage

Information Leakage is an application weakness, which discloses technical information of a website. That information is usually useful for hackers to further exploit known vulnerabilities of their target web applications or systems whose fix are not available yet. One of the most common forms of information leakage is the error pages returned from the corresponding web application or database server when an application error occurs. These pages may provide detailed error information, including program codes, software versions, database names and files’ physical locations which were originally designed for administrators and developers to troubleshoot problems in web applications. Hackers usually insert special strings to web forms and cause web applications to generate application errors. They will then make use of the error information obtained to plan for further hacking activities.

To prevent information leakage, developers should carefully validate users’ input and include error handling program codes in their web applications. When websites are put into production, developers should also disable the corresponding error messages. For Microsoft .NET applications, developers can simply disable the ASP.NET Application Level-Trace Log and turn on the Custom Error Message by locating the “trace enabled” and “customErrors” tags and change their values to “false” and “On” respectively.

          <trace enabled="false" />
          <customErrors mode="On" />

4. Logins Sent Over Unencrypted Connection

Web pages that pass sensitive information no matter in which direction should utilize SSL encryption to prevent information from being sniffed and stolen. Web pages that contain login forms, as well as the corresponding actions of the forms, should also be SSL encrypted. This will prevent Man-in-the-Middle attacks on the login forms for stealing username and password.

Server administrators should purchase and apply SSL certificates to their web servers; and developers should employ program codes in their applications to force users to use the “https” protocol when visiting their web pages with login forms or when sensitive information will be presented. Sample codes for VB.NET are shown below.

If not Request.IsSecureConnection Then
     Response.Redirect("https://" & _
          Request.ServerVariables("HTTP_HOST") & _
End If