CWE – Common Weakness Enumeration


The Common Weakness Enumeration Specification (CWE) provides a common language of discourse for discussing, finding and dealing with the causes of software security vulnerabilities as they are found in code, design, or system architecture. Each individual CWE represents a single vulnerability type. CWE is currently maintained by the MITRE Corporation with support from the National Cyber Security Division (DHS). A detailed CWE list is currently available at the MITRE website; this list provides a detailed definition for each individual CWE. 

All individual CWEs are held within a hierarchical structure that allows for multiple levels of abstraction. CWEs located at higher levels of the structure (i.e. Configuration) provide a broad overview of a vulnerability type and can have many children CWEs associated with them. CWEs at deeper levels in the structure (i.e.Cross Site Scripting) provide a finer granularity and usually have fewer or no children CWEs. The image to the right represents a portion of the overall CWE structure, the red boxes represent the CWEs being used by NVD. (click to enlarge).

NVD integrates CWE into the scoring of CVE vulnerabilities by providing a cross section of the overall CWE structure. NVD analysts score CVEs using CWEs from different levels of the hierarchical structure. This cross section of CWEs allows analysts to score CVEs at both a fine and coarse granularity, which is necessary due to the varying levels of specificity possessed by different CVEs. The cross section of CWEs used by NVD is listed below; each CWE listed links to a detailed description hosted by MITRE. For a better understanding of how the standards link together please visit: MITRE – Making Security Measurable

CWE is not currently part of the Security Content Automation Protocol (SCAP). NVD is using CWE as a classification mechanism that differentiates CVEs by the type of vulnerability they represent.

Related Activities

CWE Cross Section Mapped into by NVD

Name CWE-ID Description
Authentication Issues CWE-287 Failure to properly authenticate users.
Credentials Management CWE-255 Failure to properly create, store, transmit, or protect passwords and other credentials.
Permissions, Privileges, and Access Control CWE-264 Failure to enforce permissions or other access restrictions for resources, or a privilege management problem.
Buffer Errors CWE-119 Buffer overflows and other buffer boundary errors in which a program attempts to put more data in a buffer than the buffer can hold, or when a program attempts to put data in a memory area outside of the boundaries of the buffer.
Cross-Site Request Forgery (CSRF) CWE-352 Failure to verify that the sender of a web request actually intended to do so. CSRF attacks can be launched by sending a formatted request to a victim, then tricking the victim into loading the request (often automatically), which makes it appear that the request came from the victim. CSRF is often associated with XSS, but it is a distinct issue.
Cross-Site Scripting (XSS) CWE-79 Failure of a site to validate, filter, or encode user input before returning it to another user’s web client.
Cryptographic Issues CWE-310 An insecure algorithm or the inappropriate use of one; an incorrect implementation of an algorithm that reduces security; the lack of encryption (plaintext); also, weak key or certificate management, key disclosure, random number generator problems.
Path Traversal CWE-22 When user-supplied input can contain “..” or similar characters that are passed through to file access APIs, causing access to files outside of an intended subdirectory.
Code Injection CWE-94 Causing a system to read an attacker-controlled file and execute arbitrary code within that file. Includes PHP remote file inclusion, uploading of files with executable extensions, insertion of code into executable files, and others.
Format String Vulnerability CWE-134 The use of attacker-controlled input as the format string parameter in certain functions.
Configuration CWE-16 A general configuration problem that is not associated with passwords or permissions.
Information Leak / Disclosure CWE-200 Exposure of system information, sensitive or private information, fingerprinting, etc.
Input Validation CWE-20 Failure to ensure that input contains well-formed, valid data that conforms to the application’s specifications. Note: this overlaps other categories like XSS, Numeric Errors, and SQL Injection.
Numeric Errors CWE-189 Integer overflow, signedness, truncation, underflow, and other errors that can occur when handling numbers.
OS Command Injections CWE-78 Allowing user-controlled input to be injected into command lines that are created to invoke other programs, using system() or similar functions.
Race Conditions CWE-362 The state of a resource can change between the time the resource is checked to when it is accessed.
Resource Management Errors CWE-399 The software allows attackers to consume excess resources, such as memory exhaustion from memory leaks, CPU consumption from infinite loops, disk space consumption, etc.
SQL Injection CWE-89 When user input can be embedded into SQL statements without proper filtering or quoting, leading to modification of query logic or execution of SQL commands.
Link Following CWE-59 Failure to protect against the use of symbolic or hard links that can point to files that are not intended to be accessed by the application.
Other No Mapping NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Not in CWE No Mapping The weakness type is not covered in the version of CWE that was used for mapping.
Insufficient Information No Mapping There is insufficient information about the issue to classify it; details are unkown or unspecified.
Design Error No Mapping A vulnerability is characterized as a “Design error” if there exists no errors in the implementation or configuration of a system, but the initial design causes a vulnerability to exist.


  • admin 

Tipicamente siempre hemos trabajado con Soap con la seguridad garantizada mediante encriptación en el tunel o mediante https. Recientemente nos encontramos con que la seguridad se garantiza mediante el uso de los mecanismos mencionados, además del uso de certificados.

Adjuntaré artículos explicativos sobre esta nueva situación.


From Wikipedia, the free encyclopedia

WS-Security (Web Services Security, short WSS) is a flexible and feature-rich extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specificationsand was published by OASIS.

The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.


  • 1 Features
  • 2 Use Cases
    • 2.1 Transport Layer Security (Without WS-Security)
    • 2.2 End-to-end security
    • 2.3 Non-Repudiation
    • 2.4 Alternative transport bindings
    • 2.5 Reverse proxy/common security token
  • 3 Issues
  • 4 Performance
  • 5 History
  • 6 Associated specifications
  • 7 See also
  • 8 Alternative
  • 9 External links
  • 10 References


WS-Security describes three main mechanisms:

  • How to sign SOAP messages to assure integrity. Signed messages provide also non-repudiation.
  • How to encrypt SOAP messages to assure confidentiality.
  • How to attach security tokens to ascertain the sender’s identity .

The specification allows a variety of signature formats, encryptions algorithms and multiple trust domains, and is open to various security token models, such as:

  • X.509 certificates
  • Kerberos tickets
  • UserID/Password credentials
  • SAML-Assertion
  • Custom defined token

The token formats and semantics are defined in the associated profile documents.

WS-Security incorporates security features in the header of a SOAP message, working in the application layer.

These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies. In general, WSS by itself does not provide any guarantee of security. When implementing and using the framework and syntax, it is up to the implementor to ensure that the result is not vulnerable.

Key management, trust bootstrapping, federation and agreement on the technical details (ciphers, formats, algorithms) is outside the scope of WS-Security.

Use Cases

Transport Layer Security (Without WS-Security)

The typical SOAP use case with a communication between trusted peers (using HTTPS) does not need WS-Security at all. It is described in Alternative, and reduces complexity and improves performance.

End-to-end security

If a SOAP intermediary is required, and the intermediary is not or less trusted, messages need to be signed and optionally encrypted. This might be the case of an application level proxy at a network perimeter, that will terminate TCP connections.


The standard method for non-repudiation is to write transactions to an audit trail, that is subject to specific security safeguards. However, if the audit trail is not sufficient, digital signatures may provide a better method to enforce non-repudiation. WS-Security can provide this.

Alternative transport bindings

Although almost all SOAP services implement HTTP bindings, in theory other bindings such as JMS or SMTP could be used; in this case end-to-end security would be required.

Reverse proxy/common security token

Even if the web service relies upon transport layer security, it might be required for the service to know about the end user, if the service is relayed by a (HTTP-) reverse proxy. A WSS-header could be used to convey the end user’s token, vouched for by the reverse proxy.


  • If there are frequent message exchanges between service provider and consumer, the overhead of XML SIG and XML ENC are significant. If end-to-end security is required, a protocol like WS-SecureConversation may reduce the overhead. If sufficient, use only encryption or signing, as the combination of both is significantly slower than the mere sum of the single operations. SeePerformance below.
  • The merging of several XML-schemata like SOAP, SAML, XML ENC, XML SIG might cause dependencies on different versions of library functions like canonicalization and parsing, that are difficult to manage in an application server.


WS-Security adds significant overhead to SOAP-processing due to the increased size of the message on the wire, XML and cryptographic processing, requiring faster CPUs and more memory and bandwidth.

An evaluation in 2005 [1] measured 25 types of SOAP messages of different size and complexity processed by WSS4J with both WS-Security and WS-SecureConversation on a Pentium 4/2,8 GHz CPU. Some findings were:

  • Encryption was faster than signing
  • Encryption and signing together were 2-7 times slower than signing alone and produced significantly bigger documents.
  • Depending on the type of message, WS-SecureConversation either made no difference or reduced processing time by half in the best case.
  • It took less than 10 milliseconds to sign or encrypt up to an array of 100 kilo bytes, but it took about 100~200 to perform the security operations for SOAP.

Another benchmark in 2006[2] resulted in this comparison:

Security Mechanism Messages/second
WS-Security (X.509) XML Signature & Encryption 352
WS-SecureConversation XML Signature & Encryption 798
Transport Layer Security 2918


Web services initially relied on the underlying transport security. In fact, most implementations still do[citation needed]. As SOAP allows for multiple transport bindings, such as HTTP and SMTP, an SOAP-level security mechanism was needed. The lack of end-to-end security because of the dependence on transport security was another factor.

The protocol was originally developed by IBM, Microsoft, and VeriSign. Their original specification[3][4] was published on April 5, 2002, and was followed up by an addendum[5] on August 18, 2002.

In 2002, 2 proposals were submitted to the OASIS WSS Technical Committee[6]: Web Service Security (WS-Security) and Web Services Security Addendum. As a result, WS-Security was published:

  • WS-Security 1.0 was released on April 19, 2004
  • Version 1.1 was released on February 17, 2006

The version 1.0 standard published by OASIS contained a number of significant differences to the standard proposed by the IBM, Microsoft and VeriSign consortium. Many systems were developed using the proposed standard and the differences made them incompatible with systems developed to the OASIS standard.

Some refer to the pre-OASIS specification as the «WS-Security Draft 13»[7], or as the Web Services Security Core Specification. However these names are not widely known and indeed today it is hard to clearly identify whether an application or server is using a pre- or post-OASIS specification. Most forum posts use the keyword «WSSE» to refer to the pre-OASIS version because it mandated the use of a «wsse» XML namespace prefix to the url (and similar urls of different versions).

The protocol is currently officially called WSS and developed via committee in Oasis-Open.

Associated specifications

The following draft specifications are associated with WS-Security:

  • WS-Federation
  • WS-Privacy
  • WS-Test

The following approved specifications are associated with WS-Security:

  • WS-Policy
  • WS-Trust
  • WS-SecureConversation

See also

  • .NET Web Services Enhancements
  • List of Web service specifications (WS-*)
  • SAML
  • WS-I Basic Security Profile
  • Web service
  • X.509
  • XML Encryption
  • XML firewall


In point-to-point situations confidentiality and data integrity can also be enforced on Web services through the use of Transport Layer Security (TLS), for example, by sending messages over https. WS-Security however addresses the wider problem of maintaining integrity and confidentiality of messages until after a message was sent from the originating node, providing so called end to end security.

Applying TLS can significantly reduce the overhead involved by removing the need to encode keys and message signatures into XML before sending. A challenge in using TLS would be if messages needed to go through an application level proxy server, as it would need to be able to see the request for routing. In such an example, the server would see the request coming from the proxy, not the client; this could be worked around by having the proxy have a copy of the client’s key and certificate, or by having a signing certificate trusted by the server, with which it could generate a key/certificate pair matching those of the client. However, as the proxy is operating on the message, it does not ensure end-to-end security, but only ensures point-to-point security.

External links

  • OASIS Web Services Security TC (Contains links to download specification documents)
  • WS-Security Specification (IBM)
  • WS-I Basic Security Profile
  • Web Services Security Documentation
  • Web Service Security Patterns (Microsoft)
  • WSS4J (WS-Security Java Implementation from Apache)
  • Apache Rampart (WS-Security Java Implementation from Apache Axis2)
  • WSIT Web Services Interoperability Technologies (WSIT) that enable interoperability between the Java platform and Windows Communication Foundation (WCF)
  • python ws-security example


  1. ^ Hongbin Liu, Shrideep Pallickara, Geoffrey Fox: Performance of Web Services Security
  2. ^ Francois Lascelles, Aaron Flint: WS Security Performance. Secure Conversation versus the X509 Profile
  3. ^ Bob Atkinson, et. al.: Web Services Security (WS-Security)
  4. ^ Bob Atkinson, et. al.: Web Services Security (WS-Security)
  5. ^ Giovanni Della-Libera, Phillip Hallam-Baker Maryann Hondo: Web Services Security Addendum
  6. ^ OASIS Web Services Security TC
  7. ^ Web Services Security: SOAP Message Security – Working Draft 13