[WEB SECURITY] Web application security - basics

Matt Parsons mparsons1980 at gmail.com
Sun Aug 2 11:47:17 EDT 2009


I have been working on one high level summary of source code review.  The
OWASP papers are great, but they are hard to get first timers involved in
web application security.   I wrote a high level summary on why I thought it
was important to do source code analysis with a combination of white box and
black box testing.  I am still working on these notes and this is by no
means complete.  I look forward to thoughts, suggestions and improvements.


 

See below.  

 

Thanks,
Matt

 

 

 

 

When performing a software security review, source code should always be
available.   If you complete a web penetration test without access to the
source code, you never know how insecure the application is.  You also do
not know if there are any malicious triggers placed inside of the
application. This has become of increasing concern in the application
security community due to the number of offshore developers.     

With the source code, you can see all inputs to the application and view all
uses and misuses of the application.   You can also identify the assets in
the application and ensure the confidentiality, integrity and availability
of those assets.  You should also classify all assets and treat each one
with different levels of security. With this knowledge you can create an
accurate threat model.  

When creating a threat model, it is a good idea to think about who is
attacking your application.  Are they criminals or are they just script
kiddies, or is this more of a targeted attack from a competitor?   You must
know your enemy if you are responsible for protecting enterprise
applications.

   In some government environments, cyber terrorism has to be considered a
factor.   What level of skill does an attacker need to attack your
application?  You should also consider what an attacker has to gain from
hacking your application.  What are your assets?  Is it social security
numbers that the attacker is after or are they after trade secrets?
Whatever it is, you must document what you are trying to protect and create
different attack and defend scenarios.     

It is always a good idea to visually represent the application that you are
looking at.  When performing software security audits I always like to have
a UML diagram of different use cases of the application.  Microsoft Visio is
a great tool for this.   It is also important to interview the developers
that wrote the code to figure out what the application is doing.   

A successful software security review should consist of black box, white box
and grey box testing.     

One of the first steps is to know the business use case of the application.
What does the application do and how does it do it?  It is important to look
at the flow of the application.  Where is input coming in?  Where does input
go out?   These are potential attack vectors and should be treated with
higher care.    

All of this information can be found with commercial static analysis tools
that could not found with just a pure web penetration test.    Web
penetration testing is also important to test to see if the vulnerabilities
are really vulnerabilities and verify the weaknesses in your application.
The only proper way to do this is through mixing black box and white box
testing using static code analysis tools and manual source code review.


            With source code review one can find unsafe function calls.
They can also see the validation mechanism that is being used.  It is also
important to check the logging function of the application.  All of this is
possible with a source code review.   

By means of a source code review the security analyst can see if the
application is printing stack traces to users.  This could be a potential
Cross Site Scripting Vulnerability.   Once a security analyst finds this
vulnerability he or she can test it using a manual or automated web
penetration test.  

 There are a number of Web application vulnerability scanners that are both
free and commercial.   It is also recommended that one gets familiar with
the use of proxy tools and different plug-ins for Mozilla Fire Fox.   

With this tool combination, a security analyst can see where the credentials
are being stored.   He or she can see how the application is being connected
to the database.   With the web application testing tools he or she can also
verify the errors that are printed out to the user.  

Another benefit of doing a source code review is that the security analyst
can look for the intentional malicious vulnerability placed in their by an
offshore developer.   This is not possible with just a purely white box web
penetration test.   

If the security analyst finds a SQL injection bug in the source code, he or
she can verify that it is indeed a bug by completing a SQL injection attack
against the source.    ' or 1=1-

When doing a source code review a security analyst should look for the OWASP
top ten.   http://www.owasp.org/index.php/Top_10_2007  

This is by no means a complete list of what to look for but it should help
you get started and get the low hanging fruit vulnerabilities that are in
your application.   

 

 

Matt Parsons, CISSP

315-559-3588 Blackberry

817-238-3325 Home office 

mparsons1980 at gmail.com

www.parsonsisconsulting.com 

 

CISSP_logo

 

From: application.secure application.secure
[mailto:application.secure at gmail.com] 
Sent: Sunday, August 02, 2009 9:39 AM
To: websecurity at webappsec.org
Subject: [WEB SECURITY] Web application security - basics

 

Hello,

I'm looking a paper which explain the basics of application security
(critical vulenrabilities, why web application are vulnerable,  what are the
impact of attacks, how can we test applications ...)
There are a lot of document (especially on OWASP) but I don't find a
document which summarize application security

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090802/83f89d5d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 2509 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090802/83f89d5d/attachment.jpg>


More information about the websecurity mailing list