php-general Digest 18 Jan 2012 11:32:55 -0000 Issue 7655
Topics (messages 316324 through 316329):
Re: sessions and expirations and isolations
316324 by: Haluk Karamete
Bug 51860
316325 by: Christian Grobmeier
Re: sql injection protection
316326 by: Haluk Karamete
How to correctly validate url?
316327 by: Tanel Tammik
316328 by: Mokaddim Akm
316329 by: Tanel Tammik
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 ---
Back to this session expiration...
that old quote said...
<begin>
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:
session.cookie_lifetime = 300.
<end>
Reflecting on this a little more, I got interested in the part that
says "The default behaviour for sessions is to keep a session open
indefinitely and only to expire a session when the browser is closed."
How would do the server know that a browser is closed? No browser
sends such a data to a server.
If you re-open your browser, sure you will get asked to relogin (
cause that session id cookie is gone ) but that does not mean that old
session data has been erased form the server. How could it? The only
way for that to happen is to run session_destroy programmatically but
for that your users has to click on a link. Certainly, closing a
browser won't cause that!
This brings the question to the following;
WHEN DOES THE SERVER KNOW THAT A USER IS REALLY GONE OR HE CLOSED HIS BROWSER?
I'm afraid session.cookie_lifetime = 0 keeps all session data ( that
is past and present ) in server memory until a server restart/stop
takes place. Correct me if I'm wrong.
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 ---
Hello folks,
any chance this one is ever fixed?
https://bugs.php.net/bug.php?id=51860
I am a customer of 1&1. They told me they will not upgrade until this
one is fixed. Imagine that there are thousands of customers running
php 5.2.17 just because of this issue. Unfortunately I am not able to
fix this on myself - my C-fu is not good enough.
Because big hosters like 1&1 do not upgrade, we (the Apache log4php
team) cannot make use of newer PHP versions too. We have decided to
use the features once we see the old hosters move on. Same is true for
other projects of mine. If we would upgrade we loose all the people on
the big hosting companies.
I think it is in the interest of the PHP-dev team to see people moving
on. Otherwise at someday software like phpBB, wordpress et al will not
work on many hosts at some day in future.
Not sure if there has been any plans on this issue - i am very much
interested in this and would like know if it is already on the
schedule.
Thanks,
Christian
--- End Message ---
--- Begin Message ---
Thanks Alex. I re-read Ross's reply but I don't think you and him (
and even me ) is saying something different. It's all about validating
the input. In my dictionary of programming vocabulary, validation is
not just validating user input but also sanitizing it.
You summed it up nicely by saying programmer's string vs user's
string. It's the user's string where we want to focus on... If we go
to the source of the problem that is "receiving user input", that's
where we start.
So, every single user input ( not just query-string and form-post data
or cookies but even the server variables such as the *http_referer"
must be considered as potential threats. If we are to store the user
ip based on the server var http_referer value - without
validating/sanitizing it - then we are really risking things! I Aren't
we? So we should not think that hey that's a $_SERVER variable so why
worry about it... I wanted to bring this matter up as a side
parenthesis cause I don't think http_referer would be on many
programmers' list of things to be watched out and to be sanitized!
So first things first, we ned to identify all possible ways that a
user input can take place. and that's not limited to
querystings/form-posts and cookies. Server vars are in my list too,
not all of them but those that have issues with. If you guys can think
of some other types ( like the server variables that one would not
think from the userland ) that I may be missing, I'd appreciate your
filling in here.
Once we know what possible places are out there that a user string can
make it, we apply our function right there and then. So, yes, we need
a library function that does this for us for once and for all. This
library function must deal with data validation (on data length and on
data type ) as its first line of defense.
In that function, we should also do the escape! And that bring us to
the 2nd line of defense.
In this 2nd line of defense, we must take care of the char code
specific issues. And for that it looks like mysql_real_escape_string()
is my only line of defense. That's per this article
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
But it looks like, Alex you'd have a problem with that. Your reply
sounded like that. Correct me if I got you wrong. If I have not
misunderstood you, you have an issue with mysql_real_escape... But
then could you tell me how you would deal with the GPK and GPK like
matters in the light of Shiflett's article?
And after that if the function is still returning OK, then I take that
user input, use it in a PDO based implementation.
Am I missing anything? Feel free to fill it in please so I can close
this chapter and move on.
On Tue, Jan 17, 2012 at 2:56 PM, Alex Nikitin <niks...@gmail.com> wrote:
> Haluk, don't listen to Ross, escaping fails, it was and is a bad
> solution to an old and still largely unresolved problem. The problem
> is and has been that of language interoperability, and we have been
> and continue failing at making a good way for languages to talk to
> each other, but because this is so needed, especially on the web,
> where you blink and you are in another language; php, css, html, throw
> in some javascript, and here is some SQL, oh i need some python, now
> let's throw in some C, but none of these languages talk to each other,
> so we have had to make it work and we do it with strings... This is
> why we have SQL injection and XSS, and the only, i will repeat that,
> the ONLY way to fix this issue is to have a clear way to say from
> language to language that this is a programmer string, run it, and
> this is user input, don't run it.
>
> The only right solution is to pass your code as code and the user
> input as user input, this way you are guaranteed that no execution of
> user input is possible via usual SQL injection or XSS means. Of course
> you still need to check and sanitize your input, there are still
> typical issues, buffer and heap overflows, etc, but simple inclusion
> of some "special" character and user input code that just gets ran
> just like programmer code is simply not possible.
>
> Escaping is a bad and many times failed attempt at saying that it's ok
> to pass user input as code, we just escape the characters we think are
> bad, to tell the interpreter not to execute them as it normally would.
> But what does it mean to be a character? Well back when all these
> languages were designed there was ASCII, and life was easy, now,
> however we have utf7, utf8, utf16, with tens of thousands of
> characters, many of which are the same symbol. Oh and they morph, if
> you don't know what best-fit matching is, look it up, but at the end
> of the day, if you think that you know what characters you need to
> escape, you are wrong, i'm sorry. This is why in javascript there are
> 3 escape functions: escape, escapeURI and escapeURIComponent. Which
> roughly translate to "we failed", "we failed again" and "we failed the
> third time".
>
> So in short, no, mysqli_real_escape_string is not a good solution to
> SQL injection, PDO (as far as i can tell, though i haven't poured over
> the code yet) or prepared statements, are. And neither negate the need
> to check your input, as other, more traditional exploits would still
> be possible (potentially)
>
> Oh Haluk, drop the idea of occurrences of words, it may stop someone
> who is just testing your code for fun, someone determined to get in
> will still do plenty of bad with whatever words you allow, and you
> have to allow certain words for your queries to run ;)
>
> Anyways, hopefully this is something for you guys to think about and
> hopefully enough to stop suggesting escaping as a viable option to
> stop any sort of simple code injection...
>
>
> ~ Alex
>
> --
> The trouble with programmers is that you can never tell what a
> programmer is doing until it’s too late. ~Seymour Cray
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
Hello,
how to correctly validate url? now the special local characters like
ÜÕÖÄ etc are allowed as well...
Br,
Tanel
--- End Message ---
--- Begin Message ---
Sent from a handheld device
On 18-Jan-2012, at 4:05 PM, Tanel Tammik <keevit...@gmail.com> wrote:
> Hello,
>
> how to correctly validate url? now the special local characters like
> ÜÕÖÄ etc are allowed as well...
>
The generic URI syntax mandates that new URI schemes that provide for
the representation of character data in a URI must, in effect,
represent characters from the unreserved set without translation, and
**should convert all other characters to bytes according to UTF-8, and
then percent-encode those values**. This requirement was introduced in
January 2005 with the publication of RFC 3986. URI schemes introduced
before this date are not affected.[1]
[1] http://en.wikipedia.org/wiki/Percent-encoding
> Br,
> Tanel
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
Does anyone have a preg expression to validate the url which includes
these special characters like ÜÕÄÖ included?
Br,
Tanel
18.01.2012 12:21, Mokaddim Akm kirjutas:
Sent from a handheld device
On 18-Jan-2012, at 4:05 PM, Tanel Tammik<keevit...@gmail.com> wrote:
Hello,
how to correctly validate url? now the special local characters like
ÜÕÖÄ etc are allowed as well...
The generic URI syntax mandates that new URI schemes that provide for
the representation of character data in a URI must, in effect,
represent characters from the unreserved set without translation, and
**should convert all other characters to bytes according to UTF-8, and
then percent-encode those values**. This requirement was introduced in
January 2005 with the publication of RFC 3986. URI schemes introduced
before this date are not affected.[1]
[1] http://en.wikipedia.org/wiki/Percent-encoding
Br,
Tanel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
