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. |

| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: "Selling" a code-audit., Javier Blanque |
|---|---|
| Next by Date: | RE: Inspecting Code for Security, Aleksander P. Czarnowski |
| Previous by Thread: | RE: Inspecting Code for Security, Aleksander P. Czarnowski |
| Next by Thread: | RE: Inspecting Code for Security, Aleksander P. Czarnowski |
| Indexes: | [Date] [Thread] [Top] [All Lists] |