NYCPHP Meetup

[Jeff Siegel]

 >> Being right and convincing someone else that you're right
 >> are
 >> often very different things."

Absolutely right! (No sarcasm intended!)

Just a general clarification to all concerning the "PHundamentals."

First, the general philosophy is to offer what the NYPHP community 
believes is "best practice." Of course, there are always exceptions to 
any rule depending on circumstance. However, we're trying to create some 
rules so that when you *do* have to break a rule...you know what rule 
you are violating.

Second, each article goes through a "beta phase" (see the note that 
appears at the bottom of the article) and this type of discussion is 
exactly what is needed to make sure that the final version addresses the 
majority of concerns.

Jeff Siegel


Dan Cech wrote:

> 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
>>
> 
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
> 

-- 
Found on the Simpson's Website:
"Ooooooh, they have the internet on computers now!"