Error Reporting
With PHP security, there are two sides
to error reporting. One is beneficial to increasing security,
the other is detrimental.
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 15-11. Attacking Variables with a custom HTML
page
<form method="post" action="attacktarget?username=badfoo&password=badfoo">
<input type="hidden" name="username"
value="badfoo" />
<input type="hidden" name="password"
value="badfoo" />
</form>
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 occured in. This is all information that can be
exploited. It is not uncommon for a php developer to use
show_source(), highlight_string(), or highlight_file() 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:
|
