how to suppress sql errors

when using the db api functions to run a query I see no way to get them to simply return on sql errors so that I can handle them myself. At the moment I get an ugly « MODx Parse Error » page and a dump of the sql query to screen, which is great for development but obviously a big security issue on a live site.

I am using PHP 5.2.3 so Exception handling is available to me but seems to have no effect.
modx version is 9.6.1

thanks

I think this is due to the use of the messageQuit function in dbapi.mysql.class.inc.php from document.parser.class.inc.php.

Don’t however know how to suppress this without changing the code of this function, doesn’t seem to have a use/don’t use boolean you can set anywhere.

thanks, that’s pretty much what I thought. I’ll add this as a feature request

After a database corruption led to a user telling our client that he could delete the entire site thanks to seeing the mySQL error I have hacked the core. Following shamblett’s advice.

document.parser.class.inc.php

line 531 -> $this->messageQuit("Execution of a query to the database failed", ’’);
line 537 -> $this->messageQuit("Execution of a query to the database failed", ’’);

dbaip.mysql.class.inc.php
line 138 -> $modx->messageQuit("Execution of a query to the database failed", ’’);

Quote from: stevs at Feb 05, 2009, 11:59 AM

After a database corruption led to a user telling our client that he could delete the entire site thanks to seeing the mySQL error I have hacked the core. Following shamblett’s advice.

Fear-mongers I tell ya!

But in all seriousness, the information shown by the SQL error will not provide a web site visitor with any way to use that information to delete the site. If it does, the environment is not properly configured and secured.

Yes, it provides some information agreed, which is probably not desirable from a security standpoint but to take the information it provides and get to this conclusion

a user telling our client that he could delete the entire site thanks to seeing the mySQL error

is a massive leap. You’d need far more than this to do that kind of damage. Who is this user?

I completely agree. With properly validated and escaped input there should be no possibility of injection attacks. I will however modify ajaxSearch and custom forms querying the modx db to switch to a read only user just in case

Are there news on that issue? In 0.9.6.3 the parse error page is still exposing information to the public that is not meant to be public. And in every cyber-security seminar you’ll learn that such information really should not be displayed in anybody else’s browser. In this case, somebody else could get to know that a) the site runs under modx, and b) the web root directory. These both pieces are at least essential to base attacks on.

That is anyway one of the few things which really annoy me in modx. The reason why I wouldn’t deploy modx in environments of my direct or indirect responsibility is mainly this one issue.

Revolution addresses this issue but it does still remain in Evolution/096x, as you’re aware. Revo should hit public beta very soon.

Quote from: agilero at May 24, 2009, 09:28 AM

Are there news on that issue? In 0.9.6.3 the parse error page is still exposing information to the public that is not meant to be public. And in every cyber-security seminar you’ll learn that such information really should not be displayed in anybody else’s browser. In this case, somebody else could get to know that a) the site runs under modx, and b) the web root directory. These both pieces are at least essential to base attacks on.

That is anyway one of the few things which really annoy me in modx. The reason why I wouldn’t deploy modx in environments of my direct or indirect responsibility is mainly this one issue.

While I agree it would be better to make this configurable (which is why it is in Revo), it’s funny how much FUD these seminars generally present; yes you can base attacks on some of this data, but if you have a properly secured environment it makes no difference whether an error page reveals that MODx is running the site or that the path to the web document root is xyz. If you are getting MODx parse errors (which are generally FATAL PHP errors), you likely need to be addressing those problems and not worrying so much about FUD.