Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4182 > unrolled thread

BB type posting - is this secure?

Back to article view | Back to comp.lang.php

Contents

  BB type posting - is this secure? Michael Joel <no@please.com> - 2011-12-29 17:45 -0500
    Re: BB type posting - is this secure? "A" <a@a.a> - 2011-12-30 00:14 +0100
    Re: BB type posting - is this secure? Curtis Dyer <dyer85@gmail.com> - 2011-12-29 23:29 +0000
      Re: BB type posting - is this secure? Michael Joel <no@please.com> - 2011-12-29 23:27 -0500
        Re: BB type posting - is this secure? Michael Joel <no@please.com> - 2011-12-30 00:29 -0500
          Re: BB type posting - is this secure? Jerry Stuckle <jstucklex@attglobal.net> - 2011-12-30 05:59 -0500
    Re: BB type posting - is this secure? "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-12-30 10:59 +0100
      Re: BB type posting - is this secure? Michael Joel <no@please.com> - 2011-12-30 10:01 -0500
        Re: BB type posting - is this secure? Michael Fesser <netizen@gmx.de> - 2011-12-30 19:14 +0100
        Re: BB type posting - is this secure? "A" <a@a.a> - 2011-12-30 21:39 +0100
          Re: BB type posting - is this secure? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-01 19:20 +0100
        Re: BB type posting - is this secure? Curtis Dyer <dyer85@gmail.com> - 2012-01-04 07:24 +0000

#4182 — BB type posting - is this secure?

I am allowing posts to the page and wanted to see if this is secure.

data from sql is placed in an array (say $MyArray):

$MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));

$MyArray["Post"] = strip_tags($MyArray["Post"], "<BR>");


I notice with this text like <script>alert("hi");</script> is rendered
as literal so no script is actually recognised.

So is this gooed enough or is there something else I need to do?

Mike

[toc] | [next] | [standalone]

#4183

"Michael Joel" <no@please.com> wrote in message
news:ptqpf75jh2fra5qfu8jhum3bn4ug6r17ot@4ax.com...
>I am allowing posts to the page and wanted to see if this is secure.

> data from sql is placed in an array (say $MyArray):
> $MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));
> $MyArray["Post"] = strip_tags($MyArray["Post"], "<BR>");
> I notice with this text like <script>alert("hi");</script> is rendered
> as literal so no script is actually recognised.

strip_tags($MyArray["Post"], "<BR>");
doesn't really help because it removes only <BR> tags and not other HTML 
tags.

Use htmlspecialchars - it renders all HTML special characters to safe 
variants for displaying.

And before inserting them into database use parametrized query to stop all 
sql injection.
http://stackoverflow.com/questions/1299182/prepared-parameterized-query-with-pdo

[toc] | [prev] | [next] | [standalone]

#4184

Michael Joel <no@please.com> wrote:

> I am allowing posts to the page and wanted to see if this is
> secure. 
> 
> data from sql is placed in an array (say $MyArray):
> 
> $MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));
> 
> $MyArray["Post"] = strip_tags($MyArray["Post"], "<BR>");

Alternatively, you might call nl2br() last.

> I notice with this text like <script>alert("hi");</script> is
> rendered as literal so no script is actually recognised.
> 
> So is this gooed enough or is there something else I need to do?
> 
> Mike

After calling strip_tags(), you'll want to call htmlspecialchars() 
to ensure ensure remaining HTML characters are escaped.

-- 
Curtis Dyer
<?$x='<?$x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>

[toc] | [prev] | [next] | [standalone]

#4186

On Thu, 29 Dec 2011 23:29:23 +0000 (UTC), Curtis Dyer
<dyer85@gmail.com> wrote:

>Michael Joel <no@please.com> wrote:
>
>> I am allowing posts to the page and wanted to see if this is
>> secure. 
>> 
>> data from sql is placed in an array (say $MyArray):
>> 
>> $MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));
>> 
>> $MyArray["Post"] = strip_tags($MyArray["Post"], "<BR>");
>
>Alternatively, you might call nl2br() last.
>
>> I notice with this text like <script>alert("hi");</script> is
>> rendered as literal so no script is actually recognised.
>> 
>> So is this gooed enough or is there something else I need to do?
>> 
>> Mike
>
>After calling strip_tags(), you'll want to call htmlspecialchars() 
>to ensure ensure remaining HTML characters are escaped.


strip_tages(STRING, TAGS TO LEAVE) - second parameter is a string
containing tags to be left alone.

I used the htmlspecialchars and it replaced with html but the html was
rendered literally (" became &quot; - but was render &quot; not ") and
such.

Mike

[toc] | [prev] | [next] | [standalone]

#4188

On Thu, 29 Dec 2011 23:27:30 -0500, Michael Joel <no@please.com>
wrote:

>On Thu, 29 Dec 2011 23:29:23 +0000 (UTC), Curtis Dyer
><dyer85@gmail.com> wrote:
>
>>Michael Joel <no@please.com> wrote:
>>
>>> I am allowing posts to the page and wanted to see if this is
>>> secure. 
>>> 
>>> data from sql is placed in an array (say $MyArray):
>>> 
>>> $MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));
>>> 
>>> $MyArray["Post"] = strip_tags($MyArray["Post"], "<BR>");
>>
>>Alternatively, you might call nl2br() last.
>>
>>> I notice with this text like <script>alert("hi");</script> is
>>> rendered as literal so no script is actually recognised.
>>> 
>>> So is this gooed enough or is there something else I need to do?
>>> 
>>> Mike
>>
>>After calling strip_tags(), you'll want to call htmlspecialchars() 
>>to ensure ensure remaining HTML characters are escaped.
>
>
>strip_tages(STRING, TAGS TO LEAVE) - second parameter is a string
>containing tags to be left alone.
>
>I used the htmlspecialchars and it replaced with html but the html was
>rendered literally (" became &quot; - but was render &quot; not ") and
>such.
>
>Mike

Strike that last part about htmlspecialchars. I forgot I had put that
in on the display side of the script. I put it on the database insert
area and removed it from the display area and it now renders
everything fine. All scripts/html/php ect. is rendered "plain text".

Mike

[toc] | [prev] | [next] | [standalone]

#4191

On 12/30/2011 12:29 AM, Michael Joel wrote:
> On Thu, 29 Dec 2011 23:27:30 -0500, Michael Joel<no@please.com>
> wrote:
>
>> On Thu, 29 Dec 2011 23:29:23 +0000 (UTC), Curtis Dyer
>> <dyer85@gmail.com>  wrote:
>>
>>> Michael Joel<no@please.com>  wrote:
>>>
>>>> I am allowing posts to the page and wanted to see if this is
>>>> secure.
>>>>
>>>> data from sql is placed in an array (say $MyArray):
>>>>
>>>> $MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));
>>>>
>>>> $MyArray["Post"] = strip_tags($MyArray["Post"], "<BR>");
>>>
>>> Alternatively, you might call nl2br() last.
>>>
>>>> I notice with this text like<script>alert("hi");</script>  is
>>>> rendered as literal so no script is actually recognised.
>>>>
>>>> So is this gooed enough or is there something else I need to do?
>>>>
>>>> Mike
>>>
>>> After calling strip_tags(), you'll want to call htmlspecialchars()
>>> to ensure ensure remaining HTML characters are escaped.
>>
>>
>> strip_tages(STRING, TAGS TO LEAVE) - second parameter is a string
>> containing tags to be left alone.
>>
>> I used the htmlspecialchars and it replaced with html but the html was
>> rendered literally (" became&quot; - but was render&quot; not ") and
>> such.
>>
>> Mike
>
> Strike that last part about htmlspecialchars. I forgot I had put that
> in on the display side of the script. I put it on the database insert
> area and removed it from the display area and it now renders
> everything fine. All scripts/html/php ect. is rendered "plain text".
>
> Mike

htmlspecialchars() is a display-related function and should be used on 
the display side, not before inserting into the database.  Otherwise 
your database will be harder to search and won't be usable for non-html 
uses like sending plain text email.

Also, where are you using addslashes()/stripslashes()?  Before/after 
database inserts, maybe?  Bad idea - use mysql_real_escape_string() instead.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4190

El 29/12/2011 23:45, Michael Joel escribió/wrote:
> I am allowing posts to the page and wanted to see if this is secure.
>
> data from sql is placed in an array (say $MyArray):
>
> $MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));

What sense does it make to strip slashes in data that comes from a 
database? If stored data is valid, this will basically corrupt it as 
soon as it contains a backslash:

C:\WINDOWS\system32 --> C:WINDOWSsystem32

... and if you store corrupted data:

Jim \"Magic\" O\'Brian

...  your problem is somewhere else.

> $MyArray["Post"] = strip_tags($MyArray["Post"], "<BR>");

Right, this removes HTML tags, including the <br /> ones you injected 
yourself in the previous step. We have two possibilities:

1. If data is HTML: potential data corruption

	<p>Click <a href="http://example.com">here</a> for info.</p>
	--> Click here for info.

2. If data is not HTML: potential data corruption

	if x<y then z=1 --> if x

> I notice with this text like<script>alert("hi");</script>  is rendered
> as literal so no script is actually recognised.

This JavaScript code won't get executed basically because it gets 
corrupted in the process. A carefully crafted invalid HTML snippet might 
have a better chance to survive.

> So is this gooed enough or is there something else I need to do?

No offence but your security methods are like burning down a warehouse 
so its contents are not stolen at night.

I think the base problem is that you think that:

1. All security contexts are the same.
2. Security in general is about identifying "bad" chars and completely 
stripping them.

Instead, think about *syntax*. All languages have their own syntax with 
its own rules. In such syntax, there are language elements and there are 
literals:

<?php /* I am code */ echo '<?php I am not code ?>'; ?>


Well, this post is getting too long. To sum up, identify context and 
apply proper mechanisms:

- MySQL: Prepared statements, mysql_real_escape_string()...
- JavaScript: json_encode()
- HTML: htmlspecialchars()
- E-mail / HTTP headers: strip line feeds, encode as 7-bit



-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

#4197

On Fri, 30 Dec 2011 10:59:46 +0100, "Álvaro G. Vicario"
<alvaro.NOSPAMTHANX@demogracia.com.invalid> wrote:

>El 29/12/2011 23:45, Michael Joel escribió/wrote:
>> I am allowing posts to the page and wanted to see if this is secure.
>>
>> data from sql is placed in an array (say $MyArray):
>>
>> $MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));
>
>.......... SNIP ................


Sorry I did not make it clear.

stripslashes is used as it comes out of the db, addslashes are used as
it goes in (but as mention mysql_real_escape_string is to be used).

Someone else also claimed the strip_tags($MyString, "<br>");
will strip <br> - but it does not. Maybe it will <br /> but then just
change it to "<br><br />"

the right parameter is to provide exception tags.

Thanks for all the information-
Mike

[toc] | [prev] | [next] | [standalone]

#4201

.oO(Michael Joel)

>Sorry I did not make it clear.
>
>stripslashes is used as it comes out of the db

This will corrupt your data!

Think of adding slashes just as a way to "mark" some chars, so that the
DB doesn't interpret them. It's not about adding literal slashes to your
strings, so you don't have to remove anything after retrieving the data
from the DB.

In other words: Adding slashes doesn't change your string data, it just
ensures that all chars, even the special ones, make it into the DB as
they are.

>, addslashes are used as
>it goes in (but as mention mysql_real_escape_string is to be used).

Good. You could also have a look at prepared statements.

Micha

-- 
http://mfesser.de/blickwinkel

[toc] | [prev] | [next] | [standalone]

#4202

"Michael Joel" <no@please.com> wrote in message 
news:c6krf7l6t9mni7ql4nkua2c53kspied1g0@4ax.com...
> stripslashes is used as it comes out of the db, addslashes are used as
> it goes in (but as mention mysql_real_escape_string is to be used).

just forget about strip/addslashes. use parametrized statements. it is 
really easy and you won't have to think about tons of things.
it took me ages to switch to them, never looked back since as it is just so 
much easier.

when you use parametrized statements then on every ? or :param: it replaces 
it with raw data. it doesn't care whether you are inserting single quote or 
backslash. it just inserts it as raw data.
also, parametrized statements are FASTER. you don't have to convert strings 
from one format to another, escape them etc., you just insert them. database 
engine doesn't need to prepare virtual machine for parsing queries, again it 
is faster, especially if you use SQLite.

and finally, it is safe agains first level of sql injection attacks (data to 
database).

and also use PDO. again, so much easier it does tons of things for you.

so here is how you filter input data:

1. use filter_var or other method of removing any unwanted input (for 
example if you expect a number then filter out any other characters except 
0123456789, easily done with filter_var)
2. use pdo / parametrized statements to insert data into database for 
additional security and to avoid sql injection
3. when displaying this data back on console use htmlentities to correcly 
print < > into &lt; &gt; etc.

and that is all there is to it.

[toc] | [prev] | [next] | [standalone]

#4204

> so here is how you filter input data:
> 
> 1. use filter_var or other method of removing any unwanted input (for 
> example if you expect a number then filter out any other characters except 
> 0123456789, easily done with filter_var)
> 2. use pdo / parametrized statements to insert data into database for 
> additional security and to avoid sql injection
> 3. when displaying this data back on console use htmlentities to correcly 
> print < > into &lt; &gt; etc.
> 
> and that is all there is to it.

This is it: on input to script, on input to database, and on
output to browser. I might add to

1. use your own filter function on form input, in case you have
to adjust it. A length limit on input strings might be useful.

3. If you use Smarty (or the like) you do it in your template,
and don't clutter your code.

/Str.

[toc] | [prev] | [next] | [standalone]

#4213

Michael Joel <no@please.com> wrote:

> On Fri, 30 Dec 2011 10:59:46 +0100, "Álvaro G. Vicario"
> <alvaro.NOSPAMTHANX@demogracia.com.invalid> wrote:
> 
>>El 29/12/2011 23:45, Michael Joel escribió/wrote:
>>> I am allowing posts to the page and wanted to see if this is
>>> secure. 
>>>
>>> data from sql is placed in an array (say $MyArray):
>>>
>>> $MyArray["Post"] = nl2br(stripslashes($MyArray["Post"]));

[I'm including some of what Álvaro wrote for sufficient context:]

>> What sense does it make to strip slashes in data that comes
>> from a database? If stored data is valid, this will basically
>> corrupt it as soon as it contains a backslash:

> .......... SNIP ................
> 
> 
> Sorry I did not make it clear.
> 
> stripslashes is used as it comes out of the db, addslashes are
> used as it goes in (but as mention mysql_real_escape_string is
> to be used). 

The use of stripslashes() on DB output is not needed when properly 
sanitized data is inserted into the DB in the first place. It 
seems like you're misunderstanding the process.

In my experience, it's best to store data in the DB exactly as the 
users provide it. We sanitize the data as a necessary step to 
prevent arbitrary and malicious SQL from being executed. Upon 
retrieving the data for output, none of the artifacts remain from 
the sanitization step.

This is a simplified model of how you might conceptualize handling 
the data.

                       Incoming data
          Sanitization (e.g., prepared statements)
                             |
                             V

                          Database
                             |
                             V

                       Outgoing data
           Escape data (e.g. htmlspecialchars())

You might well do something else with the outgoing data. It 
depends on what you're doing. Álvaro demonstrates upthread.

> Someone else also claimed the strip_tags($MyString, "<br>");
> will strip <br> - but it does not. Maybe it will <br /> but then
> just change it to "<br><br />"

If you're referring to my previous reply* to your OP, then no, I 
did not claim that at all. I merely suggested, *as an 
alternative*, to make the call to nl2br() last so you don't need 
to use the filter parameter for strip_tags().

---
* Message ID: <jdit4j$jj1$1@dont-email.me>

<snip>

-- 
Curtis Dyer
<?$x='<?$x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web