Re: [nyphp-talk] Best practice for escaping data

2007-02-19 Thread Paul Houle
Randal Rust wrote: The correct process would be to: 1. Run fix_magic_quotes() to ensure that all of the backslashes are removed (if magic_quotes_gpc is on) 2. Run each piece of data through the appropriate function for validation 3. Re-insert the slashes using the database specific function

Re: [nyphp-talk] Best practice for escaping data

2007-02-18 Thread Daniel Convissor
On Thu, Feb 15, 2007 at 08:34:14PM -0500, Chris Shiflett wrote: > I was going to say you might consider using ctype_digit(), but I guess > your use of "+" is a nice extra check. :-) I remember the ctype* functions not working properly when I tried them at some point, though I can't recall what t

Re: [nyphp-talk] Best practice for escaping data

2007-02-15 Thread Randal Rust
On 2/15/07, Chris Shiflett <[EMAIL PROTECTED]> wrote: All those characters might be in a headline? If so, carry on. Probably not, but people never cease to amaze me. it would be worth finding out (using historical data or something) how you can restrict your criteria a bit more. So rather

Re: [nyphp-talk] Best practice for escaping data

2007-02-15 Thread Chris Shiflett
Randal Rust wrote: > Yes, that's what I use it for. Particular fields that I pass > through it are headline, subheadline, description All those characters might be in a headline? If so, carry on. If not, it would be worth finding out (using historical data or something) how you can restrict your c

Re: [nyphp-talk] Best practice for escaping data

2007-02-15 Thread Randal Rust
On 2/15/07, Chris Shiflett <[EMAIL PROTECTED]> wrote: I'm wondering if you use it for completely free-form data, where you don't have any particular rules that you can enforce. Yes, that's what I use it for. Particular fields that I pass through it are headline, subheadline, description -- bas

Re: [nyphp-talk] Best practice for escaping data

2007-02-15 Thread Chris Shiflett
Randal Rust wrote: > That function basically is supposed to only allow the > characters that are included in the regex. The more and > more I look at it, the more and more I realize that it's > just been bad from the start. I'm wondering if you use it for completely free-form data, where you don't

Re: [nyphp-talk] Best practice for escaping data

2007-02-15 Thread Randal Rust
On 2/15/07, Chris Shiflett <[EMAIL PROTECTED]> wrote: http://nyphp.org/phundamentals/storingretrieving.php Thanks for the link, Chris. I have been looking over your PHP security book, the PHP Cookbook and Programming PHP tonight to try to refresh myself on this topic. This article will help im

Re: [nyphp-talk] Best practice for escaping data

2007-02-15 Thread Chris Shiflett
Randal Rust wrote: > In order to work in this new environment, I just added > addslashes() to all of the data, but now it won't pass the > validateMixed() function because of the backslashes. That sounds as bad as enabling magic quotes. There's a function on the NYPHP web site called fix_magic_quo

[nyphp-talk] Best practice for escaping data

2007-02-15 Thread Randal Rust
I have custom-built CMS that I use on a lot of my website. Before I commit any data to the database, I run each piece through specific functions that contain a regular expression that accurately validates the data. checkPhoneNumber() checkFaxNumber() checkCurrency() checkEmail() You get the pict