RE: Inspecting Code for Security
"Yvan Boily" <[email protected]> Tue, 21 Sep 2004 11:39:07 -0500
| Newsgroups | gmane.comp.security.programming,gmane.comp.security.basics |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected] [mailto:[email protected]] > Sent: Monday, September 20, 2004 2:56 PM > To: [email protected]; [email protected] > 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 > > > >