1

I have a text box on my site that allows the use of html formatting to allow the users to make the text more presentable.

I use this code to protect most inputs to my db.

function clean($str) {
    $str = @trim($str);
    if(get_magic_quotes_gpc()) {
        $str = stripslashes($str);
    }
    return mysql_real_escape_string($str);
}

What i don't want it to do is remove html elements like <p> and <strong>

is there a better way to protect the inputs in text areas?

user229044
  • 232,980
  • 40
  • 330
  • 338
Stephen Wolfe
  • 215
  • 1
  • 4
  • 17
  • `strip_tags()` with the optional second parameter to permit `

    , `. But this will not protect you against scripting injections via `onclick,onmouseover` etc. http://us.php.net/manual/en/function.strip-tags.php

     – Michael Berkowski Nov 05 '11 at 16:43
  • how do i protect against it all then? – Stephen Wolfe Nov 05 '11 at 16:45
  • Read the documentation and examples on `strip_tags()` linked in my previous comment. There are many user-submitted functions there to de-fang script attributes. – Michael Berkowski Nov 05 '11 at 16:47
  • Cheers i didnt see the link before, but had already found my way to that site using google + stip_tags :D – Stephen Wolfe Nov 05 '11 at 16:49
  • http://stackoverflow.com/questions/60174/best-way-to-stop-sql-injection-in-php – Kristian82 Nov 05 '11 at 20:23
  • Please [don't add signatures or taglines to your posts](http://stackoverflow.com/faq#signatures). – user229044 Nov 07 '11 at 12:49
  • @Michael You shouldn't be worried about JS injection at this point, prior to DB insertion. You handle that by encoding your output, not escaping your input. It's a completely separate problem. – user229044 Nov 07 '11 at 12:57
  • @meagar I disagree in this one instance - protecting against regular XSS that is true, that it should happen at output. But in this case, since steps are already being taken to limit the permissible HTML tags, the filter should be extended to limit permissible attributes inside permissible tags before storage. – Michael Berkowski Nov 07 '11 at 13:58

2 Answers2

2

I only use mysql_real_escape_string() when inserting data to my DB and remove Tags like <script> (and some others) after pulling it from the DB. I think there are a few regexes out there.

sascha
  • 4,671
  • 3
  • 36
  • 54
  • 1
    If you're removing – Cory Danielson Nov 05 '11 at 16:48
  • 1
    @CoryDanielson: because you might want to use the content in a different context. Besides, what if you find a bug in your html sanitization algorithm. If you do it before, when you find the bug you have to manually loop over existing content. But if you do it after, you're fine... Not to mention that properly escaping HTML is context dependent, so you can't do it once and done... – ircmaxell Nov 05 '11 at 16:52
  • Apart from that, this topic we can discuss for weeks, isn't it? – sascha Nov 05 '11 at 17:36
1

The first line of defense against injections is using prepared statements. If you use prepared statements for your queries then it really doesn't matter what the user puts into your form because you have already separated code from data. The database will see any code that a user injects as just data rather than code. So not only do you get the benefit of protecting yourself from injection, but your code is actually cleaner and more thought out as well.

Blind Fish
  • 998
  • 4
  • 14
  • 25
  • What do u mean by a prepared statement? – Stephen Wolfe Nov 05 '11 at 18:25
  • You parse the query only once, and then you just re-execute it using different parameters ( values ). Essentially, you are guaranteeing that the sql in the query never changes. Everything that the user puts in is bound to a variable, and that variable is passed to the query prior to execution. What this means in that any code or sql injected by a user cannot be interpreted as part of the query. It is simply data. – Blind Fish Nov 05 '11 at 20:45
  • Continued...Therefore if enters sql in your form, rather than just building that sql into a query string which effectively changes your query, your query remains the same and it simply searches the database for a value matching the sql, which it is unlikely to find. You can find the basics here. [link](http://php.net/manual/en/pdo.prepared-statements.php)[/link] – Blind Fish Nov 05 '11 at 20:45