Learn about top vulnerabilities such as improper access controls, open ports, and outdated components.
13 
Learn about the top types of access control violations, including lack of authentication, misused status codes, and CSRF attacks. Protect your web application from hackers with our tips.
Disclaimer: This material is intended for educational purposes only. The information provided is intended to increase awareness and improve software security.
Access control violations are situations where users gain access to resources or functions for which they do not have the appropriate rights. This can happen for several reasons:
Description: When the system does not verify the user’s identity before providing access to sensitive data or functions.
Example: A web application allows users to view information about other accounts without having to log in. For example, a user can view personal data of others without authorization.
Description: After a user is authenticated, the system does not verify that they are authorized to access specific resources or functions.
Example: An ordinary user can access the administrative panel or change data that should be accessible only to administrators. For example, an ordinary user can delete other users’ posts.
Description: Code 403 means that access to the resource is denied, while code 404 indicates that the resource was not found. Improper use of status codes can reveal information about the structure of the application.
Example: If the system returns a 404 when trying to access the administrative section of a web application, this may indicate that such a section exists, but access to it is blocked.
Instead, code 403 clearly signals that access is denied.
Description: Inclusion of sensitive data in URLs or request parameters that may be visible or accessible to attackers.
Example: Passing user IDs or access tokens to a URL that may be stored in server logs or browser history. For example, a URL like https://example.com/profile?user_id=1234 allows you to change the user_id and access a different profile.
Description: Attacks in which an attacker tricks a user who is already authenticated into a web application into performing an unwanted action.
Example: An attacker can create a fake web page containing a password change form on a site where the user is already authenticated. If the user opens this page, a password change request will automatically be sent to the real site, changing their password without their knowledge.
BLUE TEAM
Authentication is the process of confirming a user’s identity. The most common example is when a user enters their identifier, such as an email, along with a password. When a request is sent to a protected zone, the firewall gets the opportunity to extract the user’s personal data from the Request object. Next, the system generates a token that includes the authentication manager. This manager validates the token and, if the information provided is as expected, issues a validated token. After that, this token is stored in a special storage for future use.
RED TEAM
Brute force
The attack becomes possible when authentication is missing or not strong enough, which allows attackers to use an iterative method to select passwords, iterating through all possible options until the correct one is found. In the context of Symfony, a brute force attack consists of trying to break into the protected parts of a site or application by choosing the right combination of logins and passwords. Such attacks typically target the standard authentication mechanisms that Symfony implements through the Security Bundle.
This script systematically iterates through different passwords from the list until the correct one is found. The attack is effective in cases where there is no limit on the number of attempts or the account is not blocked after several unsuccessful attempts.
Apply brute force tools: Tools like Hydra, Burp Suite or OWASP ZAP can automate this process, greatly increasing the effectiveness of the attack.
BLUE TEAM
Authorization is the process of verifying rights to access or modify resources.
RED TEAM
IDOR – Insecure Direct Object References. Lack of access rights validation can allow attackers to gain access to resources simply by changing the identifiers in the URL.
By changing the identifier in the URL, an attacker can gain access to another user’s data if proper access rights are not checked.
Forbidden – The 403 Forbidden status code indicates that the server understood the request, but refuses to fulfill it due to a lack of necessary permissions.
Not Found – The 404 Not Found status code indicates that the requested resource was not found on the server. This could be the result of an incorrect URL or a missing file on the server.
BLUE TEAM
If you do not want the user to know about the existence of a certain resource, you should use a 404 (Not Found) response. If you need to clearly show that the resource exists, but access to it is limited, it is better to use the 403 (Forbidden) code.
RED TEAM
Resource Enumeration. Attackers can use the difference between 403 and 404 responses to determine whether a resource exists, even if they don’t have access to it.
This script checks for resource availability by analyzing server responses. If the resource exists, but access is denied, a 403 code is returned, and if it does not exist, a 404 code is returned.
Sensitive Data in Insecure Parameters is a situation where sensitive information such as passwords, tokens, or personal data is transmitted through request parameters or other insecure mechanisms. This poses a threat because insufficient protection of such data can lead to its leakage or compromise.
BLUE TEAM
RED TEAM
Insecure Parameter Exploitation. Attackers can manipulate unsafe settings to gain access to sensitive information or gain elevated access rights.
This script uses unsafe parameters such as can_edit and is_admin to gain access to functions that should be protected.
Cookies are automatically sent to the site with each request.
The attacker can force the victim to send requests (including POST) to some site.
When this happens, the victim’s cookies (including authentication cookies) are sent to the server.
BLUE TEAM
Use of CSRF tokens. They are stored in user sessions and added to forms as a hidden field. When the user submits the form, the token is validated. If it doesn’t match what’s in the session, the user gets an error.
RED TEAM
Using CSRF to modify data. Attackers can force a victim to send a request to a server using their credentials to perform unwanted actions.
This code forces the victim to transfer funds to the attacker’s account using their session and cookies without them even knowing it.
Cryptographic errors are flaws in the implementation of cryptography that can lead to data leakage or compromise.
Description: Use of outdated or unsafe cryptographic algorithms or protocols.
Example: Using MD5 to hash passwords instead of more modern algorithms like bcrypt or Argon2, which can easily crack hashes.
Description: Incorrect or insufficient encryption of sensitive data.
Example: Storing passwords in plain text or using weak encryption keys, making data accessible to attackers.
Description: Storage of cryptographic keys in untrusted locations or without adequate protection.
Example: Storing cryptographic keys in application code or configuration files accessible to attackers.
Description: Insecure session management that allows attackers to intercept or spoof user sessions.
Example: Using predictable or not sufficiently complex session identifiers that can be easily guessed or forged.
HTML entities – are special characters used to replace unsafe or reserved characters in HTML code to prevent them from being misinterpreted by the browser.
Example:
Original code: <script>alert(‘XSS’);</script>
Coded: <script>alert(‘XSS’);</script>
HTML code is interpreted as text in the browser, not as executable code, which prevents XSS attacks.
If a website does not correctly process HTML code and does not properly encode input data, an attacker can use an XSS (Cross-Site Scripting) attack to execute JavaScript code on the client side. This can allow it to hijack user sessions, insert malicious scripts, or modify data on a page.
Example:
An attacker enters: <script>alert(‘XSS’);</script> into an input form, and if the data is not properly encoded, this script will be executed in another user’s browser.
URL encoding (also known as percent encoding) is used to ensure that special characters are passed in URLs. This is necessary to avoid conflicts with special characters that have meaning in the URL structure.
Example:
Original text: lorem with !@#$%^
Coded: lorem+with+%21%40%23%24%25%5E
Special characters are encoded in the format %XX, where XX is the hexadecimal ASCII value of the character code.
Attackers can use URL encoding to bypass web application filters. For example, if the server filters out dangerous characters such as < and >, an attacker could encode them into %3C and %3E and inject malicious code.
Example:
URL encoding can be used to bypass SQL injection filters or XSS attacks. An attacker could encode a malicious SQL query or JavaScript code and enter it into a form on a site that does not validate and decode this data properly.
Base64 is a way of encoding data that converts it into a format that consists only of characters that can be represented as text (letters, numbers, and a few special characters). This method is usually used to transfer binary data such as images or files in text format.
Example:
Original text: this is original text
Coded: dGhpcyBpcyBvcmlnaW5hbCB0ZXh0
Base64 encodes data as text that can be transmitted over text-based protocols.
Red Team Perspective:
Attackers can use Base64 to hide malicious code or data in a format invisible to the user, making it difficult to detect an attack.
Example:
An attacker can base64 encode malicious JavaScript code and embed it in a web page or email. Once decoded, this code can execute and cause harm to the user’s system.
How HTTP works:
A client (for example, a browser) sends an HTTP request to a web server asking for a specific resource (for example, a web page).
The server responds to the request by sending back a resource, which can be an HTML file, an image, or some other type of data.
HTTP is a dangerous protocol because it transmits data in the open, without encryption. This allows attackers to intercept information during a man-in-the-middle (MITM) attack. Such access allows them to obtain sensitive data, including passwords, session tokens, and other sensitive information.
Example:
MITM attack: An attacker can use a network sniffer, such as Wireshark, to intercept HTTP traffic and read the transmitted data, such as logins and passwords.
Session Hijacking: Using intercepted data such as session cookies, an attacker can hijack a user’s session and gain access to their account.
HTTPS is a secure version of HTTP that applies encryption to ensure the confidentiality, integrity, and authenticity of the data being transmitted. To protect data, HTTPS uses the TLS (Transport Layer Security) protocol or its predecessor SSL (Secure Sockets Layer).
How HTTPS works:
When using HTTPS, all data between the client and the server is encrypted, which protects them from interception and modification.
HTTPS also provides server authentication using digital certificates to confirm that the client is connecting to the correct server and not a fake one.
Red Team Perspective:
HTTPS is not completely secure. Although HTTPS encrypts data, it does not protect against other types of attacks. For example, if the server is configured incorrectly, attackers can perform SSL-stripping attacks or exploit vulnerabilities in the TLS/SSL implementation.
Example:
SSL-Stripping: An attacker intercepts traffic and replaces HTTPS with HTTP during a request. The user sees a normal HTTP page, thinking it is secure, and all data is transmitted in the clear.
TLS Attacks: Vulnerabilities in older versions of SSL/TLS, such as POODLE, can be used to decrypt data or perform other privacy attacks.
Protect sensitive data with encryption. To ensure the protection of sensitive information that may be used in the future, it should be stored in encrypted form. This ensures that even if the data is stolen or hacked, access to it will be restricted to unauthorized persons.
An example of encryption:
Example:
A weak password attack: If the password or passphrase is weak, an attacker can perform a brute-force attack and gain access to the data. For example, using tools like Hashcat, you can automate key selection.
IV attack: If the initialization vector (IV) is too short or repeated, an attacker can try to decrypt the data using ciphertext attacks.
Password storage using hashing. Passwords should be stored as a hash, not in the plaintext, to ensure they are protected in the event of a database leak.
Example of password hashing:
Hash attack: If password hashes are stored without proper additional protection, attackers can use methods such as Rainbow Tables or brute-force attacks to crack passwords.
Example:
Weak hashing: If a weak or outdated hashing algorithm (such as MD5 or SHA1) is used, attackers can quickly crack passwords.
Attack on salt (salt): If hashing is done without adding salt (random salt), an attacker can use pre-calculated tables (Rainbow Tables) to reveal hashes.
Injections are vulnerabilities that allow attackers to inject malicious code or data into an application that causes unwanted or dangerous behavior.
Description: A vulnerability that allows attackers to inject SQL code into database queries.
Example: A web application that uses user input to form SQL queries without proper validation, allowing an attacker to execute arbitrary SQL queries.
Description: A vulnerability that could allow an attacker to inject operating system commands.
Example: An application that executes system commands based on user input, allowing an attacker to execute unwanted commands.
Description: A vulnerability that could allow an attacker to inject malicious JavaScript code into web pages that are then executed in other users’ browsers.
Example: An application that displays user input without proper sanitization, allowing an attacker to inject malicious code.
XSS (Cross-Site Scripting) is a vulnerability that allows an attacker to inject malicious script into a web page that is executed in the victim’s browser. This can lead to the theft of session cookies, changes to the content of the page, or redirecting the user to a malicious site.
An attacker can inject JavaScript code that performs unwanted actions, such as stealing cookies or redirecting the user.
To prevent XSS attacks, ensure input and output sanitization:
Input sanitization: Use htmlspecialchars() to sanitize data received from the user.
Output sanitization: Use functions that automatically escape the output, such as htmlspecialchars() in PHP or autoescaping in the Twig or Blade template engines.
HTTP Only flag: Use the HTTP Only flag for cookies to prevent access to them via JavaScript.
Theft of cookies:
Forgery of page content:
SQL Injection is a vulnerability where an attacker can inject malicious SQL code into database queries, allowing data to be accessed, modified, or deleted.
Dangerous SQL query:
Preventing SQL Injection:
Use prepared statements:
An attacker can inject malicious code into $someString:
HTTP Parameter Injection is a vulnerability that occurs when an attacker modifies HTTP request parameters to gain unauthorized access or change data.
Vulnerable code that allows changing parameters:
File vulnerabilities can occur due to improper processing or validation of files that are uploaded by users or due to vulnerabilities in web servers.
Using require() and include() in PHP:
An attacker can include a malicious file, for example: http://attacker.site/malicious.php.
Weak file validation:
An attacker can use ../ to navigate to unwanted directories.
13 
15 
1578