NYCPHP Meetup

NYPHP.org

[nycphp-talk] Is it safe to log unsanitized, unvalidated user-inputted data into a logfile?

Brian Williams brianw1975 at gmail.com
Mon Apr 6 00:47:58 EDT 2009


On Sun, Apr 5, 2009 at 11:17 PM, Michael B Allen <ioplex at gmail.com> wrote:

> On Sun, Apr 5, 2009 at 9:06 PM, Brian Williams <brianw1975 at gmail.com>
> wrote:
> > phpinfo() pish...
> >
> >
> > $user_input = "`rm -Rf /`"
> >
> > nuff said.
> >
> > in case it wasn't - backticks are basically the short cut to get PHP to
> > execute something on the command line.
>
> I don't understand how this has any impact on the OP's code. The
> backticks would simply be written to the log file. If you are careless
> enough to try to execute a log file as a shell script then you might
> as well erase your disk.
>

and if the text isn't passed with double quotes?



>
> > always check incoming user data.
>
> Actually I do not validate incoming data. At least not when it is
> first received. I assume everything is tainted until it gets to the
> point of where it really matters and then I validate it there. If I'm
> writing some field to a database, I always escape the data just before
> it's inserted so if someone supplies total garbage it doesn't matter.
> As long as it's escaped it's completely benign (to the database).
>

Don't be absurd.

You are long-windedly saying that you validate user-input just like everyone
else -- before you put it in the database and before you present it back to
the user.  All of that *typically* happens in short order.

You can't test the database for a username existance if you haven't
completely escaped it beforehand.



>
> In fact I would go so far as to say that validating data at the
> point-of-entry is a coding error. For example, Joomla! validates
> usernames before it passes them to authentication plugins. This is an
> error because Joomla! does not know what a valid username is in the
> context of the external authority. At one point Joomla! would not work
> with OpenID or Windows Active Directory because it explicitly excluded
> certain characters that were valid for those external authorities. The
> proper solution is to allow the authentication plugin to define
> username validation and provide a default implementation that can
> easily be overridden.


This is overly complicating the matter because the OP never mentioned
Joomla! or any other specific instances of using said data outside of
inserting into the log file.

if his code had read:

error_log(__FUNCTION__ . "($username): called.", 3, $log_file);

I wouldn't have made any comment at all.

If the backticked code were not in double quotes it would be executed and
the resulting output of the backticked code would be recorded to the log.




> Note that even though validating data when it is first received is not
> critical to security, escaping output /is/ critical to security. So
> it's ok to receive garbage. Just don't send garbage.


are you joking?  how do you test for "garbage" without having tested the
input?  how do you tell your php script what garbage is?  You can't, at best
you can only program the script to test for what *isn't* garbage - i.e. a
regex. and then proceed to allow the function to work safely.



> This leads me
> back to the OP's question of "do I need to validate user input that is
> written to a log file?". The answer is no but you do need to escape
> (or rather remove, truncate or flatten) anything that you don't want
> to end up being read by a program that reads log files like passwords
> and excessively long messages that might fill up the disk or prevent
> someone from viewing the log.


i admit, yes, you have to escape stuff before it gets recorded (which is
obvious)... but you also have to make sure that by contatenating text to
anything that the text does not actually *do* something if the text is
referenced without double quotes.

throw <?php echo "this is a test of `ls -al ./`" . `ls -al ./`;?> into a
file and see what happens.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20090406/d59e1d66/attachment.html>


More information about the talk mailing list