Dealiing with large text areas.

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

fambi
Forum Newbie
Posts: 18
Joined: Sun Apr 02, 2006 12:12 am

Dealiing with large text areas.

Post by fambi »

In an application, such as a ticket-based support centre, users are given huge textareas to describe their issue.

For a malicious user, this is a huge amount of input which does not really get filtered.

Would the following approaches therefore be correct:

1. Inserting into the database

Code: Select all

$ticket = $_POST["ticket"];
$ticket = strip_tags($ticket);
$sql_ticket = mysql_escape_string($ticket);//I'm still on an old php
$sql = "INSERT INTO table SET ticket='$sql_ticket';
2. Calling the data from the database:

Code: Select all

$ticket = htmlentities($ticket);
Is the above correct... is there anything i'm missing... can this be gotten around?

Thanks again for your help.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

use mysql_real_escape_string() - is better. and don't use strip_tags() because this will likely strip the "very important" from this string: "this is a post <very important> can you please give me support" -- i think. htmlentities() will give you all the protection you need as that will convert < into < so that the browser won't interpret that as HTML.

Also make sure you call htmlentities with the two optional arguments:

Code: Select all

$html = array();
$encodingOnThisServer = 'UTF-8';
$html['ticket'] = htmlentities($fromDb['ticket'], ENT_QUOTES, $encodingOnThisServer);
this is recommended in chris shiflett's book although he doesn't specify why. The 2nd arg should always be ENT_QUOTES and the third the same as the header Content-Type that your server serves. Also notice how i'm not just reassigning the variable i'm actually putting it in a new array ($html) this is important as it help you distinguish what you've processed and what you haven't.

Hope this helps
fambi
Forum Newbie
Posts: 18
Joined: Sun Apr 02, 2006 12:12 am

Post by fambi »

Thanks for the advice.
fambi
Forum Newbie
Posts: 18
Joined: Sun Apr 02, 2006 12:12 am

Post by fambi »

But with regards to strip_tags, how do you get rid of the nasty forward slashes put in by mysql_escape_string? (note i cant use real_escape as my version of php is quite old).
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

how do you get rid of the nasty forward slashes put in by mysql_escape_string
err are you serious? That is the point in mysql_escape_string. Those slashes prevent quotes ( ' " ) from being treated as SQL itself. Without them users can send input to the server that breaks out of the SQL quotes you put in.

Consider:

Code: Select all

SELECT * FROM users WHERE username = 'Bob' AND password = 'acorn'
Now a query like that would likely be created with some PHP like this:

Code: Select all

$q = 'SELECT * FROM users WHERE username = \''.$_GET['user'].'\' AND password = \''.$_GET['pass'].'\';
The problem with this is that imagine if $_GET['user'] contains:

Code: Select all

Bob' //
The resulting query is:

Code: Select all

SELECT * FROM users WHERE username = 'Bob' // ' AND password = 'acorn'
The hacker has been able to get the user record without using a password by commenting out the second part of the query. This is just one example of many attacks. However if the forward slash is put in by mysql_real_escape_string() the resulting query is:

Code: Select all

SELECT * FROM users WHERE username = 'Bob\' // ' AND password = 'acorn'
and MySQL will say no user exists because the user "bob\' */" doesn't exist -- the correct behaviour. This is because a quote preceeded by a forward slash is an "escape" causing the quote to be treated as part of the string rather than the end (or beginning) of it
fambi
Forum Newbie
Posts: 18
Joined: Sun Apr 02, 2006 12:12 am

Post by fambi »

But if you are inserting data into a table using the mysql_real_escape, slashes are added (aren't they)?

If so, when you come to print out that data... don't those slashes still exist?

(Remember i'm new to this.)
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

no.

any query that uses a string will have to have its quotes escaped. otherwise if quotes appear inside the string (thus inside the quotes in the query) they will end the string incorrectly
fambi
Forum Newbie
Posts: 18
Joined: Sun Apr 02, 2006 12:12 am

Post by fambi »

Yes, i understand that.

Up until today, i would:

a) addslashes to the values within an sql at the time of INSERT
b) stripslashes to the values to the results of SELECT

For example:

Code: Select all

$value = "php's forum";
$sql_value = addslashes($value);
$sql = "INSERT INTO table SET field='$sql_value'";

$sql = "SELECT field FROM table";
$field = stripslashes($field);
Now, as part of security, we are being advised to use mysql_real_ascape. So does this actually add forward slashes to the data being inserted OR is it just a temporary addition to the sql to ensure that the data get's inserted okay?
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

So does this actually add forward slashes to the data being inserted OR is it just a temporary addition to the sql to ensure that the data get's inserted okay?
the second. is it just a temporary addition to the sql to ensure that quotes are treated as part of the string rather than terminating it.
fambi
Forum Newbie
Posts: 18
Joined: Sun Apr 02, 2006 12:12 am

Post by fambi »

Aaaaaaaaaaaaaah! Right!

Now i understand!

Thanks for the help.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

no problem. you should get a book on this stuff because there are probably loads of different types of attacks you aren't aware of. There certainly was when I started to read up on this stuff.
fambi
Forum Newbie
Posts: 18
Joined: Sun Apr 02, 2006 12:12 am

Post by fambi »

Aren't Chris Shiflett's presentations enough?
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

i dunno, i've got his book but never seen a presentation. yeah that's probably enough.
fambi
Forum Newbie
Posts: 18
Joined: Sun Apr 02, 2006 12:12 am

Post by fambi »

Thanks.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

ole wrote:this is recommended in chris shiflett's book although he doesn't specify why.
Sorry about that. The reason is that it's very important for the escaping function (htmlentities()) and the browser to interpret data the same way. Forgetting details for a moment, imagine if what the browser considered a less than sign (<) is different than what htmlentities() considers a less than sign.

If you want a more specific example, I blogged a bit about Google's XSS vulnerability, which was a direct result of this type of character encoding inconsistency:

http://shiflett.org/archive/178

Hope that explains it better! :-)
Post Reply