User:Amuntner/2016 Secure Coding Guidelines: Difference between revisions

intro edits
(clone page)
 
(intro edits)
 
Line 1: Line 1:
DRAFT - 2016 REVISION
=Introduction=
=Introduction=
The purpose of this page is to establish a concise and consistent approach to secure application development of Mozilla web applications and web services. The information provided here will be focused towards web based applications; however, the concepts can be universally applied to applications to implement sound security controls and design.
The purpose of this page is to establish a concise and consistent approach to secure application development of Mozilla web applications and web services. The information provided here will be focused towards web based applications; however, the concepts can be universally applied to security controls design for any application protocol.


This page will largely focus on secure guidelines and may provide example code at a later time.
This page will largely focus on secure guidelines and may provide example code at a later time.


=Status=
=Status=
The secure coding guidelines page is a living document and constantly updated to reflect new recommendations and techniques. Information that is listed is accurate and can be immediately used to bolster security in your application. If you have comments, suggestions or concerns please email  mcoates <at> mozilla.com
The secure coding guidelines page is a living document and constantly updated to reflect new recommendations and techniques. Information that is listed is accurate and can be immediately used to bolster security in your application. If you have comments, suggestions or concerns please email  amuntner <at> mozilla.com


=Layout=
=Layout=
The guidelines are discussed within logical security areas. Instead of discussing how to prevent each and every type of attack, we focus on a secure approach to designing an application. Within each section there is a listing of the types of the attacks these controls are geared to protect against. However, this document is not intended to serve as an in-depth analysis of the attack types, rather a guide to creating a secure application.
The guidelines are designed to provide secure means of performing security-sensitive programming tasks. Within each section there is a listing of the types of the attacks these controls are geared to protect against. This guide is intended to serve as a guide to creating secure applications, not an in-depth analysis of attack types. Where possible, offsite resources with more information are linked to.  


=Easy Quick Wins=
=Easy Quick Wins=
Here are a few items that are often missed and are relevant for most every website.
Here are a few items that are often missed and are relevant for most every website.


* For all cookies set the HTTPOnly and Secure flag
* For all cookies, set the HTTPOnly and Secure flag. HTTPOnly protects cookie values from being accessible by Javascript, protecting users against XSS authentication token theft. The Secure flag tells user agents to only ever transmit the cookie value over an HTTPS connection.
* Make sure login pages are only served on HTTPS and all authenticated pages are only served on HTTPS
* Make sure login pages are only served on HTTPS and all authenticated pages are only served on HTTPS.
* Don't trust any user data (input, headers, cookies etc). Make sure to validate it before using it
* Don't trust any user data (input, headers, cookies etc). Make sure to validate it before using it, and to make sure that user input that is reflected back at users always safely encodes the output. This usually means HTML entities.


=Secure Coding Guidelines=
=Secure Coding Guidelines=
==Authentication==
==Authentication==
Mozilla has two preferred forms of authentication. Used correctly, they will largely isolate you from the challenges of user and password management. If you are planning an application or service that can not use one of these two methods, email infosec@mozilla.com so we can help securely navigate the issue.
User-facing applications should use FxA
TODO: more explanation, link to examples)
Mozilla corporate applications should use LDAP/Okta MFA
TODO: more explanation, link to examples)
'''Attacks of Concern'''
'''Attacks of Concern'''
* MFA and federated authentication protocol attacks
* online & offline brute force password guessing
* online & offline brute force password guessing
* user enumeration  
* user enumeration  
Line 29: Line 40:
All sites should have the following base password policy:
All sites should have the following base password policy:


TODO: Revise and comment that sites should use LDAP/Okta MFA or FxA
* Passwords must be 8 characters or greater
* Passwords must be 8 characters or greater
* Passwords must require letters and numbers
* Passwords must require letters and numbers
* Blacklisted passwords should be implemented (contact infrasec for the list)
* Blacklisted passwords should be implemented  


====Critical Sites ====
====Critical Sites ====
Line 397: Line 409:
Michael Coates - mcoates [at] mozilla.com<br>
Michael Coates - mcoates [at] mozilla.com<br>
Chris Lyon - clyon [at] mozilla.com<br>
Chris Lyon - clyon [at] mozilla.com<br>
Mark Goodwin - mgoodwin [at] mozilla.com
Mark Goodwin - mgoodwin [at] mozilla.com<br>
Adam Muntner - amuntner [at] mozilla.com
297

edits