Page 4 of 4

Posted: Tue Nov 15, 2005 5:03 am
by Jenk
I thank you for your time spent on this discussion, I shall be reading a lot more of php|architect and anywhere else of use, if I am still left with any 'why?'s I shall be posting again in a new thread :P

Posted: Tue Nov 15, 2005 9:28 am
by Maugrim_The_Reaper
I stopped posting to this topic because we were running in circles, and at the end of the day looking at varying situations. I'll try to lay out some of these.

Perspective 1:

OOP based application with Input Filtering and Escaping taking place in TWO SEPARATE layers. Since the layers are not interdependent, a change in one would not effect the other. Although a change in one could potentially cause a failure in at least one layer (that would not be picked up or detected by the other).

As a result, under this view it becomes logical to put in place multiple redundant security measures. So even though you filter in one layer - you always back this up by escaping in the other - regardless if it's redundant, mixing responsibilities, or is essentially useless given the *current* (not future) state of the application.

Perspective 2:

Procedural (could easily be OOP too - not being picky here). You have filtering and escaping integrated directly into the main body of your working code. e.g.

$_safenum = intval($POST['num']); // its now a int
mysql_query("select * from table where id = $_safenum");

In this case, its blatantly obvious its going to be an integer. However because (some of us) are going to be truly pedantic in following DID we will still escape the obvious integer. Inval() just might break one day - unlikely but the possibility exists. Another developer could also make a dum mistake. Also happens.

Perspective 3:

Yes, there is yet another perspective - kind of.

No few people will immediately talk about it not mattering what OTHER developers may do to code you have written after you release it to them. While yet others claim it is all important since developers = humans = error prone idiots from time to time. Maybe this one is simply dependent on the project at hand.

In either case I at least would see doing nothing to protect against errors as a little lax. It happens whether by mistake, typo or simple inexperience. The double or nothing approach seems useful in that regard.


I guess 3 applies to each of 1 and 2. This maybe shows the circular reasoning, and how the discussion is running around at random. A more useful topic might be defense in depth itself and why its advantages/disadvantages.

Re:

Posted: Wed Sep 10, 2008 4:37 pm
by kaisellgren
"shiflett" is mostly right, but let me correct some misunderstanding, too. :)
shiflett wrote:(The function is called mysql_real_escape_string().)
The topic author did not mention about what DBMS he is using. He just said "real_escape_string", that could mean any DBMS, not MySQL, although it is the most widely used.
shiflett wrote:1. All data provided in an HTTP request is a string. If you ask a user's age, you'll receive it as a string. In other words, everything in $_GET, $_POST, etc., is a string.
2. An SQL query is a string. You can put an integer in it, but it's still a string. Thus, if you think it's bad to treat an integer as a string, you'll have trouble creating an SQL query that has an integer in it. :-) Stated differently, your integer is going to enter a context where it is a string. The escaping preserves it.
You are right about the "string facts". But consider this "pseudo" code:

Code: Select all

<?php
$var = $db -> real_escape_string(6.66);
$db -> query("UPDATE addresses SET value=$var WHERE name='Hell';");
?>
Our escaping has nothing to offer us, except more heated CPU. We are passing a string into an SQL clause in the above code, but we are passing an integer into an escaping method.

If we are 100% (one hundred percent) sure that our value is an integer, we do not need to escape it. The functions intval(), floatval() and (int) or (float) will make sure we have an integer (or a float) and that they will not contain any malicious characters for our SQL.

Conclusion: There is absolutely no need to escape an integer, however, this is "practically good idea", but I will now let the talking to others as I do not speak English that well ... =/