Download
1 / 6
460 likes | 829 Views
OWASP Secure Coding Practices Quick Reference Guide. Project leader Keith Turpin Keith.n.turpin@boeing.com. August, 2010. Project Overview. The guide provides a technology agnostic set of coding practices Presented in a compact, but comprehensive checklist format
E N D
OWASP Secure Coding Practices Quick Reference Guide Project leader Keith Turpin Keith.n.turpin@boeing.com August, 2010
Project Overview • The guide provides a technology agnostic set of coding practices • Presented in a compact, but comprehensive checklist format • At only 12 pages long, it is easy to read and digest • Focuses on secure coding requirements, rather then on vulnerabilities and exploits
Sections of the Guide • The bulk of the document is in the checklists, but other sections include: Introduction Table of contents Software Security Principles Overview Secure Coding Practices Checklist Glossary of important terminology Links to useful resources
Checklist Sections • The checklist are broken up into the following major sections: • Data Validation • Authentication and Password Management • Authorization and Access Management • Session Management • Sensitive Information Storage or Transmission • System Configuration Management • General Coding Practices • Database Security • File Management • Memory Management
Checklist Practices • The practices in each section are short and to the point. Some examples include: • Conduct all data validation on a trusted system • Use two factor authentication for highly sensitive or high value transactional accounts • If a session was established before login, close that session and establish a new session after a successful login • Turn off verbose system messages, especially any associated with error conditions • Restrict the web server, process and service accounts to the least privileges possible • Use strongly typed parameterized queries
Summary • The guides goal is to make it easier for development teams to quickly understand and review secure coding practices. • It does not specify what should or must be done, as all of these practices can be contributing factors to the overall security profile of an application and often it is the combination of flaws, rather than any single one, which leads to an exploitable situation.
