Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security SecProg
[Top] [All Lists]

RE: Inspecting Code for Security

Subject: RE: Inspecting Code for Security
Date: Wed, 22 Sep 2004 22:42:08 -0500

Pick up John Viega and Gary Mcgraw's Building Secure Software.. If you are
going to be auditing code understanding security is pretty important and
that book is a solid introduction to it for a programmer.

Every person who performs code audits has different weightings they place on
what to look for, but here are some of the things I look for that you missed
from your list.

Error Conditions & Exception handling : ensure that areas where function
calls / methods can fail and disrupt operation of the application are
handled properly; this is critical to maintain reliability (from a business
perspective security is not just "hack-proof", it is also ensuring the
availability, confidentiality, and integrity of the systems running the code
and providing the data to the application)

Race Conditions : Ensure that there is proper locking on resources that can
be accessed concurrently.  I can't count the number of times I have seen
this become an issue in everything from authentication systems to database
update routines.

Output Encoding: Of particular importance in web based application, an
application should be checked to ensure that any user inputted data is
emitted as HTML entities to ensure that they cannot be interpreted by the
client as markup which could be used to facilitate a cross site scripting
attack. 

Secure use of encryption: It doesn't matter if they are using Rijndael-512
if the attacker can acquire the encryption keys... Ensure that the
mechanisms used to store the encrypted data and keys is also reliable.

Logging: If it is a business application it should have fairly tunable
logging ranging from debug levels where it emits a log for just about
everything to no logging.  Logging of application errors, security events,
and other business related data can help to generate an audit trail which is
crucial when performing incident response.

Authentication, Access Controls, and Credential Management:  These three
areas are tightly related and form the overall security model of the
application, but they are distinct components.  

Authentication is the protocol used to authenticate a user, either using
assymetric keys (i.e. ssh), username/password, two-factor authentication
(i.e. RSA SecurID), etc.

Access Controls speaks to both the specific access controls between
sessions, subjects and objects within the system and the access control
model used to describe the relationships.  Some types are Mandatory Access
Controls, Discretionary Access Controls, and Role-based Access Controls.  An
examination of how the access control models fit the organization using the
application is fairly important to ensure that business related objectives
such as separation of duties can be accomplished.

Credential Management is the mechanism for binding operations performed in
an application to an authenticated session.  From a web application
perspective this is essentially the same as Session management, and it does
have parallels in stateful applications.  Any application which stores
information about which operations are permitted based on an authentication
protocol and access control model includes a credential management layer
which is responsible for ensuring that a user does not need to authenticate
for every single operation.  This is frequently overlooked (in my opinion)
outside of stateless applications and is likely a serious issue in many
protocols.

This a short list of some of the things I look at when performing a code
audit; there are many others depending on wether or not it is a stateful or
stateless application, and the application model (standalone, client-server,
peer-to-peer, etc).

Yvan Boily 

-----Original Message-----
From: caleb.dods@bell.ca [mailto:caleb.dods@bell.ca]
Sent: Monday, September 20, 2004 2:56 PM
To: security-basics@securityfocus.com; secprog@securityfocus.com
Subject: Inspecting Code for Security

I have a background in programming and code inspection. 
However our inspections were not targeted at security, instead they 
looked for logic errors, over complex code, missing comments, etc.
 
With security in mind what things other things should I be looking for 
in a code inspection? I can think of the following, but I'm sure there 
are others:
 
- buffers that could be overflowed
- ensuring all input is validated (checked to ensure it is of the 
proper type & format)
- ensuring passwords & other encrypted date is not stored unencrypted 
in memory
- ensuring strong encryption is used
- ensuring no easter eggs / backdoors are left in the code
- ???
 
Thanks
 





<Prev in Thread] Current Thread [Next in Thread>