Common Web Application Weaknesses

This section illustrates the most popular web application security weaknesses that do not really fall down under web vulnerabilities category, but can be exploited to perform information gathering and to facilitate various attacks against web applications.

Table of Content

Environment Misconfigurations:

1. Directory Listing
2. Insecure Backup Location
3. Information Exposure
4. Source Code Disclosure

Insufficient Security Mechanisms:

5. Weak/Default Password
6. Sensitive Cookie In HTTPS Session Without “Secure” Attribute
7. Non HttpOnly Cookies
8. Predictable/Unprotected Administrative Area

Other Security-related Issues:

9. Outdated Software
10. Untrusted Third-Party Content
11. Predictable CAPTCHA
12. Unprotected Email Addresses

Environment Misconfigurations

Incorrect configuration of website environment can lead to serious consequences such as information exposure, denial of service, and even system compromise, if an attacker is able to exploit them along with other weaknesses.

1. Directory Listing

Brief description
Listing of directory contents can be used to obtain valuable information on website structure and file names. An attacker can use this information to exploit vulnerabilities in otherwise hidden scripts, to determine installed applications based on discovered filenames, etc.

Knowledge of the web site structure can help an attacker to pursue other existing vulnerabilities or bypass existing security mechanisms. For example, if the web site allows uploading dangerous files (e.g. images with invalid MIME-type or extension) and changes names of uploaded files as a security measure, directory listing can be used to discover the name of the uploaded file and execute it.

Remediation
It is recommended to disable directory listing in web server configuration.

Configuration Examples:

1. Apache HTTP Server
   Directory listing is disabled by default in Apache HTTP server. However it can be enabled for some reasons. The following directive should be present in httpd.conf file, which disables indexes for the entire web site:
   [httpd.conf]
   <Directory /> Options -Indexes </Directory>

   The same configuration can be used with .htaccess files.
   [.htaccess]
   Options –Indexes

2. Microsoft IIS
   By default directory listing is disabled in Microsoft IIS. However it can be enabled for some reasons. To disable it use the following command:
   appcmd set config /section:directoryBrowse /enabled:false

If for some reason you cannot reconfigure your web server, place an empty index file into each directory. This can be used as a temporary solution.

References
WASC-16: Directory Indexing
WASC-14: Server Misconfiguration

2. Insecure Backup Location

Brief description
Incorrect configuration of the application or environment may expose certain valuable information such as backup copies of files, database or entire website. This can happen when the website administrator or web application stores backup copies within the website root and does not restrict access to these files. A remote attacker can download these files and gain access to potentially valuable information.

A recent vulnerability in XCloner (HTB23206) could be a great example of this issue. The provided CSRF exploit in the advisory uses web site functionality to created a backup file within a webroot. An attacker can download a backed up copy of the entire website, unless access to .tar files is restricted by web server.

Remediation
It is not recommended to store backup copies within the webroot. However, if there is no way to change web application behavior, we strongly advise to use server-based ACLs to restrict access to these files and folders.

In these examples we will restrict access to directory "/backup" for everyone and allow access for IP address "192.168.1.25":

Configuration Examples:

1. Apache HTTP Server
   [httpd.conf]
   <Directory /backup>
Order allow,deny
Deny from all
Allow from 192.168.1.25
</Directory>

   [.htaccess]
   Deny from all Allow from 192.168.1.25


2. Microsoft IIS
   You can restrict access by IP address to the “/backup” directory using the following server configuration:
   applicationHost.config
   <location path="WebSiteName/backup">
<system.webServer>
<security>
<ipSecurity allowUnlisted="false">
<add ipAddress="192.168.1.25" allowed="true" />
</ipSecurity>
</security>
</system.webServer>
</location>


   In this example access to the desired folder will be granted to IP address "192.168.1.25". All other IP addresses will be blocked.

   Note: IP Address and Domain Restrictions Feature must be installed to allow IP-based access controls.

3. NGinx
   You can restrict access by IP address to the “/backup” directory using the following server configuration: location /backup {
allow 192.168.1.25;
deny all;
}

   In this example access to the desired folder will be granted to IP address "192.168.1.25". All other IP addresses will be blocked.

References
WASC-34: Predictable Resource Location

3. Information Exposure

Brief description
Default configuration of environment may expose certain system information, which can be valuable for an attacker: web server version, statistics, versions of installed modules, etc.

For example, the default installation of PHP allows exposure of potentially sensitive data. The following URIs can be used to discover PHP installation on the system:
http://[host]/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
http://[host]/?=PHPE9568F35-D428-11d2-A769-00AA001ACF42
http://[host]/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
http://[host]/?=PHPE9568F34-D428-11d2-A769-00AA001ACF42

Version of webserver and interpreting langue can be exposed via HTTP headers:

Received information can be used to determine software version and exploit through the web application software-specific vulnerabilities, such as buffer errors in certain PHP functions, SSL issues, etc.

Remediation
Please follow the instructions below to mitigate exposure of excessive data.

Configuration Examples:

1. Apache HTTP Server
   You can hide version of the web server using the following directive:
   [httpd.conf]
   ServerTokens Prod

   Please refer to the official documentation for more information on secure configuration of the webserver.

2. Microsoft IIS
   We recommend using the official documentation on configuration if Microsoft IIS. Disable debugging output for ASP using the following Host configuration. Set "Send Errors To Browser" option to "False":
   
   

   It also recommended to use Custom error pages to avoid leaking potentially sensitive information. Use the "Error pages" feature to modify default behavior.

3. PHP
   Set the following options in php.ini file:
   php_expose=off
display_errrors = off

These options will prevent PHP from outputting error messages in user’s browser and disable PHP advertising to everyone.

References
WASC-13: Information Leakage
WASC-14: Server Misconfiguration
WASC-45: Fingerprinting

4. Source Code Disclosure

Brief description
Incorrect web server configuration can lead to source code disclosure of different scripts and configuration files. For example, many web applications written in PHP use “.inc” extension for included scripts. If the web server configuration does not associate the “.inc” extension with PHP scripts, it is possible to access these files directly and browse their contents. This way an attacker can obtain potentially sensitive data such as database credentials and even perform source code audit to search for existent vulnerabilities.

Another example – exposure of configuration files. A common misconfiguration of Apache web server can lead to disclosure of .htaccess files, which usually contain potentially sensitive system information.

Missing file type association can also be a result of development process, where software creates backup up copies of modified files with different extensions, which are not associated with executable scripts by default. For example, files with .bak, .old, and other extensions are treated as regular text files and the web server displays their source code instead of executing them.

Exploitation of source code disclosure can be used along with other minor issues, such as directory listing, and create a blended threat, when minor issues lead to complete compromise of the web site.

Remediation
This issue can be solved by either associating the .inc extension with PHP files (not associated by default) or by restricting access to these files. Backup copies of PHP files (for example .bak or .old files) must be not accessible from the web - you should either chmod them to 0400 or place them our of the web root directory.

Configuration Examples:

1. Apache HTTP Server
   To associate files with PHP interpreter you have to add “AddType” directive for the file extension in question. For example, the following directive will associate all “.inc” files with PHP interpreter:
   AddType application/x-httpd-php .inc or
   AddType application/x-httpd-fastphp .inc for mod_fastcgi module.

   Be sure that the following configuration is present in httpd.conf file, which prevents from viewing contents of the “.ht*” files:
   <Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>

2. Microsoft IIS
   In Microsoft IIS this can be achieved using file mappings. The following command will associate all .inc files with PHP interpreter, located at c:\PHP\php-cgi.exe:
   appcmd set config /section:system.webServer/handlers ^
/+[name='PHP_inc_via_FastCGI', path='*.inc',verb='*',modules='FastCgiModule',^
scriptProcessor='c:\PHP\php-cgi.exe',resourceType='Either']

   Or you can use IIS manager for this purpose:
   
   

References
WASC-14: Server Misconfiguration

Insufficient security mechanisms

This section describes possible issues caused by insufficient implementation or misconfiguration of security mechanisms. This issue can lead to possible security breaches, information leakage, denial of service, etc.

5. Weak/Default Password

Brief description
Weak passwords can be treated as a security-related issue or as a vulnerability, described in CWE-521. The issue arises when implemented security mechanisms are changed on purpose to serve certain criteria. This could be an issue of mobile users, who are not able to provide long passwords, typing them on old phones, or other business or personal issues.

Usage of weak or default passwords allows an attacker to perform a dictionary attack and guess the password within few attempts. In this case even correctly implemented anti brute-force mechanisms, such as visitor activity monitor, IP-blocking, CAPTCHA, WAF signatures will hardly protect your application from very simple and successful attack.

Remediation
Always use strong passwords for protection of sensitive accounts. Strong passwords should be at least 8-10 characters long and contain lower and upper case letters, numbers and special symbols.

As additional layer of protection we recommend using the following approach:

1. Monitor user logon attempts and block user account after 10 failed logins in a row for a certain period of time (this could be from 30 minutes to 24 hours);
2. Use CAPTCHA to slow password guessing process. CATPCHA can be displayed after certain (3 or 4) unsuccessful login attempts;
3. Protect your administrative accounts with additional level of protection, such as allow access from a range of IP addresses;
4. Never use the same password for different web sites and demand password change every 30 to 45 days.

6. Sensitive Cookie In HTTPS Session Without “Secure” Attribute

Brief description
If secure attribute is not set for sensitive cookies they can be transferred via unencrypted HTTP connection. An attacker can perform a MitM (man-in-the-middle) attack and intercept valuable information, which can be used later in future attacks. This issue can be used along with cross-site scripting vulnerability to steal the session identifier. It is also possible to perform session fixation attack and gain unauthorized access to the web site.

Below is an example of Secure (X-OWA-CANARY and X-BackEndCookie) and insecure (UC) cookies:

As use can see, sensitive cookies will not be transmitted over HTTP connection, but the “UC” cookie is allowed to do so.

Remediation
Always use "Secure" attribute with sensitive cookies.

For more information on cookie attributes please refer to the following manuals:
For PHP developers:
http://php.net/manual/en/function.setcookie.php
For ASP.Net developers:
http://msdn.microsoft.com/en-us/library/system.web.httpcookie.secure(v=vs.110).aspx
For ColdFusion developers:
http://www.petefreitag.com/item/764.cfm

7. Non HttpOnly Cookie

Brief description
HttpOnly is an additional flag, which is included in Set-Cookie HTTP response header. This attributed is designed to protect users against Cross-site scripting attacks. With the HttpOnly attribute an attacker will not be able to gain access to the cookie via XSS attacks. However, one should not forget that XSS has many various vectors of exploitation that are not limited by cookies theft and setting HttpOnly cookie will not protect you from the XSS attacks.

Remediation
Use HttpOnly cookie as additional layer of protection.

Here is an example of the Secure and HttpOnly cookie:

For more information on cookie attributes please refer to the following manuals:
For PHP developers:
http://php.net/manual/en/function.setcookie.php
For ASP.Net developers:
http://msdn.microsoft.com/en-us/library/system.web.httpcookie.httponly(v=vs.110).aspx
For ColdFusion developers:
http://www.petefreitag.com/item/764.cfm

8. Predictable/Unprotected Location of Administrative Area

Brief description
Default or predictable location of administrative area can help attackers to perform a variety of illegal activities against web application, such as brute-force or phishing attacks. Existing CSRF vulnerability or authentication weakness can lead to web application compromise if an attacker can predict location of application’s administrative area.

If you use a third-party CMS such as WordPress or Joomla, the default path to administrative area is more likely to be known to potential attackers, e.g. /wp-admin and /administrator respectively.

An example of a real-world combination is vulnerability HTB23212, which allows execution of arbitrary PHP code using a CSRF vector, if administrative functionality is allowed via main domain name of the web site.

Remediation
It is recommended to follow these steps to protect your administrative area:

1. Do not use /admin or /administrator folders for accessing administrative area. Use a separate subdomain if possible for such purpose,
2. Protect access to administrative area with authentication via SSL certificate, an extra password or grant access based on a list of IP addresses,
3. Implement encryption of any information to administrative area. For example, use HTTPS when connecting with administrative privileges.

References
WASC-34: Predictable Resource Location

Other Security-related Issues

9. Outdated Software Version

Brief description
This warning means that newer versions of software are available. It’s recommended to keep your software up-to-date. New versions may contain performance and usability improvements. Besides, not all vendors inform their customers on existing vulnerabilities and patch them silently. Furthermore, the version number is not always changed during the software update, which sometimes confuses its users.

Remediation
Always install the latest available official version.

10. Untrusted Third-Party Content

Brief description
Many web sites use advertisement networks to display third-party content. There are publicly known security issues, connected with compromise of advertisement networks that involve malware spreading. Malwaretising is a growing business and malicious people might use advertising networks to spread malware perform attacks against website visitors.

ImmuniWeb uses advanced techniques to discover such issues.

Remediation
Use only trusted advertisers or store scripts locally. Try to avoid placing external scripts. If possible, store the scripts locally.

11. Predictable CAPTCHA

Brief description
There is a variety of different implementations of CAPTCHA and many of them are poorly coded, which gives an attacker some space for its bypass. For example, if CAPTCHA security word is used in URL or hidden form field an attacker does not need to scan the CAPTCHA image. Predictable or guessable CAPTCHA can be exploited to perform automated attacks against your web site, bypass implemented spam protection mechanisms and implemented anti brute-force measures.

Remediation
It is recommended to use existing reliable solutions, such as “recaptcha”, limit request to scripts protected with CAPTCHA to slow its guessing.

12. Unprotected Email Addresses

Brief description
Email addresses that are present on website pages in plain text can be gathered using search engines or automated software and later used in phishing attacks or spam campaigns. They also can be used to identify individuals working for your company or involved in activities related to your website or businesses. Attackers can launch targeted attacks against your personnel to steal corporate secrets or pressure an individual to perform malicious actions using social engineering.

Remediation
It is recommended to avoid publishing personal Email addresses on your website and use feedback forms instead, so that personal or corporate Email addresses are not exposed to the public. If this is not an issue and certain address should be published, it is recommended to protect them from search engines and other automated software.

There are two easy ways to obfuscate Email addresses:

1. JavaScript
   You can output your email addresses using JavaScript code. For example:
   <script>document.write("<a href="+"m"+"ail"+"to:"+"MyMailbxName"+"@"+"mydomain"+".com>Contact</a>")</script>
2. Graphical image
   You can also use an image that displays your Email address with empty “alt” and “title” attributes, however this picture can be indexed by search engines and displayed in different image galleries.




Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to High-Tech Bridge is given.

↑ Back to Top