Web
Application Security: A Recapitulation
By
Wilson Wong
|
|
|
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
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
|