- Vulnerability Assessment in 3 PHP Frameworks - 06/01/2020
- PHP Security Best Practices-2 - 06/01/2020
- PHP Security Best Practices – 1 - 06/01/2020
Vulnerability Assessment in 3 PHP Frameworks
PHP is the most widely used server side language to build web applications and has a good variety of frameworks, most of them open source. Their popularity and increasing usage makes them an attractive target for hackers. So before adapting any of such frameworks for your project, be sure to check how secure they are, what provisions are available to implement several security measures and how quickly were the reported vulnerabilities fixed.
To get an idea of how vulnerable the applications can be, vulnerability assessment was performed on three well known PHP frameworks – Symfony , CodeIgniter and CakePHP. Sparing Laravel since it is a pretty secure framework. Vulnerability assessment tools used were Arachni, OWASP-ZAP and Nikto.
An application developed using the mentioned frameworks can have following vulnerabilities:
⦁ Revealing system paths and directory listing.
Error messages can include file paths, which can reveal the framework, language and/or server used for that application. This makes the application vulnerable to Directory Traversal Attack. If the directory listing is not turned off or if the attackers are successful in turning the directory listing on, attackers can get hold of the source code, hidden scripts and configuration files.
Fixation: Turn off the descriptive error messages and directory listing at the application level as well as at the server level. Return static error page with response code 404 for the paths that could not find content to serve. Manually review permissions of web directory contents for unnecessary files, such as documentation, template, example files, which could be used by an attacker to identify attackable surface area. Sanitize the URL parameters to prevent reverse traversal by ‘../’, an extra ‘/’ or Unicode characters.
⦁ Not configuring response headers
Not setting X-XSS-Protection, X-Frame-Options, X-Content-Type-Options and allowing TRACE/TRACK HTTP method requests makes the application vulnerable to XSS attacks, ClickJacking attacks and MIME-sniffing.
Fixation: Ensure that the web browser’s XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to ‘1’. Set X-Frame-Options to DENY or SAMEORIGIN depending on the requirement. Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to ‘nosniff’ for all web pages. Disable TRACE/TRACK methods.
⦁ Not verifying referral header of a submitted form
Not verifying referral header of form submission can lead to CSRF attacks. Most of the forms are submitted by POST method but the application may not check if the request was coming in from their own site or not. The request might be coming in from an attacker’s portal.
Fixation: Checking for a referral header can help in preventing the CSRF. Allow request from the same domain or trusted domains. Make sure the application is not vulnerable to open redirects. Use of HTTPS can also prevent this attack.
⦁ Not implementing secure authentication methods
Not using SSL/TLS, not hashing passwords before storage, not mandating tough password rules can leave the applications vulnerable to many kinds of attacks. Not limiting maximum length for passwords can make the app vulnerable to DOS attack. Weak password reset mechanism can invite MITM attacks. Giving login error response, which states if the account of a particular login id exists or not, can invite brute force attacks.
Fixation: Use either framework’s built in methods or a trusted authentication library to implement a secure authentication system. Use of HTTPS is recommended. Allow 2 Factor Authentication for Admin Accounts or for all the users of a critical application. Login error response should be standard irrespective of the existence of the login id, for example “Login ID and password combination invalid” instead of “Login ID not found”.
Few other vulnerabilities can be
⦁ Not validating, sanitizing user inputs
⦁ Not keeping the framework updated to the latest version
⦁ Using third party modules without assessing their security
⦁ Using default admin username (and even password!)
To prevent your application from zero day attacks, keep periodically checking for latest vulnerabilities and fixes that are reported by the open source community through github, newsletters and blog posts. Assess the application after it is updated using any of the robust tools available.
Shubham Dhamande
Intern, Valency Networks