Web Application Security: A Recapitulation
Introduction
World Wide Web is growing extremely fast in the past few years. Counting only the number of new websites responding to an online web server survey has already recorded an increase of 2,137,329 in June 2009 (a jump from 235,890,526 to 238,027,855). The actual number of websites in the entire world is totally unpredictable. But how many of them do you think are vulnerable to security attacks? The Web Application Security Consortium (WASC) analyzed 32,717 websites in their WASC Web Application Security Statistics Project 2007 (the corresponding report was published by the WASC in September 2008) and found that the chance of a website that is vulnerable to security attack had reached 96.85%! On average, 9 high risk vulnerabilities can be identified per website! We should therefore put more emphasis on the security of our own websites.
In order to raise users’ awareness about web application security, the Computing Services Centre (CSC) had published an article on Web Application Security (Ref: Network Computing Issue 53 - September 2007). But as more and more security incidents were reported recently, we would like to recapitulate some of its content and add a few words on the topic.
Web Application Vulnerabilities
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( _
HttpUtility.HtmlEncode(user_input))
encoded_input.Replace("<b>", "<b>")
encoded_input.Replace("</b>", "<b>")
encoded_input.Replace("<i>", "<i>")
encoded_input.Replace("</i>", "</i>")
Response.Write(encoded_input.ToString())
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")
sqlCmd.Parameters.Add(param_uid)
sqlCmd.Parameters.Add(param_pwd)
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.
<configuration>
<system.web>
<trace enabled="false" />
<customErrors mode="On" />
</system.web>
</configuration>
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") & _
Request.ServerVariables("URL"))
End If
Web Application Security Scanning
The CSC has acquired one of the best scanning tools in the market, named WebInspect from Hewlett-Packard. It 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 known security vulnerabilities by analyzing the responses. A report will be generated to allow developers and system administrators to identify and fix the security vulnerabilities. Web applications residing on the CityU’s central web servers (www.cityu.edu.hk, www6.cityu.edu.hk, and www7.cityu.edu.hk) will be scanned on rotational basis. If any security vulnerabilities are found, a report with a full list of known security vulnerabilities will be sent to the corresponding owner(s) of the website. This periodic scan does not interrupt the normal operation of the websites.
Apart from the periodic scanning, users are also encouraged to contact the CSC to initiate a scan before any releases of website upgrades at these servers. For departments whose websites reside on their own departmental web servers or on other systems may also contact the CSC for arranging an application scanning.
References