Applicable To: 

Duke Health

Duke University

Note: Developers may also want to view the Security Offices' position statement on Secure Native Application Authentication.

Duke Security Offices position statement on web application testing:

Introduction

Web application security remains a critical concern in today's IT landscape as organizations continue to rely heavily on web applications for their operations, communication, and customer interactions. The increasing sophistication of cyberattacks, the growing complexity of web applications, and the evolving threat landscape make it imperative for Duke to prioritize and maintain robust web application security measures. This document outlines and details some minimum web application vetting and testing standards. This process should be used to ensure that web applications and APIs conform to Duke’s security requirements and are analyzed for vulnerabilities.

Duke has a large footprint of web applications and APIs to communicate, share or harvest information, provide health services, and transact business with internal and external constituents. Duke’s web application presence continues to grow, including (but not exclusively) the following examples:

  • Web applications involving Duke data, including sensitive data (e.g., PHI, PII, etc.)
  • Institutional/Enterprise web applications, regardless of data classification
  • Web applications involved in specific research programs
  • School, center, and departmental web applications
  • Individual or project-oriented web applications

Web applications may be developed by Duke faculty, staff or students, or by external development companies under contract with Duke. External development companies or partners should adhere to the same minimum standards required by Duke’s IT Security Office (ITSO) and/or the Duke Health Information Security Office (ISO) before use.

In an effort to improve the security of Duke’s web applications, the ITSO and ISO have developed joint guidance and options for vetting and testing these applications at Duke.

Scope

This guidance applies to Duke-developed and affiliated web applications and to third-party developers responsible for building or maintaining Duke web applications on behalf of Duke.  All apps that are Duke branded are in scope for testing.

The following scenarios are not included in scope for this guidance, but ITSO/ISO encourages a strong Software Development Life Cycle (SDLC) – including regular testing for security vulnerabilities – by the owners of these applications.

  • Commercially available web applications that were not developed by or under contract with Duke.
  • Duke Health research Sponsored provided or required web applications that were not developed by or under contract with Duke.

Position

WEB Application Security Requirements

Duke web applications should meet defined security requirements in order to be approved for use by Duke. Each in-scope application should have a documented SDLC plan.

General APPLICATION Requirements

General application security requirements define the software and behavioral characteristics of web apps and web services of all types that should or should not be present to ensure the security of the application. These requirements apply to all in-scope web applications and are tailored to meet the security needs and risk tolerance of Duke. At minimum, Duke’s general application security requirements for all in-scope applications include those specified below:

  • Duke Security Policies, Procedures, and Standards

https://security.duke.edu/policies-procedures-and-standards/application-security/ 

  • Open Web Application Security Project (OWASP):

https://owasp.org/www-project-web-security-testing-guide/stable/

https://owasp.org/www-project-application-security-verification-standard/

The Open Web Application Security Project (OWASP) is a nonprofit organization focused on improving the security of software. OWASP provides a comprehensive list of security guidelines and resources, including the OWASP Testing Guide, which is a valuable resource for testing web applications for security vulnerabilities. The guide is regularly updated to align with the latest industry practices and security threats.
 

OWASP APPLICATION Risks and Controls Guidance

OWASP maintains multiple useful resources for web application testing and security.

The OWASP Application Security Verification Standard (ASVS) is a detailed model for application security that is used to provide baseline security requirements for Duke.

The ASVS defines a set of security declarations concerning the structure and behavior of an application and has two primary goals:

  • Helps Duke develop and maintain secure applications.
  • Helps Duke to align application security requirements with 3rd party vendors, developers, or service providers.

The Application Security Verification Standard (ASVS) defines three security verification levels, with each level increasing in depth.

  • ASVS Level 1 is for low assurance levels and is the minimum for every application.
  • ASVS Level 2 is for applications that contain sensitive data, access, or functions, which requires protection.
  • ASVS Level 3 is for the most critical applications - applications that perform high value transactions, contain significant levels of sensitive data, or any application that requires the highest level of trust.

Minimally, all in-scope applications must meet Level 1 testing.  Duke Security teams reserve the right to require Level 2 and Level 3 testing based on data sensitivity, volume of use, or other relevant factors.

The ASVS is divided into the categories listed below and it may be used by software architects and developers seeking to develop secure web applications, as well as security testers to ensure completeness and consistency of test results:

  • Architecture, Design, and Threat Modeling Requirements
  • Authentication Verification Requirements
  • Session Management Verification Requirements
  • Access Control Verification Requirements
  • Validation, Sanitization and Encoding Verification Requirements
  • Stored Cryptography Verification Requirements
  • Error Handling and Logging Verification Requirements
  • Data Protection Verification Requirements
  • Communications Verification Requirements
  • Malicious Code Verification Requirements
  • Business Logic Verification Requirements
  • File and Resources Verification Requirements
  • API and Web Service Verification Requirements
  • Configuration Verification Requirements
     

WEB Application Vulnerability Testing Requirements

An approved application vulnerability assessment must be performed on every in-scope application. An approved application vulnerability testing process includes using security test tools and penetration testing to help identify vulnerabilities and weaknesses. Testing should be performed by experienced penetration testers, which may be an authorized 3rd party advisory group or approved internal testers who did not write code for the application. At minimum, testing must follow the OWASP Web Security Testing Guide (WSTG) and should be clearly documented.

The OWASP Web Application Testing Guide (WSTG) is a comprehensive resource provided by the Open Web Application Security Project (OWASP). It offers technical guidelines and methodologies for testing the security of web applications and verifying the requirements listed in the ASVS. The guide is regularly updated to reflect the latest security threats and best practices. It covers various testing techniques, tools, and checklists to help security professionals and developers identify and address vulnerabilities in web applications.

The primary goals of the OWASP Web Application Testing Guide are to:

  • Provide a consistent and standard approach to web application security testing.
  • Offer detailed testing methodologies for various security aspects of web applications.
  • Support security professionals in identifying common vulnerabilities and weaknesses.
  • Assist developers in creating more secure web applications by understanding common security issues and mitigation techniques.

Best practice web application testing methodologies include both passive and active testing approaches. These two testing methodologies serve different purposes and are used in different scenarios to assess the security of web applications:

  1. Passive Testing: Passive testing involves monitoring and observing the application's behavior and traffic without directly interacting with it. It focuses on analyzing the information exchanged between the client and the server to gather insights into potential security issues without affecting the application's functionality. (e.g., Burp Suite, Zap, Security Headers, Wireshark, Fiddler, Whatweb, directory enumeration tools, sitemap tools, etc.)

Examples of passive testing techniques in the OWASP Web Application Testing Methodology include:

  • Information Gathering: Observing the application's responses and the URLs it accesses to understand its architecture and potential entry points for attacks.
  • Configuration and Deployment Management Testing: Analyzing the responses from the web server to identify misconfigurations or security flaws.
  • Identity Management Testing: Monitoring the authentication and session management mechanisms to gather information about how user identities are managed.
  • Error Handling Testing: Observing error messages to identify any sensitive information exposed in the responses.
  • Web Services Testing: Monitoring the communication between the application and web services to analyze potential security issues.

 

  1. Active Testing: Active testing involves interacting directly with the web application to simulate real-world attacks and gather specific security-related information. It includes techniques where the tester actively interacts with the application and sends various inputs to identify vulnerabilities. (e.g., Burp Suite, Zap, Invicti, SQLMap, Wfuzz, etc.)

Examples of active testing techniques in the OWASP Web Application Testing Methodology include:

  • Input Validation Testing: Actively sending various inputs, including malicious payloads, to test how the application handles them and identify potential injection vulnerabilities like SQL injection or Cross-Site Scripting (XSS).
  • Authentication Testing: Actively attempting to bypass authentication mechanisms or test for weak credentials.
  • Authorization Testing: Actively trying to access unauthorized resources or perform actions that should be restricted to specific users or roles.
  • Session Management Testing: Actively testing for session-related vulnerabilities like session fixation or session hijacking by manipulating session tokens.

It's essential to use both active and passive testing techniques in combination to get a comprehensive view of the web application's security posture. Passive testing provides valuable insights into the application's behavior and potential vulnerabilities without directly interacting with it, while active testing allows testers to actively simulate attacks and assess how the application responds to various threats.

  • By employing both active and passive testing methodologies from the OWASP Web Application Testing Guide, security professionals can effectively identify and address security vulnerabilities, making web applications more robust against potential cyber threats.

WEB APPLICATION Testing Cadence

Due to the frequency of updates and evolving risks, web applications do not remain static. The documented SDLC plan should include planned cadence for testing after initial approval for use.  ITSO and ISO recommends that the documented plan include testing annually and during any major version release.

NOTE: ALL applications must be registered with ITSO or ISO for automated web application scanning. Multiple tools may be used for this testing, but at minimum applications must be registered in the Web Application Vulnerability Scanning Inventory.

  • For ITSO Web Application Vulnerability Scanning registration, an email including name of application, owner’s name, department, and application details including URL/URI address may be sent to itso@duke.edu.
  • For ISO Web Application Vulnerability Scanning registration, an email including name of application, owner’s name, department, and application details including URL/URI address may be sent to vulnerability-team@mc.duke.edu.

Any person at Duke who is responsible for an in-scope web application should ensure that the above guidance is adhered to.   ITSO and ISO staff are available for consultation if there are questions about adherence to this guidance and may request to review initial penetration test reports.

Security Offices position statements outline the ISO/ITSO's view on security-related topics and provide guidance concerning Duke standards.

Document Type: Other