<?xml version="1.0" encoding="utf-8"?>

<!-- $Revision$ -->

<!-- splitted from ./index.xml, last change in rev 1.66 -->

<chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">

<title>Error Reporting</title>

<para>

With PHP security, there are two sides to error reporting. One is

beneficial to increasing security, the other is detrimental.

</para>

<para>

A standard attack tactic involves profiling a system by feeding

it improper data, and checking for the kinds, and contexts, of the

errors which are returned. This allows the system cracker to probe

for information about the server, to determine possible weaknesses.

For example, if an attacker had gleaned information about a page

based on a prior form submission, they may attempt to override

variables, or modify them:

<example>

<title>Attacking Variables with a custom HTML page</title>

<programlisting role="html">

<![CDATA[

<form method="post" action="attacktarget?username=badfoo&amp;password=badfoo">

<input type="hidden" name="username" value="badfoo" />

<input type="hidden" name="password" value="badfoo" />

</form>

]]>

</programlisting>

</example>

</para>

<para>

The PHP errors which are normally returned can be quite helpful to a

developer who is trying to debug a script, indicating such things

as the function or file that failed, the PHP file it failed in,

and the line number which the failure occurred in. This is all

information that can be exploited. It is not uncommon for a php

developer to use <function>show_source</function>,

<function>highlight_string</function>, or

<function>highlight_file</function> as a debugging measure, but in

a live site, this can expose hidden variables, unchecked syntax,

and other dangerous information. Especially dangerous is running

code from known sources with built-in debugging handlers, or using

common debugging techniques. If the attacker can determine what

general technique you are using, they may try to brute-force a page,

by sending various common debugging strings:

<example>

<title>Exploiting common debugging variables</title>

<programlisting role="html">

<![CDATA[

<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1">

<input type="hidden" name="errors" value="Y" />

<input type="hidden" name="showerrors" value="1" />

<input type="hidden" name="debug" value="1" />

</form>

]]>

</programlisting>

</example>

</para>

<para>

Regardless of the method of error handling, the ability to probe a

system for errors leads to providing an attacker with more

information.

</para>

<para>

For example, the very style of a generic PHP error indicates a system

is running PHP. If the attacker was looking at an .html page, and

wanted to probe for the back-end (to look for known weaknesses in

the system), by feeding it the wrong data they may be able to

determine that a system was built with PHP.

</para>

<para>

A function error can indicate whether a system may be running a

specific database engine, or give clues as to how a web page or

programmed or designed. This allows for deeper investigation into

open database ports, or to look for specific bugs or weaknesses

in a web page. By feeding different pieces of bad data, for example,

an attacker can determine the order of authentication in a script,

(from the line number errors) as well as probe for exploits that

may be exploited in different locations in the script.

</para>

<para>

A filesystem or general PHP error can indicate what permissions

the web server has, as well as the structure and organization of

files on the web server. Developer written error code can aggravate

this problem, leading to easy exploitation of formerly "hidden"

information.

</para>

<para>

There are three major solutions to this issue. The first is to

scrutinize all functions, and attempt to compensate for the bulk

of the errors. The second is to disable error reporting entirely

on the running code. The third is to use PHP's custom error

handling functions to create your own error handler. Depending

on your security policy, you may find all three to be applicable

to your situation.

</para>

<para>

One way of catching this issue ahead of time is to make use of

PHP's own <function>error_reporting</function>, to help you

secure your code and find variable usage that may be dangerous.

By testing your code, prior to deployment, with <constant>E_ALL</constant>,

you can quickly find areas where your variables may be open to poisoning

or modification in other ways. Once you are ready for deployment,

you should either disable error reporting completely by setting

<function>error_reporting</function> to 0, or turn off the error

display using the &php.ini; option <literal>display_errors</literal>,

to insulate your code from probing. If you choose to do the latter,

you should also define the path to your log file using the

<literal>error_log</literal> ini directive, and turn

<literal>log_errors</literal> on.

<example>

<title>Finding dangerous variables with E_ALL</title>

<programlisting role="php">

<![CDATA[

<?php

if ($username) { // Not initialized or checked before usage

$good_login = 1;

}

if ($good_login == 1) { // If above test fails, not initialized or checked before usage

readfile ("/highly/sensitive/data/index.html");

}

?>

]]>

</programlisting>

</example>

</para>

</chapter>

<!-- Keep this comment at the end of the file

Local variables:

mode: sgml

sgml-omittag:t

sgml-shorttag:t

sgml-minimize-attributes:nil

sgml-always-quote-attributes:t

sgml-indent-step:1

sgml-indent-data:t

indent-tabs-mode:nil

sgml-parent-document:nil

sgml-default-dtd-file:"~/.phpdoc/manual.ced"

sgml-exposed-tags:nil

sgml-local-catalogs:nil

sgml-local-ecat-files:nil

End:

vim600: syn=xml fen fdm=syntax fdl=2 si

vim: et tw=78 syn=sgml

vi: ts=1 sw=1

-->