NYCPHP Meetup

[Dan Cech]

Chris Shiflett wrote:

> --- Emmanuel Décarie <emm at scriptdigital.com> wrote:
> 
>>(1) "Best Practice: Do not use the function addslashes but, instead,
>>use a function that is specific to your database."
>>
>>Could the tutorial elaborate a little bit more on this?
> 
> First of all, this looks to be another great phundamentals article. I
> really like this series (or whatever you want to call it).
> 
> I agree with Emmanuel that some elaboration would be useful here. Whenever
> a best practice is seldom followed, a very clear justification can be a
> great thing. Being right and convincing someone else that you're right are
> often very different things. :-)

See my reply, I am sure jeff is working on a little clarification as I 
type this...

>>(2) htmlentities/htmlspecialchars
>>
>>I think the tutorial should insist that the best practice is not using
>>these functions on data that you want to *insert* in a database.
> 
> More elaboration in general might be good. I would consider these
> functions the "least you can do" when you're displaying potentially
> tainted data to the user. If you're not displaying data, htmlentities()
> probably isn't going to offer you the type of protection you seek.
> 
> There are also two different opinions on this:
> 
> 1. Perform htmlentities() prior to storage.
> 2. Perform htmlentities() prior to display.
> 
> The first can be better if you must display data in HTML very often.
> Rather than perform htmlentities() every time, you can just pull straight
> from the database. 

The only advantage to this method is the speed increase, you still need 
to use addslashes, it takes up more space in the database, and it is 
only useful if you will only ever be outputting HTML.

> The second is usually best if you have other uses for the data besides
> displaying it in HTML. It is also best if your security model revolves
> around cleaning up data the moment it enters into your application. This
> can be a good approach in terms of keeping things simple for your
> developers.

This is the recommended procedure.  For the vast majority of scripts the 
speed difference is negligible, especially when the added overhead in 
retrieving the html encoded data from the database is taken into account.

> The best thing to do in general would be to validate your data according
> to exactly what it is supposed to be. I'm not creative enough to think of
> a way to inject some XSS that subverts htmlentities(), but it seems like
> something that might be possible. Also, adhering to strong security
> practices is a good idea in general, since such things can potentially
> protect you from attacks that you're not even aware of.

htmlentities is designed to prevent ANY characters which have special 
meaning in HTML from being inserted without conversion.  The only way 
you could 'subvert' it in a document would be to exploit a bug in the 
function itself (ie a character which it does not convert.  I would very 
much doubt if this is even possible).

You are absolutely correct though that any data submitted by a user 
should be subject to some form of error checking/cleaning before it it 
used for any purpose.

Dan

>>PS: My spell checker (Grammarian/OS X) flagged 'conspicously' and
>>wanted 'conspicuously' instead.
> 
> Probably because conspicously is not a word. :-)
> 
> Chris
> 
> =====
> Chris Shiflett - http://shiflett.org/
> 
> PHP Security Handbook
>      Coming mid-2004
> HTTP Developer's Handbook
>      http://httphandbook.org/
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>