Secure Coding Practices Quick Ref 4

OWASP
Secure Coding Practices

Quick Reference Guide
Project leader
Keith Turpin
Keith.n.turpin@boeing.com
OWASP
August, 2010
Copyright © The OWASP Foundation

Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation

http://www.owasp.org
About Me
 Secure Coding Practices Quick Reference
Guide project leader
 Application security assessments team
leader at The Boeing Company
 United States delegate to the IEC/ISO
SC27 subcommittee on cyber security
 Member of the Software Assurance
Working Group
OWASP 2
Some Background
 Goal: Build a secure coding kick-start tool, to help

development teams quickly understand secure coding
practices
 Originally developed for use inside The Boeing Company
 July 2010, Boeing assigned copyright to OWASP
 August 2010, project goes live on owasp.org
OWASP 3
Guide Overview
 Technology agnostic coding practices
 What to do, not how to do it

 Compact, but comprehensive checklist format
 Focuses on secure coding requirements, rather

then on vulnerabilities and exploits
 Includes a cross referenced glossary to get
developers and security folks talking the same
language
OWASP 4
Sections of the Guide
 The bulk of the document is in the checklists, but it

contains all of the following:
Table of contents
Introduction
Software Security Principles Overview
Secure Coding Practices Checklist
Links to useful resources
Glossary of important terminology
OWASP 5
Checklist 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
OWASP 6
Checklist Practices
 Short and to the point.
 Straight forward "do this" or "don't do that"
 Does not attempt to rank the practices
 Some practices are conditional recommendations that

depend on the criticality of the system or information
 The security implications of not following any of the

practices that apply to the application, should be clearly
understood
OWASP 7
Extract - Database Security
 Use strongly typed parameterized queries. Parameterized queries keep the query and data
separate through the use of placeholders. The query structure is defined with place holders
and then the application specifies the contents of each placeholder.
 Utilize input validation and if validation fails, do not run the database command.
 Ensure that variables are strongly typed.
 Escape meta characters in SQL statements.
 The application should use the lowest possible level of privilege when accessing the
database.
 Use secure credentials for database access.
 Do not provide connection strings or credentials directly to the client. If this is unavoidable,
encrypted them.
 Use stored procedures to abstract data access.
 Turn off any database functionality (e.g., unnecessary stored procedures or services).
 Eliminate default content.
 Disable any default accounts that are not required to support business requirements.
 Close the connection as soon as possible.
 The application should connect to the database with different credentials for every trust
distinction (e.g., user, read-only user, guest, administrators).
OWASP 8
Using the guide
 Scenario #1: Developing Guidance Documents
Coding Practices
Guiding Principles What to do How to do it
Security Application Application

Policies Security Security
Procedures Coding
Standards
OWASP 9
Using the guide continued
 Scenario #2: Support Secure Development Lifecycle
What to do How you should do it What you did Did it work
Application Application Review Test Solution

Security Development Practices Solutions Implementation
Requirements
Standardized Libraries
Standard Guidance for
non-Library Solutions
Coding Practices
OWASP 10
Using the guide continued
 Scenario #3: Contracted Development
 Identify security requirements to be added to outsourced
software development projects.
 Include them in the RFP and Contract
We can build Coding Practices I need

How do I cool
anything
make it work Software
RFP
Best
Contract
Software
Best
Ever
Software
Ever
Programmer Salesman Customer

OWASP 11
Summary
 Makes it easier for development teams to quickly

understand secure coding practices
 Assists with defining requirements and adding them to

policies and contracts
 Provides a context and vocabulary for interactions with

security staff
 Serves as an easy desk reference
OWASP 12
A Secure Development Framework
Guidance on implementing a secure software development framework
is beyond the scope of the Quick reference Guide, however the
following OWASP projects can help:
 Implement a secure software development lifecycle

 OWASP CLASP Project
 Establish secure coding standards
 OWASP Development Guide Project
 Build a re-usable object library
 OWASP Enterprise Security API (ESAPI) Project
 Verify the effectiveness of security controls
 OWASP Application Security Verification Standard (ASVS) Proje
ct)
 Establish secure outsourced development practices including
defining security requirements and verification methodologies in
both the RFP and contract
 OWASP Legal Project
OWASP 13
Questions
OWASP 14

Secure Coding Practices Quick Ref 4

Uploaded by

Secure Coding Practices Quick Ref 4

Uploaded by

OWASP

Secure Coding Practices

Copyright © The OWASP Foundation

The OWASP Foundation

 Goal: Build a secure coding kick-start tool, to help

 August 2010, project goes live on owasp.org

 Technology agnostic coding practices

 What to do, not how to do it

 Focuses on secure coding requirements, rather

 The bulk of the document is in the checklists, but it

 Short and to the point.

 Straight forward "do this" or "don't do that"

 Does not attempt to rank the practices

 Some practices are conditional recommendations that

 The security implications of not following any of the

Guiding Principles What to do How to do it

Security Application Application

 Scenario #2: Support Secure Development Lifecycle

What to do How you should do it What you did Did it work

Application Application Review Test Solution

We can build Coding Practices I need

Programmer Salesman Customer

 Makes it easier for development teams to quickly

 Assists with defining requirements and adding them to

 Provides a context and vocabulary for interactions with

 Serves as an easy desk reference

 Implement a secure software development lifecycle

You might also like