php error report

Error reporting is a double-edged sword for PHP security. On the one hand it can improve safety, on the other hand it can be harmful.

A common technique used when attacking a system is to enter incorrect data and then check the type and context of the error message. Doing so helps attackers collect information about the server in order to find weaknesses. For example, if an attacker knows the form information a page is based on, then he will try to modify the variables:

Example #1 Use a custom HTML page to attack variables

<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>

Usually the error message returned by PHP can To help developers debug programs, it will point out which functions or codes in which files have errors, and indicate which lines of the file the errors occurred. This is the information that PHP itself can give. Many PHP developers will use the show_source(), highlight_string() or highlight_file() functions to debug code, but in a live website, this approach may expose hidden variables, unchecked syntax and other potentially dangerous System security information. It is dangerous to run programs that have internal debugging handlers or use generic debugging techniques. If an attacker determines which specific debugging technology is used by the program, they will try to send variables to turn on the debugging function:

Example #2 Use variables to turn on the debugging function

<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>

Regardless of the error handling mechanism, system errors can be detected The ability will provide the attacker with more information.

For example, PHP’s unique error prompt style can indicate that the system is running PHP. If an attacker is looking for a .html page and wants to know the technology behind it (in order to find system weaknesses), they will submit incorrect data and then they will know that the system is based on PHP.

A function error may expose the database being used by the system, or provide an attacker with useful information about a web page, program or design. Attackers will often follow the clues to find open database ports, as well as certain bugs or weaknesses on the page. For example, an attacker can use some abnormal data to cause program errors to detect the order of authentication in the script (through the line numbers in the error prompt) and information that may be leaked elsewhere in the script.

A file system or PHP error can expose what permissions the web server has and how files are organized on the server. This problem can be exacerbated by incorrect code written by developers themselves, resulting in the leakage of otherwise hidden information.

There are three common ways to deal with these problems. The first is to check all functions thoroughly and try to fix most errors. The second is to completely turn off error reporting for online systems. The third is to create your own error handling mechanism using PHP's custom error handling function. Depending on the security policy, all three methods may be suitable.

One way to prevent this problem before it happens is to use error_reporting() to help make your code safer and find dangerous uses of variables. Before publishing the program, open the E_ALL test code first, which can help you quickly find inappropriate use of variables. Once ready for release, you should turn off error reporting completely by setting the error_reporting() parameter to 0 or set display_errors in php.ini to off to turn off all error displays to isolate your code from detection. Of course, if you want to do this later, don’t forget to turn on the log_errors option in the ini file and specify the file used to record error information through error_log.

Example #3 Use E_ALL to find dangerous variables

<?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");
    }
?>