├── LICENSE.md ├── README.md └── vrdb.json /LICENSE.md: -------------------------------------------------------------------------------- 1 | # Vulnerability Reporting Database License 2 | 3 | This project uses the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) License. 4 | 5 | http://creativecommons.org/licenses/by-sa/3.0/ 6 | 7 | Some vulnerability descriptions are taken from OWASP directly, some modified, and some are written by the authors. 8 | 9 | OWASP - https://www.owasp.org/index.php/Main_Page 10 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Vulnerability Reporting Database 2 | 3 | This is an open-source, vulnerability reporting database. The idea is to have a standard database for pentesters and vulnerability assessors to be able to reference while writing reports. Most vendors have a standard descriptions for any given vulnerability, this is to make an open source version. 4 | 5 | The idea is to take OWASP vulnerabilities (a good standard for Web App vulns), and add in vulns for other architectures (thick client, SAP, infrastructure, network, etc.) 6 | 7 | The vrdb is written in JSON, so that data can easily be added and read from it in a variety of languages, but it remains human readable with just a text editor (unlike a SQL database.) If the database ever becomes too large and slow for JSON parsers, it may have to be switched over to SQL or something more efficient. 8 | -------------------------------------------------------------------------------- /vrdb.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Name": "Abuse of Functionality", 4 | "Description": "Abuse of functionality, sometimes referred to as a 'business logic attack', depends on the design and implementation for application functions and features. As functionality is added to applications, thought must be given to how the function or feature can be manipulated to circumvent the business process, or abused to perform a function not intended by the developer.", 5 | "Implication": "An attacker can abuse the functionality within the application to perform undesired actions.", 6 | "Solution": "Robust threat modeling exercises should be performed for each application feature to enumerate ways that attackers can abuse the feature. All functions and features of the application should be tested against a comprehensive set of use and abuse cases to ensure that the application enables only the intended functionality and no more.", 7 | "Likelihood": "MEDIUM", 8 | "Impact": "MEDIUM", 9 | "Risk": "MEDIUM", 10 | "Types": "Web" 11 | }, 12 | { 13 | "Name": "Application Misconfiguration", 14 | "Description": "Software applications are very complex; to ease installation and configuration of the application, many software packages come preconfigured with vulnerabilities right out of the box. Application misconfigurations are not coding issues. They are options and/or features in the application that can be easily exploited, such as: Special access mechanisms Default usernames and passwords Default configuration file settings Security settings at the lowest possible level Due to the complexity of configuration, certain combinations of settings might expose vulnerabilities, though each individual setting may be safe on its own.", 15 | "Implication": "An attacker can leverage poor configurations to get a large amount of attack surfaces, such as insufficient authorization (default credentials), or sniff traffic (running with non-encrypted network traffic).", 16 | "Solution": "All application permissions, configurable components and files should be given least privilege for the specific platform and technology stack. The application should prominently warn users/administrators when an insecure setting is in use (as it might be temporarily during deployment or in a staging environment).", 17 | "Likelihood": "MEDIUM", 18 | "Impact": "MEDIUM", 19 | "Risk": "MEDIUM", 20 | "Types": [ 21 | "Web", 22 | "Thick", 23 | "Network" 24 | ] 25 | }, 26 | { 27 | "Name": "Brute Force Login", 28 | "Description": "The application does not prevent attackers from trying many username/password combinations in rapid succession in order to guess account credentials.", 29 | "Implication": "Attackers may be able to discover valid credentials.", 30 | "Solution": "The framework should track failed login attempts even for non-existent accounts, so that the lockout feature doesn't expose an account enumeration vulnerability. The framework should track all unique accounts tried unsuccessfully for a particular password, using a hash of the password with a static salt as a key to prevent password exposure. When the threshold is reached, the application should prevent all logins using that password to any account, much like the account lockout. The framework should be capable of sending notifications to perimeter technologies to help enforce lockouts or global CAPTCHA. The lockout period should only be temporary, so as to prevent long-term denial of service against a user account. The framework should provide an interface for an administrator or customer service representative to white-list IPs for an account to log in from, in case of a targeted, sustained, long-term denial of service attack against a specific user. The framework should expose and implement configurable rules about failed login attempts with secure defaults.", 31 | "Likelihood": "LOW", 32 | "Impact": "HIGH", 33 | "Risk": "MEDIUM", 34 | "Types": "Web" 35 | 36 | }, 37 | { 38 | "Name": "Brute Force (generic) / Insufficient Anti-automation", 39 | "Description": "Applications do not define or detect when request rates are outside the bounds of normal, acceptable use.", 40 | "Implication": "Depending on what is being automated, an attacker may be able to send tons of requests that notify users, fill a database with data, or hog system resources.", 41 | "Solution": "Perimeter technologies including geocaching/proxy services must support automatic and/or manual 'panic button' anti-automation, enforcing progressive CAPTCHA for unvalidated requests, triggering on excessive 5XX responses, or direct signal from application.", 42 | "Likelihood": "LOW", 43 | "Impact": "MEDIUM", 44 | "Risk": "LOW", 45 | "Types": [ 46 | "Web", 47 | "Thick" 48 | ] 49 | }, 50 | { 51 | "Name": "Brute Force Session Identifier", 52 | "Description": "Session tokens are generated in a predictable fashion or from a key space that is too small to prevent guessing a token in reasonable time. The application does not detect and prevent session brute forcing attempts.", 53 | "Implication": "Attackers may be able to guess session identifiers, and then be authenticated as another user. This would allow the attacker to act as another user.", 54 | "Solution": "Ensure that session identifiers are created using a secure random algorithm, with enough entropy to make guessing infeasible during the average lifetime of a session. The framework should check that an active session does not already exist with the same ID as a newly generated session token before issuing the token. The application should be configurable to tie session IDs to SSL sessions, tracking those sessions across renegotiations. Any token which is sent over an SSL connection that isn't currently tied to the token should be expired immediately and the associated session terminated or suspended until the client successfully reauthenticates. The application should be configurable to tie session IDs to source IP addresses, and terminate/suspend any active session if subsequent requests originate from a different IP. The configuration should allow the setting to be enabled globally, or on a per-user or per-session basis. (Users may choose to 'opt in' to the restriction if they know their IP address is unlikely to change during the session.) The application should track the number of requests made with invalid/expired session IDs and alert or block requests based on a configurable rate limit. Malicious actors may be identified by source IP address, a combination of browser fingerprinting features, or other configurable fraud metrics.", 55 | "Likelihood": "MEDIUM", 56 | "Impact": "HIGH", 57 | "Risk": "HIGH", 58 | "Types": "Web" 59 | 60 | }, 61 | { 62 | "Name": "Brute Force Predictable Resource Location", 63 | "Description": "Server-side resources including admin pages, file backups, uploaded files, logs, and sample files exist in easy-to-guess locations. Data resources are often referenced by their auto-incremented primary key, making it easy for attackers to guess other valid values or infer transaction volumes.", 64 | "Implication": "An attacker may be able to guess the location of some sensitive files. These files could do anything from reveal software versions to allow acccess to sensitive functionality.", 65 | "Solution": "The custom framework should enforce authentication/authorization checks on all dynamic content. Custom administrative interfaces should be built on top of generic framework administrative access platform, segregated from user interfaces.", 66 | "Likelihood": "LOW", 67 | "Impact": "LOW", 68 | "Risk": "LOW", 69 | "Types": "Web" 70 | 71 | }, 72 | { 73 | "Name": "Buffer Overflow", 74 | "Description": "The application allows an attacker to supply more data than will fit in a pre-allocated block of memory and overwrite existing instructions or data.", 75 | "Implication": "The attacker is able to inject too much data into the application. This can lead to application crashes, or in some cases, add executable code after the buffer.", 76 | "Solution": "The framework should be built on a memory-managed platform which prohibits direct memory access.", 77 | "Likelihood": "HIGH", 78 | "Impact": "VERY HIGH", 79 | "Risk": "VERY HIGH", 80 | "Types": [ 81 | "Web", 82 | "Thick" 83 | ] 84 | 85 | }, 86 | { 87 | "Name": "Clickjacking", 88 | "Description": "A web application does not prevent itself from being framed into another application. This allows it to be framed into the application, and an attacker can use this to either hide the target application within an invisible frame, and pass clicks to it, or to put content on top of th", 89 | "Implication": "The attacker can use the invisible frame to 'pass' clicks to the target site. This can trick users into performing actions they otherwise would not, and bypass anti-CSRF nonces. If an attacker chooses to place content on top of the frame, the attacker can spoof an authentication box on top of the application, tricking users into revealing their credentials.", 90 | "Solution": "Apply either an X-Frame-Options header, with a value of 'DENY' or 'SAMEORIGIN'. The framework should also check the User Agent from each request, and if the User Agent does not support X-Frame-Options or Content Security Policy, then it should either insert Framebusting code, or redirect to a Browser upgrade page. Content Security Policy is a more robust solution than X-Frame-Options, but is not yet fully standardized across all browsers.", 91 | "Likelihood": "MEDIUM", 92 | "Impact": "MEDIUM", 93 | "Risk": "MEDIUM", 94 | "Types": "Web" 95 | 96 | }, 97 | { 98 | "Name": "Content Spoofing", 99 | "Description": "The application displays user-defined content in the URL or page body in a way that makes it appear to be legitimate site content.", 100 | "Implication": "An attacker can trick users into thinking that a site has some content. This is usually used in social engineering attacks. The attacker will post a fake support email, and harvest credentials, or point users to another site, causing the victim site to lose traffic.", 101 | "Solution": "Do not reflect user-passed data onto the page or URL. This includes sanitizing redirection URLs, and protecting the page from outputs. If user content is to be put onto the page, then it must be placed on the page in a manner that it does not appear to be official content from the site. Content Spoofing commonly occurs in error messages. A blanket, customized 40X status message can help prevent this.", 102 | "Likelihood": "LOW", 103 | "Impact": "MEDIUM", 104 | "Risk": "MEDIUM", 105 | "Types": "Web" 106 | 107 | }, 108 | { 109 | "Name": "Cookie Theft / Session Hijacking", 110 | "Description": "It's possible for an attacker to steal and reuse session identifiers or other sensitive cookie values when they are stored or transmitted insecurely.", 111 | "Implication": "An attacker can access the application as if they are another user. This allows them to perform actions as that user, using that user's session token.", 112 | "Solution": "Apply Secure and HttpOnly flags to all cookies. Do not track sessions in the URL, and do not allow concurrent sessions on the application. If a concurrent session occurs, deauthenticate the oldest session, and inform the user that a login was detected on another device.", 113 | "Likelihood": "MEDIUM", 114 | "Impact": "HIGH", 115 | "Risk": "HIGH", 116 | "Types": "Web" 117 | 118 | }, 119 | { 120 | "Name": "Cross-Site Request Forgery", 121 | "Description": "A vulnerable application processes a transaction using an existing session, without verifying that the transaction was intended to be initiated by the user and not a malicious 3rd-party site. This is done by using a third party site to send a request to the victim site, and using the browser to attach cookies stored for that site with the request. If a request is predictable, then an attacker can force a victim user to send a request, and perform an action on the victim site.", 122 | "Implication": "The attacker can force users to perform undesired actions. These can range from deleting other users, adding the attacker to a privileged user group, transfering funds, or making an order.", 123 | "Solution": "Automatically generate and check randomized tokens for all POST requests by default. This token should be a new, random token for every sensitive request. Tokens should not be allowed cross-session, either. Disallow state changes via GET requests, enforcing RFC.", 124 | "Likelihood": "MEDIUM", 125 | "Impact": "HIGH", 126 | "Risk": "HIGH", 127 | "Types": "Web" 128 | 129 | }, 130 | { 131 | "Name": "Cross-Site Scripting", 132 | "Description": "Cross-Site Scripting (aka XSS) is an injection attack that occurs when an application accepts untrusted data and includes it in the context of an HTML page. An attacker uses the injection to place JavaScript (or other client-side script) into the page, causing it to be exxecuted by the user. This can be either a reflected injection, or stored. Reflected XSS occurs when a part of a request is reflected onto the page. Stored XSS occurs when malicious data is stored somewhere in the application, then executed when users view the stored data (I.E. in a comment section or profile).", 133 | "Implication": "The attacker can run scripts on a victim machine, in the context of the web application. This allows the attacker to steal cookies, steal data from the browser, perform CSRF attacks on the page more easily, or use social engineering by faking Plugin updates or creating messages for the users.", 134 | "Solution": "All data from the client-side should be sanitized (using a Whitelist, not a blacklistof unstrusted data) upon input. Also, data should be output encoded to ensure that it is not read as application code. Note that output encoding should not replace data sanitization.", 135 | "Likelihood": "HIGH", 136 | "Impact": "HIGH", 137 | "Risk": "HIGH", 138 | "Types": "Web" 139 | 140 | }, 141 | { 142 | "Name": "Cross-Site Scripting (DOM Based)", 143 | "Description": "Client-side code (e.g. JavaScript) inserts attacker-controlled data into the DOM in a way that allows the data to be executed as functional code. Examples include using document.write, which can introduce SCRIPT nodes directly, and modifying innerHTML or other element attributes that can cause SCRIPT nodes to be generated or function definitions to be overwritten. DOM-Based XSS differs from other forms of cross-site scripting which are the result of vulnerable server-side code.", 144 | "Implication": "The attacker can run scripts on a victim machine, in the context of the web application. This allows the attacker to steal cookies, steal data from the browser, perform CSRF attacks on the page more easily, or use social engineering by faking Plugin updates or creating messages for the users.", 145 | "Solution": "'Web 2.0' (dynamic) frameworks must expose an API for page creation/modification that does not use document.write/ln or allow dynamic data to be injected into innerHTML or similar DOM element attributes. Dynamic data must be written to the DOM by using createTextNode, which does not introduce the danger of interpreting user data as functional code.", 146 | "Likelihood": "HIGH", 147 | "Impact": "HIGH", 148 | "Risk": "HIGH", 149 | "Types": "Web" 150 | 151 | }, 152 | { 153 | "Name": "Denial of Service (Application Based)", 154 | "Description": "The root cause of an Application Based denial of service is when an attacker uses/exhausts/depletes all of the resources (such as bandwidth, database connections, disk storage, CPU, memory, threads, or application specific resources) on a system preventing legitimate users from using the system. To prevent depletion of resources the application must restrict the size or amount of resources that are requested or used.", 155 | "Implication": "An attacker can prevent valid users from being able to use the application. As such, users may become frustrated and use an alternative application, or may not be able to complete critical tasks on time.", 156 | "Solution": "Perimeter technologies including geocaching/proxy services must support automatic and/or manual 'panic button' anti-automation, enforcing progressive CAPTCHA for unvalidated requests, triggering on excessive 5XX responses, or direct signal from application. In addition to Perimeter solutions, the application can use Profile resource-dependent transactions and build transaction queues and alerting when queues reach thresholds. Enforce transaction-based rate limits.", 157 | "Likelihood": "MEDIUM", 158 | "Impact": "MEDIUM", 159 | "Risk": "MEDIUM", 160 | "Types": [ 161 | "Web", 162 | "Thick" 163 | ] 164 | 165 | }, 166 | { 167 | "Name": "Denial of Service (Connection-Based)", 168 | "Description": "Applications are generally not designed to recognize and handle deliberately slowed connections or other abuses of HTTP below Layer 7. Some types of attacks won't even reach the application code because they prevent the web server from effectively processing requests.", 169 | "Implication": "An attacker can prevent users from accessing the application by attacking the server and infrastructure.", 170 | "Solution": "Perimeter technologies should detect an event where many TCP or HTTP connections are opened but no data are sent (or sent at very slow speeds) over these connections. These connections should be dropped during the event, only allowing normal-data-rate connections to persist during the event. Perimeter technologies should also detect an event where multiple uniquely-identifiable clients open more than the two connections allowed by HTTP standards and refuse these clients during the event. Clients can be identified by a unique username/authorization token, or a combination of unique attributes such as IP address and User-Agent", 171 | "Likelihood": "MEDIUM", 172 | "Impact": "MEDIUM", 173 | "Risk": "MEDIUM", 174 | "Types": [ 175 | "Web", 176 | "Thick", 177 | "Network" 178 | ] 179 | 180 | }, 181 | { 182 | "Name": "Directory Indexing", 183 | "Description": "A misconfigured server can show a directory listing, which could potentially yield sensitive information to an attacker.", 184 | "Implication": "An attacker can find files, or gain information on the server. If sensitive files arcessed in the directory, the attacker may be able to access files they otherwise would not have found.", 185 | "Solution": "Disable directory listings in the web server by default. Alternately, though less efficient, create an index file in each directory where Indexing should not be accessed.", 186 | "Likelihood": "LOW", 187 | "Impact": "LOW", 188 | "Risk": "LOW", 189 | "Types": "Web" 190 | 191 | }, 192 | { 193 | "Name": "Fingerprinting", 194 | "Description": "One or several components of the underlying software and framework leak version information. This could help an attacker to identify which components are vulnerable. This issue is mitigated by removing all version information. This can be as simple as server version headers in the response, or checking the hash of a file or image returned.", 195 | "Implication": "The attacker can gain a better understanding of the underlying architecure. This can lead to better crafted attacks.", 196 | "Solution": "Infrastructure should not leak information which can be used to identify the specific version of platform or infrastructure technology. Perimeter technologies should strip all such version information from outgoing responses. URL structure should not reveal the underlying technology. Default content should be removed when possible. Make sure that only generic error pages are shown without showing any information of the underlying system. Remove all development and debugging tools.", 197 | "Likelihood": "LOW", 198 | "Impact": "LOW", 199 | "Risk": "LOW", 200 | "Types": "Web" 201 | 202 | }, 203 | { 204 | "Name": "Format String", 205 | "Description": "The root cause of the format string is attacker having the ability to control or write completely the format string used to format data input for some functions. (C, C++, and Assembly functions such as fprintf, printf, sprintf, setproctitle, and syslog are common victims) potentially leading to buffer overflows or data representation problems.", 206 | "Implication": "An attacker may be able to overwrite format strings, potentially causing a buffer overflow. This can lead to Buffer Overflow vulnerabilities.", 207 | "Solution": "Alert and/or block on known format string signatures Generic Framework Solution Prohibit access to vulnerable APIs and provide safe wrappers of those APIs instead.", 208 | "Likelihood": "LOW", 209 | "Impact": "MEDIUM", 210 | "Risk": "MEDIUM", 211 | "Types": "Web" 212 | 213 | }, 214 | { 215 | "Name": "HTTP Request / Response Smuggling", 216 | "Description": "Malformed HTTP requests and responses are interpreted differently by proxies, web servers, or other systems which process HTTP along the request/response path. This can allow a request or response to bypass proxy filters or rules, poison caches, or cause the response from one request to be incorrectly matched with another.", 217 | "Implication": "An attacker may be able to force the wrong response onto another user, or even bypass certain proxy filters, and therefore bypassing certain restrictions built into the application architechture.", 218 | "Solution": "Sanitize all HTTP headers, especially duplicates, by enforcing strict adherence to RFC. Sanitize both HTTP requests and response bodies, ensuring exact correspondence between Content-Length headers and body lengths. Avoid HTTP connection sharing. Enforce SSL to prevent proxy tampering. Provide configuration option to silently sanitize malformed data or return a 5XX error response.", 219 | "Likelihood": "LOW", 220 | "Impact": "HIGH", 221 | "Risk": "MEDIUM", 222 | "Types": "Web" 223 | 224 | }, 225 | { 226 | "Name": "HTTP Response Splitting", 227 | "Description": "The application allows CRLF characters to be injected into HTTP response headers, which allows an attacker to inject a malicious response body in place of the intended response or force a redirect to a malicious resource.", 228 | "Implication": "An attacker may be able to split responses, adding content to the body, which could allow for client side code injection or content spoofing. They may also be able to perform Response Smuggling by splitting one response into two.", 229 | "Solution": "Encode all CRLF pairs in dynamic data before writing the data in the context of an HTTP response header. Prevent direct access to response headers by forcing all header write requests to use a safe API", 230 | "Likelihood": "LOW", 231 | "Impact": "HIGH", 232 | "Risk": "MEDIUM", 233 | "Types": "Web" 234 | 235 | }, 236 | { 237 | "Name": "Improper Filesystem Permissions", 238 | "Description": "The root cause of improper filesystem permissions is having incorrect filesystem permissions such as read, write, modify, or execute set on files, folders, and symbolic links. These improper permissions allow the attacker to access restricted files or directories and modify or delete their contents.", 239 | "Implication": "An attacker may be able to access, read, write to, delete, or execute from otherwise restricted files on the file system.", 240 | "Solution": "Ensure that proper file and directory permissions are applied. Enforce stricter default permissions.", 241 | "Likelihood": "LOW", 242 | "Impact": "MEDIUM", 243 | "Risk": "MEDIUM", 244 | "Types": "Web" 245 | 246 | }, 247 | { 248 | "Name": "Improper Input Handling", 249 | "Description": "The root cause of improper input handling is the application trusting, not validating or not correctly validating inputs. All inputs should be considered untrusted as they can come from a variety of mechanisms including human, browsers or devices, transferred in various formats and come in many formats. Accepting untrusted input may leave the application vulnerable to attacks such as Buffer Overflows, SQL Injection, OS Commanding, or Denial of Service.", 250 | "Implication": "An attacker may be able to abuse the improperly handled input to perform an injection attack (such as SQL injection, XSS, or Remote Code Execution).", 251 | "Solution": "Provide canonicalization and positive validation APIs for custom data types, strictly enforcing business rules, with configurable rules to reject or sanitize bad data.", 252 | "Likelihood": "MEDIUM", 253 | "Impact": "HIGH", 254 | "Risk": "HIGH", 255 | "Types": "Web" 256 | 257 | }, 258 | { 259 | "Name": "Improper Output Handling", 260 | "Description": "The root cause of improper output handling is an application passing along data and not interrogated consistently through mechanisms such as filtering or sanitization. Improper output handling can occur while passing data to applications or between tiers within an application architecture. Not validating output data may allow an application to pass along improper output encoding or escaping, invalid data, incorrect data, or malicious content to the consumer.", 261 | "Implication": "An attacker may be able to force a part of the application to handle improperly formatted data. This could lead to bad data being passed to a user, ultimately either executing or breaking parts of the application.", 262 | "Solution": "Provide context-sensitive encoders for all common data types in all output contexts, ensuring no custom code can write directly to output.", 263 | "Likelihood": "LOW", 264 | "Impact": "MEDIUM", 265 | "Risk": "MEDIUM", 266 | "Types": "Web" 267 | 268 | }, 269 | { 270 | "Name": "Information Leakage", 271 | "Description": "The application discloses sensitive/classified data or useful data about the application that can be used for targeted attacks, even though the developer did not intend for the data to be disclosed. This is often architecture information (Internal IP addresses, internal file paths, SQL Syntax with Database information, Stack traces, or back-end code).", 272 | "Implication": "An attacker may be able to hone their attack further based on additional information gained from this leak.", 273 | "Solution": "Alert, block, or automatically sanitize classified data in responses. Automatically scrub HTML, JavaScript, CSS, and other data formats of comment data. Configure the platform to return generic error codes by default and log locally. Disable stack traces in production; show a generic error page instead. Generic Framework Solution. Provide common error-handling framework and APIs which take two error messages as parameters: one to be displayed to the user and one to be written to logs. Block file paths from being displayed by default", 274 | "Likelihood": "INFO", 275 | "Impact": "INFO", 276 | "Risk": "INFO", 277 | "Types": "Web" 278 | 279 | }, 280 | { 281 | "Name": "Insufficient Authentication / Authorization", 282 | "Description": "Incorrect verification of identity and permissions can result in an unauthorized attacker accessing sensitive data or functionality. This can be something as simple as an attacker guessing what Admin functionality is called, and loading it directly (even without a link to it), or an attacker changing the username on a 'Change Password' functionality and having it accepted by the application. It is a mismanagement of authorization.", 283 | "Implication": "An attacker can perform actions that they are not supposed to, or perform actions and view, delete, write data they should not have access to.", 284 | "Solution": "Enforce a proven authentication and authorization framework scheme which emphasizes policy-based configuration files over hard-coded authentication/authorization checks wherever possible. Deny all access by default, and explicitly grant access per resource. Enforce data storage outside of web roots to prevent requests which bypass the application's access control policy.", 285 | "Likelihood": "MEDIUM", 286 | "Impact": "HIGH", 287 | "Risk": "HIGH", 288 | "Types": "Web" 289 | }, 290 | { 291 | "Name": "Insufficient Data Protection", 292 | "Description": "Sensitive data is not sufficiently protected against disclosures, modification, or non-repudiation. This can be anything from PII not being encrypted properly, to a lack of eavesdropping preventions.", 293 | "Implication": "An attacker may be able to read or modify sensitive data.", 294 | "Solution": "Provide a configuration-based suite of encryption utilities for all data security needs. This includes safeguards to prevent tampering and eavesdropping. In addition to this, all sensitive data have as little information stored as possible. All sensitive data will need to be identitifed and protected using these measures.", 295 | "Likelihood": "LOW", 296 | "Impact": "LOW", 297 | "Risk": "LOW", 298 | "Types": "Web" 299 | 300 | }, 301 | { 302 | "Name": "Insufficient Password Recovery", 303 | "Description": "Weak password recovery processes allow stronger password authentication schemes to be bypassed. Non-existent password recovery processes are expensive to support or result in denial-of-service conditions. These weak processes are often the fault of either being able to change passwords in-band, or having weak security questions to unlock an account.", 304 | "Implication": "An attacker may be able to fully take over accounts.", 305 | "Solution": "Require users to use strong, single-use tokens to recover their passwords. These should be sent to the user out-of-band, and should become unusable if the user does not use them within a set time. In addition to these recommendations, if Security Questions are used, they must be questions with answers that are hard to guess, easy to remember, and have many possible answers.", 306 | "Likelihood": "LOW", 307 | "Impact": "HIGH", 308 | "Risk": "MEDIUM", 309 | "Types": "Web" 310 | 311 | }, 312 | { 313 | "Name": "Insufficient Process validation", 314 | "Description": "The application fails to enforce business process rules, such as ordering of multi-step form submission or conditions on asynchronous transactions.", 315 | "Implication": "An attacker may be able to bypass certain requirements on forms, or change data unexpectedly from an interface that was not meant to be accessed a certain way.", 316 | "Solution": "Developers must remember to explicitly enforce all business and process rules for every transaction, including every individual step of a multi-step transaction.", 317 | "Likelihood": "LOW", 318 | "Impact": "LOW", 319 | "Risk": "LOW", 320 | "Types": "Web" 321 | 322 | }, 323 | { 324 | "Name": "Insufficient Session Expiration", 325 | "Description": "The application either does not implement an inactivity timeout or an absolute timeout, or the timeouts are too long to provide sufficient risk mitigation. The application does not provide a logout feature, or the feature does not actively terminate the user's session on the Server side.", 326 | "Implication": "An attacker has more time to try to brute force a session id, as well as more time using a session that the attacker has hijacked.", 327 | "Solution": "All sessions should have an Idle Timeout feature, so that unused sessions are destroyed. In addition to this, they should have a total timeout within a reasonable time frame, to force even active users to create a new session periodically. Also, Logout functionalities must be present, and must terminate the session on the Server side, not just remove or change cookies in the User's browser.", 328 | "Likelihood": "LOW", 329 | "Impact": "MEDIUM", 330 | "Risk": "MEDIUM", 331 | "Types": "Web" 332 | 333 | }, 334 | { 335 | "Name": "Insufficient Transport Layer Protection", 336 | "Description": "Not all traffic flowing between two endpoints is properly secured, which makes it possible for attackers to perform man-in-the-middle attacks. This can be something as wide as a total lack of HTTPS on all data to and from a site, or it can mean that a weak cipher is in use.", 337 | "Implication": "An attacker may be able to read, intercept, or modify data as it is in transit to or from the server.", 338 | "Solution": "Force the use of HTTPS (TLS 1.2) on all parts of the application (or at least parts that have any sensitive data, including session cookies.) In addition, do not support weak ciphers (like RC4). Also, make sure that all TLS End points are running TLS 1.2 with safe ciphers (including proxies or load balancers.) The site should also use HTTP Strict Transport Security.", 339 | "Likelihood": "LOW", 340 | "Impact": "HIGH", 341 | "Risk": "MEDIUM", 342 | "Types": "Web" 343 | 344 | }, 345 | { 346 | "Name": "Integer Overflow / Underflow", 347 | "Description": "Arithmetic operations cause a number to either grow too large to be represented in the number of bits allocated to it, or too small. This could cause a positive number to become negative or a negative number to become positive, resulting in unexpected/dangerous behavior.", 348 | "Implication": "An attacker may be able to force the application to overflow an integer. This may seem triivial, but can allow a lot of unexpected behaivors. This can be as simple as flipping a counter, or may change an Authorization setting from one value to another.", 349 | "Solution": "The framework should provide safe object wrappers for numerical data types, just as it does for other generic data types such as phone numbers and email addresses. All arithmetic operations performed on primitive numeric types in the framework should perform overflow/underflow checks first. Never perform arithmetic operations on numeric primitives without stricct checking for overflow/underflow conditions.", 350 | "Likelihood": "LOW", 351 | "Impact": "MEDIUM", 352 | "Risk": "MEDIUM", 353 | "Types": "Web" 354 | 355 | }, 356 | { 357 | "Name": "LDAP Injection", 358 | "Description": "LDAP queries are formed using dynamic data without performing proper encoding, allowing the data to change the functional meaning of the query.", 359 | "Implication": "An attacker may be able to manipulate LDAP queries. Much like SQL Injection, this can lead to bypassing authentication mechanisims, or pulling data that was not meant to be accessed by a user.", 360 | "Solution": "The framework should provide safe libraries for interacting with LDAP servers which automatically encode unsafe data. The framework should not allow application code to directly interact with LDAP servers.", 361 | "Likelihood": "LOW", 362 | "Impact": "HIGH", 363 | "Risk": "MEDIUM", 364 | "Types": "Web" 365 | 366 | }, 367 | { 368 | "Name": "Mail Command Injection", 369 | "Description": "An application includes dynamic data in SMTP communications without sanitizing or encoding the data. The structure of the data changes the meaning of the mail commands or allows an attacker to inject new commands.", 370 | "Implication": "An attacker may be able to change the context of a mail command in an unexpected manner. This could lead to mail not being delivered, or the mail server being interacted with in unexpected ways.", 371 | "Solution": "The framework should provide safe libraries for interacting with mail server systems which automatically encodes and escapes data to prevent alterations to the intended functionality.", 372 | "Likelihood": "LOW", 373 | "Impact": "LOW", 374 | "Risk": "LOW", 375 | "Types": "Web" 376 | 377 | }, 378 | { 379 | "Name": "Null Byte Injection", 380 | "Description": "Null Byte Injection is an exploitation technique which uses URL-encoded null byte characters (i.e. %00, or 0x00 in hex) to the user-supplied data. This injection process can alter the intended logic of the application and allow malicious adversary to get unauthorized access to the system files.", 381 | "Implication": "An attacker may be able to bypass security or authorization mechanisms.", 382 | "Solution":"Null bytes are rarely if ever needed in user input for web applications. Perimeter defenses can simply look for null bytes in user input and reject such requests safely. Should a Null Byte be needed for an input, allow it past the perimeter, but programming languages and frameworks should provide safe functions and libraries that automatically encode dynamic data in any context which uses null bytes as control characters. In many cases, API's should fail or otherwise remove null bytes from API input", 383 | "Likelihood":"LOW", 384 | "Impact": "MEDIUM", 385 | "Risk": "MEDIUM", 386 | "Types": "Web" 387 | 388 | }, 389 | { 390 | "Name": "OS Commanding", 391 | "Description": "OS-level calls are constructed using dynamic data, allowing an attacker to append additional function calls or manipulate parameters of the original call.", 392 | "Implication": "An attacker can run commands on the server. This can allow them to take over the server, and have a further foothold on the network.", 393 | "Solution": "Build safe wrappers for system calls which prevent dynamic data from changing the intended meaning of the call.", 394 | "Likelihood": "MEDIUM", 395 | "Impact": "HIGH", 396 | "Risk": "HIGH", 397 | "Types": "Web" 398 | 399 | }, 400 | { 401 | "Name": "Path Traversal", 402 | "Description": "File resources are accessed using references constructed from user-supplied data, allowing a malicious user to access files outside the web root that were not intended to be exposed. Often, the application builds file paths to grab a file based on user-supplied input. By putting relative path names, an attacker can access unexpected files.", 403 | "Implication": "An attacker may be able to access unexpected files. Depending on the permissions on the server, the attacker may be able to see the contents of any system file, or source code of files within the web root.", 404 | "Solution": "The framework should provide safe libraries for accessing the file system that canonicalize path references, enforce proper access control, and prevent direct access to the filesystem. The platform should be deployed with permissions that prevent the web server process from accessing files outside the web root.", 405 | "Likelihood": "LOW", 406 | "Impact": "MEDIUM", 407 | "Risk": "MEDIUM", 408 | "Types": "Web" 409 | 410 | }, 411 | { 412 | "Name": "Race Conditions", 413 | "Description": "Two simultaneous transactions (HTTP requests, database storage/retrieval commands, etc.) perform operations on the same data in a non-atomic fashion, resulting in an inconsistent state.", 414 | "Implication": "An attacker may be able to bypass certain restrictions, or write/modify data in an unexpected manner.", 415 | "Solution": "The framework must obtain a lock on any shared resources and complete any write/update/delete operations during an atomic transaction after obtaining the lock. The framework must maintain a task queue for transactions that are likely to take a long time to complete to avoid blocking on other related IO.", 416 | "Likelihood": "LOW", 417 | "Impact": "MEDIUM", 418 | "Risk": "MEDIUM", 419 | "Types": "Web" 420 | 421 | }, 422 | { 423 | "Name": "Remote File Inclusion", 424 | "Description": "The application loads data from an attacker-controlled resource at runtime, enabling a variety of malicious activities. Either the source address or the resource itself (or both) may be under the attacker's control.", 425 | "Implication": "An attacker may be able to supply configuration files, changing the state of a resource, or even supply a script to be run on the server. This can lead to Remote Code Execution.", 426 | "Solution": "Provide a configurable white list of 3rd-party domains which are allowed to serve inline content, and block file inclusion from all other domains.", 427 | "Likelihood": "MEDIUM", 428 | "Impact": "HIGH", 429 | "Risk": "HIGH", 430 | "Types": "Web" 431 | 432 | }, 433 | { 434 | "Name": "Server Misconfiguration", 435 | "Description": "Platform technologies (web servers, application servers, operating systems) are configured insecurely.", 436 | "Implication": "An attacker may be able to bypass security measures, automate certain tasks, or glean additional information for attacks, depending on the exact misconfiguration.", 437 | "Solution": "Ensure proper application settings are deployed in configuration file/s. Provide secure default settings. Run all server software using low-privilege user accounts.", 438 | "Likelihood": "LOW", 439 | "Impact": "LOW", 440 | "Risk": "LOW", 441 | "Types": "Web" 442 | 443 | }, 444 | { 445 | "Name": "Session Fixation", 446 | "Description": "An attacker can force a victim to use a session ID that is already known to the attacker; if the application does not change the ID when the privileges associated with the session change, the attacker then has access to those privileges via the known session ID. This is most commonly done by an attacker setting a Session ID, then the user authenticating. If the application does not force a new session ID upon authentication, then the attacker will already know their Session ID.", 447 | "Implication": "An attacker may be able to act as a victim user, given that they can preset their Session ID to pre-known value.", 448 | "Solution": "The framework must discard an existing session ID and generate a new token for a session any time the privilege level of the session changes. This includes on-authentication.", 449 | "Likelihood": "LOW", 450 | "Impact": "MEDIUM", 451 | "Risk": "MEDIUM", 452 | "Types": "Web" 453 | 454 | }, 455 | { 456 | "Name": "SOAP Array / XML Abuse", 457 | "Description": "Some features of the XML specification can be abused if XML parsers do not safely handle recursive element definitions or array declarations. These abuses are known as XML Attribute Blowup (an attack where malicious XML is given to the parser, and it causes the parser to have a hugely inneficient runtime.) and XML Entity Expansion (Also known as the Billion Laughs attack. It is an attack where Entities within XML are referencing multiple copies of an entity, causing the entity to be very large. This is done multiple times so that the largest entity is so large that the parser crashes upon trying to parse the XML.)", 458 | "Implication": "An attacker may be able to abuse the XML parsing in a manner that causes a Denial of Service on the application server.", 459 | "Solution": "Perimeter technologies should perform strict schema validation against all incoming XML documents. The validation process should enforce the following configurable limits on XML object definitions: 1. The maximum array size (as a product of the number of rows and columns). 2. The maximum number of elements. 3. The maximum number of attributes per element. 4. The maximum size of entity definitions. 5. The maximum number of references to entity definitions.", 460 | "Likelihood":"MEDIUM", 461 | "Impact":"HIGH", 462 | "Risk":"HIGH", 463 | "Types":"Web" 464 | }, 465 | { 466 | "Name": "SQL Injection", 467 | "Description": "Applications that have insufficient output encoding or non-validated literal strings concatenated into a dynamic SQL statement and subsequently interpreted as code by the SQL engine.", 468 | "Implication": "An attacker will be able to control SQL queries. Depending on the permission levels of the server, the attacker may be able to read/modify/deltete data, as well as potentially running commands on the server.", 469 | "Solution": "Use parameterized queries to execute any SQL commands. This will enforce a seperation of syntax and user-supplied data.", 470 | "Likelihood": "HIGH", 471 | "Impact": "HIGH", 472 | "Risk": "HIGH", 473 | "Types": "Web" 474 | 475 | } 476 | ] --------------------------------------------------------------------------------