| Sanitizing user input [message #169724] |
Fri, 24 September 2010 05:42  |
MikeB
Messages: 65
Registered: September 2010
Karma: 0
|
Member |
|
|
I'm reading that it is a "good idea" to sanitize all data returned in a
HTML form. The book recommends using the mysql_real_escape_string()
function as well as stripslashes() and for some data it also recommends
using htmlentities().
Question now is that the mysql function is only available if I'm
connected to a mysql database.
Is the mysql sanitizing only necessary for data fields that are going to
be used against the database? Or is there a similar function to
sanitize user data that may not be used as part of the sql data?
|
|
|
|
| Re: Sanitizing user input [message #169727 is a reply to message #169724] |
Fri, 24 September 2010 07:59  |
Helmut Chang
Messages: 22
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Am 24.09.2010 07:42, schrieb MikeB:
> I'm reading that it is a "good idea" to sanitize all data returned in a
> HTML form. The book recommends using the mysql_real_escape_string()
> function as well as stripslashes() and for some data it also recommends
> using htmlentities().
Doesn't the book tell, in which context to use those functions?
mysql_real_escape_string() is used to sanitize data that's used in
queries against a *mysql* database. There are similar functions in each
database module in PHP (because different RDBMS need different escaping).
stripslashes() is a relict from early PHP days. It removes escaping
slashes, that where/are automagically added in GET/POST/... data when
<http://www.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc>
is on.
htmlentities() sanitizes data that's used for HTML output.
And then, there are urlencode() and rawurlencode() to sanitize data,
that's used as part of URLs, that appear in the output.
And so on... ;)
Each context needs other characters escaped/sanitized and in a different
way. Look up those functions in the manual and read, what they do.
And here some examples, what might happen, if you don't sanitize the data:
MySQL:
SELECT * FROM user WHERE username = '$username'
$username = "myusername' OR '1' = '1"
Replace $username in the query with the value of $username and see, what
the query looks like...
HTML:
<input value="<?php echo $value; ?>">
$value = '">
<script type="text/javascript">
alert("XSS Attack!");
</script';
Replace the echo statement with the value of $value and see, what the
HTML looks like...
Hope, you get an idea, what to escape in the different contexts.
Helmut
|
|
|
|
| Re: Sanitizing user input [message #169728 is a reply to message #169724] |
Fri, 24 September 2010 08:15 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 24/09/2010 7:42, MikeB escribió/wrote:
> I'm reading that it is a "good idea" to sanitize all data returned in a
> HTML form.
In general:
- You must sanitize any input you didn't generate yourself.
- You must escape properly everything you insert into a string, even if
you generated it yourself.
> The book recommends using the mysql_real_escape_string()
> function as well as stripslashes() and for some data it also recommends
> using htmlentities().
You should never use stripslashes() unless you have a very old server
that is configured to add slashes to your data:
http://es2.php.net/manual/en/security.magicquotes.php
As about htmlentities(), I don't think it's worth using it. It makes
your HTML grow in size will lots of useless entities (é -> é) but
it cannot really escape all the stuff that needs to be escaped (such as
high-pane Unicode characters). And it's not even aware of the output
charset.
> Question now is that the mysql function is only available if I'm
> connected to a mysql database.
>
> Is the mysql sanitizing only necessary for data fields that are going to
> be used against the database? Or is there a similar function to sanitize
> user data that may not be used as part of the sql data?
The name says it all: it's a function to escape stuff for MySQL when you
are using the MySQL extension. It server no other purpose.
If you use PostgreSQL, you must use the PostgreSQL escaping methods. If
you use PDO you must use the PDO escaping methods.
Furthermore:
- If you are generating HTML you must escape the HTML way, e.g.
htmlspecialchars()
- If you are generating JSON you must escape the JSON way, e.g.
json_encode()
- Etc, etc.
It's nice you care about this. Even most PHP books ignore the subject :)
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: Sanitizing user input [message #169745 is a reply to message #169728] |
Fri, 24 September 2010 15:06 |
MikeB
Messages: 65
Registered: September 2010
Karma: 0
|
Member |
|
|
"Álvaro G. Vicario" wrote:
> It's nice you care about this. Even most PHP books ignore the subject :)
>
Well, thank you! :)
The last thing I want to do is put one more hackable site on the 'net.
I was considering building this "mega-sanitizing routing" and simply run
al luser input through it and apply every manner of sanitizing, but it
seems I'll have to be more selective, since I don't know that I can
reverse all the processes if need be.
I'll play with it for some time longer.
|
|
|
|
| Re: Sanitizing user input [message #169749 is a reply to message #169727] |
Fri, 24 September 2010 15:24 |
MikeB
Messages: 65
Registered: September 2010
Karma: 0
|
Member |
|
|
Helmut Chang wrote:
> Am 24.09.2010 07:42, schrieb MikeB:
>> I'm reading that it is a "good idea" to sanitize all data returned in a
>> HTML form. The book recommends using the mysql_real_escape_string()
>> function as well as stripslashes() and for some data it also recommends
>> using htmlentities().
>
> Doesn't the book tell, in which context to use those functions?
It does, but I was thinking that I may have to use the SQL routine even
perhaps when I'm not connected to the database.
>
> mysql_real_escape_string() is used to sanitize data that's used in
> queries against a *mysql* database. There are similar functions in each
> database module in PHP (because different RDBMS need different escaping).
>
> stripslashes() is a relict from early PHP days. It removes escaping
> slashes, that where/are automagically added in GET/POST/... data when
> <http://www.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc>
> is on.
So this I should not use? Never?
My book has the sample as:
if (get_magic_quotes_gpc()($string=stripslashes($string));
copied from text, so there may be a typo. :)
That should be fine, right?
>
> htmlentities() sanitizes data that's used for HTML output.
This one is good to prevent cross scripting exploits, I believe.
>
> And then, there are urlencode() and rawurlencode() to sanitize data,
> that's used as part of URLs, that appear in the output.
That one I've not come across yet, I can guess what it does, but I'll
look into it a bit more.
>
> And so on... ;)
>
> Each context needs other characters escaped/sanitized and in a different
> way. Look up those functions in the manual and read, what they do.
>
> And here some examples, what might happen, if you don't sanitize the data:
>
<snip>
Yes, that same example I've seen, either in my book or in the php.net
section on SQL injection exploits. Thanks, though.
>
<snip>
>
> Hope, you get an idea, what to escape in the different contexts.
>
You guys are very helpful. Thanks.
|
|
|
|
| Re: Sanitizing user input [message #169753 is a reply to message #169745] |
Fri, 24 September 2010 17:12 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(MikeB)
> I was considering building this "mega-sanitizing routing" and simply run
> al luser input through it and apply every manner of sanitizing, but it
> seems I'll have to be more selective, since I don't know that I can
> reverse all the processes if need be.
Correct. There's no one-fits-all routine. Inside your application you
should always work with the real, raw data (which is why stripslashes()
might be required to remove automatically added slashes by Magic Quotes,
in PHP 6 it will become obsolete). And then always apply the appropriate
escaping functions, depending on where your data goes. Every context,
every output target requires another kind of escaping. In a DB query you
have to call another escaping function than for an HTML output, even if
it's the same data.
Micha
|
|
|
|
| Re: Sanitizing user input [message #169845 is a reply to message #169749] |
Tue, 28 September 2010 10:11 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
MikeB a écrit ce vendredi 24 septembre 2010 17:24 dans <4c9cc294$1(at)news(dot)x-
privat.org> :
> My book has the sample as:
>
> if (get_magic_quotes_gpc()($string=stripslashes($string));
>
> copied from text, so there may be a typo. :)
Yep, it should be:
if (get_magic_quotes_gpc()) $string=stripslashes($string);
Or to make it clearer:
if (get_magic_quotes_gpc())
{
$string=stripslashes($string);
}
> That should be fine, right?
Yep, the above executes "$string=stripslashes($string);" only if
magic_quotes_gpc is activated ("if (get_magic_quotes_gpc())" test),
otherwise it does nothing.
you should define this in a file to include in each scripts which handle
user input:
<?php
function handlemagicquotes($string)
{
if (get_magic_quotes_gpc())
{
$string=stripslashes($string);
}
return $string
}
?>
Then use in your scripts:
$UserData = handlemagicquotes($_POST['UserData']);
And the script will work whatever state of magic quotes is set on the
server.
Instead of the above, you can even have this in an included file:
<?php
function RemoveGPSlashes($CanBeAnArrayOrString)
{
if (is_array($CanBeAnArrayOrString))
{
//Call Ourself recursively:
return array_map('RemoveGPSlashes', $CanBeAnArrayOrString);
}
elseif (is_string($CanBeAnArrayOrString))
{
return stripslashes($CanBeAnArrayOrString);
}
}
if (get_magic_quotes_gpc()) {
$_GET = RemoveGPSlashes($_GET);
$_POST = RemoveGPSlashes($_POST);
}
?>
If you include the above in all scripts handling Get or Post data, the $_GET
and $_POST Arrays will automatically have their slashes stripped off.
>> htmlentities() sanitizes data that's used for HTML output.
>
> This one is good to prevent cross scripting exploits, I believe.
Righto
>> And then, there are urlencode() and rawurlencode() to sanitize data,
>> that's used as part of URLs, that appear in the output.
>
> That one I've not come across yet, I can guess what it does, but I'll
> look into it a bit more.
<?php
$login= "Jon(at)Doe(dot)com";
$password= 'A@wFul;password"!/%<>';
$urllogin = rawurlencode($login);
$urlpasswd = rawurlencode($password);
$url = sprintf ("https://%s:%s@personal_server.com", $urllogin, $urlpasswd);
?>
<a href="<?php echo htmlspecialchars($url);?>">Your Personal access</a>
Without rawurlencode() the link will not work (or risk unexpected
behaviour).
However, it is never recommended to send a login,password over url, but it's
to show an example.
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169846 is a reply to message #169845] |
Tue, 28 September 2010 11:21 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/28/2010 6:11 AM, Web Dreamer wrote:
> MikeB a écrit ce vendredi 24 septembre 2010 17:24 dans<4c9cc294$1(at)news(dot)x-
> privat.org> :
>
>> My book has the sample as:
>>
>> if (get_magic_quotes_gpc()($string=stripslashes($string));
>>
>> copied from text, so there may be a typo. :)
>
> Yep, it should be:
>
> if (get_magic_quotes_gpc()) $string=stripslashes($string);
> Or to make it clearer:
>
> if (get_magic_quotes_gpc())
> {
> $string=stripslashes($string);
> }
>
<snip>
Or, better yet, don't use a hosting company which has magic_quotes_gpc()
enabled, and you can forget all about this mess. The whole thing has
been deprecated and will be removed in PHP 6.0.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169849 is a reply to message #169846] |
Tue, 28 September 2010 13:14 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle a écrit ce mardi 28 septembre 2010 13:21 dans
<i7sjqg$jo5$1(at)news(dot)eternal-september(dot)org> :
> Or, better yet, don't use a hosting company which has magic_quotes_gpc()
> enabled, and you can forget all about this mess. The whole thing has
> been deprecated and will be removed in PHP 6.0.
Concerning the hosting company, you get the point.
But sometimes we are asked do "develop" a web app to resell to another
company, which uses an already-in-production server and for which they can't
change the server settings without breaking an already-in-production-other-
application on the same server.
By doing so, you ensure that your code is portable.
The following ought also to always be included (with an include_once()
directive):
<?php
ini_set('magic_quotes_runtime', 0);
ini_set('magic_quotes_sybase', 0);
?>
since 'magic_quotes_gpc' can't be changed at runtime, the previous I posted
is still required.
But I agree that for our own personnel server, It's indeed better to chose a
proper hosting company. and that all the previous I have mentioned would be
useless (and will be deprecated in PHP6)
Oh, most important, if you are asked to develop on a server having other PHP
apps, and that you use sessions, it is IMPORTANT tu use:
ini_set('session.name', "SomethingElseThan_PHPSESSID");
before using any "session_start()".
This is because 'PHPSESSID' which is the default is probably used by another
application on the same server, and there is a potential risk of mixing
sessions...
Once the user's browser has a session id for a session name, it will send
the same to the same server even if they are two different applications, and
you can have bad surprises.
Imagine that in the $_SESSION array you store the grant level of a user
(admin, user, etc). Imagine this user has a login for each of the web apps
on the server, with the _same_ session.name but different grant levels,
(user on app1, admin on app2), imagine the array key in $_SESSION has the
same name for storing the grant permissions, if he logs in app1 first then
in app2 after, he becomes admin on both... (depends on your code behind).
Of course, this occurs only if they are on the _same_ server
(https://myserver.org/app1/ and https://myserver.org/app2/ )
Setting "ini_set('session.name', 'SomethingElseThan_PHPSESSID');" for each
of your Web apps is a better guarantee to avoid any of such potential
issues.
But this is out of the current subject, just felt it ought to be mentioned.
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169853 is a reply to message #169849] |
Tue, 28 September 2010 15:14 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/28/2010 9:14 AM, Web Dreamer wrote:
> Jerry Stuckle a écrit ce mardi 28 septembre 2010 13:21 dans
> <i7sjqg$jo5$1(at)news(dot)eternal-september(dot)org> :
>
>> Or, better yet, don't use a hosting company which has magic_quotes_gpc()
>> enabled, and you can forget all about this mess. The whole thing has
>> been deprecated and will be removed in PHP 6.0.
>
> Concerning the hosting company, you get the point.
> But sometimes we are asked do "develop" a web app to resell to another
> company, which uses an already-in-production server and for which they can't
> change the server settings without breaking an already-in-production-other-
> application on the same server.
And this code will then break when the host moves to PHP6 and functions
are removed.
Any host still running with magic_quotes enabled should be avoided at
all costs. If applications are dependent on it, they should be
rewritten now - before PHP6 comes out and you are forced to rewrite them
to get your site back up.
> By doing so, you ensure that your code is portable.
> The following ought also to always be included (with an include_once()
> directive):
> <?php
> ini_set('magic_quotes_runtime', 0);
> ini_set('magic_quotes_sybase', 0);
> ?>
>
> since 'magic_quotes_gpc' can't be changed at runtime, the previous I posted
> is still required.
>
Which will really screw things up, since some magic_quotes will be
enabled and others disabled.
> But I agree that for our own personnel server, It's indeed better to chose a
> proper hosting company. and that all the previous I have mentioned would be
> useless (and will be deprecated in PHP6)
>
And all new code should be written with this in mind.
>
> Oh, most important, if you are asked to develop on a server having other PHP
> apps, and that you use sessions, it is IMPORTANT tu use:
>
> ini_set('session.name', "SomethingElseThan_PHPSESSID");
>
> before using any "session_start()".
> This is because 'PHPSESSID' which is the default is probably used by another
> application on the same server, and there is a potential risk of mixing
> sessions...
> Once the user's browser has a session id for a session name, it will send
> the same to the same server even if they are two different applications, and
> you can have bad surprises.
> Imagine that in the $_SESSION array you store the grant level of a user
> (admin, user, etc). Imagine this user has a login for each of the web apps
> on the server, with the _same_ session.name but different grant levels,
> (user on app1, admin on app2), imagine the array key in $_SESSION has the
> same name for storing the grant permissions, if he logs in app1 first then
> in app2 after, he becomes admin on both... (depends on your code behind).
> Of course, this occurs only if they are on the _same_ server
> (https://myserver.org/app1/ and https://myserver.org/app2/ )
>
> Setting "ini_set('session.name', 'SomethingElseThan_PHPSESSID');" for each
> of your Web apps is a better guarantee to avoid any of such potential
> issues.
> But this is out of the current subject, just felt it ought to be mentioned.
>
Definitely NOT! This can really screw up other apps. For instance, the
site stores the login id in the session, with the default cookie
PHPSESSID. Now your page gets control and changes that session name.
It could easily screw up anything else which tries to get to the login id.
Much better is to coordinate the data - but that's only normal; when
working with an existing site, you need to have an understanding of what
the current code uses before going and adding new code. Otherwise you
can run into the exact problem you describe.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169854 is a reply to message #169853] |
Tue, 28 September 2010 16:24 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Jerry Stuckle)
> On 9/28/2010 9:14 AM, Web Dreamer wrote:
>> Setting "ini_set('session.name', 'SomethingElseThan_PHPSESSID');" for each
>> of your Web apps is a better guarantee to avoid any of such potential
>> issues.
>> But this is out of the current subject, just felt it ought to be mentioned.
>
> Definitely NOT! This can really screw up other apps. For instance, the
> site stores the login id in the session, with the default cookie
> PHPSESSID. Now your page gets control and changes that session name.
Depends on whether several applications should be allowed to access and
use the same session data or not. Usually I want my apps separated, even
if they use the same code. So each one would get its own session name if
necessary.
Micha
|
|
|
|
| Re: Sanitizing user input [message #169855 is a reply to message #169853] |
Tue, 28 September 2010 16:37 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle a écrit ce mardi 28 septembre 2010 17:14 dans
<i7t1fn$ckq$1(at)news(dot)eternal-september(dot)org> :
>> Concerning the hosting company, you get the point.
>> But sometimes we are asked do "develop" a web app to resell to another
>> company, which uses an already-in-production server and for which they
>> can't change the server settings without breaking an
>> already-in-production-other- application on the same server.
>
> And this code will then break when the host moves to PHP6 and functions
> are removed.
Yes, but as I mentioned, you are developing for something "already" hosted.
you do not have the choice, it is imposed by your customer/employer.
You are right, but I mention a precise case in which if you do not do it,
there it breaks.
What do you do in such condition?
> Any host still running with magic_quotes enabled should be avoided at
> all costs.
I mentioned that you do not have the choice (imposed by employer/customer)
> If applications are dependent on it, they should be
> rewritten now - before PHP6 comes out and you are forced to rewrite them
> to get your site back up.
If you include a file which does this, you only need to rewrite two/three
lines in the corresponding file for the whole web site, not a big issue.
>> By doing so, you ensure that your code is portable.
>> The following ought also to always be included (with an include_once()
>> directive):
>> <?php
>> ini_set('magic_quotes_runtime', 0);
>> ini_set('magic_quotes_sybase', 0);
>> ?>
>>
>> since 'magic_quotes_gpc' can't be changed at runtime, the previous I
>> posted is still required.
>>
> Which will really screw things up, since some magic_quotes will be
> enabled and others disabled.
Nope, believe it, it "fixes" rather than screwing. It makes that you can
work as if you had no more magic quotes at all.
>> But I agree that for our own personnel server, It's indeed better to
>> chose a proper hosting company. and that all the previous I have
>> mentioned would be useless (and will be deprecated in PHP6)
>>
>
> And all new code should be written with this in mind.
It is important to keep in mind that a platform change (PHP 5 to PHP6) can
be done by changing on, two or three lines in a unique file as I mentioned.
By doing so, your code is compatible with an awfull server and ready to work
on something proper.
>> Oh, most important, if you are asked to develop on a server having other
>> PHP apps, and that you use sessions, it is IMPORTANT tu use:
>>
>> ini_set('session.name', "SomethingElseThan_PHPSESSID");
>
> Definitely NOT! This can really screw up other apps. For instance, the
> site stores the login id in the session, with the default cookie
> PHPSESSID. Now your page gets control and changes that session name.
> It could easily screw up anything else which tries to get to the login id.
That's where you didn't understand what I mentioned. I was NOT talking about
writing another page for a site!
I was talking about writing a complete different application hosted on a
same server. If you do not do what I do, then your app definitely screws the
other one, believe me this is granted for sure!
If you do as I do, the other app which does not invoke
ini_set('session.name', 'SomethingElseThan_PHPSESSID');
Will have session.name set to PHPSESSID and you screw nothing.
I well mentioned "seperate apps" (on the same server) which have "no
relation" and "should not interfere". It can be two vhosts i.e.
In the case you mention, you are absolutely right, but I precised it was not
this case of figure.
> Much better is to coordinate the data - but that's only normal; when
> working with an existing site, you need to have an understanding of what
> the current code uses before going and adding new code. Otherwise you
> can run into the exact problem you describe.
You are right, but in my example I precisely mentioned that it is to do
"another site" with "absolutely no relation to the current one" but "on the
same server" and that they "should not interfere at all". I'm talking about
the exact opposite! in the case you mention you are indeed absolutely right.
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169862 is a reply to message #169855] |
Tue, 28 September 2010 22:34 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/28/2010 12:37 PM, Web Dreamer wrote:
> Jerry Stuckle a écrit ce mardi 28 septembre 2010 17:14 dans
> <i7t1fn$ckq$1(at)news(dot)eternal-september(dot)org> :
>
>>> Concerning the hosting company, you get the point.
>>> But sometimes we are asked do "develop" a web app to resell to another
>>> company, which uses an already-in-production server and for which they
>>> can't change the server settings without breaking an
>>> already-in-production-other- application on the same server.
>>
>> And this code will then break when the host moves to PHP6 and functions
>> are removed.
>
> Yes, but as I mentioned, you are developing for something "already" hosted.
> you do not have the choice, it is imposed by your customer/employer.
> You are right, but I mention a precise case in which if you do not do it,
> there it breaks.
> What do you do in such condition?
>
>> Any host still running with magic_quotes enabled should be avoided at
>> all costs.
>
> I mentioned that you do not have the choice (imposed by employer/customer)
>
>> If applications are dependent on it, they should be
>> rewritten now - before PHP6 comes out and you are forced to rewrite them
>> to get your site back up.
>
> If you include a file which does this, you only need to rewrite two/three
> lines in the corresponding file for the whole web site, not a big issue.
>
>>> By doing so, you ensure that your code is portable.
>>> The following ought also to always be included (with an include_once()
>>> directive):
>>> <?php
>>> ini_set('magic_quotes_runtime', 0);
>>> ini_set('magic_quotes_sybase', 0);
>>> ?>
>>>
>>> since 'magic_quotes_gpc' can't be changed at runtime, the previous I
>>> posted is still required.
>>>
>> Which will really screw things up, since some magic_quotes will be
>> enabled and others disabled.
>
> Nope, believe it, it "fixes" rather than screwing. It makes that you can
> work as if you had no more magic quotes at all.
>
>>> But I agree that for our own personnel server, It's indeed better to
>>> chose a proper hosting company. and that all the previous I have
>>> mentioned would be useless (and will be deprecated in PHP6)
>>>
>>
>> And all new code should be written with this in mind.
>
> It is important to keep in mind that a platform change (PHP 5 to PHP6) can
> be done by changing on, two or three lines in a unique file as I mentioned.
> By doing so, your code is compatible with an awfull server and ready to work
> on something proper.
>
>>> Oh, most important, if you are asked to develop on a server having other
>>> PHP apps, and that you use sessions, it is IMPORTANT tu use:
>>>
>>> ini_set('session.name', "SomethingElseThan_PHPSESSID");
>>
>> Definitely NOT! This can really screw up other apps. For instance, the
>> site stores the login id in the session, with the default cookie
>> PHPSESSID. Now your page gets control and changes that session name.
>> It could easily screw up anything else which tries to get to the login id.
>
> That's where you didn't understand what I mentioned. I was NOT talking about
> writing another page for a site!
> I was talking about writing a complete different application hosted on a
> same server. If you do not do what I do, then your app definitely screws the
> other one, believe me this is granted for sure!
> If you do as I do, the other app which does not invoke
> ini_set('session.name', 'SomethingElseThan_PHPSESSID');
> Will have session.name set to PHPSESSID and you screw nothing.
>
> I well mentioned "seperate apps" (on the same server) which have "no
> relation" and "should not interfere". It can be two vhosts i.e.
>
> In the case you mention, you are absolutely right, but I precised it was not
> this case of figure.
>
>> Much better is to coordinate the data - but that's only normal; when
>> working with an existing site, you need to have an understanding of what
>> the current code uses before going and adding new code. Otherwise you
>> can run into the exact problem you describe.
>
> You are right, but in my example I precisely mentioned that it is to do
> "another site" with "absolutely no relation to the current one" but "on the
> same server" and that they "should not interfere at all". I'm talking about
> the exact opposite! in the case you mention you are indeed absolutely right.
>
And how often does a company want something on their website which is
completely separate from the rest of the site? I've never seen that -
they all want it integrated into the rest of their site.
And if it's a different site, there is no clash with the session id, anyway.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169863 is a reply to message #169854] |
Tue, 28 September 2010 22:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/28/2010 12:24 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 9/28/2010 9:14 AM, Web Dreamer wrote:
>>> Setting "ini_set('session.name', 'SomethingElseThan_PHPSESSID');" for each
>>> of your Web apps is a better guarantee to avoid any of such potential
>>> issues.
>>> But this is out of the current subject, just felt it ought to be mentioned.
>>
>> Definitely NOT! This can really screw up other apps. For instance, the
>> site stores the login id in the session, with the default cookie
>> PHPSESSID. Now your page gets control and changes that session name.
>
> Depends on whether several applications should be allowed to access and
> use the same session data or not. Usually I want my apps separated, even
> if they use the same code. So each one would get its own session name if
> necessary.
>
> Micha
And how often do you have customers who want completely separate
applications on a site? I've never seen one who didn't want the new
code integrated into their existing site.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169877 is a reply to message #169862] |
Wed, 29 September 2010 07:54 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle a écrit ce mercredi 29 septembre 2010 00:34 dans
<i7tr8u$pm8$1(at)news(dot)eternal-september(dot)org> :
> And how often does a company want something on their website which is
> completely separate from the rest of the site? I've never seen that -
> they all want it integrated into the rest of their site.
It's not a "web site" it's a WEB app".
How often? very often, a server (physical machine) costs money, and very
often on the same internal server they have:
- a software for the employees to know their vacation days, and to submit
days to take on vacation.
- A CRM,
- An internal wiki,
- An internal site for emplyee notices,
- A file storage for employees,
- etc...
Many of these small companies have no more then 10 employees, and will no
afford one server per web application they have, the employees only have
light desktops.
> And if it's a different site, there is no clash with the session id,
> anyway.
If it's on the "same physical machine", believe me, there is. because the
server will store the session in the same path with the same name and same
id... it's the same PHP and Apache configuration running behind (with
vhosts, and/or different paths), that's the case I'm talking about, and if
you deal with small companies, you often get the case where they can't
afford having 15 servers for 10 employees...
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169878 is a reply to message #169863] |
Wed, 29 September 2010 08:01 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle a écrit ce mercredi 29 septembre 2010 00:35 dans
<i7trad$pm8$2(at)news(dot)eternal-september(dot)org> :
> On 9/28/2010 12:24 PM, Michael Fesser wrote:
>> Depends on whether several applications should be allowed to access and
>> use the same session data or not. Usually I want my apps separated, even
>> if they use the same code. So each one would get its own session name if
>> necessary.
Exactly, that's why each app should always have it's own session name and
not use the default.
> And how often do you have customers who want completely separate
> applications on a site? I've never seen one who didn't want the new
> code integrated into their existing site.
We are talking about "web applications", not "web sites".
Small companies can not afford more servers than employees to host web apps
(not web sites) useful for their employees.
See my other reply in this thread.
Once you choose a session.name, you keep the same for the whole web app of
course (otherwise everything would brake).
What I mean is that for a "new app" you need a "new session.name" and you
will keep this same session.name for the whole application of course.
If you do not think of choosing a session.name for an application when you
create it, and that you are asked to install this application on a server
which already runs other applications (not sites), you risk clashes if they
all use the same session.name.
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169879 is a reply to message #169877] |
Wed, 29 September 2010 08:02 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Web Dreamer a écrit ce mercredi 29 septembre 2010 09:54 dans
<4ca2f0d4$0$3073$426a34cc(at)news(dot)free(dot)fr> :
> Jerry Stuckle a écrit ce mercredi 29 septembre 2010 00:34 dans
> <i7tr8u$pm8$1(at)news(dot)eternal-september(dot)org> :
>
>> And how often does a company want something on their website which is
>> completely separate from the rest of the site? I've never seen that -
>> they all want it integrated into the rest of their site.
>
> It's not a "web site" it's a WEB app".
>
> How often? very often, a server (physical machine) costs money, and very
> often on the same internal server they have:
>
> - a software for the employees to know their vacation days, and to submit
> days to take on vacation.
>
> - A CRM,
retort : I meant an ERP (not CRM)
> - An internal wiki,
>
> - An internal site for emplyee notices,
>
> - A file storage for employees,
>
> - etc...
>
> Many of these small companies have no more then 10 employees, and will no
> afford one server per web application they have, the employees only have
> light desktops.
>
>
>> And if it's a different site, there is no clash with the session id,
>> anyway.
>
> If it's on the "same physical machine", believe me, there is. because the
> server will store the session in the same path with the same name and same
> id... it's the same PHP and Apache configuration running behind (with
> vhosts, and/or different paths), that's the case I'm talking about, and if
> you deal with small companies, you often get the case where they can't
> afford having 15 servers for 10 employees...
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169884 is a reply to message #169878] |
Wed, 29 September 2010 10:57 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/29/2010 4:01 AM, Web Dreamer wrote:
> Jerry Stuckle a écrit ce mercredi 29 septembre 2010 00:35 dans
> <i7trad$pm8$2(at)news(dot)eternal-september(dot)org> :
>
>> On 9/28/2010 12:24 PM, Michael Fesser wrote:
>>> Depends on whether several applications should be allowed to access and
>>> use the same session data or not. Usually I want my apps separated, even
>>> if they use the same code. So each one would get its own session name if
>>> necessary.
>
> Exactly, that's why each app should always have it's own session name and
> not use the default.
>
>> And how often do you have customers who want completely separate
>> applications on a site? I've never seen one who didn't want the new
>> code integrated into their existing site.
>
> We are talking about "web applications", not "web sites".
> Small companies can not afford more servers than employees to host web apps
> (not web sites) useful for their employees.
> See my other reply in this thread.
>
That is true. And even small companies want their site to provide one
consistent interface. What you have is a bunch of different
applications thrown together with no consistency between them. No
business which knows anything about the internet would want such on
their site. And only a code hacker would build such a site.
> Once you choose a session.name, you keep the same for the whole web app of
> course (otherwise everything would brake).
> What I mean is that for a "new app" you need a "new session.name" and you
> will keep this same session.name for the whole application of course.
>
> If you do not think of choosing a session.name for an application when you
> create it, and that you are asked to install this application on a server
> which already runs other applications (not sites), you risk clashes if they
> all use the same session.name.
>
And you still run that same risk because some other application may have
chosen the same name. If you must separate your information, you should
use some prefix for your session array keys.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169885 is a reply to message #169877] |
Wed, 29 September 2010 11:01 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/29/2010 3:54 AM, Web Dreamer wrote:
> Jerry Stuckle a écrit ce mercredi 29 septembre 2010 00:34 dans
> <i7tr8u$pm8$1(at)news(dot)eternal-september(dot)org> :
>
>> And how often does a company want something on their website which is
>> completely separate from the rest of the site? I've never seen that -
>> they all want it integrated into the rest of their site.
>
> It's not a "web site" it's a WEB app".
>
And it runs on a web site.
> How often? very often, a server (physical machine) costs money, and very
> often on the same internal server they have:
>
> - a software for the employees to know their vacation days, and to submit
> days to take on vacation.
>
> - A CRM,
>
> - An internal wiki,
>
> - An internal site for emplyee notices,
>
> - A file storage for employees,
>
> - etc...
>
> Many of these small companies have no more then 10 employees, and will no
> afford one server per web application they have, the employees only have
> light desktops.
>
They don't need more than one server per web application. It is quite
easy to put multiple web sites, i.e. an external public web site and an
internal employee-only web site on the same server. And often the
external web site is hosted at a data center, while the internal web
site may be on the company's main server.
>
>> And if it's a different site, there is no clash with the session id,
>> anyway.
>
> If it's on the "same physical machine", believe me, there is. because the
> server will store the session in the same path with the same name and same
> id... it's the same PHP and Apache configuration running behind (with
> vhosts, and/or different paths), that's the case I'm talking about, and if
> you deal with small companies, you often get the case where they can't
> afford having 15 servers for 10 employees...
>
Even if it's on the same physical machine, it can be multiple web sites.
Only one server needed for 15 sites - or 150 sites.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169891 is a reply to message #169885] |
Wed, 29 September 2010 13:15 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle a écrit ce mercredi 29 septembre 2010 13:01 dans
<i7v69i$8bp$1(at)news(dot)eternal-september(dot)org> :
>> It's not a "web site" it's a WEB app".
>>
>
> And it runs on a web site.
No
On an internal server.
> They don't need more than one server per web application. It is quite
> easy to put multiple web sites, i.e. an external public web site and an
> internal employee-only web site on the same server. And often the
> external web site is hosted at a data center, while the internal web
> site may be on the company's main server.
Indeed
> Even if it's on the same physical machine, it can be multiple web sites.
> Only one server needed for 15 sites - or 150 sites.
Indeed.
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169893 is a reply to message #169884] |
Wed, 29 September 2010 13:47 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle a écrit ce mercredi 29 septembre 2010 12:57 dans
<i7v63r$7hh$1(at)news(dot)eternal-september(dot)org> :
> On 9/29/2010 4:01 AM, Web Dreamer wrote:
>> We are talking about "web applications", not "web sites".
>> Small companies can not afford more servers than employees to host web
>> apps (not web sites) useful for their employees.
>> See my other reply in this thread.
>>
>
> That is true. And even small companies want their site to provide one
> consistent interface. What you have is a bunch of different
> applications thrown together with no consistency between them.
Depends, some can be consistent, but will "require" different logins and
separate sessions.
Some not.
i.e. an application may be accessed ONLY by HR, and you do not want the HR
to be automatically logged in this application (for security reasons) if
he/she's logged in another application : you separate session handling (but
can be linked to same user database)
handling sessions separately does not mean you have to separate everything.
This makes sure you are not logged in an application automatically after
having logged in another, if you want separate sessions for security
reasons.
Explain why you would have inconsistency?
Choosing consistency depends on the target and usage of the application, and
can require to be totally separated concerning session handling even with
consistency. I was only mentioning session handling.
> No
> business which knows anything about the internet would want such on
> their site. And only a code hacker would build such a site.
No,
Another example different from the one above:
A shopkeeper can have two companies:
A shoe shop
A flower shop
two different entities.
They share one same server (same boss, different legal entities, and
employees).
You SURELY do not want to mix anything together! But the owner of the shops
can afford only one server (2 or 3 employees in each shop), and you
configure vhosts on the server.
Are you really sure you want top mix this?
I seriously doubt it.
Do you know any small business who would want to have mixed employee
logins/accountability with another small business?
Honestly... no...
But sometimes they share a same "physical" server (same owner for the 2
shops)
>> Once you choose a session.name, you keep the same for the whole web app
>> of course (otherwise everything would brake).
>> What I mean is that for a "new app" you need a "new session.name" and you
>> will keep this same session.name for the whole application of course.
>>
>> If you do not think of choosing a session.name for an application when
>> you create it, and that you are asked to install this application on a
>> server which already runs other applications (not sites), you risk
>> clashes if they all use the same session.name.
>>
>
> And you still run that same risk because some other application may have
> chosen the same name. If you must separate your information, you should
> use some prefix for your session array keys.
There is much less risk, but indeed you are right about adding also a
prefix.
And again, separating sessions does not necessarily mean separating
information.
Sometimes you want things totally separated.
Sometimes only "sessions" to be separated.
And it's the one who pays you who decides.
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169897 is a reply to message #169893] |
Wed, 29 September 2010 16:21 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/29/2010 9:47 AM, Web Dreamer wrote:
> Jerry Stuckle a écrit ce mercredi 29 septembre 2010 12:57 dans
> <i7v63r$7hh$1(at)news(dot)eternal-september(dot)org> :
>
>> On 9/29/2010 4:01 AM, Web Dreamer wrote:
>>> We are talking about "web applications", not "web sites".
>>> Small companies can not afford more servers than employees to host web
>>> apps (not web sites) useful for their employees.
>>> See my other reply in this thread.
>>>
>>
>> That is true. And even small companies want their site to provide one
>> consistent interface. What you have is a bunch of different
>> applications thrown together with no consistency between them.
>
> Depends, some can be consistent, but will "require" different logins and
> separate sessions.
>
> Some not.
>
> i.e. an application may be accessed ONLY by HR, and you do not want the HR
> to be automatically logged in this application (for security reasons) if
> he/she's logged in another application : you separate session handling (but
> can be linked to same user database)
> handling sessions separately does not mean you have to separate everything.
> This makes sure you are not logged in an application automatically after
> having logged in another, if you want separate sessions for security
> reasons.
>
> Explain why you would have inconsistency?
>
You have inconsistency because a person has to use multiple logins to
the same site to access different information. It means users not only
have to keep track of multiple userids/passwords for the same site, but
which userid/password accesses which information.
If you have completely separate applications, it is much better to have
them on separate sites - additionally, system software can further limit
access (i.e. only from certain ip addresses).
> Choosing consistency depends on the target and usage of the application, and
> can require to be totally separated concerning session handling even with
> consistency. I was only mentioning session handling.
>
Which affects consistency.
>> No
>> business which knows anything about the internet would want such on
>> their site. And only a code hacker would build such a site.
>
> No,
>
> Another example different from the one above:
>
> A shopkeeper can have two companies:
> A shoe shop
> A flower shop
> two different entities.
> They share one same server (same boss, different legal entities, and
> employees).
> You SURELY do not want to mix anything together! But the owner of the shops
> can afford only one server (2 or 3 employees in each shop), and you
> configure vhosts on the server.
>
No, and I would have two separate sites - one for each company. No
special session handling required, because each site can only access its
own cookies - and therefore only its own session information.
> Are you really sure you want top mix this?
> I seriously doubt it.
>
> Do you know any small business who would want to have mixed employee
> logins/accountability with another small business?
> Honestly... no...
> But sometimes they share a same "physical" server (same owner for the 2
> shops)
>
Nope, which is why they would have different sites. It makes no
difference whether they are on the same server or not - cookies are
domain specific, not server specific. One domain cannot access cookies
from another domain - it makes absolutely no difference whether they are
on the same server or not.
>>> Once you choose a session.name, you keep the same for the whole web app
>>> of course (otherwise everything would brake).
>>> What I mean is that for a "new app" you need a "new session.name" and you
>>> will keep this same session.name for the whole application of course.
>>>
>>> If you do not think of choosing a session.name for an application when
>>> you create it, and that you are asked to install this application on a
>>> server which already runs other applications (not sites), you risk
>>> clashes if they all use the same session.name.
>>>
>>
>> And you still run that same risk because some other application may have
>> chosen the same name. If you must separate your information, you should
>> use some prefix for your session array keys.
>
> There is much less risk, but indeed you are right about adding also a
> prefix.
>
> And again, separating sessions does not necessarily mean separating
> information.
>
Yes, it does - because scripts using one session cookie will not be able
to access data from the other session cookie.
> Sometimes you want things totally separated.
> Sometimes only "sessions" to be separated.
>
> And it's the one who pays you who decides.
>
So, you use different domains and different hosts. No problem at all,
and separation of session information is guaranteed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169898 is a reply to message #169891] |
Wed, 29 September 2010 16:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/29/2010 9:15 AM, Web Dreamer wrote:
> Jerry Stuckle a écrit ce mercredi 29 septembre 2010 13:01 dans
> <i7v69i$8bp$1(at)news(dot)eternal-september(dot)org> :
>
>>> It's not a "web site" it's a WEB app".
>>>
>>
>> And it runs on a web site.
>
> No
> On an internal server.
>
Which contains a web server. Otherwise, it is not a "web app". Web
sites do not have to be public - in fact, there are good reasons for
having some websites only accessible to the intranet - and many
companies have such sites.
>> They don't need more than one server per web application. It is quite
>> easy to put multiple web sites, i.e. an external public web site and an
>> internal employee-only web site on the same server. And often the
>> external web site is hosted at a data center, while the internal web
>> site may be on the company's main server.
>
> Indeed
>
>> Even if it's on the same physical machine, it can be multiple web sites.
>> Only one server needed for 15 sites - or 150 sites.
>
> Indeed.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169917 is a reply to message #169897] |
Thu, 30 September 2010 07:44 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Le 29/09/10 18:21, Jerry Stuckle a écrit :
> You have inconsistency because a person has to use multiple logins to
> the same site to access different information. It means users not only
> have to keep track of multiple userids/passwords for the same site, but
> which userid/password accesses which information.
You can have identical logins (same database) with different session
handling.
And it works very neatly :-)
Why do you think it mean having different logins?
I want to have a session to not log automatically to the other for
security reasons.
>> I was only mentioning session handling.
>>
>
> Which affects consistency.
No
>> A shopkeeper can have two companies:
>> A shoe shop
>> A flower shop
>> two different entities.
>> They share one same server (same boss, different legal entities, and
>> employees).
>> You SURELY do not want to mix anything together! But the owner of the
>> shops
>> can afford only one server (2 or 3 employees in each shop), and you
>> configure vhosts on the server.
>>
>
> No, and I would have two separate sites - one for each company. No
> special session handling required, because each site can only access its
> own cookies - and therefore only its own session information.
The shopkeeper wants the same domain name "HisSurname.com/shopname"
That's "his" choice, I have do with this. Or he get's someone else.
>> Are you really sure you want top mix this?
>> I seriously doubt it.
>>
>> Do you know any small business who would want to have mixed employee
>> logins/accountability with another small business?
>> Honestly... no...
>> But sometimes they share a same "physical" server (same owner for the 2
>> shops)
>>
>
> Nope, which is why they would have different sites. It makes no
> difference whether they are on the same server or not - cookies are
> domain specific, not server specific. One domain cannot access cookies
> from another domain - it makes absolutely no difference whether they are
> on the same server or not.
As I explained, same domain.
I'm paid to do as "his will", and had do do it.
A person/company can own several little companies, and may want
"CompanyGroup.com/smallCampany"
The domain is "the same".
Dangerous for cookies.
I do not "always" have Vhosts, so I make sure it can work without vhosts.
>> And again, separating sessions does not necessarily mean separating
>> information.
>>
>
> Yes, it does - because scripts using one session cookie will not be able
> to access data from the other session cookie.
You want these (sessions) to be seperate.
And they can share databases if required, works like a charm.
And for security, a script which needs only "read" access to a database,
will have a login to this database with only "select" permission.
I always create two users for databases, and I never use the one with
full write permissions on the database if I only need read access in the
script.
I use prepared statements to protect from sql injection, but add this
extra security.
>> Sometimes you want things totally separated.
>> Sometimes only "sessions" to be separated.
>>
>> And it's the one who pays you who decides.
>>
>
> So, you use different domains and different hosts. No problem at all,
> and separation of session information is guaranteed.
With different domains, no big issue,
But I'have already been asked the same domain, and the shop was the path
after the domain name.
When you say "it's not secure", they say "if you want this check with
that much money? well make it secure and the way I want".
What do you reply? you refuse the check? :-)
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169918 is a reply to message #169898] |
Thu, 30 September 2010 07:47 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Le 29/09/10 18:22, Jerry Stuckle a écrit :
> Which contains a web server. Otherwise, it is not a "web app". Web
> sites do not have to be public - in fact, there are good reasons for
> having some websites only accessible to the intranet - and many
> companies have such sites.
Exactly, and that's the kind of web apps I'm talking about.
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169929 is a reply to message #169917] |
Thu, 30 September 2010 12:32 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/30/2010 3:44 AM, Web Dreamer wrote:
> Le 29/09/10 18:21, Jerry Stuckle a écrit :
>> You have inconsistency because a person has to use multiple logins to
>> the same site to access different information. It means users not only
>> have to keep track of multiple userids/passwords for the same site, but
>> which userid/password accesses which information.
>
> You can have identical logins (same database) with different session
> handling.
> And it works very neatly :-)
> Why do you think it mean having different logins?
> I want to have a session to not log automatically to the other for
> security reasons.
>
Which would be a huge security exposure. Any decent security expert
will tell you to have different login ids/passwords for different jobs.
But if you have the different applications on different virtual hosts,
you don't need to change the session id.
>>> I was only mentioning session handling.
>>>
>>
>> Which affects consistency.
>
> No
>
Yes it does. You now have completely separate applications on the same
site. Either there is no link between them, which means users have to
type in a page, or you have links between them and now have to worry
about which session id is being used.
>>> A shopkeeper can have two companies:
>>> A shoe shop
>>> A flower shop
>>> two different entities.
>>> They share one same server (same boss, different legal entities, and
>>> employees).
>>> You SURELY do not want to mix anything together! But the owner of the
>>> shops
>>> can afford only one server (2 or 3 employees in each shop), and you
>>> configure vhosts on the server.
>>>
>>
>> No, and I would have two separate sites - one for each company. No
>> special session handling required, because each site can only access its
>> own cookies - and therefore only its own session information.
>
> The shopkeeper wants the same domain name "HisSurname.com/shopname"
> That's "his" choice, I have do with this. Or he get's someone else.
>
You are just being argumentative now. First of all, if the businessman
has two different businesses, they are going to have two different
names. That's just simple marketing. The same goes for web sites. He
wouldn't want someone looking for flowers to land on a shoe store site.
Please show me ONE example of a real business which has such a set up.
>>> Are you really sure you want top mix this?
>>> I seriously doubt it.
>>>
>>> Do you know any small business who would want to have mixed employee
>>> logins/accountability with another small business?
>>> Honestly... no...
>>> But sometimes they share a same "physical" server (same owner for the 2
>>> shops)
>>>
>>
>> Nope, which is why they would have different sites. It makes no
>> difference whether they are on the same server or not - cookies are
>> domain specific, not server specific. One domain cannot access cookies
>> from another domain - it makes absolutely no difference whether they are
>> on the same server or not.
>
> As I explained, same domain.
> I'm paid to do as "his will", and had do do it.
> A person/company can own several little companies, and may want
> "CompanyGroup.com/smallCampany"
> The domain is "the same".
> Dangerous for cookies.
> I do not "always" have Vhosts, so I make sure it can work without vhosts.
>
And as I've explained - you are just arguing to argue, now. You're so
full of hot air if you were a balloon you'd never come down. Again,
show me one real company which does such tings.
>>> And again, separating sessions does not necessarily mean separating
>>> information.
>>>
>>
>> Yes, it does - because scripts using one session cookie will not be able
>> to access data from the other session cookie.
>
> You want these (sessions) to be seperate.
> And they can share databases if required, works like a charm.
> And for security, a script which needs only "read" access to a database,
> will have a login to this database with only "select" permission.
> I always create two users for databases, and I never use the one with
> full write permissions on the database if I only need read access in the
> script.
> I use prepared statements to protect from sql injection, but add this
> extra security.
>
More hot air.
>>> Sometimes you want things totally separated.
>>> Sometimes only "sessions" to be separated.
>>>
>>> And it's the one who pays you who decides.
>>>
>>
>> So, you use different domains and different hosts. No problem at all,
>> and separation of session information is guaranteed.
>
> With different domains, no big issue,
> But I'have already been asked the same domain, and the shop was the path
> after the domain name.
> When you say "it's not secure", they say "if you want this check with
> that much money? well make it secure and the way I want".
> What do you reply? you refuse the check? :-)
>
Again, more hot air.
But it's again obvious you either are arguing just to argue, or have no
idea of what you're doing - but are doing your best to support your
unsupportable argument.
So much for you. I like to discuss things with intelligent people.
<plonk>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169930 is a reply to message #169918] |
Thu, 30 September 2010 12:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/30/2010 3:47 AM, Web Dreamer wrote:
> Le 29/09/10 18:22, Jerry Stuckle a écrit :
>
>> Which contains a web server. Otherwise, it is not a "web app". Web
>> sites do not have to be public - in fact, there are good reasons for
>> having some websites only accessible to the intranet - and many
>> companies have such sites.
>
> Exactly, and that's the kind of web apps I'm talking about.
>
So now you agree the machine does contain a web server - which you
previously denied.
And intranet web sites would be using completely different domains than
extranet sites - so your session handling is not necessary.
But as I said in my other response - you obviously have no way to
support such an argument, but are doing your best to come up with
examples which are invalid to do it. I don't wish to continue this
discussion with an idiot.
<plonk>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitizing user input [message #169932 is a reply to message #169929] |
Thu, 30 September 2010 12:51 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Le 30/09/10 14:32, Jerry Stuckle a écrit :
> You are just being argumentative now. First of all, if the businessman
> has two different businesses, they are going to have two different
> names. That's just simple marketing. The same goes for web sites. He
> wouldn't want someone looking for flowers to land on a shoe store site.
>
> Please show me ONE example of a real business which has such a set up.
If you remember, I told you they were "INTRANET" software.
I can't show you something private.
> And as I've explained - you are just arguing to argue, now. You're so
> full of hot air if you were a balloon you'd never come down. Again,
> show me one real company which does such tings.
Funny, I have the exact same impression on you.
Again, I'm not allowed to show you an Intranet.
Looks like you are a bit hard of understanding?
> More hot air.
It only affects non cool people :-p
> Again, more hot air.
A cooling problem?
> But it's again obvious you either are arguing just to argue, or have no
> idea of what you're doing - but are doing your best to support your
> unsupportable argument.
I wonder who's the first to argue.
> So much for you. I like to discuss things with intelligent people.
You wouldn't stand a discussion with yourself?
> <plonk>
AAaaah at last.
Thanks :-)
--
Web Dreamer
|
|
|
|
| Re: Sanitizing user input [message #169933 is a reply to message #169930] |
Thu, 30 September 2010 12:57 |
Web Dreamer
Messages: 13
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Le 30/09/10 14:35, Jerry Stuckle a écrit :
> So now you agree the machine does contain a web server - which you
> previously denied.
I denied an external web site.
> And intranet web sites would be using completely different domains than
> extranet sites - so your session handling is not necessary.
There is NO extranet!
> But as I said in my other response - you obviously have no way to
> support such an argument, but are doing your best to come up with
> examples which are invalid to do it. I don't wish to continue this
> discussion with an idiot.
Idiots are people who don't want to understand or deny understanding in
purpose to argue. And therefore, you couldn't stand speaking with yourself!
> <plonk>
Thanks, you saved me from yourself!
It's the best reply you gave so far and the most pleasurable one.
--
Web Dreamer
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]