There are a lot of changes in web application development in the last 4 years. Developers have adopted many new methodologies. As mentioned by OWASP, Microservices written in node.js and Spring Boot are replacing traditional monolithic applications. Single-page applications, written in JavaScript frameworks such as Angular and React, allow creating highly modular feature-rich front ends. Client-side functionality that has traditionally been delivered server-side brings its own security challenges. JavaScript is now the primary language of the web with node.js running server-side and modern web frameworks such as Bootstrap, Electron, Angular, and React running on the client.”

Three New Vulnerabilities Added

These new methodologies also introduce new risks and vulnerabilities. This time, OWASP 2017 added a new issue supported by data. As mentioned by OWASP, “A4:2017-XML External Entities (XXE) is a new category primarily supported by source code analysis security testing tools (SAST) data sets. The other two new issues added in OWASP 2017 are A8:2017-Insecure Deserialization, which permits remote code execution or sensitive object manipulation on affected platforms, and  A10:2017-Insufficient Logging and Monitoring.

Two Vulnerabilities Merged into One

Some vulnerabilities in OWASP TOP 10 2013 have been merged in OWASP TOP 10 2017, and some have been retired from OWASP Top 10 2013. A4-Insecure Direct Object References and A7-Missing Function Level Access Control merged into A5:2017-Broken Access Control.

Two Vulnerabilities Removed

A8-Cross-Site Request Forgery (CSRF), removed from OWASP Top 10 2017, as now many frameworks include CSRF defenses, it was found in only 5% of applications as mentioned by OWASP in the official release. A10-Unvalidated Redirects and Forwards, also removed from OWASP Top 10 2017.

Now we summarize what are the changes in OWASP Top 10 2017.

• A1 Injection and A9 Using Components with Known Vulnerabilities remain intact in OWASP Top 10 2017.
• A2 Broken Authentication and Session Management name is slightly trim; now it is just Broken Authentication. Some vulnerabilities changed position in OWASP Top 10 2017.
• A3 Cross-Site Scripting now at the 7th position in OWASP Top 10 2017. A5 Security Misconfiguration is now at the 6th position.
• A6 Sensitive Data Exposure is now at the 3rd position in OWASP Top 10 2017. As discussed earlier, A8 Cross-site Request Forgery and A10 Unvalidated Redirects and Forward are removed from OWASP Top 10 2017.
• Some vulnerabilities in OWASP TOP 10 2013 have been merged in OWASP TOP 10 2017. A4-Insecure Direct Object References and A7-Missing Function Level Access Control merged into A5:2017-Broken Access Control.
• As discussed, this time, the three new issues which have been added in OWASP 2017 are A4:2017-XML External Entities (XXE), A8:2017-Insecure Deserialization, and A10:2017-Insufficient Logging&Monitoring.

References:
https://www.owasp.org

The post OWASP Top 10 2017: What changed from 2013 to 2017? first appeared on All About Testing.

Q1. What is OWASP? Also Mention OWASP TOP 10 2021.

Ans: OWASP is a non-profit organization that releases the top 10 web vulnerabilities. It works as a community of cybersecurity professionals, who constantly work to build an ecosystem for awareness about secure web applications. Recently, OWASP released new top 10 vulnerabilities for 2021:

• A01 Broken Access Control
• A02 Cryptographic Failures
• A03 Injection
• A04 Insecure Design
• A05 Security Misconfiguration
• A06 Vulnerable and Outdated Components
• A07 Identification and Authentication Failures
• A08 Software and Data Integrity Failures
• A09 Security Logging and Monitoring Failures
• A10 Server Side Request Forgery (SSRF)

Q2. Mention what flaw arises from session tokens having poor randomness across a range of values.

Ans:  Session hijacking, is the issue related to A2: 2017 – Broken Authentication. It is also called cookie hijacking. In this type of attack, there is the possibility of exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized access to information or services in a system. This flaw comes when there is poor randomness in the session key.

Q3. How to mitigate SQL Injection risks?

Ans: Mitigations of SQL injection:

• Prepared Statements with Parameterized Queries: Always ensure that your SQL interpreter can always differentiate between code and data. Never use dynamic queries which fail to find the difference between code and data. Instead, use static SQL query and then pass in the external input as a parameter to query.  The use of Prepared Statements (with Parameterized Queries) forces the developer first to define all the SQL code and then pass each parameter to the query later.
• Use of Stored Procedures: Stored Procedure is like a function in C where the database administrator calls it whenever he/she needs it. It is not completely mitigated SQL injection but definitely helps in reducing risks of SQL injection by avoiding dynamic SQL generation inside.
• White List Input Validation: Always use white list input validation and allow only preapproved input by the developer. Never use a blacklist approach as it is less secure than a whitelist approach.
• Escaping All User Supplied Input
• Enforcing the Least Privilege

Click Here for SQL Injection Interview Questions

Q4. How to mitigate the risk of Weak authentication and session management?

Ans: Weak Authentication and Session management can be mitigated by controls of strong authentication and session management. Such controls are as follows:

• Compliant with all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).
• Always use a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.
• Use standard practices to secure session id by cross-site scripting attack.

Q5. How to mitigate the risk of Sensitive Data Exposure?

Ans: Following are the mitigation techniques employed for secure applications from Sensitive data exposure:

• Prepare a threat model to secure data both in transit and at rest from both types of the attacker( e.g., insider attack, external user)
• Encrypt data to protect it from any cyber attack.
• Never store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
• Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data.
• Always implement and ensure strong standard algorithms and strong keys are used, and proper key management is in place. Consider using FIPS 140 validated cryptographic modules.
• Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.

Q6. What is a bug bounty?

Ans: Bug bounty is a program run by many big organizations which rewards those individuals who report security vulnerabilities to them. These organizations generally publish those vulnerabilities on websites after fixing those issues.

Q7. What Is Failure to Restrict URL Access?

Ans: This vulnerability has been removed from OWASP Top 10 2013. Actually, this issue is related to forced browsing where a user forcibly accesses URLs which is not supposed to access by the user. The attacker may guess links and brute force techniques to find unprotected pages through this vulnerability.

Q8. How to Prevent Breaches Due to Failure to Restrict URL Access?

Ans: This can be mitigated by using secure techniques for proper authentication and proper authorization for each page of the web application. Some mitigation techniques are described below:

• Implement Authentication and authorization policies based on the role instead of based on the user.
• Policies are highly configurable in favor of standard practices.
• Deny all access by default, and allow only those controls that the user needs.

Q9. How can we Protect Web Applications From Forced Browsing?

Ans: To protect web applications from forced browsing, strictly monitor access-control settings to be accurate and up-to-date on every page and application on the site.

Q10. Mention what is the basic design of OWASP ESAPI.

Ans: OWASP ESAPI is short for OWASP Enterprise Security API which is voluntarily developed by the OWASP community to provide a free, open-source, web application security control library to web developers to help them to develop a less vulnerable web application.

The basic design of OWASP ESAPI includes a set of security control interfaces. For each security control, there is a reference implementation that can be implemented as the requirement of the organization.

The post Top 10 Interview Questions | OWASP TOP 10 first appeared on All About Testing.