Remove passwords from (PHP) stream wrapper error messages?

Question

On production servers, error output is surely be off as a matter of routine. Still, I'm feeling jumpy when I see error messages like this even on my dev screen:

stat(): stat failed for ftp://user:pass@127.0.0.1:21/dir-de-nada

This is in the context of a class I wrote around the ftp:// stream. Of course PHP can't filter out passwords from any arbitrary location. But in this case (as with URL wrappers and wherever else), the presence of a password is standard and obvious.

I'm already catching the errors. However I found myself wondering if I need to X these out myself, just to be on the safe side in all contexts, or if there's a way I can have PHP to do it automatically and globally. (That's the question here.) I'm guessing not, but no harm in tossing in a probe here.

As to what me worry, it's only on my dev screen. However error reports will also be relevant to site managers etc., who may not need to know the FTP password. Having the FTP password blurted into the error log is less of a concern, but for reports saved into a database etc. -- I really don't want this sort of information propagating anywhere, ever, for obvious reasons. Prevention pointers please?

And if anyone feels like contributing related notes on keeping PHP from blurting out passwords etc. sensitive info in whatever context, that's also welcome. Aside "don't output anything anywhere".

---

Edit: Better options pending, the message-part of my error and exception handlers now runs this:

$msg = preg_replace('#((ftp|http)://)([^@]+?)@#', '$1*:*@', $msg);

If working with SSH2 streams, add in regex for ssh2\\.(shell|exec|sftp|scp) in case concerned. And for good measure, if you use stack traces that show arguments, sanitize those too.

---

Edit2: On a general note on experiences with PHP's FTP stream context wrapper.

1. Performs lousy in particular if there are any failing requests, giving repeated script timeouts.
2. Stream callback (defined in create_stream_context / $param['notification'] ) logs mostly blanks/partials instead of complete responses from the FTP server.
3. Filesystem functions using stream contexts may or may not return proper/consistent errors, or log anything to the callback. (If someone wants a breakdown of malfunctions, ask away.)
4. It seems there's no option for a persistent connection: PHP re-logs-in in for every filesys call in the same script even if I recycle the stream_context_create resource.

Suppose FTP stream contexts are fine for one-off basic transactions, but a serious no for trying to do anything more in one go, feels a bit like an immature alt. rig for the filesys functions. Next...

Answer 1

No.

I think there's an argument for making the username and password configurable in the stream context , but this is not an option .

You can prevent this from arising by using an API that does not use URIs ( FTP or Curl) but that does mean more verbose code.

Disabling error reporting on production systems is definitely a requirement. But enabling your own error handler (in dev/test as well as production - with environment specific functionality) gives an added layer of protection.

Attempting to tamper with the output stream to control the content of error messages is a non-starter. But its certainly a good idea within your error handler. Why are you hard-coding schemes in your regex?

#(([a-zA-Z]+)://)([^@]+?)@#