php-general Digest 17 Jan 2012 10:55:25 -0000 Issue 7653
Topics (messages 316309 through 316318):
Re: sessions and expirations and isolations
316309 by: Stuart Dallas
316310 by: Haluk Karamete
316311 by: Stuart Dallas
316312 by: Haluk Karamete
sql injection protection
316313 by: Haluk Karamete
316315 by: marco.behnke.biz
316316 by: Ross McKay
if http_referer is not reliable then how do we ...
316314 by: Haluk Karamete
316317 by: marco.behnke.biz
SOAP
316318 by: DPRJ Sistemas (OK Cosméticos)
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 16 Jan 2012, at 22:51, Haluk Karamete wrote:
> Hi, in ASP, sessions expire when the client does not request an asp
> page for more than 20 min. (The 20 min thing is a server level setting
> - which can be changed by IIS settings ) And sessions work out of the
> box.
>
> I use sessions a lot. So, most likely, I would keep that style in my
> PHP apps too.
>
> I read the following about PHP sessions... I wanted to know how
> accurate this info is.
>
> <quote>
> The default behaviour for sessions is to keep a session open
> indefinitely and only to expire a session when the browser is closed.
> This behaviour can be changed in the php.ini file by altering the
> line:
>
> session.cookie_lifetime = 0
> If you wanted the session to finish in 5 minutes you would set this to:
>
> Listing 23 Keeping a session alive for five minutes (listing-23.txt)
> session.cookie_lifetime = 300.
> Remember to restart your web server after making this change.
> </quote>
That's totally accurate, except that it doesn't touch upon how sessions are
cleaned up...
> Now, if this info is correct and it is this simple, why do we have
> some elaborate posts like this one?
>
> http://stackoverflow.com/questions/520237/how-do-i-expire-a-php-session-after-30-minutes
...which explains that post. The session.cookie_lifetime is simply the expiry
time that will be set on the cookie that specifies the visitor's session ID.
That ID is used as the unique identifier on the server in the session storage
system (defaults to files of serialized data). If you want to have more precise
control over the session lifetime (though I can't see any reason why you would
need to) then you can write your own session handler and implement the timeout
logic yourself. You could also handle it by storing a timestamp in the session
and using that to decide whether the session data should be considered valid
(as described in the accepted answer on that post).
> What do you do when you write a PHP app that relies on sessions? how
> do you manage the server memory allocation issues?
> Say you wanted to keep session vars alive for 20 min ( from the last
> request from the client ) and you wanted your server to completely
> empty the session if there no request, no new php page is requested
> from that client within that next 20 min. And if a client requests a
> page say on the 19th min, session gets extended another 20 from that
> time on, just like the ASP works.
The only reason there would be memory allocation issues is if you're storing
huge amounts of data in the session. If you are then I'd suggest that you
either re-architect your application so you don't need to, or implement a
custom storage mechanism for that data that doesn't use the session system.
> My second question on session is abut keeping sessions apart from one
> another - if such a concept exists...
>
> Let's say you have a session var FirstName in app1 and another session
> variable exactly named as FirstName in app2.
> how do you keep them seperate?
>
> In ASP, I create a virtual app at the IIS server - assigning a virtual
> dir path to the app, and from that point on, any page being served
> under that virtual path is treated as an isolated ASP app and thus the
> sessions are kept isolated and not get mixed up by asp pages that do
> not live under that virtual app path.
I don't know much about the way ASP implements sessions but I highly doubt
there is anything significantly different in there to the way PHP does it. For
all intents and purposes the isolation of a given user's session is guaranteed
by the use of cookies. As I mentioned earlier, the session ID is stored in a
cookie. Cookies are not shared between domain names, so there is no way that
two sites, or "applications", could use the same session [1].
-Stuart
[1] This is not entirely true, but since it requires some nasty trickery to
make it happen it's not something you need to worry about unless it sharing
sessions is required which is incredibly rare and almost certainly another sign
of poor architecture!
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Well Stuart,
When I said this
> In ASP, I create a virtual app at the IIS server - assigning a virtual
> dir path to the app, and from that point on, any page being served
> under that virtual path is treated as an isolated ASP app and thus the
> sessions are kept isolated and not get mixed up by asp pages that do
> not live under that virtual app path.
I did not mean that aspect of the business which you replied to. I
did not mean that 2 user's session can get being mixed up. Of course,
neither PHP nor ASP would allow that and that's all thru the current
session cookie ID - which is nearly impossible to guess for somebody
else's session cookie ID for that session time.
Instead, I was meaning something totally different. Sorry for not
being very clear about it. Here is another shot at it.
Here, you are developing an app and the app is being developed under say
domain.com/app1/. Let's call this app APP_1
And this app got say 10 php files and these files use lots of some
session vars to pass some data from one another. That's the case for
APP_1.
now you need a second app... which is totally different that APP_1.
And that is to be developed under say the same server as say
domain.com/APP_2/ and this one too has its 5 php files too.
But there is nothing common between two apps.
Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two
separate apps ( virtual apps they call it ) and once I do that ( and
that's thru the IS settings ), the sessions vars I store in APP_1 does
not get overwritten by the APP_2, even though they may or may not
share the ame names... With that, I can set up a session var "Age" as
43 right there in APP_1 and I can have another session variable in the
other app, still named as "Age" where I store age value as a string,
something like say "middle-age". If I weren't create these virtual
apps at IIS, ASP would have overwritten the value 43 with the value
middle-age and vice versa back and forth.
I'm trying to understand if the same flexibility is available or not with PHP.
I should be able to go the APP_1 and do a _SESSION dump and I should
see 10 session variables in there and then I should be able to go
APP_2 and there I should se only 8. That's the case with classic ASP.
On Mon, Jan 16, 2012 at 4:19 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 16 Jan 2012, at 22:51, Haluk Karamete wrote:
>
>> Hi, in ASP, sessions expire when the client does not request an asp
>> page for more than 20 min. (The 20 min thing is a server level setting
>> - which can be changed by IIS settings ) And sessions work out of the
>> box.
>>
>> I use sessions a lot. So, most likely, I would keep that style in my
>> PHP apps too.
>>
>> I read the following about PHP sessions... I wanted to know how
>> accurate this info is.
>>
>> <quote>
>> The default behaviour for sessions is to keep a session open
>> indefinitely and only to expire a session when the browser is closed.
>> This behaviour can be changed in the php.ini file by altering the
>> line:
>>
>> session.cookie_lifetime = 0
>> If you wanted the session to finish in 5 minutes you would set this to:
>>
>> Listing 23 Keeping a session alive for five minutes (listing-23.txt)
>> session.cookie_lifetime = 300.
>> Remember to restart your web server after making this change.
>> </quote>
>
> That's totally accurate, except that it doesn't touch upon how sessions are
> cleaned up...
>
>> Now, if this info is correct and it is this simple, why do we have
>> some elaborate posts like this one?
>>
>> http://stackoverflow.com/questions/520237/how-do-i-expire-a-php-session-after-30-minutes
>
> ...which explains that post. The session.cookie_lifetime is simply the expiry
> time that will be set on the cookie that specifies the visitor's session ID.
> That ID is used as the unique identifier on the server in the session storage
> system (defaults to files of serialized data). If you want to have more
> precise control over the session lifetime (though I can't see any reason why
> you would need to) then you can write your own session handler and implement
> the timeout logic yourself. You could also handle it by storing a timestamp
> in the session and using that to decide whether the session data should be
> considered valid (as described in the accepted answer on that post).
>
>> What do you do when you write a PHP app that relies on sessions? how
>> do you manage the server memory allocation issues?
>> Say you wanted to keep session vars alive for 20 min ( from the last
>> request from the client ) and you wanted your server to completely
>> empty the session if there no request, no new php page is requested
>> from that client within that next 20 min. And if a client requests a
>> page say on the 19th min, session gets extended another 20 from that
>> time on, just like the ASP works.
>
> The only reason there would be memory allocation issues is if you're storing
> huge amounts of data in the session. If you are then I'd suggest that you
> either re-architect your application so you don't need to, or implement a
> custom storage mechanism for that data that doesn't use the session system.
>
>> My second question on session is abut keeping sessions apart from one
>> another - if such a concept exists...
>>
>> Let's say you have a session var FirstName in app1 and another session
>> variable exactly named as FirstName in app2.
>> how do you keep them seperate?
>>
>> In ASP, I create a virtual app at the IIS server - assigning a virtual
>> dir path to the app, and from that point on, any page being served
>> under that virtual path is treated as an isolated ASP app and thus the
>> sessions are kept isolated and not get mixed up by asp pages that do
>> not live under that virtual app path.
>
>
> I don't know much about the way ASP implements sessions but I highly doubt
> there is anything significantly different in there to the way PHP does it.
> For all intents and purposes the isolation of a given user's session is
> guaranteed by the use of cookies. As I mentioned earlier, the session ID is
> stored in a cookie. Cookies are not shared between domain names, so there is
> no way that two sites, or "applications", could use the same session [1].
>
> -Stuart
>
> [1] This is not entirely true, but since it requires some nasty trickery to
> make it happen it's not something you need to worry about unless it sharing
> sessions is required which is incredibly rare and almost certainly another
> sign of poor architecture!
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
--- End Message ---
--- Begin Message ---
On 17 Jan 2012, at 02:21, Haluk Karamete wrote:
> Well Stuart,
>
> When I said this
>
>> In ASP, I create a virtual app at the IIS server - assigning a virtual
>> dir path to the app, and from that point on, any page being served
>> under that virtual path is treated as an isolated ASP app and thus the
>> sessions are kept isolated and not get mixed up by asp pages that do
>> not live under that virtual app path.
>
> I did not mean that aspect of the business which you replied to. I
> did not mean that 2 user's session can get being mixed up. Of course,
> neither PHP nor ASP would allow that and that's all thru the current
> session cookie ID - which is nearly impossible to guess for somebody
> else's session cookie ID for that session time.
>
> Instead, I was meaning something totally different. Sorry for not
> being very clear about it. Here is another shot at it.
>
> Here, you are developing an app and the app is being developed under say
> domain.com/app1/. Let's call this app APP_1
> And this app got say 10 php files and these files use lots of some
> session vars to pass some data from one another. That's the case for
> APP_1.
>
> now you need a second app... which is totally different that APP_1.
> And that is to be developed under say the same server as say
> domain.com/APP_2/ and this one too has its 5 php files too.
>
> But there is nothing common between two apps.
>
> Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two
> separate apps ( virtual apps they call it ) and once I do that ( and
> that's thru the IS settings ), the sessions vars I store in APP_1 does
> not get overwritten by the APP_2, even though they may or may not
> share the ame names... With that, I can set up a session var "Age" as
> 43 right there in APP_1 and I can have another session variable in the
> other app, still named as "Age" where I store age value as a string,
> something like say "middle-age". If I weren't create these virtual
> apps at IIS, ASP would have overwritten the value 43 with the value
> middle-age and vice versa back and forth.
>
> I'm trying to understand if the same flexibility is available or not with PHP.
> I should be able to go the APP_1 and do a _SESSION dump and I should
> see 10 session variables in there and then I should be able to go
> APP_2 and there I should se only 8. That's the case with classic ASP.
Of course. I did touch on this in my reply but I obviously wasn't verbose
enough. Sessions are tied to an ID, and that ID is (usually) stored in a
cookie. Therefore the cookie is what links a session to a user, and it's the
limits on that cookie that determine the level of isolation.
In the case you describe above, the default behaviour would be for both apps to
share the session because the cookie would be set on domain.com with the
default path of /. You can change the path with the session.cookie_path
setting. See here for more details:
http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path
Basically, each app would need to use the ini_set function to set
session.cookie_path to /APP_1 or /APP_2 accordingly, before calling
session_start. That will effectively isolate the sessions for the two apps in
the same way that virtual directories do in ASP.
Hope that makes it clearer.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
great exp. now I'm heading towards the
http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path.
you definitely deserved a good chocolate cookie!
On Mon, Jan 16, 2012 at 6:38 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 17 Jan 2012, at 02:21, Haluk Karamete wrote:
>
>> Well Stuart,
>>
>> When I said this
>>
>>> In ASP, I create a virtual app at the IIS server - assigning a virtual
>>> dir path to the app, and from that point on, any page being served
>>> under that virtual path is treated as an isolated ASP app and thus the
>>> sessions are kept isolated and not get mixed up by asp pages that do
>>> not live under that virtual app path.
>>
>> I did not mean that aspect of the business which you replied to. I
>> did not mean that 2 user's session can get being mixed up. Of course,
>> neither PHP nor ASP would allow that and that's all thru the current
>> session cookie ID - which is nearly impossible to guess for somebody
>> else's session cookie ID for that session time.
>>
>> Instead, I was meaning something totally different. Sorry for not
>> being very clear about it. Here is another shot at it.
>>
>> Here, you are developing an app and the app is being developed under say
>> domain.com/app1/. Let's call this app APP_1
>> And this app got say 10 php files and these files use lots of some
>> session vars to pass some data from one another. That's the case for
>> APP_1.
>>
>> now you need a second app... which is totally different that APP_1.
>> And that is to be developed under say the same server as say
>> domain.com/APP_2/ and this one too has its 5 php files too.
>>
>> But there is nothing common between two apps.
>>
>> Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two
>> separate apps ( virtual apps they call it ) and once I do that ( and
>> that's thru the IS settings ), the sessions vars I store in APP_1 does
>> not get overwritten by the APP_2, even though they may or may not
>> share the ame names... With that, I can set up a session var "Age" as
>> 43 right there in APP_1 and I can have another session variable in the
>> other app, still named as "Age" where I store age value as a string,
>> something like say "middle-age". If I weren't create these virtual
>> apps at IIS, ASP would have overwritten the value 43 with the value
>> middle-age and vice versa back and forth.
>>
>> I'm trying to understand if the same flexibility is available or not with
>> PHP.
>> I should be able to go the APP_1 and do a _SESSION dump and I should
>> see 10 session variables in there and then I should be able to go
>> APP_2 and there I should se only 8. That's the case with classic ASP.
>
> Of course. I did touch on this in my reply but I obviously wasn't verbose
> enough. Sessions are tied to an ID, and that ID is (usually) stored in a
> cookie. Therefore the cookie is what links a session to a user, and it's the
> limits on that cookie that determine the level of isolation.
>
> In the case you describe above, the default behaviour would be for both apps
> to share the session because the cookie would be set on domain.com with the
> default path of /. You can change the path with the session.cookie_path
> setting. See here for more details:
> http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path
>
> Basically, each app would need to use the ini_set function to set
> session.cookie_path to /APP_1 or /APP_2 accordingly, before calling
> session_start. That will effectively isolate the sessions for the two apps in
> the same way that virtual directories do in ASP.
>
> Hope that makes it clearer.
>
> -Stuart
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
--- End Message ---
--- Begin Message ---
I understand some ways are better than others in this one, and it
looks like the PDO based implementations shine the most as far as SQL
Injection.
But would not the following be good enough - without implementing a
PDO solution?
1- get the user input
2- for each input, deliberately enforce a data type ( that is
date/string/integer ) and validate it.
3- for each input, deliberately enforce a data length ( for strings
data length and for integer a valid range for example )
4- check the magic_quotes_gpc and do the stripslashes and then the
mysqli_real_escape_string() and the htmlentities.
5- and on top pf all this, I also check for the specific occurrences
of these following words; if any exist, I just do not execute that SQL
query.
and that list is
sysobjects,
syscolumns,
systypes,
EXEC(@,
CHAR(,
exec%20,
DECLARE%20@,
wscript.
CAST(
CONVERT(
6- I also count the number of "0x" occurrences, if the user input
contains more than 2 of "0x", again I do not execute that command.
With all these in place, I don't know of a way that a userinput can
still make it thru.
These may raise a false negative on some valid user input that's
coming from a textarea where the data type is string, and an accepted
char length is big enough to create some havoc in the db, so be it, I
reject that input.
My question even after all these are there still ways to break in?
All the aboce can be easily tucked in a function which does a data
validation something like
VallidateUserInput ( $_GET['first_name'], "varchar(100)",Please supply
a first name that is less than 100 characters");
VallidateUserInput ( $_GET['age'], "smallint",Please supply an age
that is between 1-20")
Your insight is greatly appreciated on this.
I also read somewhere that mysql does NOT allow statement chaining.
So, that's even better.
--- End Message ---
--- Begin Message ---
Hi Haluk,
all your mentioned actions secure sql statements against sql injection, but why
invent the wheel another time if you could use prepared statements that do all
this for you?
Storing values with htmlentities escaped in the database is highly discouraged.
It makes searching more complicated.
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3
Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz
Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal
http://www.behnke.biz
--- End Message ---
--- Begin Message ---
On Mon, 16 Jan 2012 19:34:09 -0800, Haluk Karamete wrote:
>I understand some ways are better than others in this one, and it
>looks like the PDO based implementations shine the most as far as SQL
>Injection.
PDO is one way (and happens to be the one I prefer), but there are
others. Essentially, you are best validating your inputs (always!) and
then using prepared statements where possible. See here for some
options:
http://bobby-tables.com/php.html
>But would not the following be good enough - without implementing a
>PDO solution?
>[...]
You should always validate your inputs anyway, but whereas a "PDO
solution" (by which I infer you mean using prepared statements) is
safest simply because it forces you to use safe practices, you can still
build safe SQL statements by using mysql(i)_real_escape_string().
Equally, you can bollocks up a prepared statement by building it with
string appends for some parameters that should instead be bound.
Use common sense, use the appropriate tool for the job, but err on the
side of caution and use prepared statements in preference to dynamic SQL
where appropriate. (And where I need to use dynamic SQL, e.g. some
searches, I often do so by building sets of parameters to apply to the
prepared statement for the dynamic SQL)
>[...]
>4- check the magic_quotes_gpc and do the stripslashes and then the
>mysqli_real_escape_string() and the htmlentities.
htmlentities() and htmlspecialchars() are for writing safe HTML, and are
not concerned with SQL injection. You should use them, but only when
writing output to HTML (e.g. don't use them for plain text or XML) and
certainly they have no place in writing to a database except in specific
circumstances (like where you're storing HTML in the database, not
text).
>5- and on top pf all this, I also check for the specific occurrences
>of these following words; if any exist, I just do not execute that SQL
>query.
> and that list is
>sysobjects,
>syscolumns,
>systypes,
>EXEC(@,
>CHAR(,
>exec%20,
>DECLARE%20@,
>wscript.
>CAST(
>CONVERT(
A nice-to-have if you're going to try to detect an attack, but otherwise
not required if you have the bases covered with prepared statements or
properly escaped data. Realise that this is a short list and incomplete,
and can never be complete. I would not rely on it to safe-guard
anything; it can only be used as an indication of a *possible* attack
(but it will also prevent someone submitting perfectly good code to a
forum, for example).
>[...]
>These may raise a false negative on some valid user input that's
>coming from a textarea where the data type is string, and an accepted
>char length is big enough to create some havoc in the db, so be it, I
>reject that input.
Which may be fine in your application, but why stop legitimate data for
no good reason?
>My question even after all these are there still ways to break in?
>[...]
Yes :)
--
Ross McKay, Toronto, NSW Australia
"Pay no attention to that man behind the curtain" - Wizard of Oz
--- End Message ---
--- Begin Message ---
Let' say we have a form mailer script, which takes any form ( whose
action is directed to it ) and goes thru the submitting form's fields
list ( programmatically) , to build a nice email on the fly and email
the build up string to the email address that's coming in the hidden
field. Let's say that's the case...
And you do not want everyone to use this form mailier functionality.
What's the best way to protect it?
I currently use captcha to prevent robotic submissions but that won't
prevent the issue I'm talked about above.
I see no other way then the http_referer to test if the submitting
form resides in one of the accepted domains that mailer.php has been
hardcoded to work with and give privileges to, But then it's known
fact that http_referer can be spoofed.
What would be your way of protecting your script from being taken
advantage of email functionality - without the http_referer?
--- End Message ---
--- Begin Message ---
Haluk Karamete <halukkaram...@gmail.com> hat am 17. Januar 2012 um 04:51
geschrieben:
> Let' say we have a form mailer script, which takes any form ( whose
> action is directed to it ) and goes thru the submitting form's fields
> list ( programmatically) , to build a nice email on the fly and email
> the build up string to the email address that's coming in the hidden
> field. Let's say that's the case...
>
> And you do not want everyone to use this form mailier functionality.
> What's the best way to protect it?
Summed up there is no 100% secured way of building such a workflow.
As you said, everyone can modify the referer.
Captchas can hold back robots, but no real person who misuses your form.
You should not write the recipients email address in a hidden form, but instead
read it from a config file. This way you can make sure, that no one alters it.
Although this won't stop anyone from using the mailform.
You can implement session/cookie/ua/ipbased lockings to prevent mass mailing.
You can use a hidden token generated by your system, passed as hidden value to
the form, which is checked upon submit. That way you can make sure, that no
double submitting is allowed.
But as I stated earlier, there is no 100% protection.
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3
Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz
Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal
http://www.behnke.biz
--- End Message ---
--- Begin Message ---
Hello!
I am looking for some help on Web Services (SOAP) client.
Is there anyone here who has already worked with such client?
Thank you
Deleo
--- End Message ---
