Team Foundation Server (TFS) and the Open Web Application Security Project (OWASP) Top Ten

Grant Holliday

October 2008

Summary

The purpose of this document is to describe the level of compliance of Team System 2008 Team Foundation Server with Open Web Application Security Project (OWASP). Specifically it identifies how the OWASP Top Ten 2007 threats are handled by the security design and test procedures of Microsoft and the Team Foundation Server product team.

Applies to:

Microsoft Visual Studio Team Foundation Server 2008

Introduction

What are the OWASP Top Ten?

How does Team Foundation Server address the OWASP Top 10?

Conclusion

Additional Information

Introduction

The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. The OWASP Top Ten provides a powerful awareness document for Web application security. The OWASP Top Ten represents a broad consensus about what the most critical Web application security flaws are. The current version is the OWASP Top Ten 2007.

Visual Studio Team System 2008 Team Foundation Server (TFS) is an integrated collaboration server for Visual Studio Team System. It combines team portal, version control, work item tracking, build management, process guidance, and business intelligence into a unified server. It allows everyone on the team to collaborate more effectively and deliver better quality software.

What are the OWASP Top Ten?

The primary aim of OWASP Top 10 2007 is to educate developers, designers, architects and organizations about the consequences of the most common Web application security vulnerabilities. The following table provides a summary of the vulnerabilities included in OWASP Top Ten 2007.

Area	Description
A1 - Cross Site Scripting (XSS)	XSS flaws occur whenever an application takes user supplied data and sends it to a Web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
A2 - Injection Flaws	Injection flaws, particularly SQL injection, are common in Web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.
A3 - Malicious File Execution	Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.
A4 - Insecure Direct Object Reference	A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
A5 - Cross Site Request Forgery (CSRF)	A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable Web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the Web application that it attacks.
A6 - Information Leakage and Improper Error Handling	Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.
A7 - Broken Authentication and Session Management	Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
A8 - Insecure Cryptographic Storage	Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
A9 - Insecure Communications	Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
A10 - Failure to Restrict URL Access	Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

How does Team Foundation Server address the OWASP Top 10?

Team Foundation Server uses the Microsoft Security Development Lifecycle, or SDL, to minimize security-related vulnerabilities in the design, code, and documentation of the product. This process helps to detect and eliminate vulnerabilities as early as possible in the development lifecycle, as well as reduce the number and severity of security vulnerabilities and improve the protection of users’ privacy.

Secure software development has three elements: best practices, process improvements, and metrics. Microsoft has implemented a stringent software development process that focuses on these elements.

Figure 1: The Microsoft Security Development Lifecycle (SDL)

The 14 stages of the SDL are:

• SDL Stage 0: Security and Privacy Education and Awareness
• SDL Stage 1: Project Inception
• SDL Stage 2: Cost Analysis
• SDL Stage 3: Design Best Practices
• SDL Stage 4: Risk Analysis
• SDL Stage 5: Creating Documentation and Tools for Users that Address Security and Privacy
• SDL Stage 6: Establish and Follow Best Practices for Development
• SDL Stage 7: Security and Privacy Testing
• SDL Stage 8: Security Push
• SDL Stage 9: Public Release Privacy Review
• SDL Stage 10: Response Planning
• SDL Stage 11: Final Security and Privacy Review
• SDL Stage 12: Release to Manufacturing (RTM)/Release to Web (RTW)
• SDL Stage 13: Response Execution

The Microsoft Software Development Lifecycle (SDL) is available to the public as process guidance on the MSDN Security Developer Center.

The following table describes how the SDL maps to the OWASP Top Ten 2007 vulnerabilities.

Area	Software Development Lifecycle Reference
A1 - Cross Site Scripting (XSS)	CROSS-SITE SCRIPTING (XSS) INPUT VALIDATION GENERAL - Security Requirement CROSS-SITE SCRIPTING (XSS) INPUT HTML AND SCRIPT VALIDATION - Security Requirement CROSS-SITE SCRIPTING (XSS) INPUT VALIDATION VALIDATEREQUEST ATTRIBUTE - Security Requirement CROSS-SITE SCRIPTING (XSS) OUTPUT ENCODING - Security Requirement CROSS-SITE SCRIPTING (XSS) STATIC BINARY ANALYSIS - Security Requirement
A2 - Injection Flaws	SQL EXECUTE ONLY PERMISSION - Security Requirement SQL PARAMETERIZED QUERY - Security Requirement SQL STORED PROCEDURES - Security Requirement
A3 - Malicious File Execution	Identified during threat modeling in SDL Stage 4: Risk Analysis.
A4 - Insecure Direct Object Reference	Identified during threat modeling in SDL Stage 4: Risk Analysis.
A5 - Cross Site Request Forgery (CSRF)	Identified during threat modeling in SDL Stage 4: Risk Analysis.
A6 - Information Leakage and Improper Error Handling	Identified during threat modeling in SDL Stage 4: Risk Analysis.
A7 - Broken Authentication and Session Management	Identified during threat modeling in SDL Stage 4: Risk Analysis.
A8 - Insecure Cryptographic Storage	CRYPTO DESIGN - Security Requirement Microsoft Cryptographic Standards for SDL Covered Products
A9 - Insecure Communications	TFS can be configured to use SSL encryption on front-end and backend connections. For more information, see Team Foundation Server Security Architecture.
A10 - Failure to Restrict URL Access	Identified during threat modeling in SDL Stage 4: Risk Analysis.

Conclusion

Starting with the Trustworthy Computing (TwC) directive of January 2002, many software development groups at Microsoft instigated “security pushes” to find ways to improve the security of existing code. However, the reliable delivery of more secure software requires a comprehensive process. To that end Microsoft defined four guiding principles to guide the creation and support of more secure software: Secure by Design; Secure by Default; Secure in Deployment; and Communications (SD3+C). The Security Development Lifecycle (SDL) brings these principles to life, by integrating them into every step of the software development lifecycle.

The Microsoft Security Development Lifecycle (SDL) is the industry-leading software security assurance process. A Microsoft-wide initiative and a mandatory policy since 2004, SDL has played a critical role in embedding security and privacy into Microsoft software and culture. Combining a holistic and practical approach, SDL introduces security and privacy early and throughout the development process.

Every shipping Microsoft product must be approved by the Secure Windows Initiative (SWI) team and go through a process of review and registration in a central repository. Visual Studio Team System 2008 Team Foundation Server SP1 has achieved compliance with Microsoft’s Security Development Lifecycle (SDL).

Additional Information

Team Foundation Server Security Architecture

Open Web Application Security Project website

OWASP Top Ten Project page

Team Foundation Server Developer Center

The Microsoft Security Development Lifecycle (SDL): Process Guidance