Skip to main content

OWASP Top 10 Web Application Security Risks

The following identifies each of the OWASP Top 10 Web Application Security Risks, and offers solutions and best practices to prevent or remediate them.

1. Injection
Injection flaws, such as SQL injection, LDAP injection, and CRLF injection, occur when an attacker sends untrusted data to an interpreter that is executed as a command without proper authorization.
* Application security testing can easily detect injection flaws. Developers should use parameterized queries when coding to prevent injection flaws.
2. Broken Authentication and Session Management
Incorrectly configured user and session authentication could allow attackers to compromise passwords, keys, or session tokens, or take control of users’ accounts to assume their identities.
* Multi-factor authentication, such as FIDO or dedicated apps, reduces the risk of compromised accounts.
3. Sensitive Data Exposure
Applications and APIs that don’t properly protect sensitive data such as financial data, usernames and passwords, or health information, could enable attackers to access such information to commit fraud or steal identities.
* Encryption of data at rest and in transit can help you comply with data protection regulations.
4. XML External Entity
Poorly configured XML processors evaluate external entity references within XML documents. Attackers can use external entities for attacks including remote code execution, and to disclose internal files and SMB file shares.
* Static application security testing (SAST) can discover this issue by inspecting dependencies and configuration.
5. Broken Access Control
Improperly configured or missing restrictions on authenticated users allow them to access unauthorized functionality or data, such as accessing other users’ accounts, viewing sensitive documents, and modifying data and access rights.
* Penetration testing is essential for detecting non-functional access controls; other testing methods only detect where access controls are missing.
6. Security Misconfiguration
This risk refers to improper implementation of controls intended to keep application data safe, such as misconfiguration of security headers, error messages containing sensitive information (information leakage), and not patching or upgrading systems, frameworks, and components.
* Dynamic application security testing (DAST) can detect misconfigurations, such as leaky APIs.
7. Cross-Site Scripting
Cross-site scripting (XSS) flaws give attackers the capability to inject client-side scripts into the application, for example, to redirect users to malicious websites.
* Developer training complements security testing to help programmers prevent cross-site scripting with best coding best practices, such as encoding data and input validation.
8. Insecure deserialization
Insecure deserialization flaws can enable an attacker to execute code in the application remotely, tamper or delete serialized (written to disk) objects, conduct injection attacks, and elevate privileges.
* Application security tools can detect deserialization flaws but penetration testing is frequently needed to validate the problem.
9. Using Components With Known Vulnerabilities
Developers frequently don’t know which open source and third-party components are in their applications, making it difficult to update components when new vulnerabilities are discovered. Attackers can exploit an insecure component to take over the server or steal sensitive data.
* Software composition analysis conducted at the same time as static analysis can identify insecure versions of components.
10. Insufficient Logging and Monitoring
The time to detect a breach is frequently measured in weeks or months. Insufficient logging and ineffective integration with security incident response systems allow attackers to pivot to other systems and maintain persistent threats.



Comments

Popular posts from this blog

Mobile Application Testing Checklist

1. DEVICE SPECIFIC CHECKS 1.1  Can the app be installed on the device? 1.2 Does the app behave as designed/desired if there is an incoming call? 1.3 Does the app behave as designed/desired if there is an incoming SMS? 1.4 Does the app behave as designed/desired if the charger is connected? 1.5 Does the app behave as designed/desired if the charger is disconnected? 1.6 Does the app behave as designed/desired if the device goes to sleeping mode 1.7 Does the app behave as designed/desired if the device resumes from sleeping mode 1.8  Does the app behave as designed/desired if the device resumes from lock screen? 1.9    Does the app behave as designed/desired if the device is tilted? 1.10  Does the app behave as designed/desired if the device is shaken? 1.11 Does the app behave as designed/desired if a local message is coming from another app (think   of: calendar reminders, to-do task etc.). 1.12 Does the app behave as designed/desired if a push message i...

Test Scenarios for Excel Export Functionality

1. The file should get exported in the proper file extension. 2. The file name for the exported Excel file should be as per the standards e.g. if the file name is using the timestamp, it should get replaced properly with an actual timestamp at the time of exporting the file. 3. Check for date format if exported Excel file contains the date columns. 4. Check number formatting for numeric or currency values. Formatting should be the same as shown on the page. 5. The exported file should have columns with proper column names. 6. Default page sorting should be carried in the exported file as well. 7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages. 8. Check if the data displayed on a page and exported Excel file is the same. 9. Check export functionality when pagination is enabled. 10. Check if export button is showing proper icon according to the exported file type E.g . Excel file icon for xls files 11. ...

Software Testing Tips

Here are some of the Best Testing Practices which I learned by Experience:  1) Learn to analyze your test results thoroughly. Do not ignore any test result. The final test result may be ‘pass’ or ‘fail’, but troubleshooting the root cause of ‘fail’ will give you the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions. 2) Learn to maximize the test coverage each time you test any application. 100% test coverage might not be possible but still, you can always try to reach near it. 3) In order to ensure maximum test coverage, break your application under test (AUT), into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts. E.g : Lets assume that you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing ...