owasp top 10
2. Broken Authentication fix
* Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks. * Do not ship or deploy with any default credentials, particularly for admin users. * Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords .* Align password length, complexity and rotation policies with NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies. * Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes. * Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected. * Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
5. Broken Access Control fix
Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata. * With the exception of public resources, deny by default. * Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage. * Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record. * Unique application business limit requirements should be enforced by domain models. * Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots. * Log access control failures, alert admins when appropriate (e.g. repeated failures). * Rate limit API and controller access to minimize the harm from automated attack tooling. * JWT tokens should be invalidated on the server after logout.Developers and QA staff should include functional access control unit and integration tests.
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 to exploit other implementation flaws to assume other users' identities temporarily or permanently.
10. insufficient logging and monitoring fix
As per the risk of the data stored or processed by the application: * Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis. * Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions. * Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar. * Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion. * Establish or adopt an incident response and recovery plan, such as NIST 800-61 rev 2 or later.There are commercial and open source application protection frameworks such as OWASP AppSensor (old wiki), web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting.
2. Broken Authentication impact
Attackers can use this to fully compromise the system if they can get a few accounts, or one admin account. this could allow money laundering, social security fraud, identity theft, or disclose legally protected highly sensitive information.
3. Sensitive Data Exposure
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.
3. Sensitive Data exposure fix
Classify the data your site stores, transmits, or processes. Identify which data is sensitive. apply controls per the classification level don't store something sensitive if you do not need it. discard all sensitive data as soon as possible. encrypt data at rest. use only up-to-date and strong standard algorithms, protocols, and keys. use proper key management. ensure all data in transit is properly encrypted with TLS and perfect forward secrecy ciphers, cipher prioritization by the server and secure parameters. enforce strict transport security. disable caching for responses containing sensitive data store passwords using strong adaptive and salted hashing functions with a work factor (delay factor). ex: argon2, scrypt, bcrypt, pbkdf2 independently verify the effectiveness of configuration and settings
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.
3. Sensitive Data exposure impact
Failure here frequently compromises all data you're trying to protect. PII, health records, credentials, personal data, credit cards. these often require protection as defined by laws like GDPR and local privacy laws. its in the name.
8. Insecure Desrialization
Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
10. Insufficient logging and 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.
4. XML External Entities
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.
10. insufficient logging and monitoring impact
Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100%.In 2016, identifying a breach took an average of 191 days - plenty of time for damage to be inflicted.
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 Fix
Secure installation processes should be implemented, including: * A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to setup a new secure environment. * A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks. * A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process (see A9:2017-Using Components with Known Vulnerabilities). In particular, review cloud storage permissions (e.g. S3 bucket permissions). * A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups (ACLs). * Sending security directives to clients, e.g. Security Headers. * An automated process to verify the effectiveness of the configurations and settings in all environments.
1. Injection fix
Separate data from commands and queries. Use a safe API avoiding the use of an interpreter entirely or provides a parameterized interface. ORM is a good fix too, but not entirely. ORM means you don't have to compose any SQL along the way, but there is still software composing SQL, and some of the top ORMs have had vulnerabilities come up. Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec(). * Use positive or "whitelist" server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications. * For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter. Note: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software. * Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
7. Cross Site Scripting fix
Some frameworks will automatically escape XSS by design. Each framework typically has some defense that can be used, but may require further research to implement effectively. Don't trust just the framework. Escape untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. Apply context-sensitive encoding when modifying the browser document on the client side, this will act against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet 'DOM based XSS Prevention'. Use a Content Security Policy as a defense-in-depth mitigating control against XSS. If is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (path traversal overwrites or vulnerable libraries from permitted CDNs).
7. Cross Site Scripting impact
The impact of XSS is moderate for reflected and DOM XSS, and severe for stored XSS, with remote code execution on the victim's browser, such as stealing credentials, sessions, or delivering malware to the victim. Reflected and DOM are things an attacker can do to the session they are on. Or they can get someone to click a link that executes some reflected or DOM, and then that gets severe in my opinion because now you can get other people to execute actions they do not intend, maybe change their password, reset their email, send their session token and csrf token to an attacker, allow for session hijacking or account takeover. Stored is the same as if you can get someone to click on a link for reflected or Dom.
8. insecure deserialization impact
The impact of ____________ flaws cannot be overstated. These flaws can lead to remote code execution attacks, one of the most serious attacks possible.The business impact depends on the protection needs of the application and data.
8. insecure deserialization fix
The only safe architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types. If that is not possible, consider one of more of the following: * Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering. * Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable. * Isolating and running code that deserializes in low privilege environments when possible. * Log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions. * Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize. * Monitoring deserialization, alerting if a user deserializes constantly.
5. Broken Access Control impact
The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record.The business impact depends on the protection needs of the application and data.
9. using components with known vulnerabilities fix
There should be a patch management process in place to: * Remove unused dependencies, unnecessary features, components, files, and documentation. * Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like versions, DependencyCheck, retire.js, etc. Continuously monitor sources like CVE and NVD for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use. * Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component. * Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue.Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.
4. XML External Entities impact
These flaws with XML processors can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks. The business impact depends on the protection needs of all affected application and data.
4. XML External Entities fix
Train developers not to allow external xml entities. Also: when possible, use less complex data formats like json and avoid serialization of sensitive data patch and upgrade all xml processors and libraries in use by application or underlying os. use dependency checkers. dependency checkers - tool to run against your build and find vulnerabilities update soap to soap 1.2 or higher. Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet 'XXE Prevention'. * Implement positive ("whitelisting") server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes. * Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar. * SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations.If these controls are not possible, consider using virtual patching, API security gateways, or Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks.
9. using components with known vulnerabilities impact
While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list.
7. Cross Site Scripting
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.
1. Injection impact
_____ can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. ________ can sometimes lead to complete host takeover.The business impact depends on the needs of the application and data.
6 Security Misconfiguration
most commonly seen issue. This is commonly 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.
6. Security Misconfiguration Impact
not properly setup. Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise.The business impact depends on the protection needs of the application and data.
1. injection
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. ex: SQL, NoSQL, OS, and LDAP injection