Jump to content

A Few Questions?


mds1256

Recommended Posts

Hi all

 

Looking at best practices when submitting forms and running SQL queries in PHP.

 

My findings so far are as follows:

  1. Turn off Register Globals
  2. Turn off Magic Quotes and use addslashes in the php script.
  3. use mysqli_real_escape_string when processing form elements and sql queries
  4. use htmlentities (with ENT_QUOTES and UTF8) for displaying text returned from a database or a form message box.
  5. use trim when inserting values into the database just to clear white space.

 

Couple of questions:

  1. when using addslashes should I always use stripslashes when displaying / returning values with addslashes. E.g. returning text from the database that has had addslashes applied.
  2. For htmlentities should I use this or htmlspecialchars.
  3. In the example of an edit form where you populate the form text fields with the current values should I return the value from the database with the escaping reversed and then on re-submit just put it back through the escaping process again?

Also any more tips for securing / filtering a form / sql queries

Link to comment
Share on other sites

2. Turn off Magic Quotes and use addslashes in the php script.

 

You should turn off magic quotes. But, you should not use addslashes. You should use the appropriate method based upon the database you are using AND the type of data. For MySQL, when escaping string data you should use mysql_real_escape_string() or mysqli_real_escape_string(). If you were to use addslashes AND mysql_real_escape_string you would actually escape the escaped characters ending up with corrupt data (which is why you are having to use stripslashes when usign the data from the database!). Taht should answer your first question. For data that should be an integer you should either cast the value as an integer or use intval(). For floats or dates or whatever you need to use the appropriate method of validating/sanitizing the data. However, you can remove the need for sanitizing the input (e.g mysql_real_escape_string) by using prepared statements. But, you should still run processes to validate that the data is of the right type (e.g. intval).

 

 

For htmlentities should I use this or htmlspecialchars

Typically htmlspecialchars() is sufficient. The important thing to remember is that you need to prepare the data appropriate based upon the intended output. You maybe outputting to an HTML page today, but tomorrow you may want to output the data to a PDF file or something else. So, I never recommend running functions such as htmlspecialchars() on the data before saving it to the database.

 

In the example of an edit form where you populate the form text fields with the current values should I return the value from the database with the escaping reversed and then on re-submit just put it back through the escaping process again?

You are outputting to a web page - so use htmlspecialchars() or htmlentities(). Nothing else special needed

Link to comment
Share on other sites

You are outputting to a web page - so use htmlspecialchars() or htmlentities(). Nothing else special needed

 

Thanks for the detailed reply.

 

a question on the above, I have noticed that when populating the edit fields (so that the input fields have the values from the database), if I use htmlspecialchars() then inside the text area the source it the html special codes.

 

Is this correct or should I be pulling back the raw(unescaped) returned data from the table and putting it into the text area?

Link to comment
Share on other sites

I have noticed that when populating the edit fields (so that the input fields have the values from the database), if I use htmlspecialchars() then inside the text area the source it the html special codes.

 

Is this correct or should I be pulling back the raw(unescaped) returned data from the table and putting it into the text area?

 

Looks like you mis-typed your explanation of the result - not sure what you meant. I think you meant that you are seeing HTML code in the text area. If so, then that means there was HTML code in the content saved to the database (which would be correct in my opinion) OR you are appending HTML code either before saving or before using htmlentities().

 

You don't want to be using the raw unescaperd content from the database, because if any of the saved data had characters that would be interpreted as HTML code it would screw up the page - which is the reason you would use htmlentities()

Link to comment
Share on other sites

Looks like you mis-typed your explanation of the result - not sure what you meant. I think you meant that you are seeing HTML code in the text area. If so, then that means there was HTML code in the content saved to the database (which would be correct in my opinion) OR you are appending HTML code either before saving or before using htmlentities().

 

You don't want to be using the raw unescaperd content from the database, because if any of the saved data had characters that would be interpreted as HTML code it would screw up the page - which is the reason you would use htmlentities()

 

Sorry, it does read a bit funny.

 

Basically if I use mysqli_real_escape_string to take the textarea text and place it into the database, when looking in the database using mysql command line when you do a select it doesnt have any escape characters in the command line select statement result (I am guessing this is correct).

 

So when returing the data from the database into a textarea do I need to escape anything or just return exactly what the database has held (initially escaped using mysqli_real_escape_string). Or would I use htmlspecialchars / html entities on the returned data/text before echo'ing this into the textarea?

 

Also when I re-submit (as this is an edit form) this using mysqli_real_escape_string would the value in the text area then have the htmlentities codes submitted rather than the proper html or would the textarea convert the html entities codes back into proper html code to then store the proper HTML in the database, ready for using htmlentities to display on a webpage again?

Link to comment
Share on other sites

The escaping done by mysql_real_escape_string () disappears when the content is stored in the database, so you don't have to worry about that when retrieving data.

 

As for when you output to HTML, and you don't want the data to actually be a part of the HTML code on that site, you need to use htmlspecialchars (). This will then display the content inside the textarea in the exact same manner as it was typed.

Since htmlspecialchars () escape data for outputting to HTML, it'll behave in exactly the same way as mysql_real_escape_string () when you retrieve the content again; Namely to "undo" the escaping, and give you the content as typed into the textarea.

Link to comment
Share on other sites

The escaping done by mysql_real_escape_string () disappears when the content is stored in the database, so you don't have to worry about that when retrieving data.

 

As for when you output to HTML, and you don't want the data to actually be a part of the HTML code on that site, you need to use htmlspecialchars (). This will then display the content inside the textarea in the exact same manner as it was typed.

Since htmlspecialchars () escape data for outputting to HTML, it'll behave in exactly the same way as mysql_real_escape_string () when you retrieve the content again; Namely to "undo" the escaping, and give you the content as typed into the textarea.

 

I see, so when outputting to textarea use htmlspecialchars and then when you resubmit it turns this back into characters and not the html entities.

 

Thank you to you all for the contributions.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.