0

I have a question, in the PDO manuial somewhere I read that errors reveal the db connect with username and password (due to a flaw in the zend engine). I see several examples of catching the pdo like this:

    catch(PDOException $exception){ 
    return $exception; 
}

if the exception is returned, doesn't the user see the error? Is it better to have disabled the error reporting in the php.ini file, or even do something like

  setAttribute(PDO::ERRMODE_SILENT)

instead of the catch statement, or is it better to do a combination of above and redo the catch statement so it doesn't return the error to the user.

This is referring to the pink paragraph on the manual page that says: Warning: If your application does not catch the exception thrown from the PDO constructor, the default action taken by the zend engine is to terminate the script and display a back trace. This back trace will likely reveal the full database connection details, including the username and password. It is your responsibility to catch this exception, either explicitly (via a catch statement) or implicitly via set_exception_handler(). php.net/manual/en/pdo.connections.php.

The user "YOUR COMMON SENSE" marked this as duplicate which is not correct. I don't have an issue with using PDO, Its just a question of dealing with error responses, and correct methodology of error handling.

drtechno
  • 298
  • 2
  • 9
  • There are NO bugs in the zeng engine, there are only noob php users unable to configure their web-server. The problem of leaking error messages is not specific to PDO. Like many others, you are confusing error handling with error *displaying*. And trying to fix the latter by means of the former, making things worse. So just go straight for the latter, tell your PHP not to display its errors, that's all. Neither ERRMODE_SILENT nor a blunt catch should be ever used. Just log your errors on a live server and nothing will be leaked ever. – Your Common Sense Mar 02 '18 at 18:44
  • I was referring to the pink paragraph on the manual page that says: Warning: If your application does not catch the exception thrown from the PDO constructor, the default action taken by the zend engine is to terminate the script and display a back trace. This back trace will likely reveal the full database connection details, including the username and password. It is your responsibility to catch this exception, either explicitly (via a catch statement) or implicitly via set_exception_handler(). http://php.net/manual/en/pdo.connections.php. just asking when it was recommended to catch errors – drtechno Mar 02 '18 at 21:43
  • so why "Neither ERRMODE_SILENT nor a blunt catch should be ever used." when the pink paragraph in the manual exist? – drtechno Mar 02 '18 at 22:01
  • Because someone who wrote it has no clue. Do you understand what displaying PHP errors is? – Your Common Sense Mar 02 '18 at 22:40
  • Yes. because I only set them on in php when I'm writing, but turn it off when its online. But I'm just curious why the paragraph in the manual, since in normal operation it shouldn't throw an error. Now if the database server is having issues (like under attack) the script might throw the exception error if the script isn't serviced correctly by the DB. Still makes me wonder why the warning paragraph if its so benign? – drtechno Mar 02 '18 at 22:49
  • Documentation is written by humans and it's in the human nature to do mistakes. Someone who wrote it confused completely different matters ending up writing a fiction. There is no such thing as "the displaying of a back trace". What zend engine really does is just converting an uncaught exception into a fatal error that contains a stack trace. And then this fatal error is treated like any other error - so it will be displayed only if appropriate php.ini directive is set. if you set display errors to off, you won't see any stack traces. – Your Common Sense Mar 02 '18 at 23:03
  • I've only seen the username and password revealed on db connect errors. I should simulate this somewhere to see if it throws the exception with the error report set to off (but still log the errors) – drtechno Mar 02 '18 at 23:10
  • throwing exceptions has nothing to do with displayint errors. thats completely different matters. an exception is always thrown, no matter what your display_errors is. display errors is only responsible for showing errors. – Your Common Sense Mar 02 '18 at 23:28
  • very true. I tried simulating it, with the wrong db password and malform the connect, and it returned a 500 error in firefox (like it should). Its still strange why the warning though.. but oh well – drtechno Mar 02 '18 at 23:43

0 Answers0