OWASP Top 10 - Threats and Mitigations

PrintOWASP Top 10 - Threats and Mitigations Table of Contents: Course Overview and Objectives Module 1: OWASP Top 10 Threats: Part 1 Module Overview and Objectives OWASP 2010 and 2013 Threat 1: Injection What is Risk? Threat 1: Injection, the Web's Greatest Risk How Injection Works SQL Injection Overview SQL Injection Overview (Contd.) SQL Injection in Action Advanced SQL Injection SQL Injection Impact: Real-World Examples Preventing SQL Injection Vulnerabilities Additional Mitigation Techniques Threat 2: Broken Authentication and Session Management Threat 2: Broken Authentication and Session Management The Session Lifecycle Knowledge Check Broken Authentication and Session Management: Best Practices Threat 3: Cross-Site Scripting (XSS) Threat 3: Cross-site Scripting (XSS) Stored vs. Reflected XSS The Mechanics of XSS Attacks Stored XSS Attack Stored XSS Attack The Impact of XSS A Real-World Example of XSS Preventing XSS: A Two-Step Approach Preventing XSS: Escaping Web Application Output Preventing XSS: The Importance of Character Sets Threat 4: Insecure Direct Object References Threat 4: Insecure Direct Object References Identifying Insecure Direct Object References Exploiting a Direct Object Reference Prevent Insecure Direct Object References Threat 5: Security Misconfiguration Threat 5: Security Misconfiguration A Substantial Attack Surface Ways to Misconfigure Defending the Operating System Defending the Web Server Defending the Database Defense in Depth: Other Strategies Module Summary Module 2: OWASP Top 10 Threats: Part 2 Module Overview and Objectives Threat 6: Sensitive Data Exposure Threat 6: Sensitive Data Exposure Insecure Cryptographic Storage Overview Common Cryptographic Storage Mistakes Selecting Cryptographic Algorithms Generating Random Numbers Hashing With Salt Overview Weakness of Unsalted Hashes How Salted Hashes Work Key Derivation Functions Key Management: Best Practices Insufficient Transport Layer Protection Overview Attacks on SSL and TLS Summary of Attacks on SSL and TLS Selecting Cipher Suites Prioritizing Cipher Suites Securely Implementing TLS Best Practices for Handling SSL/TLS Certificates Threat 7: Missing Function Level Access Control Threat 7: Missing Function Level Access Control Failure to Restrict URL Access Illustrated - Path Traversal Vulnerabilities Authorization Strategies File and Directory Enumeration Threat 8: Cross-Site Request Forgery (CSRF) Threat 8: Cross-Site Request Forgery (CSRF) Preventing CSRF Threat 9: Using Components with Known Vulnerabilities Threat 9: Using Components with Known Vulnerabilities Auditing External Components Threat 10: Unvalidated Redirects and Forwards Threat 10: Unvalidated Redirects and Forwards Finding Vulnerable Components Protecting Redirects OWASP 2007 Top Ten Vs. OWASP 2010 Top 10 Past Top Risks: OWASP 2007 Top Ten Module Summary Locating Additional Resources TEAM Mentor eKnowledge Course Overview and Objectives The Open Web Application Security Project, or OWASP, is an open-source, non-profit initiative dedicated to improving the security of web applications.OWASP develops standards and provides guidance on development, testing, and tools. OWASP’s mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks. More information about OWASP can be found at www.owasp.org. The OWASP Top 10 list is an educational tool that describes the greatest threats that web application developers face. Securing a web application is an enormous task, and the OWASP Top 10 list helps you prioritize your efforts by addressing those flaws that pose the most significant security risks. This course describes the top 10 threats that web application developers face. It explains how to identify and eliminate common security flaws in your own web applications and mitigate exposure to attack. Course Objectives: After completing this course, you will be able to: • Identify the most significant and prevalent security flaws that impact web applications. • Explain mitigation techniques to remediate common security flaws in your web application. Narration: Hi there, I’m Michelle, and I will guide you as we look at the most significant security flaws that impact web applications. As this course progresses, we will look at the various mitigation techniques that you can use to remediate common security flaws. The Open Web Application Security Project, or OWASP, is an open-source, non-profit initiative dedicated to improving the security of web applications. OWASP develops standards and provides guidance on development, testing, and tools. OWASP’s mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks. More information about OWASP can be found at www.owasp.org. The OWASP Top 10 list is an educational tool that describes the greatest threats that web application developers face. Securing a web application is an enormous task, and the OWASP Top 10 list helps you prioritize your efforts by addressing those flaws that pose the most significant security risks. This course describes the top 10 threats that web application developers face. It explains how to identify and eliminate common security flaws in your own web applications and mitigate exposure to attack. After completing this course, you will be able to identify the most significant and prevalent security flaws that affect web applications. You will also be able to describe mitigation techniques to remediate common security flaws in your web application. Module 1: OWASP Top 10 Threats: Part 1 Module Overview and Objectives This module provides an overview of the differences between the OWASP Top 10 lists of 2010 and 2013. It then covers the first five threats in the OWASP Top 10 list in detail, which include: • • • • • Threat 1: Injection Threat 2: Broken Authentication and Session Management Threat 3: Cross-Site Scripting (XSS) Threat 4: Insecure Direct Object References Threat 5: Security Misconfiguration Module Objectives: After completing this module, you will be able to: • Understand the methodology used to determine risk. • Describe the first five threats in the OWASP Top 10 list and their mitigation techniques. Narration: This module provides an overview of the differences between the OWASP Top 10 lists of 2010 and 2013. It then covers the first five threats in the OWASP Top 10 list in detail, which include: • • • • • Threat 1: Injection Threat 2: Broken Authentication and Session Management Threat 3: Cross-Site Scripting Threat 4: Insecure Direct Object References Threat 5: Security Misconfiguration After completing this module, you will understand the methodology used to determine risk. You will also be able to describe the first five threats in the OWASP Top 10 list and their mitigation techniques. OWASP 2010 and 2013 The following table provides a summary of the differences between OWASP 2010 and OWASP 2013 vulnerabilities: Narration: The table on the screen shows a summary of the differences between the OWASP 2010 and OWASP 2013 list of top ten vulnerabilities. “New” 2013 items resulting from merging or renaming 2010 items are indicated accordingly in the item titles. Threat 1: Injection What is Risk? Narration: Before we discuss each type of threat, let's first make sure that we understand the methodology used to determine risk. In OWASP, risk is the potential for a particular security flaw or attack to lead to a negative impact on a business or organization. Many different attackers, attack vectors, security weaknesses, and security controls can affect a web application. In the right combination, these components could provide paths that lead directly to threats to your technical or business operations. To determine risk, OWASP considers the prevalence of the flaw, the number of agents (attackers) able to find and exploit this flaw, and the likeliness that this flaw will have a significant impact on technical or business operations. Of course, for any particular organization, the number of attackers, the security controls in place, and the actual impact on operations will vary. So, it is important to interpret each of the top 10 threats individually for your situation. XML parsers. click the relevant image. SQL Injection Overview SQL injection is by far the most common form of injection attack. making them available to more attackers. the Web's Greatest Risk Narration: Now that we’ve taken a quick look at the methodology used to determine threats. But what is an injection attack and what causes it? Injection attacks are rated by OWASP as the greatest threat to web applications. In addition. By crafting special input. which is added as a parameter to a mailer command. and execute. If you would like to learn more about these attacks. injection attacks expose the most sensitive parts of a web application. The application may ask the user to enter an email address. In this case. a user could inject commands into the expected input. without validating that the data contains only an email address. targeting the most critical components of the web application. The first threat is caused by an injection. an attacker can potentially manipulate server operations. Injection attacks occur when a user embeds instructions in such a way that an interpreter treats them as commands rather than data. or command shells. why are injection attacks especially considered high risk? They require little effort to learn. If the web application does not filter user input properly. If the web application does not filter user input properly. now.txt. If users can trick the web application into sending input data as actual commands. Now.Threat 1: Injection. a user could inject commands into the expected input. Many applications are vulnerable because developers often overlook flaws or fail to properly defend against these attacks. Many web applications dynamically build and send commands to external interpreters such as databases. the web application appends the user input as shown. let's look at its most common form—the SQL injection attack. Many shell interpreters allow you to use && to execute multiple commands on a single line. they can potentially cause the interpreter to execute any commands they want. In this example. How Injection Works Narration: The following example will help you understand how injection works. Narration: We have seen what an injection attack is and how it works. . let's examine each of the threats in detail. Here are some real-world examples of SQL injection attacks. the application sends the email and then outputs a directory listing to a file named dir. LDAP servers. Consider a web server that sends email by running a mailer executable through a shell or command interpreter. discover. Injection works by manipulating user input to exploit a web application. such as the database or the underlying operating system. even a beginner can execute basic attacks. or even execute stored procedures. This jeopardizes the security of thousands of websites. Notice how the user can modify the logic of the SQL statement simply by changing the customer-id parameter on the URL. stored procedures.) Narration: SQL injection manipulates web application input to change the behavior of a query sent to the database. and limit user permissions. Although some SQL injection techniques are very elaborate. simply failing to validate a single input could allow an attacker to bypass all other efforts you have made to firewall servers. With SQL injection. SQL Injection in Action Narration: This example shows how SQL injection works. Advanced SQL Injection Narration: Although SQL injection in the previous example was very simple. and even browser headers. along with the continual discovery of flaws in widely used web applications. the web application displays a list of all orders for that user. An application that dynamically creates SQL queries from unfiltered input is vulnerable to SQL injection. What makes SQL injection an even greater threat is the development of tools to automate more advanced techniques. harden operating systems. The pseudo code to perform the orders lookup might look like the code shown. SQL injection could allow an attacker to bypass security restrictions. session variables. This exploit is by no means limited to URL parameters. One way an application can do this is to pass the customer’s ID on the URL. delete or modify data. SQL injection techniques can be quite complex and powerful. an application shows all orders for a particular customer. consider what would happen if the user entered the additional input to the URL as shown. In the example on the screen. access sensitive data. cookie values.SQL Injection Overview (Contd. So. an attacker might be able to inject SQL through form fields. An attacker can launch an SQL injection attack simply by modifying a URL parameter to change the logic of an SQL statement. In our example. When the user browses to the specified URL. These include unions. errors. what happens when the code examples shown are executed? Move your mouse over each line of code to find out! . and timing. SlimStat tightened its SQL queries and strengthened its encryption key. This meant that user input was not properly validated so that an attacker was able to inject SQL queries in order to perform a blind . In October 2014 it confirmed a vulnerability in the Drupal version 7's database abstraction API that allowed an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation. Worldview The UK's Information Commissioner's Office (ICO) fined Worldview Ltd for "a vulnerability in the code that retrieved rate information on the web page. potentially allowing attackers to take over an entire site. or other attacks. In response. arbitrary PHP execution. WordPress A flaw in the WordPress plugin WPSlimstat discovered in March of 2015 allowed hackers to perform an SQL Injection attack against the website by breaking the plugin’s weak “secret” key.SQL Injection Impact: Real-World Examples Drupal Drupal is an open source content management platform. A flaw in the WordPress plugin WP-Slimstat discovered in March of 2015 allowed hackers to perform an SQL Injection attack against the website by breaking the plugin’s weak “secret” key.SQL injection attack. This meant that user input was not properly validated so that an attacker was able to inject SQL queries in order to perform a blind SQL injection attack. SlimStat tightened its SQL queries and strengthened its encryption key. WordPress. it confirmed a vulnerability in the Drupal version 7's database abstraction API that allowed an attacker to send specially crafted requests resulting in arbitrary SQL execution. Drupal is an open source content management platform. Depending on the content of the requests this can lead to privilege escalation. potentially allowing attackers to take over an entire site." Click each example to learn more. In October 2014. arbitrary PHP execution. or other attacks. In response.” Narration: To better understand the impact of SQL injection attacks. and Worldview. let's consider some realworld attacks that occurred on three websites: Drupal. . The UK's Information Commissioner's Office (ICO) fined Worldview Ltd for "a vulnerability in the code that retrieved rate information on the web page. if using them makes more sense for your particular environment. or you need to properly escape them. determine which of the characters are "special. as illustrated by the following pseudo code: id=GET(‘customer-id’) If not numeric(id) then raise error end if • Blacklist validation. blacklist validation. • Carefully consider user permissions to take advantage of the stored procedures and mitigate potential exposure.Preventing SQL Injection Vulnerabilities Prepared Statements With prepared statements. Always use some form of whitelist validation on user input. Note that if you build dynamic SQL from the parameters passed to stored procedures. • In whitelist validation. lengths. and input validation. The primary and most consistent defense against SQL injection is to use parameterized queries in the form of prepared statements. input validation does not completely eliminate injection vulnerabilities. If necessary. Let's look at each of these techniques in detail. you specify a set of data types. the database performs the following tasks on the query before receiving user input: • Parsing • Compiling • Optimizing Parameters. although not nearly as effective. . you must validate all parameter values and treat them as if they were untrusted. • Escaping special characters. • Avoid or take extra precautions when using system stored procedures that perform sensitive operations such as sp_execute. resulting in a clear distinction. keep in mind that even when it is consistently implemented. execute. and characters to allow. When building dynamic SQL inside a stored procedure. parameterized stored procedures. For example. Input validation minimizes risk and is easy to implement on existing applications. The OWASP website provides code libraries and samples in various languages for parameterizing SQL queries. and escaping special characters. Input Validation Validation of every user input is an important defense against injection (and against most of the OWASP Top 10 vulnerabilities). Parameterized Stored Procedures Although parameterized stored procedures are typically safe. always check that the user-supplied data is in fact a number." After you have identified these characters. patterns. are sent to the database separately. Parameterized stored procedures are normally a good alternative to prepared statements. When creating code for a particular technology. or bind variables. if you expect numeric input. you again expose the database to SQL injection attacks. lets you specify a set of bad data or data patterns to block and take appropriate action against any input that matches this set. Take extra care with input validation--it is easy to neglect it or to overlook some inputs. All data that does not match this approved set is blocked. you must take appropriate measures to filter and sanitize user input. Input validation includes whitelist validation. you still must consider the following: • Avoid dynamically generating SQL statements with user input from within the stored procedure. or exec. you need to prevent them from appearing in input. Also. Narration: You can prevent SQL injection vulnerabilities by using prepared statements. Parameterized stored procedures are similar to parameterized queries except that the SQL itself resides on the database server. These statements allow you to pass user input as parameters instead of dynamically building SQL statements. Validating every user input is crucial to defending against injection attacks (and against most of the OWASP Top 10 vulnerabilities). Input validation includes whitelist validation. blacklist validation. and escaping special characters. . Click each technique to learn more. Input validation minimizes risk and is easy to implement on existing applications. Perform all web queries with minimal privileges necessary for the application. . Use blacklist validation prudently to help detect actual attacks and complement other security measures. 8. 3. 4. Harden the underlying operating systems and applications on the web and database servers. 9. use LIMIT 1. Use the LIMIT clause in SQL statements that return a fixed number of results. Implement proper exception handling and never return raw error messages to the web browser. 1. Select only the fields you need in a query and avoid using SELECT * if not necessary. Be consistent with the character sets used throughout your application. 7. preferably using UTF-8. When executing external programs or dynamically evaluating scripts. 2. Narration: We have now covered some techniques to prevent injection attacks from occurring. Use the LIMIT clause in SQL statements that return a fixed number of results. Implement proper exception handling and never return raw error messages to the web browser. Perform all web queries with minimal privileges necessary for the application. Here are some additional techniques to defend against injection attacks: Although not effective as a primary defense.Additional Mitigation Techniques Here are some additional mitigation techniques to defend against injection attacks. use LIMIT 1. Specify character sets explicitly whenever possible and never assume defaults. if you expect one result. 6. 5. Harden the underlying operating systems and applications on the web and database servers. Select only the fields you need in a query and avoid using SELECT * if not necessary. be extra cautious to ensure that user input cannot modify the intent of those operations. Always normalize file paths and check the result to ensure the file is within the bounds of your application. if you expect one result. blacklist validation used prudently can help detect actual attacks and can complement other security measures. Be consistent with the character sets used throughout your application. Explicitly specify character sets whenever possible and never assume defaults.When executing external programs or dynamically evaluating scripts. preferably using UTF-8. . use extra caution to ensure that user input cannot modify the intent of those operations. Always normalize file paths and check the result to ensure the file is within the bounds of your application. Recovery methods include providing answers to secret questions to obtain a forgotten password. Many Web applications include functionality for forgotten passwords. Although the application initially authenticates a user based on username. Developers often forget that if an attacker can retrieve a user name. but can potentially achieve a lot by knowing the user name. which then directs them to a password recovery page. a second factor of authentication. These flaws are usually the result of poor session control and isolation. The following diagram illustrates a typical session lifecycle. and having inadequate timeouts for inactive sessions. and in some cases. and in some cases a second factor of authentication. authorizing. Although the application initially authenticates a user based on username. password. or submitting a user name or email address to receive temporary password information that can be used to reset the password. An attacker cannot do much by just knowing a password.Threat 2: Broken Authentication and Session Management Threat 2: Broken Authentication and Session Management Narration: Let's look at the second threat: broken authentication and session management. Broken authentication and session management vulnerabilities are those in which an attacker exploits flaws to impersonate other users either through session hijacking. the puzzle is half solved. and managing users from login until session termination. all subsequent session authentication relies on a unique session identifier. or credential discovery. authorizing. . The diagram illustrates a typical session lifecycle. relying on an IP address for a session. The Session Lifecycle User session management is the process of authenticating. Examples of broken authentication and session management include forgotten password functionality. all subsequent session authentication relies on a unique session identifier. Attackers often exploit this functionality to identify valid user names for the application. Users submit their usernames to the application. Because this single session identifier—or token—is equivalent to the user’s credentials for the duration of the session. it is critical to take all precautions necessary to protect it from attack. password. Let's see an example of forgotten password functionality to understand this threat better. and managing users from login until session termination. session manipulation. Narration: User session management is the process of authenticating. and inadequately secured transmission or storage of user credentials. it is critical to take all precautions necessary to protect it from attack. Because this single session identifier—or token—is equivalent to the user’s credentials for the duration of the session. weak password recovery and account management functions. Narration: Here is a diagram depicting the steps in a typical session lifecycle.Knowledge Check Here is a diagram depicting the steps in a typical session lifecycle. Drag the numbered steps to the correct placeholder circles. . Drag the numbered steps to the correct placeholder circles. . • Use well-tested framework or platform session management features instead of implementing your own. immediately after privilege escalation or role change. including creative assets such as style sheets and graphics. Through years of developing new techniques and learning from past mistakes. • Always store session identifiers in cookies and never rely on sending session IDs via URL parameters. the industry has developed a long list of best practices. • Never accept user-provided session identifiers if the application did not generate that ID for the user. • Avoid pop-up windows that do not show the address bar and SSL validation icon. • Do not mix secure and non-secure content in secure areas of the application. • Consider countermeasures for handling brute-force attacks and credential harvesting. or SMS onetime-passwords greatly enhance account security. • Generate new session identifiers after user login. but never send the actual passwords. • The session ID should only contain a single session identifier and never contain any other identifying information. even for private internal communications. Never store session-related values in persistent cookies. • Avoid using the remember me functionality with high-value applications. • Always set the HttpOnly cookie attribute to ensure that scripts cannot access cookies via the DOM document. • Always send user credentials and session tokens over secure encrypted channels. or custom HTTP headers. even for internal applications.cookie object. • Always set both absolute and relative time limits on session identifiers to ensure proper session expiration. • Use generic error messages. • Do not automatically assign temporary passwords. • Ensure that all passwords have fixed but reasonable expiration dates. Some rules are simple and seemingly obvious. • Provide users with a logout button to manually terminate a session. it is important to understand and strictly follow even the most basic of these rules. hidden form fields. • Provide two-factor authentication features for sensitive applications. Hardware devices. Avoid creating your own custom session management systems. • Although TLS content is encrypted. Narration: User authentication and session management have a long history in information technology. • Leverage the built-in platform whenever possible. • Expire all current sessions after changing passwords. • Implement strong yet usable and practical password complexity requirements. • Always use certificates signed by an organizational certificate authority for private intranet applications and by a recognized and trusted certificate authority for public applications. • Ensure that the session ID is sufficiently long and is created using strong random number generators. and it should never reveal sensitive information. • Always notify users of password changes via email or SMS. • Be familiar with regulations and standards required for your organization and industry. software tokens. • Carefully plan Domain and Path cookie attributes to clearly define the bounds of cookie use. • Always set the Secure cookie attribute to ensure that the application always transmits cookies over secure connections. or after sensitive operations such as password changes. • Never use hidden form fields for storing authentication-related information. • Always ask for the previous password when setting a new password. • Validate form input. However. due to the compounding nature of security threats. the URL itself is not.Broken Authentication and Session Management: Best Practices User Logins Password and Password Policies Session Tokens Cookie Security Cryptography • Always use SSL-encrypted forms for user login. • Consider supporting third-party authentication providers such as Google™ or Facebook. Never use self-signed certificates. • Never transmit session-related content over non-TLS connections. • Only store session identifiers in session cookies. Account compromise is perhaps the oldest security threat we face. • Store session identifiers in a generic variable that does not allow fingerprinting or profiling. password and password policies. session tokens. Click each category to learn more. let’s review best practices for user logins. cookie security. and cryptography.To better understand how to make secure authentication and session management an integral part of any web application. . Additional Categories XSS has two additional categories based on where the injection occurs: Traditional XSS vulnerabilities occur when the server itself modifies the data. the attacker gets the user to send malicious input to a particular URL—for example. The malicious input is then displayed as a normal part of the site’s content. Narration: Cross-site scripting attacks usually fall into two categories: Stored cross-site scripting and reflected cross-site scripting. Perform actions on your site on behalf of the client. Cross-site scripting flaws in an application allow attackers to exploit other users. and access private and sensitive client information and even spy on all actions the client performs on your website. whereas DOM-based vulnerabilities occur when modification occurs—usually via JavaScript—within the client’s web browser while rendering the page. and behavior of browser content or simply redirect the user to a site that contains malicious content. and then uses the input to generate output. Reflected XSS In a reflected XSS attack. This is the most common form of XSS attack. the malicious code is executed.Threat 3: Cross-Site Scripting (XSS) Threat 3: Cross-site Scripting (XSS) Narration: Let's now move on to the third type of threat. By clicking the link. The application then uses that input to generate a response. Cross-site scripting has two additional categories based on where the injection occurs: traditional cross-site scripting and DOM-based cross-site scripting. . also known as a persistent attack. also known as a non-persistent attack. appearance. Execute client-side scripts. what are the risks? An attacker can use cross-site scripting to: Access and modify the structure. Reflected XSS Stored XSS In a stored XSS attack. by sending the user email with a link to click. Despite its prevalence. such as site content or a response to a client. what is cross-site scripting and why is it a threat? Cross-site scripting is a form of injection attack. Stored vs. Although cross-site scripting is a form of injection. it is unique in both scope and target and warrants its own classification. without proper escaping. which is cross-site scripting. the risks of cross-site scripting are often underestimated. the user sends the malicious input to the web application. So. an attacker sends malicious input that is stored in the application’s database. Click each category to learn more. So. When a user views or requests the stored content. Access sensitive session and cookie information. exploiting the users’ trust of your web application. Cross-site scripting can occur whenever the application accepts user input without proper validation. Narration: The stored cross-site scripting attack can become much more serious. Let's look at an example. Drag the icons to the correct placeholder circles to indicate the correct sequence followed by an attacker. as shown in this example. Drag the icons to the correct placeholder circles to indicate the correct sequence. as shown here. Drag the icons to the correct placeholder circles to indicate the correct sequence followed by an attacker.The Mechanics of XSS Attacks Narration: So far. If attackers inject HTML and JavaScript. Of course. depending on the malicious code injected by the attacker. as shown in this example. Let’s look at attempting the question shown to see if you can identify what impact cross-site scripting vulnerabilities can have on your web application. . Cross-site scripting attacks can be applied in a wide variety of ways. the consequences can be quite serious. they can change the behavior of a page to accomplish their objectives. Although these attacks may be very simple. Drag the icons to the correct placeholder circles to indicate the correct sequence followed by an attacker. you can also understand the most sophisticated ones. The Impact of XSS Narration: In the previous examples. If attackers can inject HTML and JavaScript. attackers can employ cross-site scripting to attack any site visitor as well. Stored XSS Attack The stored XSS attack can become much more serious. but they all exploit the basic concept that the user trusts your website. But how does a cross-site scripting attack work? By understanding basic cross-site scripting attacks. you saw how an attacker can use cross-site scripting to gain information about a site’s administrator. we have a basic understanding of cross-site scripting attacks and their types. as shown here. they can change the behavior of a page to accomplish their objectives. as shown in this example. depending on the malicious code injected by the attacker. Narration: An attacker can inject a stored cross-site scripting attack. Stored XSS Attack An attacker can inject a stored XSS attack. Now. the social media site Tumblr fell victim to a malicious cross-site scripting worm that caused offensive posts to appear on numerous blogs. Narration: We've learned about cross-site scripting attacks. and seen some realworld examples of such attacks.000 users and forced Tumblr to temporarily suspend all posting capabilities to prevent the worm from spreading further. To do this correctly. . The vulnerability simply required a logged-in Tumblr user to view one of these posts to further spread the malicious content. • Explicitly define character encoding and output mime types. how do you prevent them? To prevent cross-site scripting attacks. • Escape all untrusted data using the method most appropriate for the type of output. Click each technique to learn more. how they work. Preventing XSS: A Two-Step Approach Input Validation Output Sanitizing • Use whitelist validation to allow data that matches a set of approved parameters. The vulnerability quickly spread to nearly 90. use input validation and output sanitizing (escaping). In December 2012. and block all other data.A Real-World Example of XSS Narration: Let's now look at a real-world example of how cross-site scripting works. you must understand the structure of your application’s input and output. You must carefully consider the context and any sub-contexts of output data to implement the appropriate prevention measures. . and use hex encoding to avoid breaking out of context. Limit untrusted data to data values that would be enclosed in strings. use specific URL validation and canonicalization as appropriate for your application. and avoid backslash escaping. use HTML entity encoding along with an HTML sanitization library. • Style and CSS values. use whitelist URL validation if possible. Place un-trusted data in property values only. Use strict whitelist validation on all data. Use strict whitelist validation on all data.Preventing XSS: Escaping Web Application Output Following is a list of recommendations for securing common types of output data. link. SRC. and limit protocols to http and https. use whitelist URL validation if possible. and ensure that all JavaScript variables are quoted. • JavaScript variables. and use hex encoding to avoid breaking out of context. With URL links. and avoid backslash escaping. For HTML attributes. URL encoding replaces unsafe ASCII characters with a "%" followed by two hexadecimal digits. or HREF attributes. Use URL encoding in URL parameters. Here is an example of URL encoding: – Input string: Sample input here is $270 – Encoded output: Sample%20Input%20Here%20is%20$270 • SRC or HREF attributes. Hex-encode data to avoid breaking out of context. and avoid placing untrusted data in unsafe attributes such as style. and limit protocols to http and https. link. • URL parameters. And. and onclick. Use more aggressive HTML and validation. Use HTML entity encoding along with an HTML sanitization library. and ensure that all JavaScript variables are quoted. place un-trusted data in property values only. Narration: So how does escaping Web application output help in preventing cross-site scripting? Preventing cross-site scripting attacks involves more than simply encoding all output. for JavaScript variables. Here is a list of recommendations for common types of output data. • HTML elements. limit untrusted data to data values that would be enclosed in strings. • HTML attributes. use more aggressive HTML and validation. Hexencode data to avoid breaking out of context. Use specific URL validation and canonicalization as appropriate for your application. and avoid placing untrusted data in unsafe attributes such as style. Use URL encoding. For style and CSS values. For HTML elements. and onclick. and on XML/XHTML content. you need to: Explicitly specify a character set (such as UTF-8) wherever possible. ensure that your application uses a consistent character set. . Narration: Let's now examine the importance of character sets in preventing cross-site scripting. script interpreters. To complement input validation and output escaping. To ensure consistent character sets throughout your application. Many cross-site scripting evasion techniques take advantage of character-set ambiguity. web platforms. do the following: • Explicitly specify a character set (such as UTF-8) wherever possible. web platforms. such as with htmlspecialchars in PHP. including in databases. • Verify character sets as part of the input validation process.0" encoding="UTF-8"?> • Specify a character set when using encoding or other conversion functions that allow you to indicate character sets. Specify a character set when using encoding or other conversion functions that allow you to indicate character sets. script interpreters. such as with htmlspecialchars in PHP. including in databases. and verify character sets as part of the input validation process. and on XML/XHTML content. such as: <?xml version="1.Preventing XSS: The Importance of Character Sets To ensure consistent character sets throughout your application. Failure to control access to this content is an (often unintentional) attempt at security through obscurity. a hacker needs to identify the flawed interface and also predict the pattern to identify an insecure object such as file or user name. Even with extensive input validation. user ID. When designing a web application. it is easy to mistakenly assume that users cannot access content that they cannot see. leading to exposure of sensitive system and user information. or database record. drop-down list boxes. Common implementation areas where these objects could be exposed include URLs and links. you instead need to perform a code review. and data objects are exposed by the application. this can potentially allow attackers to predict or guess other objects that they may not be authorized to access. When designing a web application. user account. To exploit this vulnerability. To understand this threat better. In a direct object reference. Narration: The next threat we'll discuss is insecure direct object references. Identifying Insecure Direct Object References Narration: How can you identify an Insecure Direct Object References threat? These threats are difficult to identify with automated tools. an application directly refers to an object such as a filename. followed by a walkthrough of the website to help identify interfaces that provide access to sensitive content. leading to exposure of sensitive system and user information. or predictable object names. You can then verify that the object is not directly accessible based on common information such as user name. and JavaScript arrays. this can potentially allow attackers to predict or guess other objects that they may not be authorized to access. This exposure occurs when developers assume that users always adhere to the basic rules of the application. or database record. This exposure occurs when developers assume that users always adhere to the basic rules of the application. user account. The Insecure Direct Object References threat reflects flaws in system design where access to sensitive data or assets is not fully protected. an application directly refers to an object such as a filename. Even with extensive input validation. such as business reports that include the organization or client name. To protect against this threat. . it is easy to mistakenly assume that users cannot access content that they cannot see.Threat 4: Insecure Direct Object References Threat 4: Insecure Direct Object References In a direct object reference. The Insecure Direct Object References threat reflects flaws in system design where access to sensitive data or assets is not fully protected. Failure to control access to this content is an (often unintentional) attempt at security through obscurity. let's make sure that we understand what a direct object reference is. email address. hidden variables. and data objects are exposed by the application. Next. This normally requires maintaining a hash table or a list applicable only to the current user session. non-informative object identifiers that are valid only for the current context (such as a user session). an attacker might try to guess another file name to see if the application permits downloading other products. The example here shows a customer download page that contains direct object references to a filename and a customer ID. Then. .Exploiting a Direct Object Reference Narration: So how exactly is a direct object reference exploited? It involves three steps: First. the attacker may eventually discover the customer that *does* have access to the file. there are two values that stand out: a reference to a file name. and a reference to a customer ID. experiment with how to exploit the flaw and bypass any input validation that might exist. Although this may not work. it might indicate that the customer ID does not have access to this file. By guessing other customer IDs or simply trying all possible IDs. So how do you address these problems? The best way to eliminate this vulnerability is through indirect object access. Let’s look at another example. What are your observations when you see this image? Looking at this URL. What can you conclude from this image? As illustrated here. Indirect object access uses random. identify a potentially exploitable direct object reference. predict or guess other object names to access. This mapping can be stored temporarily in the server cache or in a permanent mapping table. perhaps in a file system. and when the user requests the resource. to an internal customer. he can probably pass a different ID to access reports of other customers as well. Click each technique to learn more. Consider an example in which you retrieve critical report contents from a database for a particular customer with the following query: Example: SELECT * FROM Monthly_Budget_Reports WHERE CustID="111" If the attacker can manipulate the CustID field from the UI. to a user ID. you can easily add validation in SQL by checking the user authorization as follows: SELECT * FROM Monthly_Budget_Reports INNER JOIN ReportAccessControlbyOrg On ReportAccessControlbyOrg.OrgId = Monthly_Budget_Reports. Therefore. it is crucial to verify the user’s authorization to make sure that the user is valid and can request the resource. An indirect reference map maintains a non-sequential and random identifier for a server-side resource. If you use an alternate or random object ID. you are just reducing the chances that the user might be able to predict the resource identifier. or contents are accessed. In the client-side link. Consider a scenario in which your application allows a user to download a confidential file. the contents accessed could be stored outside of the database. The chances of an attack are reduced but not completely eliminated. the user retrieves the file without knowing the actual name under which it is stored. Instead of saving files with obvious names. it is crucial to verify the user’s authorization to make sure that the user is valid and can request the resource. This way. An indirect reference map maintains a non-sequential and random identifier for a server-side resource. you may also need to ensure that other methods of file retrieval are also protected.Prevent Insecure Direct Object References Use an Indirect Reference Map You can use an indirect reference map to create an alternative ID or name for server side objects or data to ensure that the exact ID or name is not exposed to the end user. In this scenario. you are just reducing the chances that the user might be able to predict the resource identifier. you use the mapping table to obtain the actual (random) file name. You can address this scenario with database-based validation more easily than you can with application code. because the attacker may attempt access by direct HTTP requests to objects or FTP. The object ID can be anything from a file name. If the attacker gets information about the alternative object ID (maybe from the browser history information on a shared computer). The object ID can be anything from a file name. This mapping can be stored temporarily in the server cache or in a permanent mapping table. . The chances of an attack are reduced but not completely eliminated. he can still send a resource request in a legitimate manner and retrieve the required information. he can still send a resource request in a legitimate manner and retrieve the required information. The end user can view only the alternate ID and not the actual ID of the object. You can use an indirect reference map to create an alternative ID or name for server side objects or data to ensure that the exact ID or name is not exposed to the end user. Verify User Authorization If you use an alternate or random object ID. files. Narration: How can insecure direct object references be prevented? You can prevent insecure direct object references by reducing a user's ability to determine object IDs and names. you should instead use a randomly generated identifier as the file name and maintain a mapping table with a user-friendly file name internally. you display the user-friendly file name. You can address this scenario with database-based validation more easily than you can with application code.OrgId = “loggedInUser_OrgId” However. The end user can view only the alternate ID and not the actual ID of the object. To mitigate this.OrgId WHERE CustID="111" AND ReportAccessControlbyOrg. Avoid disclosing the actual IDs or names of objects and verify user authorization every time sensitive objects. to an internal customer. to a user ID. If the attacker gets information about the alternative object ID (maybe from the browser history information on a shared computer). Therefore. including data storage. Improperly secured operating systems. and some application servers provide a number of auxiliary services for their associated web applications. The misconfiguration of security-related settings within operating systems. Can you identify the security configuration error that occurred? . Most security misconfiguration mistakes are common. This setting leads to a risk of exposing underlying vulnerabilities. A Substantial Attack Surface Narration: Web and application server platforms play a key role in the security of a web application. Narration: The fifth threat is the security misconfiguration threat. and messaging. Let’s understand this better with the help of an example. Each application server adds to the overall attack surface.Threat 5: Security Misconfiguration Threat 5: Security Misconfiguration Although an application’s code is vital to its security. web server applications. the platform it runs on is also very important. On the next few screens. we will look at the different ways in which security is misconfigured and how you can prevent these mistakes. and databases contribute to your application’s attack surface. consider the following scenario. An application server is configured in such a manner that stack traces can be resent to users. and these common errors are the preferred attack vector and the easiest to exploit. Drag each attack surface to its appropriate circle. directory services. web services. and databases all contribute to the overall attack surface. Although an application’s code is vital to its security. mail. requiring significant effort to manage their configuration. the platform it runs on is also very important. Ways to Misconfigure Narration: To understand how security misconfiguration occurs. The attack surface resulting from all of these services can be quite large. • Avoid installing software development and debugging tools on the server. • Keep the system up-todate with the latest operating system. database. Keep the system up-to-date with the latest operating system. Avoid installing software development and debugging tools on the server. Install anti-virus and other security software as appropriate. • Ensure that proper system auditing and log file management is in place. • Use a packet filter or firewall to restrict access and isolate the machine on the network.Defending the Operating System Some key approaches to hardening the operating system (OS) include: • Take a minimalist approach and only install what is necessary for your purpose. Consider using a hardening guide or tool appropriate for your operating system. Take a minimalist approach and only install what is necessary for your purpose. • Set file and directory permissions to the least necessary to run the required applications. Review OS settings that can improve system security. • Consider using a hardening guide or tool appropriate for your operating system. Set file and directory permissions to the least necessary to run the required applications. and other software patches. Strictly limit user accounts and disable or rename default accounts. • Strictly limit user accounts and disable or rename default accounts. Use a packet filter or firewall to restrict access and isolate the machine on the network. • Ensure that the server is physically secure. web server. Establish strong password policies for the OS and all installed applications. • Install anti-virus and other security software as appropriate. • Review OS settings that can improve system security. Narration: Here are some key approaches to hardening the operating system (OS). and other software patches. Ensure that the server is physically secure. • Establish strong password policies for the OS and all installed applications. . Ensure that proper system auditing and log file management is in place. database. web server. backup. Consider using a hardening guide or tool appropriate for your web server and application framework. . or restrict IP address access to administrative directories.Defending the Web Server Key approaches to improving the security of web servers include: • Install only the modules or services necessary for your application. Modify server headers to not reveal server platform and version. • Review web server settings that can improve platform security. Remove. and other directories not appropriate for a production server. • Disable or reconfigure error reporting features so that users never see detailed error messages. Narration: Let's now look at how you can improve the security of web servers. • Remove. and other directories not appropriate for a production server. demo. Review web server settings that can improve platform security. backup. • Disable or block HTTP methods not needed for your application. Use appropriate file and directory permissions to strictly control access to web content directories. temporary. demo. Disable directory browsing. Ensure that the server is physically secure. • Use appropriate file and directory permissions to strictly control access to web content directories. temporary. • Modify server headers to not reveal server platform and version. Review script interpreter and application framework settings to ensure that proper limits and security settings are in place. rename. Remove default. • Review script interpreter and application framework settings to ensure that proper limits and security settings are in place. • Ensure that the server is physically secure. Disable or reconfigure error reporting features so that users never see detailed error messages. Disable or block HTTP methods not needed for your application. Install only the modules or services necessary for your application. • Disable directory browsing. • Consider using a hardening guide or tool appropriate for your web server and application framework. or restrict IP address access to administrative directories. • Remove default. rename. Now let's look at how we can defend database servers. • Use a packet filter or firewall to tightly restrict access to database ports. • Ensure that the server is physically secure. . • Strictly limit user accounts and disable or rename default accounts. testing. root.Defending the Database Key approaches to improving the security of database servers include: • Remove or disable unnecessary database features or services. Strictly limit user accounts and disable or rename default accounts. Carefully configure user roles and permissions to strictly limit access for web application accounts. or system accounts for general database access. Never use DBA. Consider using a hardening guide or tool appropriate for your database platform. and all other databases not necessary for the web application. testing. Remove or disable unnecessary database features or services. or system accounts for general database access. • Remove any demo. we have looked at how we can improve the security of the operating system and web servers. • Carefully configure user roles and permissions to strictly limit access for web application accounts. training. training. • Consider using a hardening guide or tool appropriate for your database platform. • Disable stored procedures that are not required for the application. root. Remove any demo. Ensure that the server is physically secure. Disable stored procedures that are not required for the application. Never use DBA. and all other databases not necessary for the web application. Use a packet filter or firewall to tightly restrict access to database ports. Narration: So far. . manage system configuration settings with version control software. Deploy intrusion detection systems to identify any overlooked misconfigurations.Defense in Depth: Other Strategies Following are key measures you can take to further mitigate security misconfigurations: • • • • • Regularly audit the full system configuration. Where possible. Monitor search engines to identify changes made to your web application and identify possible information leaks. manage system configuration settings with version control software. Where possible. Deploy intrusion detection systems to identify any overlooked misconfigurations. Narration: Are there additional ways to improve the system security? Yes! Here are measures you can take to further mitigate security misconfiguration. Utilize log analysis or event management software to identify unusual system activity. Regularly audit the full system configuration. Use software to perform regular vulnerability scanning of the web server. • Utilize log analysis or event management software to identify unusual system activity. Monitor search engines to identify changes made to your web application and identify possible information leaks. Use software to perform regular vulnerability scanning of the web server. You also learned about the two categories of XSS attacks—stored and reflected—in detail. why it is considered a threat. You learned how to identify an insecure direct object reference threat and how a direct object reference can be exploited. improving the security of web servers. and improving the security of database servers. Click here to review this section again. session tokens. password and password policies. you learned about cross-site scripting. Click each objective above to learn more. you learned how to further mitigate security misconfigurations. Click here to review this section again. Click each objective above to learn more. Then. Click each objective above to learn more. In addition. Click here to review this section again. cookie security. with the help of realworld examples. You learned what an injection attack is. Click here to review this section again. You also learned about SQL injection and how to prevent SQL injection vulnerabilities. You also learned how to prevent these threats. You learned about how to make secure authentication and session management an integral part of any web application by reviewing best practices for user logins. Click each objective above to learn more. you learned about the first threat in the OWASP Top 10 list. you learned about the different techniques that can be used to prevent XSS attacks: input validation and output sanitizing. why it is a high-risk threat. you learned about the different ways that security can be misconfigured and the methods by which you can prevent misconfigurations. Threat 4: Insecure Direct Object References In this topic. Click here to review this section again. you learned about the insecure direct object references threat. and cryptography. Threat 5: Security Misconfiguration In this topic. You learned about direct object references and the concept of insecure references. and how it works. You also learned key approaches to hardening the operating system. You saw examples that demonstrated the threat. Threat 3: Cross-Site Scripting (XSS) In this topic. Click each objective above to learn more. .Module Summary Threat 1: Injection In this topic. Threat 2: Broken Authentication and Session Management In this topic. you learned about the second threat in the OWASP Top 10 list: Broken Authentication and Session Management. injection. You learned what XSS is. and the risks associated with it. you will be able to explain the final five threats in the OWASP Top 10 list and their mitigation techniques. Threat 6: Sensitive Data Exposure . you will be able to: • Explain the final five threats in the OWASP Top 10 list and their mitigation techniques.Module 2: OWASP Top 10 Threats: Part 2 Module Overview and Objectives This module provides an overview of the remaining five threats of the OWASP Top 10 list. in the following topics: • • • • • Threat 6: Sensitive Data Exposure Threat 7: Missing Function Level Access Control Threat 8: Cross-Site Request Forgery Threat 9: Using Components with Known Vulnerabilities Threat 10: Unvalidated Redirects and Forwards After completing this module. in the following topics: • • • • • Threat 6: Sensitive Data Exposure Threat 7: Missing Function Level Access Control Threat 8: Cross-Site Request Forgery (CSRF) Threat 9: Using Components with Known Vulnerabilities Threat 10: Unvalidated Redirects and Forwards Module Objective: After completing this module. Narration: This module provides an overview of the remaining five threats of the OWASP Top 10 list. we covered the first five threats in the OWASP Top 10 list. The purpose of this encryption is to avoid end user exposure. The next threat we will discuss is sensitive data exposure. This threat further comprises two steps: insecure cryptographic storage and insufficient transport layer protection. Although the learning curve may seem steep. This functioning of the database could be exploited by an SQL injection attack.Threat 6: Sensitive Data Exposure Narration: In the first module. The alternative—failure to properly secure the data that users place in your trust—can negatively impact your organization’s reputation. we’ll look at how to protect against the risks of insufficient transport layer protection. Strong encryption is a fundamental and vital part of protecting the system’s most sensitive secrets. Insecure Cryptographic Storage Overview Narration: To understand what insecure cryptographic storage is. But. best practices for basic cryptography are easy to learn and implement. Can you identify the insecure data storage error that occurred in this scenario? . let's look at insecure cryptographic storage. there are two key considerations: Using symmetric encryption algorithms such as AES to securely store data. requiring a specific key—or password—to retrieve the data. Cryptography is a critical aspect of information security. But what should you keep in mind when storing data using cryptography? Although we use cryptography in several areas of applications. Next. let’s look at an example. In terms of storing data. Quite often. and using one-way hashing algorithms such as SHA256 to store hashes used to verify user passwords. strong encryption comes late in the development process as an afterthought or as a low-priority enhancement. An application is designed such that debit card information is encrypted in the database. here we will specifically focus on cryptographic storage. First. the damage being that all the debit card information is then retrieved in cleartext. we'll look at the next five threats in detail. the drawback here is that the database works to decrypt any queries against the columns of the debit card automatically. In this module. Heavy mathematical theory and unfamiliar technology frequently cause some developers to avoid or postpone implementing strong cryptography. Using weak random number generation. Let's look at how to avoid these errors when storing sensitive data. avoid these common errors. • Failure to encrypt sensitive data. out-of-date algorithms. • Using weak. • Using insufficient key lengths. Using insufficient key lengths. • Using weak random number generation. out-of-date algorithms. Narration: When storing sensitive data. • Failure to use salt with password hashes. . Using weak. Failure to use salt with password hashes. Let's look at how to avoid these errors when storing sensitive data. • Using homegrown algorithms. Poor key management. avoid these common errors: Failure to encrypt sensitive data. • Poor key management. Using homegrown algorithms.Common Cryptographic Storage Mistakes When storing sensitive data. Always be aware of the minimal acceptable algorithms and key lengths. Appropriate algorithms and minimum key lengths change over time and may differ.wikipedia. Although computers can generate what appear to be random numbers. weak. Over time. Keep in mind that other algorithms such as MD5 or SHA1 (both used for hashing) are inadequate and should be phased out of all applications.keylength. You can use random number generators (RNGs) to generate numbers randomly. Cryptography that uses weak sources of randomness is ultimately vulnerable to attack. and stay well ahead of these minimums. Whether encrypting data or storing passwords in the form of hashes. If your organization operates in a regulated industry. It is difficult to prove with certainty that any particular algorithm is without flaws. Generating Random Numbers Narration: Another way of minimizing errors when storing sensitive data is to use random numbers. with proper key lengths. regulations and standards can often provide guidance on using the correct algorithm and key length. More information and current recommendations can be found at: http://www. .org/wiki/Key_size Keep in mind that other algorithms such as MD5 or SHA1 are inadequate and should be phased out of all applications. Narration: You can avoid errors when storing sensitive data by selecting appropriate cryptographic algorithms. Always know the minimal acceptable algorithms and key lengths. There are three types of RNGs: algorithm-based. always select algorithms that meet minimum acceptable standards.gov/groups/ST/toolkit http://en. it is actually very difficult to generate truly unpredictable randomness. Click each image to learn more. are the only acceptable ones to use. and strong.Selecting Cryptographic Algorithms Avoid errors when storing sensitive data by selecting appropriate cryptographic algorithms. and stay well ahead of these minimums.nist. certain algorithms have withstood scrutiny and.com http://csrc. The strength of any cryptographic operation relies largely on the ability to use highquality random numbers. we know that they both have the same password. The salt ensures that an attacker must always compute the hash in a brute-force attack. This is significant because. Weakness of Unsalted Hashes Hash functions allow you to verify user passwords without having to store the actual passwords. So. comparing the results of a hashing algorithm is sufficient to prove that a password matches what was originally stored. you use a salt. and why the 2012 LinkedIn™ hash leak mentioned previously resulted in so many exposed user passwords. This is why leaks of unsalted password hashes quickly get cracked. if you know the password of one of these users. The table shown is a common but obsolete method that many websites use to store and verify passwords using unsalted MD5 hashes. Password hashes are the only acceptable manner of storing user passwords. However. . If you use unsalted hashes. you can see that the users athompson and cwhite both have the same hash. However. You do not need to store the actual password. In the table. password hashes are vulnerable to brute-force attacks and require strategies to make such attacks more difficult. what is a salt? A salt is random data added to the hashing process to ensure that every hash of a password produces a unique result. you also know the password for all other users with the same hash. Let's look at this with an example. To prevent attackers from simply collecting large databases of hashes. Because an unsalted hashing algorithm always produces the same hash for a particular password. The table shown here is a common but obsolete method that many websites use to store and verify passwords using unsalted MD5 hashes. If you run a password through a hashing algorithm.Hashing With Salt Overview Narration: Passwords are critical information that need to be secured with high priority. you will always get the same result. The salt is saved as a pseudo-secret that the application later uses when comparing passwords. the passwords are not stored securely enough. if you use unsalted hashes. the passwords are not stored securely enough. Narration: Hash functions allow you to verify user passwords without having to store the actual passwords. • Add additional salt and optionally a master key or password. Narration: You can also secure data by strengthening the keys used. These functions increase the size and entropy of a password before hashing to protect them from certain attacks. bcrypt. Algorithms such as PBKDF2.How Salted Hashes Work Narration: You have seen the table generated with the use of unsalted hashes. Although users athompson and cwhite still have the same password. Now let's look at the table generated with salted hashes. their stored hashes are now different. Also. Salt values greatly increase the resilience of password hashes. and scrypt are all common key-derivation functions. every hash is unique. can strengthen password hashes. Algorithms such as PBKDF2. . because you are protecting the password itself. • Reduce exposure to cryptanalytic and timing attacks by working from keys of standard length and high entropy. Key derivation functions do not compensate for weak passwords. Key Derivation Functions Key derivation functions increase the size and entropy of a password before hashing to accomplish the following: • Hinder brute-force attacks by increasing the cost in both CPU cycles and memory overhead. applying a salt or master key in each iteration. Observe that the second table now shows password hashes with the addition of a salt. • Increase the bit length and entropy of short passwords. Although actual implementations vary. also called key stretching or strengthening functions. Key derivation functions. you can store the salt along with the hash. These algorithms perform cryptographic functions over many hundreds or thousands of iterations. bcrypt. a salt is similar to a password on top of the user’s password. By adding a random value to each user password. Key derivation functions only ensure a certain cost in brute-force attacks on passwords of any size. and protect weak passwords from certain attacks. and scrypt are all common key-derivation functions. even if two passwords are the same. and can be intercepted by an attacker. When using symmetric encryption.1 or later. store encryption keys outside of the web content directories. Note that TLS is similar to and based on the older protocol called secure sockets layer (SSL). Sensitive Data Exposure. access is granted. A vital part of protecting sensitive data is ensuring that you encrypt network communications with transport layer security. Never hard-code encryption keys in your application. all versions of SSL have significant security flaws and are considered unsafe to use. Let's look at this threat in detail. but preferably TLS v1. or TLS. The most basic vulnerability scenario is when developers include the key as part of an “if” statement in the application. . Carefully plan file system permissions to protect files that contain encryption keys. The table on screen lists the security status for each version of SSL and TLS. your application should support only TLS for secure communications—at minimum TLS v1.0. it is critical that you follow best practices for protection of the encryption keys. However. Insufficient Transport Layer Protection Overview Narration: Insufficient transport layer protection is the other threat included under Threat 6. If the user’s input matches the key’s character string. If possible. session IDs and sensitive data are exposed and vulnerable. Therefore.Key Management: Best Practices Narration: Let's look at a scenario and determine the best practice for the scenario in relation to protecting encryption keys. Build the application to support periodic key changes and establish a regular schedule for changing keys. Without TLS. back up and store them separately. Do not include encryption keys in backups. Renegotiation Attacks Flaws in the way SSL and TLS handle handshake renegotiation allow for an attacker to inject plaintext into client requests. Although many widely-deployed software libraries such as OpenSSL are considered mature products. Both Mozilla Firefox and Google Chrome were affected by this vulnerability. it was still considered secure for some time. compression can introduce flaws allowing an attacker to decrypt small portions of the traffic.0. RC4 Attacks RC4 has long been a widely-implemented stream cipher used with SSL and TLS. TIME and BREACH both attack HTTP-level message body compression to reveal data in a server response. leaving users open to man-in-the middle attacks. CRIME is an attack against TLS-level compression that can expose sensitive cookies. let’s look at some of the most common of these attacks. such as a cookie or session token. Padding Oracle attacks use feedback from a server to determine which padding is valid for an encrypted message. in reality SSL is still widely in use. Recent discoveries have shown that even well-established software is still prone to critical security faults. recent research has shown that RC4 is no longer considered sufficiently secure for use with TLS. passwords. due to the manner in which it is used with SSL and TLS. is a buffer over-read flaw in OpenSSL that allows anyone to view segments of server memory. Padding Oracle Attacks Block ciphers such as CBC and EBC use padding to ensure that every block is the same size. revealing private keys. and other secrets. BERserk is vulnerability with Mozilla’s NSS crypto library that allows forgery of RSA signatures. Numerous other attacks on SSL have evolved over the years. they are by no means free of vulnerabilities. Although known vulnerabilities exist with RC4. discovered in 2014. Version Rollback or Downgrading These attacks force a client or server to downgrade or rollback to an older protocol version or a weaker cipher suite. BEAST Browser Exploit Against SSL/TLS (BEAST) is a chosen plaintext attack against SSL 3. This gives enough information to decrypt the message.Attacks on SSL and TLS Narration: Though you should only use TLS and not SSL. Attacks such as FREAK and Logjam. However. Although the attacker cannot decrypt this traffic. it is important that you understand the common threats against both SSL and TLS. for example connecting with HTTP instead of HTTPS. Let’s discuss these threats. researchers have discovered serious vulnerabilities in many products including Java.0 and TLS 1. GNUTLS and Microsoft’s Schannel. Heartbleed. The attack involves injecting a malicious JavaScript or other applet into the same origin of the web site and sniffing the network to obtain cookie and other HTTP headers. Therefore. for example. Compression Flaws In some cases. . Therefore. the ability to inject plaintext could enable other more serious attacks. SSL Stripping is another variation of downgrading that causes a web client to not use encryption at all. both cause the connection to downgrade to weak 512-bit encryption keys that are easy to attack. Apple’s iOS and OS X. In recent years. Mitigation largely depends on the client using up-to-date browser software. it is critical to keep server software and libraries up to date. NOTE: . Never use a cipher suite with Anon as these do not verify certificates. although 3DES is satisfactory for backwards compatibility.0. Let’s see some of the options available to help ensure secure connections. For more information.or 56bit security. refer the TEAM Mentor article Use Only Strong TLS Algorithms. or DES. you should also disable any CBC-mode ciphers to prevent version rollback attacks. Although it is not necessary to understand the exact naming mechanism for cipher suites. MD5. As you can see. Never use a cipher suite with an EXPORT-grade cipher as these only provide 40. Narration: This table summarizes the common attacks on SSL and TLS. A server and client will negotiate a cipher suite that both ends can support.Summary of Attacks on SSL and TLS Here is a summary of common attacks on SSL and TLS. Never use a cipher suite with NULL encryption as these do not encrypt the TLS traffic. secure connections can be difficult to achieve—server configuration and up-to-date software are critical. Selecting Cipher Suites Narration: Cipher suites are a critical determining factor of the strength of a TLS session. it is important to be able to identify which suites are safe to use and in which order you should use them. Let’s discuss some basic rules. A cipher suite is a collection of ciphers used for various aspects of a secure connection. Note that if you support TLS 1. Never use a cipher suite that includes RC4. Securely Implementing TLS Narration: Let’s discuss the important points for securely implementing TLS. • Next.0 support. disable HTTP and implement HTTP Strict Transport Security (HSTS) to force all traffic to use HTTPS. prefer AES 128 over AES 256. Keep sensitive information such as session tokens off the URL.Prioritizing Cipher Suites Narration: The priority of a cipher suite is just as important as the selected suites because this allows the server to negotiate the most secure combination available. if necessary. You should prioritize cipher suites as follows: • Prefer any cipher suite with ECDHE. Use TLS to protect all network communications. Use vulnerability scanners to identify and assess all SSL and TLS implementations on your network. the current consensus is that AES 128 is the better choice and should be a higher preference. even for internal network traffic. see SSL Server Test. AES. except in extreme and restricted scenarios where necessary to communicate with legacy hardware or software. NOTE: . • Include 3DES last for backwards compatibility. Keep all software and encryption libraries up to date to protect from the latest threats. Completely disable SSL and only allow TLS. Use the Secure flag on all authentication cookies. For web sites. Although AES 256 is stronger than AES 128. prefer any cipher suites that use DHE.0 or implement a plan for phasing out TLS 1. disable TLS 1. and GCM as this is currently the strongest combination of ciphers. Disable support for TLS compression and renegotiation initiated by the client. For more information. if possible. If possible. • Next. both ECDHE and DHE allow the server to support Perfect Forward Secrecy which ensures that a compromise of a session key will not allow for decryption of past or future communications. • Do not use X. . • Do not use X. Do not use X.509 certificates signed using MD5 hash. never on the server itself. HTTP Public Key Pinning. Store private keys in a secure location.509 certificates signed using MD5 hash. due to known collision attacks. • Use extended validation (EV) certificates if appropriate for your organization. Never use self-signed certificates. • Consider using HSTS. and OCSP Stapling. never on the server itself.Best Practices for Handling SSL/TLS Certificates Follow these best practices for handling SSL or TLS certificates: • Never use self-signed certificates because they provide little security over non-encrypted communications and provide a false sense of security.509 certificates with an RSA or DSA key less than 2048 bits. HTTP Public Key Pinning. Consider using HSTS.509 certificates with an RSA or DSA key less than 2048 bits. • Store private keys in a secure location. and OCSP Stapling. Use extended validation (EV) certificates if appropriate for your organization. Keep certificates up-to-date and include all applicable domain names so that the user is never presented with a certificate error. They provide little security over non-encrypted communications and provide a false sense of security. • Keep certificates up-to-date and include all applicable domain names so that the user is never presented with a certificate error. Do not use X. due to known collision attacks. Narration: Let's now look at the best practices for handling SSL or TLS certificates. Let's look at the next threat: missing function level access control. backups. file and directory enumeration. directory browsing. Most applications have at least some requirements for restricting access to sensitive application functions. . protect log files. Narration: We have covered six of the Top 10 OWASP 2010 threats list so far. map file extensions to mime types to control how they are handled. hidden files. check for directory traversal when accessing files based on user input. The greatest risk of these vulnerabilities is exposure of sensitive user data or information that could facilitate other attacks. and restrict access to folders on FTP servers. directory browsing. Common examples of failing to restrict URL access include failure to: • Prevent directories from listing contents when no default document exists. or other unprotected files in your web content directories. test files. Insufficient access controls could allow attackers to access administrative features. • Protect log files. • Check for directory traversal when accessing files based on user input. Insufficient access controls could allow attackers to access administrative features.Threat 7: Missing Function Level Access Control Threat 7: Missing Function Level Access Control Most applications have at least some requirements for restricting access to sensitive application functions. • Map file extensions to mime types to control how they are handled. Examples of attacks might include path traversal. • Restrict access to administrative and maintenance features. or temporary files. authenticate AJAX or other APPI requests properly. Common examples of failing to restrict URL access include failure to: prevent directories from listing contents when no default document exists. or other unprotected files in your web content directories. • Authenticate AJAX or other APPI requests properly. and unauthorized file access. hidden files. restrict access to administrative and maintenance features. The greatest risk of these vulnerabilities is exposure of sensitive user data or information that could facilitate other attacks. AJAX endpoints. • Restrict access to folders on FTP servers. backups. test files. or temporary files. file and directory enumeration. and unauthorized file access. Examples of attacks might include path traversal. AJAX endpoints. Path Traversal Vulnerabilities Narration: Let’s look at some of the vulnerabilities caused by failure to restrict URL access./). How can an attacker do damage here? If the application does not properly check for directory traversal. and might try to access other files. . starting with the path traversal vulnerability. Path traversal occurs when an application does not properly check user input and allows access to files outside the intended file path. By including a dot-dot-slash (. Consider that you are accessing a web application with the URL as shown. checking for specific character sequences such as dot-dot is prone to error. The application must validate all user input that affects file system operations.Failure to Restrict URL Access Illustrated . and then check to ensure that the user is authorized to access that path or file. an attacker might be able to access other files on the system.. An attacker can see that it refers to an actual file name. You must completely resolve and normalize the path using operating system functions. Let's look at an example. What do you think could be a problem here? This example downloads a file attachment. an attacker might be able to traverse directories in the file system. Note that due to a variety of encoding techniques. private. URLs. private. • When making authorization decisions based on workflow or other state. Clearly separate public. data. • Supplement security boundaries through userbased access control and file system permissions. always consider unexpected state conditions that might occur. and administrative content by placing them in separate physical directories. Deny access to all protected pages and sensitive functions by default. • Clearly separate public. Avoid hardcoded policy enforcement in individual modules. Adherence to these strategies requires careful planning and an organized approach to user permissions.Authorization Strategies Here are some guidelines to help ensure proper URL authorization throughout a web application. and administrative content by placing them in separate physical directories. Always make authorization decisions on the server side. files. Centralize authorization functions and policy management. files. data. and services. never in client-side code. check user permissions to explicitly grant access. • Always make authorization decisions on the server side. URLs. and services. When making authorization decisions based on workflow or other state. • Deny access to all protected pages and sensitive functions by default. • Consider role-based security to define clear boundaries and check user roles before allowing access to functions. Then. Then. Supplement security boundaries through user-based access control and file system permissions. • Centralize authorization functions and policy management. never in client-side code. Consider role-based security to define clear boundaries and check user roles before allowing access to functions. always consider unexpected state conditions that might occur. check user permissions to explicitly grant access. Adherence to these strategies requires careful planning and an organized approach to user permissions. Narration: Here are some guidelines to help ensure proper URL authorization throughout a web application. . Avoid hard-coded policy enforcement in individual modules. or out-of-date files. Reviewing web logs and web log statistics to identify possible abuse of unidentified vulnerabilities. involves submitting lists of URLs to see if they exist. the attacker enumerates files and directories to find useful information or identify known vulnerabilities. These URLs may include unprotected log files or backup directories. sensitive. sensitive. This process. This process.File and Directory Enumeration Often in one of the first steps in an attack. • Employing a web application firewall or intrusion detection system to block or at least identify unknown vulnerabilities. Running automated vulnerability scanners on your web server to identify vulnerabilities that an attacker might also be able to find. Narration: Often in one of the first steps in an attack. . and employing a web application firewall or intrusion detection system to block or at least identify unknown vulnerabilities. It is important to identify unprotected and potentially vulnerable files by: • Manually reviewing web content directories for unneeded. or may involve looking for specific applications known to be vulnerable. involves submitting lists of URLs to see if they exist. These URLs may include unprotected log files or backup directories. the attacker enumerates files and directories to find useful information or identify known vulnerabilities. or may involve looking for specific applications known to be vulnerable. sometimes called forced browsing. • Reviewing web logs and web log statistics to identify possible abuse of unidentified vulnerabilities. It is important to identify unprotected and potentially vulnerable files by: Manually reviewing web content directories for unneeded. sometimes called forced browsing. or outof-date files. • Running automated vulnerability scanners on your web server to identify vulnerabilities that an attacker might also be able to find. Otherwise. . and after submitting the form. the image tag directs the admin's browser to visit the URL that creates a new admin user. How does it work? Well. an attacker does not have access to the particular admin page for adding a user. Later. The attacker who created the first malicious post never compromised anyone’s account. attackers can use cross-site request forgery to get you to take action for them. When a user submits a form. the attacker fills out the feedback form and includes an image tag that links to the URL for creating a user. Let’s look an example in detail. the session token in the form must match the token in their cookie. That attack exploited cross-site scripting and created a new post that further spread the attack. and the browser interprets the image tag as if it were HTML. The attack was designed so that just viewing the post would cause the user to unknowingly reblog the same post under their account. instead of trying to steal your password. thinking that it is grabbing an image. However. Consider a web application that has a form for adding new users. PHP. An example of cross-site request forgery is the previously mentioned Tumblr worm. Per-Request Nonces Per-request nonces provide an even stronger safeguard by generating a random one-time token—or nonce—in every form sent to the user. and other methods to cause a user to perform an undesired action in their current authenticated user context. The server tracks this nonce and accepts a form submission only if the nonce matches the one originally sent to the user. it has allowed the attacker to create a new admin user account. First. Cross-site request forgery is a technique that uses cross-site scripting. OWASP’s CSRFGuard project provides CSRF protection modules for Java. the form submission fails. Instead of displaying an image.NET. the resulting URL appears. and . This causes the browser to visit the URL to retrieve the image. but can trick the administrator's web browser to visit that URL. Although an attacker cannot access this URL without being an administrator. social engineering. an admin views the feedback. In this example. Preventing CSRF DoubleSubmitted Cookies Using double-submitted cookies is a simple technique in which you include session tokens in hidden form fields. Click each method to learn more.Threat 8: Cross-Site Request Forgery (CSRF) Threat 8: Cross-Site Request Forgery (CSRF) Narration: The eighth threat is cross-site request forgery. Narration: How can you prevent cross-site request forgery attacks? You can easily prevent cross-site request forgery attacks by using double-submitted cookies and per-request nonces. he can use a cross-site request forgery attack to get the administrator to access it on his behalf. browser flaws. making the application more susceptible to attacks. giving them a window of attack before systems are updated or patched. external code could easily make up 50% or more of a modern application’s code base. although popular. • Some open source projects. Some sites will never get patched. which is using components with known vulnerabilities. a growing dependence on open source software and other external components means increased exposure to vulnerabilities in these components. may not have the development resources or may be too new to have been fully reviewed for security flaws. your websites might still get hacked. Because attackers typically learn about flaws at the same time as everyone else. In addition. • Open-source applications are easy for attackers to review and find unpublished vulnerabilities. • With flaws in commonly used components.) Narration: Keep in mind that even when you consistently follow security best practices. This is where we come to the ninth threat. some open source projects receive significant public review. application frameworks that reduce development time. . (On the other hand. attackers can easily automate massive attacks and even compile lists of vulnerable sites through search engines. With increasing popularity of open source projects. and CMS plugin features that make it easy to install entire modules. Exploiting known flaws in components is particularly attractive to attackers. and therefore few flaws escape unnoticed.Threat 9: Using Components with Known Vulnerabilities Threat 9: Using Components with Known Vulnerabilities Exploiting known flaws in components is particularly attractive to attackers because: • Attackers generally learn about flaws at the same time as everyone else. • Exploit code is often widely available shortly after a flaw is made public. they can often exploit a flaw before it is remedied. If possible. frameworks. Be aware of and document configuration and other implementation details necessary for a component’s security. • Maintain lists or repositories of components approved for use in your organization. Subscribe to notifications for new and updated versions of all components you use and keep all components up-to-date. Only use those produced by reputable developers and that have received extensive security review. Carefully consider the risks of using any third-party components. if possible. • Prevent your application from displaying names and version numbers of included components. including any child components. whenever possible. For example. • Be aware of and document configuration and other implementation details necessary for a component’s security. some frameworks may rely on multiple external libraries that you must also track. . whenever possible. Use both manual and automated reviews to identify security flaws in any components you implement. Identify all third-party components in existing applications and their versions. you need to adopt some unique strategies. Maintain lists or repositories of components approved for use in your organization. or components. • Use both manual and automated reviews to identify security flaws in any components you implement. • Subscribe to notifications for new and updated versions of all components you use and keep all components up-to-date. prevent your application from displaying names and version numbers of included components. including any child components. • Identify all third-party components in existing applications and their versions.Auditing External Components Use the following strategies and techniques: • Carefully consider the risks of using any third-party components. Narration: To secure external libraries. Only use those produced by reputable developers and that have received extensive security review. Consider search engine alerts to learn about vulnerabilities as they are made public. an attacker might also exploit the vulnerability in conjunction with cross-site scripting or cross-site request forgery attacks. . Users believe they are clicking a known or trusted URL but are instead redirected to a different. Pages that grab and include remote content based on user input. possibly malicious URL. an attacker could potentially exploit redirects in a number of ways. Elements to look for include files with keywords such as redirect. You also need to check for URL parameters such as URL. Web applications often use URL redirection to handle moved resources. it can expose the user to phishing and other attacks. load-balance. and redirect. reverse DNS lookups. including less obvious input sources such as HTTP headers. are all examples of vulnerable components. you may need to perform a deep and creative review of all code. These include: Pages that include iframe content or pop-up windows based on user input. or other data that a user can modify. cookie contents. when implemented improperly. Although primarily implemented as a phishing attack. Although some redirect URLs may be obvious. go. To identify these vulnerable components or weaknesses. abbreviate URLs. and how can you identify them? Components that redirect based on any user input. Login pages that redirect back to where a user was before logging in. or track outgoing links. Finding Vulnerable Components Narration: What components are vulnerable to unvalidated redirects and forwards. hidden form fields. and link.Threat 10: Unvalidated Redirects and Forwards Threat 10: Unvalidated Redirects and Forwards Narration: The last threat on the list is unvalidated redirects and forwards. Although redirecting is convenient and essential for some applications. ReturnURL. using redirects and forwards on a web page creates a vulnerability. Click each strategy to learn more. Lookup Tables Use a redirect ID or keyword that the application uses to look up the actual URL to redirect to. If redirects or forwards are necessary. unusual URL patterns. If the page is compromised. Intermediate Warning Pages In some cases. nonces and MACs can ensure that redirect URLs originated from your application. nonces and MACs. lookup tables. Nonces and Message Authentication Codes (MACs) When redirecting from a form submission. Application Firewalls and Intrusion Detection Systems Although not effective enough to prevent the problem. you may need to specifically warn users that they are leaving the current site. you can use a number of strategies to protect them from attackers. . Narration: By definition. or attempts to obfuscate malicious input. application firewalls or intrusion detection systems can help identify and block known vulnerabilities. These include whitelists. Therefore. before implementing redirects or forwards.Protecting Redirects Whitelists Maintain a list of valid domains or URLs and restrict redirection to only the items on the list. always consider more secure alternatives. and application firewalls and intrusion detection systems. intermediate warning pages. the URL can be changed and users can be unknowingly redirected to a nefarious web page. or they improperly trust input files. Finally. . protected log file. OWASP 2010 Top 10 Past Top Risks: OWASP 2007 Top Ten Narration: Every few years. Malicious file execution vulnerabilities are still found in many applications. they are worth reviewing. remote. “malicious file execution” and “information leakage and improper error handling” are two risks in the 2007 Top Ten that were not included in the 2010 list. First. Developers sometimes directly use or concatenate potentially hostile input with file or stream functions. let's look at the malicious file execution threat. and use search engine alerts to monitor your web domain for error messages. and hostile content being included. or invoked by the web server. Even vague error messages can be useful to an attacker. To prevent information leakage. use strict input validation and carefully planned file permissions. As you can see from the table. Poorly-configured applications can unintentionally leak information about their configuration and internal structure through information provided in error messages. To prevent malicious file execution vulnerabilities. When data is not properly validated. never reveal too much information to users if an error occurs. Save detailed debugging information to a separate. processed. it can lead to arbitrary. frameworks allow external object references. However. This can allow attackers to perform remote code execution or remote root kit installation and completely compromise the system. let's look at the information leakage and improper error handling threat. such as URLs or file system references. OWASP re-evaluates and re-prioritizes its list of top ten web application security risks. on many platforms. In addition.OWASP 2007 Top Ten Vs. You also learned about the guidelines for proper URL authorization in a web application. salted algorithms. You learned how to securely implement TLS with the help of an example. intermediate warning pages. Click here to review this section again. Click each objective above to learn more. Click here to review this section again. Click here to review this section again. you learned about cross-site request forgery. Threat 9: Using Components with Known Vulnerabilities In this topic. Click each objective above to learn more. you saw an example that showed how unvalidated redirects and forwards occur. Click here to review this section again. Click each objective above to learn more. In addition. and you learned strategies to audit these components in order to help secure your application. you learned about common cryptographic storage errors and how to avoid them by using appropriate cryptographic algorithms. Threat 10: Unvalidated Redirects and Forwards In this topic.Module Summary Threat 6: Sensitive Data Exposure In this topic. lookup tables. Click here to review this section again. Click each objective above to learn more. and application firewalls and intrusion detection systems. you saw some common examples of failing to restrict URL access and path traversal vulnerabilities. nonces and MACs. Threat 7: Missing Function Level Access Control In this topic. You learned about insecure cryptographic storage in an example scenario. Finally. Threat 8: Cross-Site Request Forgery (CSRF) In this topic. and hashed. you learned about protecting sensitive data through cryptography and secure transport protocols. you learned about the best practices for proper TLS implementation and for handling SSL or TLS certificates. RNGs. Click each objective above to learn more. You also learned about how to find vulnerable components and how to protect redirects by using whitelists. and you learned how to prevent CSRF attacks: use double-submitted cookies and per-request nonces. You learned about CSRF with the help of an example. You learned about the best practices for managing keys. you learned why components with known vulnerabilities are attractive targets for attack. . You learned about insufficient transport layer protection and the security status for each version of the SSL and TLS protocols. you can refer to https://www.Locating Additional Resources For more information on OWASP Top 10 . Integrating security scanning and guidance into a development workflow ultimately results in quicker production of more secure and stable applications. With optional plugins to the most popular Static and Dynamic code analysis tools.org. Use TEAM Mentor to find guidance for implementing the application security controls that are relevant to your particular application in your development language.Threats and Mitigation. Narration: TEAM Mentor eKnowledge Provides faster and better remediation guidance within the developer’s environment TEAM Mentor is an interactive Application Security eKnowledge base with thousands of articles on how to prevent vulnerabilities during application development. TEAM Mentor provides users with quick and easy access to comprehensive security guidance that is accurate and relevant to specific code security questions. Narration: .owasp.