Application Security Code Review Guidelines Version 5 Effective Date 11/8/2010
The following security guidelines must be followed when performing code reviews to comply with the GDP development process and regulatory requirements.
Access Control
Authentication is enforced at every entry point into the application (e.g. every URL for a web application) and is performed before any other processing. Following authentication, authorization is enforced at every entry point into the application. For all user actions, the application verifies that the user is authorized to perform the requested action on the requested object. An object might be coarse grained (e.g. screen level) or fine grained (e.g. field level). On web pages that create, update or delete Sensitive1 data, a control2 to prevent Cross Site Request Forgery (CSRF) is implemented. The client-side code comments do not contain any sensitive data (code flow, business logic, system information, username/passwords). Extraneous test and debug code has been removed before move-to-production.
Input Validation
User-supplied data is properly encoded or escaped before it is interpreted or parsed by another application, middleware component, or system. (e.g. Browser (HTML, JavaScript, etc), OS command line, LDAP, etc.) Bind variables are used in database queries. (e.g. Prepared Statements for Java, PLANS for db2, etc.) Inputs with well a defined set of expected values (e.g. dropdowns, radio buttons, checkboxes, text fields with an expected range of values, etc.) are validated using a white list on the server side. For web applications, when user input is used to redirect or forward the user to other URLs, the input is validated to contain only an allowed destination.
Data Protection
Cookies do not store any Sensitive1 data. The secure flag is set on session cookies that represent an authenticated user. Sensitive1 data such as Credit card numbers, SSNs, TAX IDs, etc., is always stored encrypted using InfoSec approved techniques and methodology. (InfoSec standards Section 2.43).
1 2
InfoSec Data Classification - http://www.infosec.fedex.com/standards/docs/InformationSecurityDataClassifications.pdf Recommended controls https://appsec.infosec.fedex.com/main/Cross_Site_Request_Forgery 3 http://www.infosec.fedex.com/standards/docs/currentstandards/Data%20Security%20Standards.pdf
FedEx Internal Use Page 1 of 3 Application Security Code Review Guidelines - http://itg.prod.fedex.com/sf/go/doc302589 Date Revised: 11/08/10 Printed copies for reference only Date Printed: 12/20/11
Application Security Code Review Guidelines Version 5 Effective Date 11/8/2010
Sensitive1 data such as passwords, pass codes, PINs, secret answers, etc., is stored hashed using InfoSec approved algorithms techniques and methodology. (InfoSec standards Section 2.433). For web applications, Sensitive1 data is only sent via the POST method to ensure that it is not logged anywhere. For web applications, caching and auto-complete are turned off on pages handling Sensitive1 data. After processing a specific Sensitive1 data element, it is overwritten and set to null, effectively removing it from memory.
Malicious Code
The application does not contain any code that does not support a business, software, or design requirement, including backdoors4, logic bombs5, data leaks6, and all other forms of malicious code. The database triggers, procedures, or functions do not contain any code that does not support a business, software, or design requirement including backdoors, logic bombs, and all other forms of malicious code. The scheduled tasks do not contain unusual entries or any logic that does not support a business, software, or design requirement. The configuration, properties, and script files do not contain any unnecessary or unusual code entries. e.g. configuration of framework(s) such as Hibernate, Struts, Spring, etc. Revision History
Backdoors Malicious code that enables a user to bypass normal authentication. To locate backdoors, for example, search and review for: Hardcoded user id s or employee ids Open ports
5
Logic Bombs Malicious code that intentionally inserted to execute when certain conditions (such as pre-defined time, a certain command is executed, or a certain parameter value is received, etc.,) are met. To locate logic bombs, for example, search and review for: Hardcoded dates Objects such as Date, Time, Calendar, etc. Counters
6
Data Leaks Malicious code that intentionally transmits Sensitive or Internal data to an unauthorized system or user. To locate data leaks, for example, search and review for: Open sockets URL connections Proxy addresses or ports File access Code sending emails
FedEx Internal Use Page 2 of 3 Application Security Code Review Guidelines - http://itg.prod.fedex.com/sf/go/doc302589 Date Revised: 11/08/10 Printed copies for reference only
Date Printed: 12/20/11
Application Security Code Review Guidelines Version 5 Effective Date 11/8/2010
Versio n
Date
Description of Change
By
1.0 2.0 3.0 4.0 4.1 5.0
10/24/2008 5/5/2009 6/25/2009 6/1/2010 7/29/2010 11/10/2010
Initial version Added checks for malicious code Removed infrastructure and non-code checks GDP3.5 and PCI revisions Removed the Mutable object requirement for Sensitive data Removed Reviewer Attestation
eCAS (eCommerce & Application Security) eCAS eCAS eCAS eCAS eCAS
FedEx Internal Use Page 3 of 3 Application Security Code Review Guidelines - http://itg.prod.fedex.com/sf/go/doc302589 Date Revised: 11/08/10 Printed copies for reference only
Date Printed: 12/20/11
