Prev: Re[2]: [PHP] Re: PHP Sessions
Next: natural text / human text analysis
From: Ashley Sheridan on 14 Mar 2010 06:16
On Sun, 2010-03-14 at 11:15 +0100, Rene Veerman wrote:

> On Sun, Mar 14, 2010 at 7:18 AM, Paul M Foster <paulf(a)quillandmouse.com> wrote:
> >
> > Tedd's perfectly capable of speaking for himself, but I can tell you
> > he's been on this list for a long time, and his skills are plenty
> > adequate for this task. He's just asking for second opinions.
> >
> Wouldn't someone with adequate DB skills know if he(/she) even needs
> to build a datamodel, and given the simplicity of this one, how? Based
> on what i mentioned earlier, type and amount of use of stored reports?
>
> I don't mind noobishness in any area, but i have learned to keep code
> as simple as possible.
>
> BTW;
> - as always, i recommend adodb.sf.net for DB abstractions.
> - if you are storing in DB and displaying from DB later you need to
> prevent code injections (sql, html, js, flash) by pushing all strings
> used in sql insert- and update-fields;
> $sql = 'insert into table (field1_int, field2_string,etc) values
> ('.$field1.', "'.antiSQLinjection($field2).'", ...);
>
> I'm using this function atm, maybe someone can improve upon it. This
> disables all sql injections, and strips all html, js & flash.
>
> function antiSQLinjection ($string) {
>
> //anti SQL injections:
> if (phpversion() >= '4.3.0')
> {
> $string = mysql_real_escape_string($string);
> }
> else
> {
> $string = mysql_escape_string($string);
> }
>
> if(get_magic_quotes_gpc()) // prevents duplicate backslashes
> {
> $string = stripslashes($string);
> }
>
> //anti HTML/JS/flash injections (into searchterms, for instance):
> $string = strip_tags ($string);
>
> return $string;
> }
>


That function won't always work. You're using a PHP version check for
mysql_real_escape_string() when the most likely failure point for it is
if no database connection has been opened.

Also, you shouldn't strip the tags from a string that's being inserted
into the database. strip_tags() is for the display of data on a web
page. It's best practice not to alter the actual data you've stored but
to convert it once it's displayed. Don't forget that the browser display
may not be the only use for that data.

Thanks,
Ash
http://www.ashleysheridan.co.uk


From: Rene Veerman on 14 Mar 2010 07:14
On Sun, Mar 14, 2010 at 11:16 AM, Ashley Sheridan
<ash(a)ashleysheridan.co.uk>wrote:

> That function won't always work. You're using a PHP version check for
> mysql_real_escape_string() when the most likely failure point for it is if
> no database connection has been opened.
>

I never call it without an open db connection..


>
> Also, you shouldn't strip the tags from a string that's being inserted into
> the database. strip_tags() is for the display of data on a web page. It's
> best practice not to alter the actual data you've stored but to convert it
> once it's displayed. Don't forget that the browser display may not be the
> only use for that data.
>

Let's call that a coder's / payer's preference..

If i'd need human text, i'd want to strip it of computer code before it
enters the db. Possibly log the attempt to insert code.
From: Ashley Sheridan on 14 Mar 2010 07:13
On Sun, 2010-03-14 at 12:14 +0100, Rene Veerman wrote:

>
>
>
> On Sun, Mar 14, 2010 at 11:16 AM, Ashley Sheridan
> <ash(a)ashleysheridan.co.uk> wrote:
>
>
>
>
> That function won't always work. You're using a PHP version
> check for mysql_real_escape_string() when the most likely
> failure point for it is if no database connection has been
> opened.
>
>
> I never call it without an open db connection..
>
>
> Also, you shouldn't strip the tags from a string that's being
> inserted into the database. strip_tags() is for the display of
> data on a web page. It's best practice not to alter the actual
> data you've stored but to convert it once it's displayed.
> Don't forget that the browser display may not be the only use
> for that data.
>
>
>
> Let's call that a coder's / payer's preference..
>
> If i'd need human text, i'd want to strip it of computer code before
> it enters the db. Possibly log the attempt to insert code.
>
>
>
>


I have to deal with a lot of CMS's, so I expect the users to enter some
HTML code through a rich-text editor, and they expect to be able to.

Aside from that, it's good to have a complete copy of the code a user
attempted to insert, to see the methodology of an attack should it ever
occur.

Thanks,
Ash
http://www.ashleysheridan.co.uk


From: Rene Veerman on 14 Mar 2010 07:24
On Sun, Mar 14, 2010 at 12:13 PM, Ashley Sheridan
<ash(a)ashleysheridan.co.uk>wrote:

>
> I have to deal with a lot of CMS's, so I expect the users to enter some
> HTML code through a rich-text editor, and they expect to be able to.
>

I'd love to have a copy of whatever function you use to filter out bad
HTML/js/flash for use cases where users are allowed to enter html.
I'm aware of strip_tags() "allowed tags" param, but haven't got a good list
for it.


>
> Aside from that, it's good to have a complete copy of the code a user
> attempted to insert, to see the methodology of an attack should it ever
> occur.
>

I should've said "possibly log & mail the details of the attempt", which is
what i'd do ;)
From: Rene Veerman on 14 Mar 2010 07:25
On Sun, Mar 14, 2010 at 12:24 PM, Rene Veerman <rene7705(a)gmail.com> wrote:
>
> I'd love to have a copy of whatever function you use to filter out bad
> HTML/js/flash for use cases where users are allowed to enter html.
> I'm aware of strip_tags() "allowed tags" param, but haven't got a good list
> for it.
>

oh, and even <img> tags can be used for cookie-stuffing on many browsers..
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Re[2]: [PHP] Re: PHP Sessions
Next: natural text / human text analysis