|
|
I hope that you have
already read first part
of this article and familiar
with the concept of how web
applications are different
from traditional
client-server applications.
If you have not, you might
find it useful to read
Part-1 as well.
In this part we will
explore what kind of
information is available to
the client? What kind of
information can be gathered
from the pages which client
can access? How validation is important to
ensure proper security for
the web application? What
are cookies and how web
applications use them?
|
It is
very important in web
application security testing to
gather as much information
about your application as you
can. You need to find out how people outside
your organization will
access your web application and
what kind of information
they can access. Typical
information that will be
available to any person
outside your organization
could be categorized as
- Comments & Sensitive
information embedded in
the HTML source code
- Error messages
generated at the server
and HTTP response
returned.
- Application error
message
During web
application development,
it is very important to
think about these
aspects. Comments or
sensitive information
can be very useful for
you while developing and
maintaining the code,
but if it is accessed by
malicious user it can
be dangerous. Similarly,
detailed error messages
given to improve
usability can results in
the security loophole.
HTML source present
on the client side can
be an excellent source of
information for the
attacker. It is very easy
for everyone to view
HTML source code and
since it is not
compiled, there is no
way to hide HTML
comments. For testing
web applications for
security,
you should look for the
sensitive information
like passwords,
usernames, database
names, connection
strings etc. As a
person responsible for
security testing you need to
make sure that sensitive
information is not
present in the HTML
source code.
In order to start
attack on any web
application, it is
important to know how
its pages can be
accessed, what kind of
data and parameters are
passed from one page to
another. You can keep an
eye on the URL for this
purpose and look for
key-value pairs.
You should always
consider creating page
map of your site
containing this
information. You can use
tool or can create it
manually by navigating
to all the pages and
making appropriate maps. After you have created
this page map, you can
search HTML source for
specific strings
containing information
related to HTML
comments, Application
Comments, IP Address,
E-Mail Address, SQL
Queries, Database
Connection Strings,
Hidden input fields etc.
If you try to change
parameters selected
during this process and
resubmit the request,
you can find interesting
information in error
messages.
Sometimes
server or application
throws overly
helpful error messages
which can give subtle hints to
the attackers. For
example on supplying
invalid password during
login process if system
throws error like
'invalid password' , it
essentially means that
username is proper.
Page map created
earlier can also help
you in guessing file
names and directory
structure
present on the web
server. Using this
technique you can access
files for which there is
no link present on the
pages, or which is not
intended to be visible
to the user. You must
always check for the
presence of any pattern
in file names and
location. Files which should not
be viewed by clients
should be located in
places not
accessible to the
clients. Using this
technique of educated
guessing, malicious
users can even access
admin or control panel
of the website, which
usually runs as a
separate sub-site or run
on a different port.
These type of loopholes
can be identified easily
by tools like port
scanners and other
brute-force tools.
Vulnerability of the
web application can also
be exposed by
manipulating UI
controls. For example,
you might have used
websites containing list
boxes to take user
input. Reason for
providing list box is to make
sure that client do not
choose any other option
apart from whatever is
supplied in the list. It
is very easy for
development team to make
this assumption and not
do any other form
of validation. What they
fail to realize is that,
these values can be
changed by making
changes in the page
source even request can
be tampered on transit using
appropriate tools. Also
if validations are
present at the
client-side, it is still
possible to bypass those
validations. This could
be achieved either by
disabling the java
scripts or saving a local
copy of the file and
removing those
validations. To safeguard
from these
vulnerabilities, it is
essential to make sure
that validations are
present on the server
side as well.
Another thing that
should be checked at the
client side is cookies.
For people not familiar
with cookies, cookies
are small files of
textual data that a web
application writes on a
client's hard drive. Web
application can reuse
this data on subsequent
visits. Cookies can be
delivered by web
application using either
persistent/non-persistent
and secure/non-secure
mode. Cookies can
be used for
personalization or
making sure that
information is not
accessed after it is
expired. There are many
ways in which cookies
can be used. Cookies are
normally stored at
predefined location with
predefined formats. If
your application relies
on cookies for any
functionality, it is
essential for you to
make sure that tempered
cookies can not be used
with your application.
Hope after
understanding the
different ways in which
security can be
compromised, you
will appreciate
the importance of
security testing of web
applications. In the next
article, we will explore
how data supplied by
client can be tempered
and servers can be
attacked.
You can read more
articles on software testing
in our
article section. You can
suggest topics of your
interest
here
, we will try to provide
information on those topics
as well.
These articles are
influenced by the book (
“How to Break Web Software”
from Mike Andrews and James
A. Whittaker ) I have
recently read and should be
a good read for you if you
need information on web
application security
testing.
|