PENETRATION TESTING

A user should have access only to the objects and actions that are permitted for that user. Access control can be related to information disclosure, modification or deleting of data, unauthorized file access or performing a function outside of the user’s limits.

Security misconfigurations can be faced in many different aspects: for example, there are unnecessary features used, error handling reveals information about system’s internals, and application server, frameworks, libraries, databases etc. are not set to secure values. Although configurations cannot be reviewed directly in black-box testing, misconfigurations show up as security vulnerabilities.

Software supply chain failures arise when vulnerabilities or malicious changes are introduced through third-party dependencies, build tools, or distribution channels. Inventory of used components and regular security pathing diminish the risk for security issues from third-party components. Also, it is essential to harden the entire CI/CD pipeline, enforce strict access controls, and ensure that no single person can promote code to production without oversight.

Data requires protection both in transit and in rest depending on the sensitiveness of the related data. Passwords, credit card numbers, health records, personal information and so on require extra protection especially when the data falls under privacy laws (e.g. GDPR).

Hostile data from an untrusted source can end up to an interpreter, which executes the injected data. The interpreter can be for example a database (e.g. SQL injection), operating system (e.g. OS command injection) or user’s browser (Cross-site scripting).

The implementations that follow the design precisely are not unconditionally secure as the design may contain flaws. For example, business logic errors, bypassing client-side security and external control of file names and paths expose the system for different types of vulnerabilities.

Authentication-related attacks are usually related to confirmation of the user's identity, authentication and session management. Only users with correct credentials should have access to the system. For example, if authentication can be bypassed, external users can get information they are not allowed to access. Session management should always create a new authentication token whenever a user is logged in or logged out and the token should be automatically invalidated after timeout.

Applications, CD/CI pipeline and auto-updates should always have a trusted data source and have sufficient integrity verification. The data that is sent from an attacker is always untrusted and especially serialized data require some form of integrity check or digital signature to prevent insecure deserialization.

When a system is properly monitored and operations are logged, it is easier to detect suspicious actions. There should be logging in the application, logging should raise alerts, the alerts should be monitored and when suspicious activity is observed, there should be actions to handle the situation.

This category focuses on the failure of software to properly prevent, detect, and respond to abnormal or unpredictable system states. When applications fail to "fail securely" or lack specific handlers for environmental and logical errors, they often revert to an unpredictable state that attackers can exploit to bypass authentication or leak sensitive reconnaissance data.