OWASP Testing Guide
  • Foreword by Eoin Keary
  • Frontispiece
  • Introduction
  • The OWASP Testing Framework
    • The Web Security Testing Framework
    • Penetration Testing Methodologies
  • Web Application Security Testing
    • Introduction and Objectives
    • Information Gathering
      • Conduct Search Engine Discovery Reconnaissance for Information Leakage (WSTG-INFO-01)
      • Fingerprint Web Server (WSTG-INFO-02)
      • Review Webserver Metafiles for Information Leakage (WSTG-INFO-03)
      • Enumerate Applications on Webserver (WSTG-INFO-04)
      • Review Webpage Content for Information Leakage (WSTG-INFO-05)
      • Identify Application Entry Points (WSTG-INFO-06)
      • Map Execution Paths Through Application (WSTG-INFO-07)
      • Fingerprint Web Application Framework (WSTG-INFO-08)
      • Fingerprint Web Application (WSTG-INFO-09)
      • Map Application Architecture (WSTG-INFO-10)
    • Configuration and Deployment Management Testing
      • Test Network Infrastructure Configuration (WSTG-CONF-01)
      • Test Application Platform Configuration (WSTG-CONF-02)
      • Test File Extensions Handling for Sensitive Information (WSTG-CONF-03)
      • Review Old Backup and Unreferenced Files for Sensitive Information (WSTG-CONF-04)
      • Enumerate Infrastructure and Application Admin Interfaces (WSTG-CONF-05)
      • Test HTTP Methods (WSTG-CONF-06)
      • Test HTTP Strict Transport Security (WSTG-CONF-07)
      • Test RIA Cross Domain Policy (WSTG-CONF-08)
      • Test File Permission (WSTG-CONF-09)
      • Test for Subdomain Takeover (WSTG-CONF-10)
      • Test Cloud Storage (WSTG-CONF-11)
      • Testing for Content Security Policy (WSTG-CONF-12)
    • Identity Management Testing
      • Test Role Definitions (WSTG-IDNT-01)
      • Test User Registration Process (WSTG-IDNT-02)
      • Test Account Provisioning Process (WSTG-IDNT-03)
      • Testing for Account Enumeration and Guessable User Account (WSTG-IDNT-04)
      • Testing for Weak or Unenforced Username Policy (WSTG-IDNT-05)
    • Authentication Testing
      • Testing for Credentials Transported over an Encrypted Channel (WSTG-ATHN-01)
      • Testing for Default Credentials (WSTG-ATHN-02)
      • Testing for Weak Lock Out Mechanism (WSTG-ATHN-03)
      • Testing for Bypassing Authentication Schema (WSTG-ATHN-04)
      • Testing for Vulnerable Remember Password (WSTG-ATHN-05)
      • Testing for Browser Cache Weaknesses (WSTG-ATHN-06)
      • Testing for Weak Password Policy (WSTG-ATHN-07)
      • Testing for Weak Security Question Answer (WSTG-ATHN-08)
      • Testing for Weak Password Change or Reset Functionalities (WSTG-ATHN-09)
      • Testing for Weaker Authentication in Alternative Channel (WSTG-ATHN-10)
      • Testing Multi-Factor Authentication (MFA) (WSTG-AUTH-11)
    • Authorization Testing
      • Testing Directory Traversal File Include (WSTG-ATHZ-01)
      • Testing for Bypassing Authorization Schema (WSTG-ATHZ-02)
      • Testing for Privilege Escalation (WSTG-ATHZ-03)
      • Testing for Insecure Direct Object References (WSTG-ATHZ-04)
      • Testing for OAuth Authorization Server Weaknesses
      • Testing for OAuth Client Weaknesses
      • Testing for OAuth Weaknesses (WSTG-ATHZ-05)
    • Session Management Testing
      • Testing for Session Management Schema (WSTG-SESS-01)
      • Testing for Cookies Attributes (WSTG-SESS-02)
      • Testing for Session Fixation (WSTG-SESS-03)
      • Testing for Exposed Session Variables (WSTG-SESS-04)
      • Testing for Cross Site Request Forgery (WSTG-SESS-05)
      • Testing for Logout Functionality (WSTG-SESS-06)
      • Testing Session Timeout (WSTG-SESS-07)
      • Testing for Session Puzzling (WSTG-SESS-08)
      • Testing for Session Hijacking (WSTG-SESS-09)
      • Testing JSON Web Tokens (WSTG-SESS-10)
    • Input Validation Testing
      • Testing for Reflected Cross Site Scripting (WSTG-INPV-01)
      • Testing for Stored Cross Site Scripting (WSTG-INPV-02)
      • Testing for HTTP Verb Tampering (WSTG-INPV-03)
      • Testing for HTTP Parameter Pollution (WSTG-INPV-04)
      • Testing for Oracle
      • Testing for MySQL
      • Testing for SQL Server
      • Testing PostgreSQL
      • Testing for MS Access
      • Testing for NoSQL Injection
      • Testing for ORM Injection
      • Testing for Client-side
      • Testing for SQL Injection (WSTG-INPV-05)
      • Testing for LDAP Injection (WSTG-INPV-06)
      • Testing for XML Injection (WSTG-INPV-07)
      • Testing for SSI Injection (WSTG-INPV-08)
      • Testing for XPath Injection (WSTG-INPV-09)
      • Testing for IMAP SMTP Injection (WSTG-INPV-10)
      • Testing for File Inclusion
      • Testing for Code Injection (WSTG-INPV-11)
      • Testing for Command Injection (WSTG-INPV-12)
      • Testing for Buffer Overflow (WSTG-INPV-13)
      • Testing for Format String Injection (WSTG-INPV-13)
      • Testing for Incubated Vulnerability (WSTG-INPV-14)
      • Testing for HTTP Splitting Smuggling (WSTG-INPV-15)
      • Testing for HTTP Incoming Requests (WSTG-INPV-16)
      • Testing for Host Header Injection (WSTG-INPV-17)
      • Testing for Server-side Template Injection (WSTG-INPV-18)
      • Testing for Server-Side Request Forgery (WSTG-INPV-19)
      • Testing for Mass Assignment (WSTG-INPV-20)
    • Testing for Error Handling
      • Testing for Improper Error Handling (WSTG-ERRH-01)
      • Testing for Stack Traces (WSTG-ERRH-02)
    • Testing for Weak Cryptography
      • Testing for Weak Transport Layer Security (WSTG-CRYP-01)
      • Testing for Padding Oracle (WSTG-CRYP-02)
      • Testing for Sensitive Information Sent via Unencrypted Channels (WSTG-CRYP-03)
      • Testing for Weak Encryption (WSTG-CRYP-04)
    • Business Logic Testing
      • Introduction to Business Logic
      • Test Business Logic Data Validation (WSTG-BUSL-01)
      • Test Ability to Forge Requests (WSTG-BUSL-02)
      • Test Integrity Checks (WSTG-BUSL-03)
      • Test for Process Timing (WSTG-BUSL-04)
      • Test Number of Times a Function Can Be Used Limits (WSTG-BUSL-05)
      • Testing for the Circumvention of Work Flows (WSTG-BUSL-06)
      • Test Defenses Against Application Misuse (WSTG-BUSL-07)
      • Test Upload of Unexpected File Types (WSTG-BUSL-08)
      • Test Upload of Malicious Files (WSTG-BUSL-09)
      • Test Payment Functionality (WSTG-BUSL-10)
    • Client-Side Testing
      • Testing for Self DOM Based Cross-Site Scripting
      • Testing for DOM-Based Cross Site Scripting (WSTG-CLNT-01)
      • Testing for JavaScript Execution (WSTG-CLNT-02)
      • Testing for HTML Injection (WSTG-CLNT-03)
      • Testing for Client-side URL Redirect (WSTG-CLNT-04)
      • Testing for CSS Injection (WSTG-CLNT-05)
      • Testing for Client-side Resource Manipulation (WSTG-CLNT-06)
      • Testing Cross Origin Resource Sharing (WSTG-CLNT-07)
      • Testing for Cross Site Flashing (WSTG-CLNT-08)
      • Testing for Clickjacking (WSTG-CLNT-09)
      • Testing WebSockets (WSTG-CLNT-10)
      • Testing Web Messaging (WSTG-CLNT-11)
      • Testing Browser Storage (WSTG-CLNT-12)
      • Testing for Cross Site Script Inclusion (WSTG-CLNT-13)
      • Testing for Reverse Tabnabbing (WSTG-CLNT-14)
    • API Testing
      • Testing GraphQL (WSTG-APIT-01)
  • Reporting
    • Reporting
    • Vulnerability Naming Schemes
  • Appendix
    • Testing Tools Resource
    • Suggested Reading
    • Fuzz Vectors
    • Encoded Injection
    • History
    • Leveraging Dev Tools
  • Testing Checklist
  • Table of Contents
  • REST Assessment Cheat Sheet
  • API Testing
Powered by GitBook
On this page
  • Software Identification Tag
  • Examples
  • Common Platform Enumeration
  • Examples
  • Package URL
  • Examples
  • Recommendation Uses
  • References
  • Known Implementations
  1. Reporting

Vulnerability Naming Schemes

With a constantly growing number of IT assets to administer, security practitioners require new and more powerful tools to perform automated and large scale analysis. Thanks to software attention can be focused on the more creative and intellectually challenging problems. Unfortunately, having vulnerability assessment tools, antivirus software, and intrusion detection systems communicate its not an easy job. It has resulted in several technical complications, requiring a standardized way to identify each software flaw, vulnerability, or configuration issues identified. The lack of this interoperability capabilities can cause inconsistencies during the security assessment, confusing reporting, and extra correlation efforts among other problems that will produce an important waste of resources and time.

A naming scheme is a systematic methodology used to identify each one of those vulnerabilities in order to facilitate clear identification and information sharing. This goal is achieved by the definition of a unique, structured, and software-efficient name for each vulnerability. There are multiple schemes used to facilitate this effort, the most common are:

  • Common Platform Enumeration (CPE)

  • Software Identification Tag (SWID)

  • Package URL (PURL)

Software Identification Tag

Software Identification Tag (SWID) is an International Organization for Standardization's standard defined by the ISO/IEC 19770-2:2015. The SWID tags are used to identify each software clearly as part of comprehensive software asset management lifecycles. This information schema is recommended to be used by the National Institute of Standards and Technology (NIST) as the primary identification for any developed or installed software. From SWID it's possible to generate other schemas such as the CPE used by the National Vulnerability Database (NVD) whereas the reverse process is not possible.

Each SWID tag is represented as a standardized XML format. A SWID tag is composed for three groups of elements. The first block composed by 7 predefined elements required to be considered a valid tag. Followed by an optional block which provides a set of 30 possible predefined elements that the tag creator can use to provide reliable and detailed information. Finally, the Extended group of elements provides the opportunity for the tag creator to define any non predefined elements required to accurately define the described software. The high level of granularity provided by SWID, not only provides the capability to describe a given product of software, but also it's specific status on the software lifecycle.

Examples

  • ACME Roadrunner Service Pack 1 patch created by the ACME Corporation for the already installed product identified with the @tagId: com.acme.rms-ce-v4-1-5-0:

<SoftwareIdentity
                  xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
                  name="ACME Roadrunner Service Pack 1"
                  tagId="com.acme.rms-ce-sp1-v1-0-0"
                  patch="true"
                  version="1.0.0">
  <Entity
          name="The ACME Corporation"
          regid="acme.com"
          role="tagCreator softwareCreator"/>
  <Link
        rel="patches"
        href="swid:com.acme.rms-ce-v4-1-5-0">
    ...
</SoftwareIdentity>
  • Red Hat Enterprise Linux version 8 for x86-64 architecture:

<SoftwareIdentity
                  xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
                  xml:lang="en-US"
                  name="Red Hat Enterprise Linux"
                  tagId="com.redhat.RHEL-8-x86_64"
                  tagVersion="1"
                  version="8"
                  versionScheme="multipartnumeric"
                  media="(OS:linux)">

Common Platform Enumeration

The Common Platform Enumeration scheme (CPE) is a structured naming scheme for information technology systems, software, and packages maintained by NVD. Commonly used in conjunction with the Common Vulnerabilities and Exposures identification codes (e.g. CVE-2017-0147). Despite being considered a deprecated scheme superseded by SWID, CPE is still widely used by several security solutions.

Defined as a Dictionary of registered values provided by NVD. Each CPE code can be defined as a well-formatted name or as a URL. Each value MUST follow this structure:

  • cpe-name = "cpe:" component-list

  • component-list = part ":" vendor ":" product ":" version ":" update ":" edition ":" lang

  • component-list = part ":" vendor ":" product ":" version ":" update ":" edition

  • component-list = part ":" vendor ":" product ":" version ":" update

  • component-list = part ":" vendor ":" product ":" version

  • component-list = part ":" vendor ":" product

  • component-list = part ":" vendor

  • component-list = part

  • component-list = empty

  • part = "h" / "o" / "a" = string

  • vendor = string

  • product = string

  • version = string

  • update = string

  • edition = string

  • lang LANGTAG / empty

  • string = *( unreserved / pct-encoded )

  • empty = ""

  • unreserved = ALPHA / DIGIT / "-" / "." / "_" / " ̃"

  • pct-encoded = "%" HEXDIG HEXDIG

  • ALPHA = %x41-5a / %x61-7a ; A-Z or a-z

  • DIGIT = %x30-39 ; 0-9

  • HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"

  • LANGTAG = cf. [RFC5646]

Examples

  • Microsoft Internet Explorer 8.0.6001 Beta (any edition): wfn:[part="a",vendor="microsoft",product="internet_explorer", version="8\.0\.6001",update="beta",edition=ANY] which binds to the following URL: cpe:/a:microsoft:internet_explorer:8.0.6001:beta.

  • Foo\Bar Big$Money Manager 2010 Special Edition for iPod Touch 80GB: wfn:[part="a",vendor="foo\\bar",product="big\$money_manager_2010", sw_edition="special",target_sw="ipod_touch",target_hw="80gb"], which binds to the following URL: cpe:/a:foo%5cbar:big%24money_manager_2010:::~~special~ipod_touch~80gb~.

Package URL

Package URL standardizes how software package metadata is represented so that packages can be universally located regardless of what vendor, project, or ecosystem the packages belongs.

A PURL is a valid RFC3986 ASCII string defined URL composed of seven elements. Each of them is separated by a defined character in order to make it easily manipulated by software.

scheme:type/namespace/name@version?qualifiers#subpath

The definition for each component is:

  • scheme: URL scheme compliant constant value of "pkg". (Required).

  • type: package type or package protocol such as maven, npm, nuget, gem, pypi, etc. (Required).

  • namespace: type-specific value to a package prefix such as it's owner name, groupid, etc. (Optional).

  • name: name of the package. (Required).

  • version: package version. (Optional).

  • qualifiers: extra qualifying data for a package such as an OS, architecture, a distro, etc. (Optional).

  • subpath: extra subpath within a package, relative to the package root. (Optional).

Examples

  • Curl software, packaged as a .deb package for Debian Jessie meant for an i386 architecture: pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie

  • Docker image of Apache Casandra signed with the SHA256 hash 244fd47e07d1004f0aed9c: pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c

Recommendation Uses

USE
RECOMMENDATION

Client or Server Application

CPE or SWID

Container

PURL or SWID

Firmware

CPE or SWID*

Library or Framework (package)

PURL

Library or Framework (non-package)

SWID

Operating System

CPE or SWID

Operating System Package

PURL or SWID

Note: Due to the deprecated status of CPE, industry recommended seems to be that new projects implement SWID when they need to decide between the two methods. Even though CPE is known to be a widely used naming schema within current active projects and solutions.

References

Known Implementations

PreviousReportingNextAppendix

Last updated 2 years ago

,

NISTIR 8060 - Guidelines for the Creation of Interoperable Software Identification (SWID) Tags (pdf)
NISTIR 8085 - Forming Common Platform Enumeration (CPE) Names from Software Identification (SWID) Tags
ISO/IEC 19770-2:2015 - Information technology— Software asset management—Part2:Software identification tag
Official Common Platform Enumeration (CPE) Dictionary
Common Platform Enumeration: Dictionary Specification Version 2.3
PURL Specification
packageurl-go
packageurl-dotnet
packageurl-java
package-url-java
packageurl-python
packageurl-rust
packageurl-js