error_reporting levels

[bbxrider]

please see my site page at (server probably down from 1:00-8:00am pacific)

http://coolgulfbreeze.com/index.php/component/adsmanager/?page=write_ad

i thought the 'notice' messages could be suppressed with

error_reporting  =    E_ALL & ~E_NOTICE

but actually it seems nothing suppresses the messages on this page, is there perhaps some other place other than the php.ini my php directory that this can also be set?

i was also trying find the variable/array/technique that contains the php.ini settings so i can check them individually

bob

[redarrow]

The function eval, it self is a very bad programming function and has got load,

of security holes.

 

i suggest you re-program your code.

 

you can use the @ <<< in front off a variable, to suspend a error message.

[iarp]

Try

<?php
ini_set("display_errors", "0");
?>

[Maq]

Have you checked in the manual: error_reporting()?

[bbxrider]

thanks for the replies, the ini-set and error_reporting() look like good tools to use for debugging and more granular reporting error reporting. however, when considering an application that has many scripts, i'm still wondering why setting error_reporting in the php.ini did not or does not set the level of reporting everywhere. i checked the script that produced the page in question and it does not use ini_set or error_reporting() to override the php.ini settings

as far as eval, unfortunately (or maybe fortunately if it is considered bad coding practice) i did not write that code myself but am using an open source joolma extension. at this time i would not want to try the recoding necessary to remove the eval.

[Maq]

when considering an application that has many scripts, i'm still wondering why setting error_reporting in the php.ini did not or does not set the level of reporting everywhere.

 

It does, but when you use the inline error_reporting functions it overrides the ini setting.

[DeanWhitehouse]

It is bad practice to ignore or suppress errors (although some must be suppressed), and bad practice to turn error reporting off while developing, if the site is developed you should develop your own error reporter.

 

 

[bbxrider]

thanks again for the replies,

so experimenting with setting error_reporting in the script, i can finally suppress the notices.

however, this is strange. when error_reporting is set to E_ALL & ~E_NOTICE in php.ini, notices are still displayed, i checked, and its value at the script execution is 6137

when i set error_reporting to E_ALL & ~E_NOTICE in the script itself with the error_reporting function, notices are surpressed and its value is 6137.

so even though it has the same value of 6137 there is different behavior depending on whether it is overridden or not in the script from the value set in php.ini???????????????????????????

[PFMaBiSmAd]

Every line of php code that generates a warning or notice error, even if you modify the error_reporting or display_errors settings to hide them, takes 10-20 time longer to execute than if the line of code does not generate an error. It is always better to fix problems causing errors than to mask the error.

 

In your last post, how are you determining what the error_reporting value is and did you set it before you displayed it (php has a habit of not showing the run time values of php.ini settings that have been modified by a script)? Also, is the php.ini that you are changing the one that php is using and did you stop and start your web server to get any change in php.ini to take effect?

[redarrow]

# config.ini

# PHP error reporting. supported values are given below.

# 0 - Turn off all error reporting

# 1 - Running errors

# 2 - Running errors + notices

# 3 - All errors except notices and warnings

# 4 - All errors except notices

# 5 - All errors

[redarrow]

read this carefully ok

 

Regardless of the method of error handling, the ability to probe a system for errors leads to providing an attacker with more information.

 

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.

 

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.

 

A filesystem or general PHP error can indicate what permissions the webserver 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.

 

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.

 

[redarrow]

now read this

 

One way of catching this issue ahead of time is to make use of PHP's own error_reporting(), to help you secure your code and find variable usage that may be dangerous. By testing your code, prior to deployment, with E_ALL, 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 error_reporting() to 0, or turn off the error display using the php.ini option display_errors, 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 error_log ini directive, and turn log_errors on. '

 

 

last comment but read what can happen

 

 

Finding dangerous variables with E_ALL

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

[Maq]

redarrow, please stop spamming this thread, just modify your existing reply.

 

The OP doesn't want these error visible on the live server, hence the start of this thread.

[redarrow]

yes very sorry just like to show all the in and out's and whys sorry.

 

 

i always trie to catch the page but it seems to catch me out it my eyes so sorry.

[bbxrider]

yikes, thanks for all the great replies, please note, i am a php newbie, so that plus working with open source code is putting me in uncharted waters, but certainly want to hear as much as possible about the security issues.

 

i'm getting the value of error_reporting with ini_get, i restart my server after any changes to php.ini, which brings up the question, is it possible to reset php.ini without restarting the server?

for debugging, could you set a global variable in an application ini file, that you could check for debug/development or production and control error reporting that way?

at this point not sure about redarrow's 'Finding dangerous variables with E_ALL' will have to digest that for a bit and probably repost with questions about that