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)
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")
<script>alert('XSS has been found');</script>
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.
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") & _