In this chapter, we’ll talk about setting up a security testing environment and introduce basic processes and techniques you can use to test Android apps for security flaws. These basic processes are the foundation for the test cases outlined in the following chapters.
These are some tips from OWASP to check for security testing in projects.
These are some of the security Checkups in 2021 by using OWASP.
- 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.
Broken Access Control
Overview
Moving up from the fifth position, 94% of applications were tested for some form of broken access control with an average incidence rate of 3.81% and has the most occurrences in the contributed dataset with over 318k.
Description
- Accessing API with missing access controls for POST, PUT and DELETE.
- Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, or a cookie or hidden field manipulated to elevate privileges or abusing JWT invalidation.
- Violation of the principle of least privilege or deny by default, where access should only be granted for particular capabilities, roles, or users, but is available to anyone.
How to Prevent
Access control is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.
- Except for public resources, deny by default.
- Log access control failures, and alert admins when appropriate (e.g., repeated failures).
- Rate limit API and controller access to minimize the harm from automated attack tooling.
Examples
An attacker simply forces browses to target URLs. Admin rights are required for access to the admin page.
https://example.com/app/accountInfo?acct=notmyacct
Attacker checks for these kind of URLs and if it present in our code then it can be simply used for some other purposes.
Cryptographic Failures
Overview
Shifting up one position to #2, previously known as Sensitive Data Exposure, which is more of a broad symptom rather than a root cause, the focus is on failures related to cryptography (or lack thereof). Which often leads to exposure of sensitive data.
Description
- Is the received server certificate and the trust chain properly validated?
- The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection.
- Are deprecated cryptographic padding methods such as PKCS number 1 v1.5 in use?
How to Prevent
- Apply required security controls as per the data classification.
- Classify data processed, stored, or transmitted by an application.
- Don’t store sensitive data unnecessarily.
- Always use authenticated encryption instead of just encryption.
Example Attack Scenarios
An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing a SQL injection flaw to retrieve credit card numbers in clear text.
Injection
Overview
Injection slides down to the third position. 94% of the applications were tested for some form of injection with a max incidence rate of 19%, an average incidence rate of 3%, and 274k occurrences.
Description
- User-supplied data is not validated, filtered, or sanitized by the application.
- Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
How to Prevent
- Use positive server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
- Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
Example Attack Scenarios
String query = “SELECT \* FROM accounts WHERE custID='” + request.getParameter(“id”) + “‘”;
In this cases, the attacker modifies the ‘id’ parameter value in their browser to send: ‘ or ‘1’=’1. For example:
http://example.com/app/accountView?id=’ or ‘1’=’1
Insecure Design
Overview
A new category for 2021 focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures. As a community we need to move beyond “shift-left” in the coding space to pre-code activities that are critical for the principles of Secure by Design.
Description
- Requirements and Resource Managements.
- Secure Design.
- Secure Development Lifecycle.
How to Prevent
- Integrate security language and controls into user stories.
- Limit resource consumption by user or service.
- Use threat modeling for critical authentication, access control, business logic, and key flows.
Example Attack Scenarios
A credential recovery workflow might include “questions and answers,” which is prohibited by NIST 800–63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers cannot be trusted as evidence of identity as more than one person can know the answers, which is why they are prohibited. Such code should be removed and replaced with a more secure design.
Security Misconfiguration
Moving up from #6 in the previous edition, 90% of applications were tested for some form of misconfiguration, with an average incidence rate of 4.%, and over 208k occurrences of a Common Weakness Enumeration (CWE) in this risk category. With more shifts into highly configurable software, it’s not surprising to see this category move up.
Description
- Default accounts and their passwords are still enabled and unchanged.
- For upgraded systems, the latest security features are disabled or not configured securely.
- Error handling reveals stack traces or other overly informative error messages to users.
How to Prevent
- A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
- Review cloud storage permissions.
Example Attack Scenarios
- The application server comes with sample applications not removed from the production server.
- The application server’s configuration allows detailed error messages, e.g., stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable.
Vulnerable and Outdated Components
Overview
It was #2 from the Top 10 community survey but also had enough data to make the Top 10 via data. Vulnerable Components are a known issue that we struggle to test and assess risk and is the only category to not have any Common Weakness Enumerations (CWEs) mapped to the included CWEs, so a default exploits/impact weight of 5.0 is used.
Description
- If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.
- If software developers do not test the compatibility of updated, upgraded, or patched libraries.
How to Prevent
- Remove unused dependencies, unnecessary features, components, files, and documentation.
Example Attack Scenarios
Some flaws can be accidental (e.g., coding error) or intentional (e.g., a backdoor in a component).
Identification and Authentication Failures
Overview
Previously known as Broken Authentication, this category slid down from the second position and now includes Common Weakness Enumerations (CWEs) related to identification failures.
Description
- Permits default, weak, or well-known passwords, such as “Password1” or “admin/admin”.
- Uses plain text, encrypted, or weakly hashed passwords data stores.
- Reuse session identifier after successful login.
How to Prevent
- Do not ship or deploy with any default credentials, particularly for admin users.
- Implement weak password checks, such as testing new or changed passwords against the top 10,000 worst passwords list.
Example Attack Scenarios
- Credential stuffing, the use of lists of known passwords, is a common attack.
- Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered, best practices, password rotation, and complexity requirements encourage users to use and reuse weak passwords.
Software and Data Integrity Failures
Overview
A new category for 2021 focuses on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data.
Description
- An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise.
- Many applications now include auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application.
How to Prevent
- Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes.
- Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered.
Example Attack Scenarios
- Update without signing
- SolarWinds malicious update.
Security Logging and Monitoring Failures
Overview
Security logging and monitoring came from the Top 10 community survey (#3), up slightly from the tenth position in the OWASP Top 10 2017. Logging and monitoring can be challenging to test, often involving interviews or asking if attacks were detected during a penetration test.
Description
- Warnings and errors generate no, inadequate, or unclear log messages.
- Logs of applications and APIs are not monitored for suspicious activity.
- Logs are only stored locally.
How to Prevent
- Ensure that logs are generated in a format that log management solutions can easily consume.
- Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems.
- Ensure all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis.
Example Attack Scenarios
- A major Indian airline had a data breach involving more than ten years’ worth of personal data of millions of passengers, including passport and credit card data.
- The data breach occurred at a third-party cloud hosting provider, who notified the airline of the breach after some time.
Server-Side Request Forgery (SSRF)
Overview
This category is added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above average testing coverage and above-average Exploit and Impact potential ratings.
Description
As modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidence of SSRF is increasing. Also, the severity of SSRF is becoming higher due to cloud services and the complexity of architectures.
How to Prevent
- From Network Layer
- From Application Layer
Example Attack Scenarios
Access metadata storage of cloud services — Most cloud providers have metadata storage such as http://169.254.169.254/. An attacker can read the metadata to gain sensitive information.
