Lecture 7 OWASP

What are the top 10?

A1. 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. A2. 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. A3. 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. A4. 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. A5.Broken Access Controls - 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, access other users' accounts, view sensitive files, modify other users' data, change access rights, etc. A6. Security Misconfiguration - Security misconfiguration is the 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. A7.Cross Site Scripting (XXS) - 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. A8. Insecure Deserialization - 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. A9. 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. A10. 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.

What are the ASVS goals?

ASVS has two main goals: • to help organizations develop and maintain secure applications. • to allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.

What is ASVS?

ASVS is a community-driven effort to create a framework of security requirements and controls that focus on defining the functional and non-functional security controls required when designing, developing and testing modern web applications and web Wgservices.

What else does OWASP has to offer?

Application Security Requirements: To produce a secure web application, you must define what secure means for that application. OWASP recommends you use the OWASP Application Security Verification Standard (ASVS), as a guide for setting the security requirements for your application(s). Application Security Architecture: Rather than retrofitting security into your applications, it is far more cost effective to design the security in from the start. OWASP recommends the OWASP Developer's Guide, and the OWASP Prevention Cheat Sheets as good starting points for guidance on how to design security in from the beginning. Standard Security Controls: Building strong and usable security controls is exceptionally difficult. A set of standard security controls radically simplifies the development of secure applications. OWASP recommends the OWASP Enterprise Security API (ESAPI project) as a model for the security APIs needed to produce secure web applications. Secure Development Lifecycle: To improve the process your organization follows when building such applications, OWASP recommends the OWASP Software Assurance Maturity Model (SAMM). This model helps organizations formulate and implement a strategy for software security that is tailored to the specific risks facing their organization. Application Security Education: The OWASP Education Project provides training materials to help educate developers on web application security and has compiled a large list of OWASP Educational Presentations.

What is the OWASP risk rating methodology?

Discovering vulnerabilities is important, but being able to estimate the associated risk to the business is just as important. Early in the life cycle, one may identify security concerns in the architecture or design by using threat modeling. Later, one may find security issues using code review or penetration testing. Or problems may not be discovered until the application is in production and is actually compromised. By following the approach here, it is possible to estimate the severity of all of these risks to the business and make an informed decision about what to do about those risks. Having a system in place for rating risks will save time and eliminate arguing about priorities. This system will help to ensure that the business doesn't get distracted by minor risks while ignoring more serious risks that are less well understood. Ideally there would be a universal risk rating system that would accurately estimate all risks for all organizations. But a vulnerability that is critical to one organization may not be very important to another. So a basic framework is presented here that should be customized for the particular organization. It goes from 3 to 1, 3 being the highest. - Exploitability: easy, average, difficult - Weakness prevalence: Widespread, common, uncommon. - Weakness detectability: easy, average, difficult - Technical impacts: Severe, moderate, minor. Threat agents and business impacts are also there, but there are application and business specific.

What is the OWASP Mobile top 10?

M1 - Improper Platform Usage. This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.. M2 - Insecure Data Storage. This covers insecure data storage and unintended data leakage. M3 - Insecure Communication. This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc. M4 - Insecure Authentication. This category captures notions of authenticating the end user or bad session management. This can include: Failing to identify the user at all when that should be required, Failure to maintain the user's identity when it is required. M5 - Insufficient Cryptography The code applies cryptography to a sensitive information asset. This category is for issues where cryptography was attempted, but it wasn't done correctly. M6 - Insecure Authorization This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrollment, user identification, etc.). If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure not an authorization failure. M7 - Client Code Quality This was the "Security Decisions Via Untrusted Inputs", one of our lesser-used categories. This would be the catch-all for code-level implementation problems in the mobile client. That's distinct from server-side coding mistakes. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that's running on the mobile device. M8 - Code Tampering This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification. M9 - Reverse Engineering This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back end servers, cryptographic constants and ciphers, and intellectual property. M10 - Extraneous Functionality. Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app.

What are the OSVS security verification levels?

The Application Security Verification Standard defines three security verification levels, with each level increasing in depth. • ASVS Level 1 is for low assurance levels, and is completely penetration testable • ASVS Level 2 is for applications that contain sensitive data, which requires protection and is the recommended level for most apps • ASVS Level 3 is for the most critical applications - applications that perform high value transactions, contain sensitive medical data, or any application that requires the highest level of trust. Each ASVS level contains a list of security requirements. Each of these requirements can also be mapped to security-specific features and capabilities that must be built into software by developers.

What is the OWASP Top 10?

The OWASP Top 10 is a regularly-updated report outlining security concerns for web application security, focusing on the 10 most critical risks. The report is put together by a team of security experts from all over the world. OWASP refers to the Top 10 as an 'awareness document' and they recommend that all companies incorporate the report into their processes in order to minimize and/or mitigate security risks.

What are the OWASP Pro Active controls?

The OWASP Top Ten Proactive: Controls 2018 is a list of security techniques that should be included in every software development project. They are ordered by order of importance, with control number 1 being the most important. 1. Define security requirements: Security requirements provide a foundation of vetted security functionality for an application, the OWASP team explained in a document on the project. Instead of creating a custom approach to security for every application, standard security requirements allow developers to reuse the definition of security controls and best practices. 2. Leverage security frameworks and libraries: Using secure coding libraries and software frameworks with embedded security helps software developers guard against security-related design and implementation flaws. A developer writing an application from scratch might not have sufficient knowledge, time, or budget to properly implement or maintain security features. 3. Secure database access: Ensure that the security controls available from the DBMS and hosting platform are enabled and properly configured. All access to the database should also be properly authenticated. 4. Encode and escape data: These are defensive techniques meant to stop injection attacks. 5. Validate all inputs: Input validation ensures that only properly formatted data may enter a software system component. 6. Implement digital identity: This control is the unique representation of a subject as it engages in an online transaction. 7. Enforce access controls: Also called authorization, this determines if a request by a user, program, or process should be granted or denied. 8. Protect data everywhere: Data needs to be protected in transit and at rest. 9. Implement security logging and monitoring: By having an application generate data for security, you can provide valuable information for intrusion detection systems and forensic analysis, as well as help your organization meet compliance requirements. 10. Handle all errors and exceptions: Applications that mishandle errors can expose an organization to all kinds of trouble, from data leakage to the compromise of data in transit to denial of service and system shutdowns.

What is OWASP?

The Open Web Application Security Project, or OWASP, is an international non-profit organization dedicated to web application security. One of OWASP's core principles is that all of their materials be freely available and easily accessible on their website, making it possible for anyone to improve their own web application security. The materials they offer include documentation, tools, videos, and forums. Perhaps their best-known project is the OWASP Top 10.

What are the 14 categories in ASVS?

• V1: Architecture, Design and Threat Modeling Requirements • V2: Authentication Verification Requirements • V3: Session Management Verification Requirements • V4: Access Control Verification Requirements • V5: Validation, Sanitization and Encoding Verification Requirements • V6: Stored Cryptography Verification Requirements • V7: Error Handling and Logging Verification Requirements • V8: Data Protection Verification Requirements • V9: Communications Verification Requirements • V10: Malicious Code Verification Requirements • V11: Business Logic Verification Requirements • V12: File and Resources Verification Requirements • V13: API and Web Service Verification Requirements • V14: Configuration Verification Requirements