Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2007
    Location
    Glendale AZ
    Posts
    188
    Rep Power
    93

    Extra spaces & <br>s while "proofing" a form...


    I'm working on this blog script and I'm at the "edit" page. I've got this function for displaying to screen while removing the ESCing for the database:

    PHP Code:
    function h_html($text) {return stripslashes(nl2br($text));} 
    If I enter into the form:

    Code:
    Line 1
    
    Line 2
    and hit the proof button it displays on screen properly and then echos the data back into the form field for further editing. But, it looks like this when echoed back into the form field:

    Code:
    Line One<br />
    <br />
    Line Two
    There's the two <br>s that I entered but it's adding line breaks after each. So, even if I just hit the proof button again I then get:

    Code:
    Line One<br /><br />
    <br /><br />
    Line Two
    If I go in and delete the extra line breaks it works as expected but makes it difficult to edit the entry because it's all one long, run-on-looking sentence with <br>s for line breaks.

    I'm obviously implementing something wrong but I'm not sure what? How do I make it display on screen properly while displaying in the edit field in a manner that works but it also readable and easy to edit?

    Thanks,

    Mike
  2. #2
  3. No Profile Picture
    I haz teh codez!
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Dec 2003
    Posts
    2,549
    Rep Power
    2337
    Manual says

    nl2br ó Inserts HTML line breaks before all newlines in a string
    Emphasis added. Doesn't say it *removes* or *replaces* newlines.
    I ♥ ManiacDan & requinix

    This is a sig, and not necessarily a comment on the OP:
    Please don't be a help vampire!
  4. #3
  5. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2007
    Location
    Glendale AZ
    Posts
    188
    Rep Power
    93
    Interesting... it seems the name nl2br isn't accurate If it's simply adding <br>s I think I'm failing to see that function's actual purpose now.

    So, I need to figure out how to strip the <br> while keeping the \r\n for the text box only...
  6. #4
  7. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Hi,

    I don't get what you're trying to do. A textarea must be filled with actual newlines, not <br /> elements. So all you have to do is not apply nl2br() to the string you wanna echo into the textarea -- but you do need to escape it with htmlspecialchars() to prevent JavaScript injections.

    I also don't understand the purpose of stripslashes(). If you webhoster still has magic quotes turned on, I'd consider switching to a hoster that doesn't use ancient features from the 90s.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  8. #5
  9. Sarcky
    Devshed Supreme Being (6500+ posts)

    Join Date
    Oct 2006
    Location
    Pennsylvania, USA
    Posts
    10,908
    Rep Power
    6351
    1) Using stripslashes means your server is configured wrong, you shouldn't need it.

    2) Textareas don't need <br> tags at all, so you're adding <br> tags unnecessarily. Don't do ANYTHING to this input (aside from call htmlentities on it right as you reprint it to the screen, and using PDO or calling mysqli_real_escape_string right as you put it into the database).
    HEY! YOU! Read the New User Guide and Forum Rules

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin

    "The greatest tragedy of this changing society is that people who never knew what it was like before will simply assume that this is the way things are supposed to be." -2600 Magazine, Fall 2002

    Think we're being rude? Maybe you asked a bad question or you're a Help Vampire. Trying to argue intelligently? Please read this.
  10. #6
  11. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2007
    Location
    Glendale AZ
    Posts
    188
    Rep Power
    93
    I'm at Hostgator with NO Magic Quotes and running fairly current versions of PHP and MySQL.

    So, you are saying if I simply don't do anything to the data as it comes OUT of the database (except htmlentities) then it will display correctly? I thought stripping the slashes was ALWAYS necessary?

    I was adding the <br> tags so that it displays on the web page correctly.
  12. #7
  13. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by big0mike
    So, you are saying if I simply don't do anything to the data as it comes OUT of the database (except htmlentities) then it will display correctly? I thought stripping the slashes was ALWAYS necessary?
    What? No. A string from the database is a normal string, it comes out as it came in (unless you've changed it, of course).

    I wonder what makes you think that all strings from the database are cluttered with useless backslashes. Where should they come from? And why should they be there? Wouldn't that be a pretty ... weird bug?

    The only time something like this actually did happen was when magic quotes were still alive. The PHP devs once had a gigantic brainfart and thought to themselves: Hey, our users don't know that they have to escaping their data before inserting it into queries, and escaping in (non-SQL-compliant) database systems like MySQL is done with backslashes, so why not just fill all strings coming from a critical source with backslashes?

    Of course this was total nonsense. Correct escaping depends on the concrete context and the target encoding. Escaping for MySQL is completely different from escaping for HTML or a Unix shell or Excel. Escaping for ASCII or UTF-8 is completely different from escaping for, say, the asian CJK encoding (which is something many people still don't realize).

    Today, of course, people have realized that the solution to the escaping problem is education and specialized features for each context and intelligent concepts like Taint Checking. But certainly not randomly injecting backslashes.



    Originally Posted by big0mike
    I was adding the <br> tags so that it displays on the web page correctly.
    This again depends on the context. You mustn't just throw some <br> into your variables, because that doesn't work for <textarea> or <script> or <pre> or whatever.

    In other word, you have to call the nl2br() ad hoc for when you actually need it. Don't overwrite the original variable or something like that.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  14. #8
  15. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2007
    Location
    Glendale AZ
    Posts
    188
    Rep Power
    93
    Originally Posted by Jacques1
    What? No. A string from the database is a normal string, it comes out as it came in (unless you've changed it, of course).

    I wonder what makes you think that all strings from the database are cluttered with useless backslashes. Where should they come from? And why should they be there? Wouldn't that be a pretty ... weird bug?
    Isn't it "normal" and actually "necessary" to use mysql_real_escape_string on all user-entered data that goes into a database?

    Well, that's what makes me assume that my data is going to have backslashes.

    Originally Posted by Jacques1
    Today, of course, people have realized that the solution to the escaping problem is education and specialized features for each context and intelligent concepts like Taint Checking. But certainly not randomly injecting backslashes.
    I'd never heard of this but I get it and think I'm doing this by both using MySQLi and mysql_real_escape_string on all user-entered data, right? Certainly, there's probably much more I can do but I'm sure what I'm doing would be considered a bare minimum.

    Originally Posted by Jacques1
    This again depends on the context. You mustn't just throw some <br> into your variables, because that doesn't work for <textarea> or <script> or <pre> or whatever.

    In other word, you have to call the nl2br() ad hoc for when you actually need it. Don't overwrite the original variable or something like that.
    OK, that makes sense. So I need to can the nl2br in the function and only use it when displaying to the screen as part of the page. I'll see how that works out for me...
  16. #9
  17. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by big0mike
    Isn't it "normal" and actually "necessary" to use mysql_real_escape_string on all user-entered data that goes into a database?
    This is a misunderstanding.

    First of all, manual SQL escaping is pretty much obsolete, since all modern database extensions support prepared statements. You only need to do that in legacy applications. In any other case, use prepared statements.

    Secondly, the backslashes are not actually in the strings stored in the database. A simple SELECT in phpmyadmin or the MySQL console proves that. The backslashes belong to the "SQL code". They are meta-characters telling the SQL parser to interpret the quote as an actual quote rather than a string delimiter.

    It's the same with PHP:
    Code:
    $str = 'It\'s Friday!';
    The backslash isn't in the string. It's part of the PHP code and tells the PHP parser to interpret the second quote as a literal quote rather than the end of the string. Without this hint, PHP wouldn't know how to parse this expression correctly.



    Originally Posted by big0mike
    I'd never heard of this but I get it and think I'm doing this by both using MySQLi and mysql_real_escape_string on all user-entered data, right? Certainly, there's probably much more I can do but I'm sure what I'm doing would be considered a bare minimum.
    If you have MySQLi available, use prepared statements, and there will never be any risk of SQL injections.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  18. #10
  19. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2007
    Location
    Glendale AZ
    Posts
    188
    Rep Power
    93
    Originally Posted by Jacques1
    If you have MySQLi available, use prepared statements, and there will never be any risk of SQL injections.
    AND I don't need to use mysql_real_escape_string? Good...
  20. #11
  21. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2007
    Location
    Glendale AZ
    Posts
    188
    Rep Power
    93
    OK, so I canned that function altogether.

    I made it so that the only place I use the h function (h($text) {return htmlspecialchars($text, ENT_COMPAT, 'UTF-8');}) now is here:

    PHP Code:
        <div class="center">
            <p>If this looks correct...<br>
            <form name="create" method="post" action="/admin/blog_edit.php">
                <input type="hidden" name="blog_no" value="<?php echo $blog['blog_no']; ?>" />
                <input type="hidden" name="date_posted" value="<?php echo $blog['date_posted']; ?>" />
                <input type="hidden" name="date_readable" value="<?php echo $blog['date_readable']; ?>" />
                <input type="hidden" name="heading" value="<?php echo h($blog['heading']); ?>" />
                <input type="hidden" name="post" value="<?php echo h($blog['post']); ?>" />
                <input name="createBlog" type="submit" value="Create Blog Entry" />
            </form><br>
            Otherwise, correct it below...</p>
        </div>
    Without it I was getting the last half of an <a> link I put in the post output as text right in front of the createBlog button. Apparently one of the quotes in it was throwing things off.

    I output the blog as nl2br($blog['post'] so that it breaks on screen correctly and don't do anything in the text area.

    No problems now.

    Wish I would've known 2 years ago I didn't need to hassle with the slashes and mysql_real_escape_string. I got both of those functions from someone here, too...

    Oh, well.
  22. #12
  23. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Just to make sure there are no misunderstandings:

    • You can only omit manual escaping if you actually use prepared statements and pass all values via bind_param(). I've seen people writing the variables directly into the query string. This of course makes the whole prepared statement useless and vulnerable to SQL injections.
    • You need to escape every variable coming from any critical source before you can output it. You should in fact escape everything, even if it's currently not dangerous. When you start to distinguish between "safe" and "unsafe" variables, there's a gigantic risk of messing that up sooner or later. And saving a few keystrokes isn't really worth the risk of a JavaScript injection (which can have very bad consequences).
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  24. #13
  25. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2007
    Location
    Glendale AZ
    Posts
    188
    Rep Power
    93
    Originally Posted by Jacques1
    You can only omit manual escaping if you actually use prepared statements and pass all values via bind_param(). I've seen people writing the variables directly into the query string. This of course makes the whole prepared statement useless and vulnerable to SQL injections.
    Since I "learned" PHP I've always used bind_param for variables. The only thing I've ever hard coded into the SQL statement is a Y or N in a column but never an actual variable. Even if it's something simple like a date that I've generated myself and the user couldn't have altered.

    Originally Posted by Jacques1
    You need to escape every variable coming from any critical source before you can output it. You should in fact escape everything, even if it's currently not dangerous. When you start to distinguish between "safe" and "unsafe" variables, there's a gigantic risk of messing that up sooner or later.
    Then make sure I understand what you are meaning by escaping. When I think of that my thoughts are:

    1. Always use mysql_real_escape_string.
    2. Using some combination of striptags, stripslashes, htmlentities, htmlspecialchars.

    But, since we've been talking I know I shouldn't need stripslashes for reading data from the database.

    I know striptags only works for perfectly formed, opened and closed, tags so it's not "perfect."

    I don't really understand WHY htmlentities is needed but I've seen some cases where it is needed and used it effectively. So, I'm not sure if this is one I should always use or just occasionally.

    Can't recall if I've used htmlspecialchars or not yet.

    I'll have to do some more in depth reading on those last two...
  26. #14
  27. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by big0mike
    Since I "learned" PHP I've always used bind_param for variables. The only thing I've ever hard coded into the SQL statement is a Y or N in a column but never an actual variable. Even if it's something simple like a date that I've generated myself and the user couldn't have altered..
    Great!



    Originally Posted by big0mike
    Then make sure I understand what you are meaning by escaping.
    You understand the general issue, right? When you generate "code" for some other language like HTML or SQL and you want to insert user-defined values into the code, you need to ensure the user cannot manipulate the code.

    Let's say you'd just output a POST parameter on your page:
    PHP Code:
    echo $_POST['text']; 
    This would allow me to write my own HTML directly into your page via this POST parameter. I could, for example, make a script element and open a pop-up window on the page, asking the user to enter his/her password. Chances are I'll actually get it. I could also fetch all (unprotected) cookies, include malware links on your site etc.

    So you must prevent your visitors from injecting HTML on your page. You do this by converting all special characters like "<" or ">" into literal characters. This way they won't be interpreted as actual HTML.

    The correct method for that is htmlspecialchars. Using htmlentities works as well, but it will convert all characters into their corresponding HTML entitity. This is unnecessary with modern character encodings and obviously inefficient. Only the "dangerous" characters need to be escaped.

    The striptags function is stupid, because it will mangle the user input (and I'm not too sure if it actually works). There's no reason why a user shouldn't be able to write down literal HTML -- it's up to you to make sure it's never actually interpreted as HTML.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  28. #15
  29. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2007
    Location
    Glendale AZ
    Posts
    188
    Rep Power
    93
    Originally Posted by Jacques1
    You understand the general issue, right? When you generate "code" for some other language like HTML or SQL and you want to insert user-defined values into the code, you need to ensure the user cannot manipulate the code.

    Let's say you'd just output a POST parameter on your page:
    PHP Code:
    echo $_POST['text']; 
    This would allow me to write my own HTML directly into your page via this POST parameter... So you must prevent your visitors from injecting HTML on your page. You do this by converting all special characters like "<" or ">" into literal characters.

    The correct method for that is htmlspecialchars. Using htmlentities works as well, but it will convert all characters into their corresponding HTML entitity. This is unnecessary with modern character encodings and obviously inefficient. Only the "dangerous" characters need to be escaped.
    Cool, then I've got that covered because all user-entered data gets output to the screen using the h function which uses htmlspecialchars. Sounds like maybe I should run ALL data output to the screen using that h function since in your earlier post you mention differentiating between "good" and "bad" data can be a recipe for disaster.

    I'm sure I know your answer to this but would it be wise to run all $_POST and $_GET data through that h function? Any time I get $_POST or $_GET data I always run it through something that assigns it to another variable or array simply because I HATE typing "$_" to get output.

    Sounds like I'm mostly on the right page then...

    But, what about when I have data that I WANT to be output as HTML? As an example in my blog post I placed a link to a gallery of race photos. When I use the h function it's output on screen in all it's HTML glory. No link.

    In this case it's data entered by me so I'm fairly positive that it will always be "good" code. But, someone could always crack the password if they really wanted to and this may come up on someone else's site that I'm working on so that I may not KNOW what's being entered. I suspect there's no real way to have HTML be actually "safe", eh?
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo