BB type posting - is this secure?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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?


Re: BB type posting - is this secure?

Quoted text here. Click to load it

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

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.

Re: BB type posting - is this secure?

Quoted text here. Click to load it

Alternatively, you might call nl2br() last.

Quoted text here. Click to load it

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

Curtis Dyer

Re: BB type posting - is this secure?

On Thu, 29 Dec 2011 23:29:23 +0000 (UTC), Curtis Dyer

Quoted text here. Click to load it

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


Re: BB type posting - is this secure?


Quoted text here. Click to load it

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".


Re: BB type posting - is this secure?

On 12/30/2011 12:29 AM, Michael Joel wrote:
Quoted text here. Click to load it

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.

Re: BB type posting - is this secure?

El 29/12/2011 23:45, Michael Joel escribió/wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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=" ">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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

<?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

-- - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web:
-- Mi web de humor satinado:

Re: BB type posting - is this secure?

On Fri, 30 Dec 2011 10:59:46 +0100, "Álvaro G. Vicario"

Quoted text here. Click to load it

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-

Re: BB type posting - is this secure?

.oO(Michael Joel)

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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



Re: BB type posting - is this secure?

Quoted text here. Click to load it

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

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.

Re: BB type posting - is this secure?

Quoted text here. Click to load 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.


Re: BB type posting - is this secure?

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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)


                       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.

Quoted text here. Click to load it

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().



Curtis Dyer

Site Timeline