Learn about the top types of access control violations, including lack of authentication, misused status codes, and CSRF attacks.
445 
How to protect web applications from unsafe design and insecure configurations? Learn about top vulnerabilities such as improper access controls, open ports, and outdated components.
Insecure designs are problems in the architecture and design of an application that can lead to security vulnerabilities.
Description: Ignoring security during the design or development phase of an application.
Example: Necessary security measures are not included in the planning and implementation of the application, resulting in vulnerabilities.
Description: Ignoring security during the design or development phase of an application.
Example: Necessary security measures are not included in the planning and implementation of the application, resulting in vulnerabilities.
Description: Improper management of access to functions and data.
Example: Lack of access segmentation or protection of sensitive data, allowing unauthorized users to gain access to critical functions.
Single Entry Point, or Front Controller, is an architectural pattern where all requests to a web application go through a single access point. This provides centralized processing of requests, simplifying security and routing controls.
In frameworks like Symfony, Laravel, and Yii2, this pattern is implemented through a single file, such as index.php, that handles all requests to the application.
If the Front Controller is configured incorrectly or contains vulnerabilities, attackers can try to bypass it or use it for attacks. This can cause them to gain access to files or directories, bypassing the main control mechanism. Such situations arise due to an incorrect configuration of the server, when direct access to files that should be protected is allowed.
curl http://target-site.com/config.php
If there are errors in the routing, attackers can try to manipulate the routes to access unwanted parts of the application.
curl http://target-site.com/index.php?controller=Admin&action=editUser&id=1
It is possible to use query parameters for manipulation or performing unwanted actions.
curl http://target-site.com/index.php?module=User&action=delete&id=1
Attackers can look for vulnerabilities in the code that handles requests through the Front Controller, such as SQL injection or other input-based attacks.
curl http://target-site.com/index.php?search=’ OR ‘1’=’1
Basic principles:
Minimize open ports: Only necessary ports should be available to users. For example, the ports for the web server (80/443 for HTTP/HTTPS) or the port for the database (if needed).
Limit access to critical ports: Some ports, such as port 22 for SSH, should be open only on demand or accessible only from an isolated environment, such as through a VPN or from specific IP addresses.
Monitoring and auditing: Continuous monitoring of open ports and auditing of settings help to detect and close unnecessary ports in time.
Firewall application: Use firewall rules to restrict access to ports, allowing access only for certain services and from certain IP addresses.
Using tools such as Nmap to scan the network and detect open ports. This is the first step in attacks on open ports.
nmap -p- target-ip
After detecting open ports, attackers can try to exploit vulnerabilities in the corresponding services.
hydra -l username -P password_list.txt ssh://target-ip
Open ports can be used to carry out Denial of Service (DDoS) attacks aimed at overloading the resource.
An attacker can use an open port to create a tunnel and access internal resources that are not normally accessible from the outside.
ssh -L 8080:localhost:80 user@target-ip
Deny by Default and Fail Early — are principles of application development and security that involve the system automatically blocking access or execution of actions if necessary conditions are not met, and stopping code at early stages when errors or problems are detected. This helps minimize risks and increases system reliability.
Deny by Default:
All actions and accesses should be denied by default, and only after the necessary checks have been successfully passed are actions or access allowed. This approach minimizes the risk of accidental or unauthorized access. Principle of Fail Early:
When an error or incorrect state is detected, the system must stop further execution immediately to avoid further problems or possible attacks.
Attacks on systems with incorrect implementation of these principles
If the system has hidden routes or functions that do not have explicit access checks, an attacker can gain access to them using a direct request.
curl -X POST https://target-app.com/hidden-route
If authentication is not performed properly at all stages of the process, an attacker can leave the session open and use it for an attack.
An attacker can attempt to perform administrative actions through the standard user interface if the system does not validate roles and permissions properly.
Whitelist and Blacklist are important methods for managing access and restricting actions in systems.
Whitelist: Includes only those items that are allowed. Everything else is automatically prohibited. This is an approach that provides a higher level of security because it clearly defines what can be done.
Blacklist: Includes only those items that are prohibited. Everything else is automatically allowed. This is a less reliable approach because it does not cover all possible threats.
If only certain extensions are disallowed in the blacklist (e.g. .php), an attacker can download a file with other extensions that can still be executed on the server (e.g. .phtml, .php5).
curl -X POST https://target-app.com/upload -F “[email protected]”
If the system allows certain types of files to be uploaded (such as images), an attacker can embed malicious code in the file’s metadata. Embedding malicious JavaScript in images via an XSS attack.
An attacker can try to use non-standard or new extensions that are not included in the whitelist, but can be executed on the server. Downloading a file with a .phar extension, which can also be done on some servers.
Security misconfigurations are mistakes in security settings that can leave an application or system vulnerable.
Description: Leaving outdated or unreliable security settings.
Example: Opened ports or services that are not used but left in the configuration.
Description: Improper configuration of servers that could lead to vulnerabilities.
Example: Incorrect settings for database servers or web servers that allow unauthorized access.
Description: Lack of proper management of accounts and access rights.
Example: Accounts with excessive privileges or with insecure passwords.
Blue Team: Use separate environments for development, testing, and production. Ensure that test environments do not have access to production data.
Red Team: Try to find URLs related to test environments or access to configuration files that may reveal data about the production environment.
Blue Team: Disable HTTP and require the use of HTTPS with up-to-date certificates.
Red Team: Check for traffic tampering (MITM) or data injection in HTTP use cases.
Blue Team: Check your SSL/TLS settings are correct, make sure only trusted protocols and ciphers are used.
Red Team: Check for SSL/TLS vulnerabilities, such as unsafe ciphers or legacy protocol support.
Blue Team: Deny root SSH access, disable password authentication in favor of SSH keys.
Red Team: Try to attack the SSH configuration, focusing on detecting root access or weak passwords.
Blue Team: Deny access to the directory listing via server settings (e.g. via .htaccess or Nginx/Apache configuration).
Red Team: Check the access to the list of directories, look for sensitive files or backups.
Blue Team: Open only those ports that are necessary for the services to work, close the database ports (for example, 5432 for PostgreSQL).
Red Team: Conduct port scans to identify open ports that can be used for attacks.
Blue Team: Change default logins and passwords immediately after system installation, disable outdated accounts.
Red Team: Use brute force attacks or lists of standard passwords to log in.
Blue Team: Disable or delete all test accounts before deploying a production system.
Red Team: Try to detect test accounts through fusing or dictionary-type attacks.
Blue Team: Enable custom error pages, disable call stack display in production environment.
Red Team: Use information from errors for further attacks, such as file paths or database names.
Blue Team: Ensure all security mechanisms remain enabled even during development. For example, require a password to use sudo.
Red Team: Try to use temporary settings that were left after testing.
Vulnerable and deprecated components are the use of components, libraries, or frameworks that contain known vulnerabilities.
Description: Using components that are no longer supported or contain known vulnerabilities.
Example: Using older versions of libraries that have known security bugs that have not been patched.
Description: Neglecting to update components and libraries to the latest versions.
Example: Ignoring patches or updates that fix known vulnerabilities.
Description: Using third-party components without checking their security.
Example: Integrating third-party libraries or frameworks without properly checking their security and integrity.
Use CVE databases such as CVE.mitre.org or Exploit-DB to regularly check your software for known vulnerabilities. Update all system components regularly to avoid using vulnerable versions.
CVE-2021-44228 (Log4Shell) vulnerability in the Log4j library. Installing updates or using settings that reduce risk.
Use known CVEs to attack the target system. Look for vulnerable versions of components or references to exploits in databases to gain penetration. Exploitation of CVE-2021-44228 to allow remote code execution on a server.
Use PHP dependency auditing tools such as Composer Audit to identify outdated and vulnerable dependencies. Keep track of dependency updates and regularly check the project for new vulnerabilities.
Look for vulnerable dependencies within the project. Use them for attacks, for example, through vulnerabilities in libraries or components. Find a vulnerability in an old version of a PHP library that could allow malicious code to be executed.
Use tools like npm audit or Yarn Audit to check Node.js dependencies for vulnerabilities. Regularly check the project for vulnerable packages and update them.
Check if the target system is using old versions of Node.js packages and look for exploits for the identified vulnerabilities. Exploiting a vulnerability in an older version of a library to perform attacks such as data theft or code execution.
445 
37