[Xerte] Re: latex/stripslashes/magic quotes etc

[Paul Swanson]

Hi David,

In regards to your first point, I would never use that function in that manner (directly in the query). You should always validate user input before using in a query. The way to use it would be:

if ( !empty ($_GET['id']) ) {
   $id = (int) escape_data ($_GET['id']);
} else {
    $id = null;
}

Then you can use $id in the query without being open to SQL injection. Good to point out that even a function meant to safeguard queries must be used properly. Thanks!

Paul Swanson
Internal Business Systems Analyst
Internal Business Intelligence
Harland Financial Solutions
(800) 274-7280 Ext. 2462
Paul.Swanson at harlandfs.com

From: xerte-bounces at lists.nottingham.ac.uk [mailto:xerte-bounces at lists.nottingham.ac.uk] On Behalf Of David Goodwin
Sent: Monday, January 21, 2013 12:43 PM
To: Xerte discussion list
Subject: [Xerte] Re: latex/stripslashes/magic quotes etc


On 21 Jan 2013, at 17:48, Paul Swanson <Paul.Swanson at harlandfs.com<mailto:Paul.Swanson at harlandfs.com>> wrote:


On my php applications, I use the following function before saving any data to the database:

// function for escaping and trimming form data
function escape_data ($data) {
    global $dbc;
    if (ini_get ('magic_quotes_gpc')) {
        $data = stripslashes ($data);
   }
    return mysql_real_escape_string (trim ($data), $dbc);
} // end of escape_data() function


Hi,
Random 2p ....

1.I'd avoid using the above - it doesn't protect against e.g.

$sql = "SELECT * FROM users WHERE id = " . escape_data($_GET['id']);

(in this instance, $_GET['id'] needs casting to an int, else injection of SQL could take place - e.g. $_GET['id'] = '5 union .... "


It checks to see if magic_quotes_gpc is on, and if so, employs the stripslashes function, since magic_quotes adds slashes. If magic_quotes isn't on, it skips the stripslashes function. This function ensures that either configuration is handled.

$dbc in the function is the database connection resource variable.

2. Make sure you've called SET NAMES UTF8 or whatever on that connection ... assuming you're using unicode...


3. In XOT, use the db_query/db_query_one functions; they'll take in prepared-statement-esque SQL, which is immune to injection and doesn't result in you having to care whether $foo has been escaped, double escaped or not escaped. Just pass the variables you want to embed within the SQL within an array with ? marks within the actual SQL - like :

$row = db_query_one("SELECT * FROM users WHERE id = ?", array($_GET['id']));
or
$rows = db_query("SELECT * FROM whatever WHERE id = ? AND blah = ?", array($_GET['id'], $_GET['blah']));

etc etc.

4. Different output formats need different escaping; e.g. the escaping you need for within javascript (addcslashes) is different to that for html (htmlentities) and so on. While the 'escapedata' approach may work, it's not ideal or correct  to apply escaping which is appropriate to MySQL on data which is meant to be output as LaTeX or HTML or whatever.

<snip/>


In previous discussions it's clear that depending on php configuration previewing and/or publishing was/is stripping slashes to the point that latex code had all slashes removed and therefore didn't work. There was a suggestion of using ini_set( 'magic_quotes_gpc', true ); in save.php but it's not clear if that resolved the issue.

Don't use magic_quotes. They cause PHP to escape everything with 'addslashes()' that comes from user supplied data -e.g database calls, file_get_contents (probably) and so on. The result of this is that you will eventually find the data to be a mess - e.g. it\\\\\\\\\'s and so on.



I have an installation (linux) where this is happening so as a test I turned on magic_quotes_gpc server wide but that hasn't resolved the issue.

Did you check with e.g. phpinfo(); ? Perhaps there is a local setting either in XOT, or a .htaccess file or elsewhere which is overriding your change? Perhaps your change didn't take effect.


Also I read that magic quotes has been DEPRECATED

Indeed.


as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.

Yes.


So what's the solution to this? Why is it working ok on the Nottingham install but not for me and others? Or is it?

Different versions of the code base?


David.


Pale Purple Ltd.  (Company No: 5580814)
'Business Web Application Development and Training in PHP'

http://www.palepurple.co.uk
Office: 0845 0046746     Mobile: 07792380669

Follow us on Twitter: @PalePurpleLtd







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nottingham.ac.uk/pipermail/xerte/attachments/20130121/5fa5e1c2/attachment-0001.html>