Web Platform Security Best Practices

We've covered numerous web platform attacks and countermeasures in this chapter, but we're the first to admit that it's impossible to exhaustively catalog all the techniques by which a web platform can fall victim. This section is devoted to summarizing the most important recommendations for hardening web platforms generally , as well as specific information on IIS, Apache, and PHP, which are among the most popular web platforms as of this writing. You can be sure you've covered all your bases when deploying these technologies in your online environment.

Tip 

Also see Appendix A for our summarized web security checklist.

Common Best Practices

The following recommendations apply to any web platform, no matter if it's off-the-shelf or custom-made.

Implement Aggressive Network Access Controlin Both Directions!

We hope by this point in the history of the Internet that we don't need to emphasize the need for strong firewalling of inbound communications to web servers. TCP port 80 (and optionally 443 if you implement SSL/TLS) are the only ports that should be made available to general audiences in the inbound direction (obviously, specific user communities may require special access to other ports for content management, server administration, and so on).

Although inbound filtering is broadly appreciated, one mistake that we see made commonly is to ignore outbound access control. One of the first things an attacker will seek to do once they've gained the ability to run arbitrary commands on a web server is to "shovel" an outbound shell, or make an outbound connection to upload more files to the victim. With appropriate egress filtering on the firewall in front of the web server(s), these requests can be blocked, radically raising the bar for attackers . The simplest rule is to deny all outbound connections except those that are established, which can be implemented by blocking all packets bearing only a TCP SYN flag. This will not block replies to legitimate incoming requests, allowing the server to remain accessible to outsiders (your ingress filters are tight, too, right?).

It's important to note that sophisticated attackers may be able to hijack legitimate outbound connectivity to bypass outbound filtering. However, in our experience, this is difficult to achieve in practice, and establishing rigorous outbound access control remains one of the most important defensive layers you can implement for your web servers.

Keep Up with Security Patches

The most effective way to maintain a strong and secure web platform is to keep the system up-to-date with security patches. There's no shortcut or way around the fact that you must continuously patch your platforms and applications. While there are plenty of other steps you can take to better harden your systems from attacks, pushing security updates out to your systemsas they're announcedis the most important thing you can do. We recommend the use of automated patching tools such as the Microsoft Update Service to help you keep your patch levels current. For Apache, we recommend simply subscribing to the Apache announcements list to be notified anytime a new version is released so that you can upgrade (see the "References and Further Reading" section at the end of this chapter for links).

Don't Put Private Data in Source Code

If you educate your development team not to commit this classic error, you won't have to worry so much about the latest and greatest source disclosure making the rounds within hacker circles. Some of the most common failures include these:

  • Cleartext SQL connect strings in ASP scripts   Use SQL integrated security or a binary COM object instead.

  • Using cleartext passwords in application configuration files   Always avoid cleartext passwords in application configuration files such as global.asa or web.config.

  • Using include files with the .inc extension   Rename them to .asp and change the internal references in your other scripts (or map .inc to the ASP extension as we described earlier in this chapter).

  • Comments within scripts that contain private information like e-mail addresses, directory structure information, and passwords   Don't document yourself into being highly vulnerable. Make sure to rid your web platforms and applications of information that can be so easily turned against you.

Regularly Scan Your Network for Vulnerable Servers

The best mechanism for preventing such compromises is to regularly scan for the vulnerabilities that make them possible. There are a number of very useful web application assessment products such as WebInspect from SPI Dynamics and AppScan from Watchfire. These do an excellent job at identifying web-platform and application-level vulnerabilities.

Tip 

See Chapter 13 for a review of tools that automate web security assessment.

Know What It Looks Like When You Are/Have Been Under Attack

You always want to approach incident response as seriously as you approach preventionthis is especially true with fragile web servers. To identify if your servers have been the victim of a directory traversal attack, we recommend following prescribed investigation activities, including the following classic techniques.

Using the Netstat utility on a victimized web server is a good way for you to identify any strange connections inbound to a web server's high ports. As we have seen, these are likely connections to rogue shells instantiated following an exploit of a vulnerability. Outbound connections are much harder to differentiate from legitimate connections with web clients .

Tip 

On versions of Windows following XP, the netstat command was modified to show programs that use TCP/IP portscheck out the o switch.

Another good point of investigation is the file system. Hosts of canned exploits are circulating on the Internet. There are a number of files related to these exploits that are commonly reused by script kiddies exactly as originally published by serious security researchers. For example, on IIS, files such as Sensepost.exe, Upload.asp, Upload.inc, and Cmdasp.asp are commonly used to backdoor a system. Although trivially renamed, you'll at least keep the script kiddies at bay by doing this. Especially keep an eye out for these files in writable/executable directories like the IIS /scripts folder. Other commonly employed IIS exploits often deposit files with names like root.exe (a renamed command shell), e.asp, dl.exe, reggina.exe, regit.exe, restsec.exe, makeini.exe, newgina.dll, firedaemon.exe, mmtask.exe, sud.exe, and sud.bak. Be on the lookout for them.

Finally, and perhaps most obviously, the web server logs are often the first place unauthorized activity will show up (modulo the log evasion techniques we discussed earlier in this chapter). Next , we present a simple example illustrating visitations from the Code Red and Nimda worms that spread across the Internet in late 2001 and into 2002 by infecting servers that were vulnerable to the buffer overflow and planting code that then went on to infect other servers. Web server logs on Code Redinfected servers contained entries similar to the following:

 GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090 %u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff %u0078%u0000%u00=a 

Code Red and Nimda also left behind numerous files on a compromised system. The presence of the directory % systemdrive %\notworm is a tell-tale sign that a server has been compromised by Code Red. The existence of a renamed Windows command shell called root.exe is a similar signpost that Nimda has paid a visit.

We're aware of the monumental effort involved in regularly monitoring the logs and file systems of even a moderately sized web server farm, but hopefully these tips can assist you once you have identified a server that may have been compromised already.

IIS Hardening

Here are our favorite techniques for securing IIS against common attacks:

  • Turning off of detailed error messages that give potential assailants too much information

  • Proper placement of web folders

  • Elimination of unused extension mappings

  • Savvy use of file system access control lists

We'll talk in more detail about these and other techniques in the next section.

Turn Off IIS' Detailed Error Messages

Detailed error messages should never be left on in your production servers. They simply give attackers too much information that can be used against you. Here's how to disable them from within IIS Manager:

  1. Right-click properties on the target web site.

  2. Navigate to the Home Directory tab.

  3. Click the Configuration button.

  4. Navigate to the Debugging tab.

  5. Under the Script Error Messages box, select the radio option "Send text error message to client".

Install Your Web Folders on a Drive Other Than the System Drive

In the past, directory traversal exploits were quite common on the IIS platform (see the "References and Further Reading" section for links to past advisories). To date, these types of attacks have been restricted by URL syntax that doesn't allow the ability to jump across volumes . Thus, by moving the IIS web root to a volume without powerful tools like cmd.exe, such exploits aren't feasible . On IIS, Internet Services Manager (iis.msc) controls the physical location of the web root. Select Properties for the Default Web Site, choose the Home Directory Tab, and change the Local Path setting to a non-%systemroot% drive.

When you relocate your web roots to a new drive, make sure that the integrity of any NTFS ACLs is maintained . If you fail to do this, the ACLS will be set to the default in the destination: Everyone:Full Control! The Robocopy tool from the Windows Server Resource Kit is a handy tool for moving Windows files and folders with ACLs intact. The Robocopy /SEC switch is the relevant parameter to consider.

Remove Unused Extension Mappings

Throughout the years there have been many security issues surrounding IIS extensions known as ISAPI DLLs. Some of these include the .printer buffer overflow and the +.htr source disclosure bug. All of the bugs lay within ISAPI DLLs that should be disabled by removing the specific DLL application mappings. You also have the option of deleting the actual .dll files. When you remove the application mapping, the DLLs won't be loaded into the IIS process during startup. As a result, the vulnerabilities can't be exploited.

Tip 

Because of the many security issues associated with ISAPI DLL mappings, this is one of the most important countermeasures to implement when securing IIS.

To unmap DLLs from file extensions, right-click the computer you want to administer, select Properties, and then the following items are shown:

  • Master Properties

  • WWW Service

  • Edit

  • Properties of the Default Web Site

  • Home Directory

  • Application Settings

  • Configuration

  • App Mappings

At this final screen, remove the mapping for the desired ISAPI extensions (the .printer mapping to msw3prt.dll is selected in Figure 3-5, as it appears on IIS5).


Figure 3-5: Removing the IIS extension mapping for the Internet printing protocol on IIS5

There are several other ISAPI DLLs that have also had serious vulnerabilities associated with them. Table 3-2 presents other vulnerabilities and the associated DLLs that should be unmapped.

Table 3-2: ISAPI Extension Mappings That Should Be Unmapped in a Secure IIS Configuration

If You Don't Need

Unmap This Extension

Past Associated Vulnerabilities

Active Server Pages functionality

.asp

Buffer overflows, MS02-018

Web-based password reset

.htr

+.htr source disclosure, MS01-004

Internet Database Connector

.idc

Reveals web directory paths, Q193689

Server Side Includes

.stm, .shtm, .shtml

Remote system buffer overflow, MS01-044

Internet printing

.printer

Remote system buffer overflow, MS01-023

Index Server

.ida, .idq

Remote system buffer overflow, MS01-033

Hit highlighting

.htw

"Webhits" source disclosure, MS00-006

FrontPage Server Extensions RAD support

Uninstall FPSE RAD Support

Remote IUSR or System buffer overflow, MS01-035

With the release of IIS6 in Windows Server 2003, Microsoft disabled all extensions by default. If you're a Microsoft shop, this and many other security improvements made in IIS6 make it our minimum recommendation as the web platform of choice. A good practice is to follow Microsoft's lead with IIS6 and work with your development team to identify what extensions are needed and disable all other extensions.

Use IISLockdown and URLScan

In late 2001, Microsoft released the IISLockdown Wizard (see the "References and Further Reading" section at the end of this chapter). As its name implies, IISLockdown is an automated, template-driven utility used to apply security configurations to IIS. It configures various settings related to the following items:

  • Internet Services   Allows the four IIS services (WWW, FTP, SMTP, and NNTP) to be disabled as appropriate for the role of the server.

  • Script Maps   Allows disabling of ISAPI DLL script mappings as appropriate for the server's role.

  • Additional Security   A catch-all section that includes removal of selected default virtual directories such as IISSamples, MSADC, IISHelp, Scripts, and others. Here you can also set NTFS ACLs in order to prevent anonymous users from being able to write to content directories through tools such as cmd.exe. You can also disable WebDAV from here.

  • URLScan   A template-driven filter that intercepts requests to IIS and rejects those that meet certain criteriathink of it as a firewall for IIS.

While we've run through a very comprehensive list of IIS-specific security configuration topics, there are some that we still need to address. While IISLockdown helps to automate many of the tasks needed to help secure the platform, it's by no means comprehensive. IISLockdown doesn't provide a way to install service packs and hotfixes, and its features don't reach into any other aspects of the Windows operating system to secure vulnerabilities. Neither does it provide an appropriately configured firewall in front of the server. That's why, while IISLockdown is a helpful tool to help simplify many aspects of IIS security, you don't want to allow yourself to be lulled into a false sense of security through its use.

Because you can manually achieve most of the security features of IISLockdown, we consider one of its most compelling features to be URLScan. In fact, URLScan can be extracted separately from the IISLockdown Installer and manually deployed.

Tip 

IIS 6 ships with URLScan enabled. See Appendix D for a complete discussion of URLScan deployment and usage.

Always Use NTFS for Web Server Volumes and Conservatively Set Your ACLs!

With FAT and FAT32 file systems, file- and directory-level access control is impossible, and as a result, the IUSR account has carte blanche to read and upload files. When configuring access control on web-accessible NTFS directories, use the least-privilege principle. IIS 5 also provides the IIS Permissions Wizard that walks you through a scenario-based process of setting ACLs. The Permissions Wizard is accessible by right-clicking the appropriate virtual directory in the IIS Admin console. We strongly suggest that you use it.

Move, Rename, Delete, or Restrict Any Powerful Utilities

Microsoft Corp. recommends setting the NTFS ACLs on cmd.exe and several other powerful executables to Administrator and SYSTEM:Full Control only. Microsoft has publicly demonstrated that this simple trick stops most remote command execution shenanigans cold, because IUSR no longer has permissions to access cmd.exe. Microsoft also recommends using the built-in CACLS tool to globally set these permissions. Let's walk through an example of how CACLS might be used to set permissions on executable files in the system directory. Because so many executable files are in the system folder, it's easier for us to explore a simple example by moving files to a new directory called test1 with a subdirectory named test2. Using CACLS in display-only mode, we can see the existing permissions of our test files are way too lax:

 C:\  cacls test1 /T  C:\test1 Everyone:(OI)(CI)F C:\test1\test1.exe Everyone:F C:\test1\test1.txt Everyone:F C:\test1\test2 Everyone:(OI)(CI)F C:\test1\test2\test2.exe Everyone:F C:\test1\test2\test2.txt Everyone:F 

Let's assume that you want to change the permissions for all executable files in test1 and all subdirectories to System:Full, Administrators:Full. Here's the command syntax you'd need using CACLS:

 C:\  cacls test1\*.exe /T /G System:F Administrators:F  Are you sure (Y/N)?  y  processed file: C:\test1\test1.exe processed file: C:\test1\test2\test2.exe 

Now we run CACLS again to confirm our results. Note that the .txt files in all subdirectories have the original permissions, but the executable files are now appropriately set:

 C:\  cacls test1 /T  C:\test1 Everyone:(OI)(CI)F C:\test1\test1.exe NT AUTHORITY\SYSTEM:F                         BUILTIN\Administrators:F C:\test1\test1.txt Everyone:F C:\test1\test2 Everyone:(OI)(CI)F C:\test1\test2\test2.exe NT AUTHORITY\SYSTEM:F                               BUILTIN\Administrators:F C:\test1\test2\test2.txt Everyone:F 

When applying this example to a typical web server, it's a good practice to set ACLs on all executables in the %systemroot% directory to System:Full, Administrators:Full, like so:

 C:\cacls %systemroot%\*.exe /T /G System:F Administrators:F 

This blocks non-administrative users from using these executables and helps to prevent exploits such as Unicode, which rely heavily on nonprivileged access to these programs.

Of course, such executables may also be moved, renamed, or deleted. This puts them even further out of the reach of hackers.

Tip 

The IISLockdown tool automates assigning ACLs to system utilities.

Remove the Everyone and Guests Groups from Write and Execute ACLs on the Server

The anonymous IIS access accounts IUSR_ machinename and IWAM_ machinename are members of these groups. And you want to be extra careful that the IUSR and IWAM accounts don't have write access to any files or directories on your systemyou've already witnessed what shenanigans a single writable directory can lead to! Also, carefully scrutinize execute permissions for nonprivileged groups. And be especially sure not to allow any nonprivileged users to have both write and execute permissions to the same directory!

Scrutinize Existing ISAPI Applications for Calls to RevertToSelf and Expunge Them

Older versions of IIS were vulnerable to a privilege escalation attack against the RevertToSelf Win32 programming call. By instantiating an existing DLL that made this call, attackers could subvert it to gain all-powerful LocalSystem privileges. IIS version 5 and older are the main concern here, although version 6 in compatibility mode can also be vulnerable. You can help prevent RevertToSelf calls from being used to escalate privilege by assessing your IIS DLLs for this call. Use the dumpbin tool included with many Win32 developer tools to assist you with this, as shown in the following example using IsapiExt.dll:

 dumpbin /imports IsapiExt.dll  find "RevertToSelf" 

Apache Hardening

Apache comes fairly secured right out of the box, and the Apache group does a good job at fixing most security problems quickly. When you start using Apache in the real world, though, and run real-world web applications on top of it, securing Apache can begin to get quite complex.

In fact, when looking at all the multiple ways Apache can be configured and the ways that it can be misconfigured, the task of securing Apache or even knowing all the proper ways of securing Apache becomes quite daunting. We have compiled a list of what some consider to be the top security basics that should be done on any Apache server in order to harden the server properly. This list by no means is comprehensive or complete and can change depending on what you might be using the server for. Luckily, there are plenty of automated scripts, tools, and documentation that can be used to help you walk through a proper Apache security configuration. References to these can be found at the end of this chapter.

Disable Unneeded Modules

One of the most important things to consider when installing Apache is what types of functionality the web server is required to have. For instance, are PHP scripts or Perl scripts going to be run? Will Server Side Includes be used in the application running on the web server? Once you can create a list of needed functionality, you can enable the appropriate modules. You can retrieve a list of all the enabled modules by using httpd.

 #  httpd l  Compiled-in modules:   http_core.c   mod_env.c   mod_log_config.c   mod_mime.c   mod_negotiation.c   mod_status.c   mod_include.c   mod_autoindex.c   mod_dir.c   mod_cgi.c   mod_asis.c   mod_imap.c   mod_actions.c   mod_userdir.c   mod_alias.c   mod_access.c   mod_auth.c   mod_so.c   mod_setenvif.c   mod_perl.c 

To disable modules, use the configure script before compiling and pass in any modules that should be disabled.

Apache 1.x

./configure --disable-module=userdir

Apache 2.x

./configure --disable-userdir

Note 

This method is used to remove built-in modules in Apache and does not apply to dynamic modules.

The modules shown in Table 3-3 could be a security risk and are suggested to be removed in your Apache configuration.

Table 3-3: Apache Modules That Are Potential Security Risks and Should Be Considered for Removal

mod_userdir

Allows username home folders to be present on the web server via the /~username/ request

mod_info

Allows an attacker to view the Apache configuration

mod_status

Displays runtime information about Apache status

mod_include

Allows the use of Server Side Includes, which are rarely used today and can represent a significant security risk

Implement ModSecurity

ModSecurity is an Apache module written by Ivan Ristic that works as a web application firewall. It has a huge amount of flexibility and is considered one of the best projects available in terms of helping to secure Apache against application and web platform attacks. Some of the features that ModSecurity has are listed here:

  • Request Filtering

  • Anti-Evasion Techniques

  • HTTP Filtering Rules

  • Full Audit Logging

  • HTTPS Intercepting

  • Chroot Functionality

  • Mask Web Server Identity

Tip 

See Appendix D for detailed information on ModSecurity deployment and configuration.

Chrooting Apache

One of the standard rules in security is to practice defense in depth. When an attacker breaks into a web server, one of the first things the attacker will do is attempt to access files on the system such as /etc/passwd, or escalate their privileges via a local exploit. In order to prevent this type of attack, a method of putting the Apache server in a contained environment, or "jail" of sorts, has been created, and it is called chrooting . By implementing this, Apache runs with limited privileges inside of its own contained file system. If an attacker were to gain access to the file system, they would be stuck inside this jail environment with no access to the real file system. There are two methods to chrooting Apache that we'll review here.

External Chrooting   This type of chrooting starts out with a file system that contains nothing but the basic shell, all processes, and required dependencies need to be copied to this environment in order to run. This is a real containment method for Apache in that if you break into a shell somehow the attacker has nowhere to go. The method to set up and configure this kind of jail is quite complex and requires a lot of research, depending on what software is required to run with the web application. To find out more detailed steps on how to set up this environment, see the "References and Further Reading" section at the end of this chapter.

Internal Chrooting   Internal chrooting is different from external chrooting in that during internal chrooting, the chroot is created from inside the Apache process. Apache starts out and initializes normally but then creates a chroot environment for the process to run. By default, Apache does not support this kind of chroot method. However, a couple of people have created third-party add-ons that enable Apache to support this.

  • ModSecurity supports a chroot environment via its SecChrootDir configuration. Just set the value to the directory where you would like Apache to be jailed.

  • ModChroot is an Apache module that works in the same manner as the ModSecurity chroot. Just set the ChrootDir to the proper directory.

  • Apache chroot(2) patch by Arjan De Vet is an actual patch to Apache that enables support for internal chrooting.

Implement SuExec

Implementing an execution wrapper like SuExec allows CGI scripts to be run with the privileges of another user besides the default Apache web user. This can be a very dangerous issue. Let's look at two examples where this can become a problem.

Example 1   An attacker identifies a vulnerable CGI script that exists on the web server that allows command execution. By taking advantage of this script, if SuExec is not used the attack could create a backdoor version of httpd and replace the existing web server with the attacker's backdoor version.

Example 2   A multi-hosted environment exists that allows each virtual-hosted web site to upload and host its own scripts. If SuExec is not used, any hole or even malicious web site administrator could access the contents of any of the other web sites being hosted on that server. This can be a big problem especially if you have tested your web site and have taken all precautions to have secure code and a good secure web configuration, only to find out you were hacked because one of the other virtual sites had a security issue and it gained access via that route.

Now you can see why something like SuExec is important. Installing and configuring SuExec can sometimes be a complex and frustrating process. SuExec is very strict in its configuration and multiple things have to be set up properly. We suggest walking through the process using Apache's documentation, which can be located in the "Reference and Further Reading" section at the end of this chapter.

Document Root Restriction

An important configuration is to make sure that Apache is not allowed to access anything outside the document root. This type of restriction is quite simple and can be done with the following configuration change in httpd.conf:

 <Directory/> order deny,allow deny from all </Directory>     <Directory /www/htdocs> order allow,deny allow from all </Directory> 

Using Apache Benchmark from CIS

Manually going through and trying to secure Apache is a daunting task; luckily, there is the Apache Benchmark from the Center of Internet Security. They produce a document that explains how to harden Apache properly and produce a tool that checks your given configuration and explains whether you pass or fail a certain security requirement. Following is a simple walkthrough of how to use their tool to check an Apache configuration.

First, download the product from their web site and unzip it to a working directory. Run the benchmark.pl script and point it to your httpd.conf file.

 ############## Help and Usage Information ############  Flags:  -c: Specify the apache configuration file.  -s: Specify the web server url. (optional)  -o: Specify and HTML output file name. (optional)          Check Apache configuration file for compliance.  Usage: benchmark.pl -c httpd.conf -s http://foo.com  Usage: benchmark.pl -c httpd.conf -s http://foo.com -o results.html          Show help.  Usage: benchmark.pl -h ######################################################         # benchmark.pl -c /usr/local/apache/conf/httpd.conf -o result.html         ########### CIS Apache Benchmark Scoring Tool 2.08 ############  Version: 2.08  Description: Check Apache configuration file against the CIS Apache Benchmark.  Copyright 2003-2004, CISecurity. All rights reserved. ###############################################################             CIS Apache Benchmark requires answers to the following questions: Press enter to continue. -  Location of the Apache server binary [/usr/local/apache/bin/httpd] -  Has the Operating System been hardened according to any and all applicable OS system security benchmark guidance? [yesno] -  Created three dedicated web groups? [yesno] -  Downloaded the Apache source and MD5 Checksums from httpd.apache.org? [yesno] -  Verified the Apache MD5 Checksums? [yesno] -  Applied the current distribution patches? [yesno] -  Compiled and installed Apache distribution? [yesno] -  Is the root@localhost.localdomain address a valid email alias? [yes no] -  Are fake CGI scripts used? [yesno] -  Have you implemented any basic authentication access controls? [yes no] -  Updated the default apachectl start script's code to send alerts to the appropriate personnel? [yesno] 

It then asks a series of questions, runs a security-checking script against your configuration, and produces a nice report, like the one shown in Figure 3-6, letting you know what issues need to be fixed. You can then reference the included benchmark document for how to solve each issue.


Figure 3-6: The CIS tool scores an Apache configuration with a 2.54 out of 10ugh!

Php Best Practices

Since we discussed a number of vulnerabilities in the popular PHP scripting platform, here are a few tips on making sure you can avoid them.

  • Avoid using user input for any filenames or paths.

  • Use the eval() function sparingly and without user input.

  • Turn register_globals to off.

  • Validate all user input.

Common Security Options for PHP

The following configuration options are security related and can be set in the php.ini file. By using these settings, it will ensure that the PHP configuration you have running will be in a good default secure setting.

open_basedir   This setting will restrict any file access to a specified directory. Any file operations are then limited to what is specified here. A good recommendation is that any file operations being performed should be located within a certain set of directories. This way, the standard old "../../../../etc/passwd" won't go anywhere .

disable_functions   This allows a set of functions to be disabled in PHP. This should be considered a great way to practice defense in depth. If the applications don't make use of security risky functions such as eval(), passthru (), system(), etc., then add these as functions that should never be allowed. If an attacker does find a security issue in PHP code, it will cause some headache .

expose_php   Setting this configuration to off will remove the PHP banner that displays in the server headers on an HTTP response. If your concern is to hide the version of PHP or the fact that it is running on the application, setting this will help.

display_errors   This is a simple but important configuration that enables detailed error information to be displayed to the user on an exception. This should always be turned off in any production environment.

safe_mode   Turning safe_mode on in PHP allows very strict file access permissions. It does this by checking the permissions of the owner of the PHP script that is running and any file access that the script does. If the permissions do not match, then PHP throws a security exception. Safe_mode is mostly used by ISPs, so that in virtual-hosted environments, multiple users can develop their own PHP scripts without risking the integrity of the server.

allow_url_fopen   This configuration will disable the ability to do file operations on remote files. This is a nice overall setting to remove the inclusion vulnerabilities from working. An example of this would be if the $absolute_path variable in the following code sample was set to a value of "http://www.site.com/", the exploit would fail because allow_url_ fopen was set.

 include($absolute_path.'inc/adodb/adodb.inc.php'); 


Hacking Exposed Web Applications
HACKING EXPOSED WEB APPLICATIONS, 3rd Edition
ISBN: 0071740643
EAN: 2147483647
Year: 2006
Pages: 127

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net