2. www.valencynetworks.com
Introduction
PHP is the most widely used server side language
Many open source frameworks are popular
Easy targets for attackers
Frameworks Analysed: CodeIgniter, CakePHP, Symfony
Vulnerability Analysis Tools used: Arachni, OWASP-ZAP, Nikto
3. www.valencynetworks.com
1. 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.
4. www.valencynetworks.com
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.
5. www.valencynetworks.com
2. 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.
6. www.valencynetworks.com
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.
7. www.valencynetworks.com
3. 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.
8. 8
4. 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.
9. 9
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”.
10. 10
Few other vulnerabilities
• 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!)
11. 11
Recommended
Be updated about the latest vulnerabilities regarding the frameworks,
modules and languages used by the web application through
newsletters, github and blog posts.
Assess the application after it is updated using any of the robust tools
available.