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 (at) bell (dot) ca [email concealed] [mailto:caleb.dods (at) bell (dot) ca [email concealed]]
> Sent: Monday, September 20, 2004 2:56 PM
> To: security-basics (at) securityfocus (dot) com [email concealed]; secprog (at) securityfocus (dot) com [email concealed]
> 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
>  
>
>
>

[ reply ]