Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
You guys are missing the point. This isn't a language level issue. I can imagine some sort of package or a library being made, some sort of wrapper around the current session commands, perhaps integrated into some sort of extension. But it is NOT a language level issue. This isn't a problem the language needs to solve, ESPECIALLY since userland implementation is so trivial. The core of the problem is education, not lack of tools by the side of the language. And that's where the focus should be. How do we do it? I don't know. Blog posts? PHP manual? Conferences? Maybe. But I still don't think this is a problem that language should solve. On Sat, Sep 28, 2013 at 1:47 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Leigh, On Fri, Sep 27, 2013 at 7:12 PM, Leigh lei...@gmail.com wrote: So on a successful session hijack (correct SID, new IP) the attacker gets a new SID and keeps the valid session while the legitimate user gets kicked out. Not seeing how that improves things at all. There are 2 improvements 1. Generally speaking, more frequent session ID regeneration is more security. 2. Detection/indication of attacks is good for security. Showing active sessions and possible intrusion/source of intrusion is applications task, but session ID regeneration upon IP change is easy and simple task for session module. Why not have it as optional feature? It would be better than nothing if end user has chance to know the attack. IMHO. Many systems have notification mail when password or important information have changed. Damage has already done if it is an attack, but user could know there were attack. Session ID regeneration is the same kind of counter measure. If app supports number of active sessions, user could verify if they are under session hijack attack or not. It's up to app, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On 28 September 2013 11:27, Madara Uchiha mad...@tchizik.com wrote: You guys are missing the point. This isn't a language level issue. I can imagine some sort of package or a library being made, some sort of wrapper around the current session commands, perhaps integrated into some sort of extension. But it is NOT a language level issue. This isn't a problem the language needs to solve, ESPECIALLY since userland implementation is so trivial. I would disagree. PHP has very low security levels by default and some WTF security issues because of default settings. It should be the other way round: high security by default that you need to actively change if you want it lowered. The problem is that the majority of PHP developers for better or worse think they can copypaste solutions to problems and forget about things after that as long as the output on their screens look ok. For many developers, security is an afterthought if even that. And you are, quite simply, NOT GOING TO CHANGE THAT IN THE FORESEEABLE FUTURE. It's not a question of whether you're right or wrong in principle - it's a simple question of statistics. You will have close to zero impact on the PHP developers, no matter how many blog articles you write. It is too large and too diverse a group. So you're stuck with two choices: accept that PHP security is lax and that as a result a lot of code will have many attack vectors, or try to change the language itself for the better. The third option of educate is a mirage. Note: I'm not saying this feature would be an overall benefit for the security of PHP, but the reasoning behind it is right. Regards Peter -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] Gnu/Hurd support
On Fri, Sep 27, 2013 at 3:02 PM, Derick Rethans der...@php.net wrote: On Thu, 26 Sep 2013, Lior Kaplan wrote: Hi, In Debian we build PHP for GNU/Hurd system, which need some minor fixes available here: http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/patches/116-posixness_fix.patch 46 --- php5.orig/main/php.h 47 +++ php5/main/php.h 48 @@ -244,6 +244,10 @@ END_EXTERN_C() 49 /* macros */ 50 #define STR_PRINT(str) ((str)?(str):) 51 52 +#ifndef PATH_MAX 53 +#define PATH_MAX 4096 54 +#endif 55 + 56 #ifndef MAXPATHLEN 57 # ifdef PATH_MAX 58 # define MAXPATHLEN PATH_MAX That looks wrong. You're unconditionally defining PATH_MAX, but there is logic in line 57 that deals with this too... That whole section is about defining MAXPATHLEN, not PATH_MAX. Kaplan
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Sep 28, 2013 10:39 AM, Peter Lind peter.e.l...@gmail.com wrote: So you're stuck with two choices: accept that PHP security is lax and that as a result a lot of code will have many attack vectors, or try to change the language itself for the better. The third option of educate is a mirage. PHP provides you with all the tools you need to write secure apps. I could go around writing mysql_query($_REQUEST[blah]) but I don't. Why? Because I have been educated. We don't have restrictions in the core that prevent me from doing it, and we don't need them either. I agree with you, being secure by default is a worthy objective, but the proposal here shouldn't even be on by default. (remember not everyone is able to control their ini settings and whatnot) Education is not a mirage. People picked up their insecure coding habits from somewhere, and if its from laziness then I don't think they really deserve protecting. If it was from a terrible blog article promoting insecure practices then we need better articles. There's not much we can do to remove the content that's already out there, but there's a lot we can do with providing new, up to date and accurate content.
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On 28 September 2013 12:25, Leigh lei...@gmail.com wrote: On Sep 28, 2013 10:39 AM, Peter Lind peter.e.l...@gmail.com wrote: So you're stuck with two choices: accept that PHP security is lax and that as a result a lot of code will have many attack vectors, or try to change the language itself for the better. The third option of educate is a mirage. PHP provides you with all the tools you need to write secure apps. I could go around writing mysql_query($_REQUEST[blah]) but I don't. Why? Because I have been educated. We don't have restrictions in the core that prevent me from doing it, and we don't need them either. Care to back that up with an argument? I agree with you, being secure by default is a worthy objective, but the proposal here shouldn't even be on by default. (remember not everyone is able to control their ini settings and whatnot) Worthy objective? You just stated your opinion that you don't want default protection in the core language. Which is it? Education is not a mirage. People picked up their insecure coding habits from somewhere, and if its from laziness then I don't think they really deserve protecting. If it was from a terrible blog article promoting insecure practices then we need better articles. There's not much we can do to remove the content that's already out there, but there's a lot we can do with providing new, up to date and accurate content. How many years have PHP been around? For how long have we been trying to educate people to avoid mysql_* functions? Has it worked? No. You can educate a fair amount of people but when you have the userbase of PHP it's downright stupid to think you'll get the majority on board. Also, saying that people deserve what they get because they're not educated developers, is being arrogant. -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] Gnu/Hurd support
On Sat, 28 Sep 2013, Lior Kaplan wrote: On Fri, Sep 27, 2013 at 3:02 PM, Derick Rethans der...@php.net wrote: On Thu, 26 Sep 2013, Lior Kaplan wrote: Hi, In Debian we build PHP for GNU/Hurd system, which need some minor fixes available here: http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/patches/116-posixness_fix.patch 46 --- php5.orig/main/php.h 47 +++ php5/main/php.h 48 @@ -244,6 +244,10 @@ END_EXTERN_C() 49 /* macros */ 50 #define STR_PRINT(str) ((str)?(str):) 51 52 +#ifndef PATH_MAX 53 +#define PATH_MAX 4096 54 +#endif 55 + 56 #ifndef MAXPATHLEN 57 # ifdef PATH_MAX 58 # define MAXPATHLEN PATH_MAX That looks wrong. You're unconditionally defining PATH_MAX, but there is logic in line 57 that deals with this too... That whole section is about defining MAXPATHLEN, not PATH_MAX. Sure it is, but currently that code reads: #ifndef MAXPATHLEN # ifdef PATH_MAX # define MAXPATHLEN PATH_MAX # elif defined(MAX_PATH) # define MAXPATHLEN MAX_PATH # else # define MAXPATHLEN 256/* Should be safe for any weird systems that do not … # endif #endif With your change, PATH_MAX is *always* defined, so the fallback to defined(MAX_PATH) - which is probably valid on some other platform - is no longer used. These lines were added by Ilia: cd82349b (Ilia Alshanetsky 2005-12-20 14:24:24 + 250) # elif defined(MAX_PATH) cd82349b (Ilia Alshanetsky 2005-12-20 14:24:24 + 251) # define MAXPATHLEN MAX_PATH With as comment: commit cd82349b9e51c6986ede11f482f727e12717a6f5 Author: Ilia Alshanetsky il...@php.net Date: Tue Dec 20 14:24:24 2005 + Fixed bug #31347 (is_dir and is_file (incorrectly) return true for any string greater then 255 characters). And bug 31347 is that was a fix for a specific issue on Windows: https://bugs.php.net/bug.php?id=31347 cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Gnu/Hurd support
On Sat, Sep 28, 2013 at 12:57 PM, Derick Rethans der...@php.net wrote: And bug 31347 is that was a fix for a specific issue on Windows: https://bugs.php.net/bug.php?id=31347 The patch originates in Debian, and I can assure you that they don't build for Windows (: So that's a good point, thanks. We could probably test for ZEND_WIN32, or at least that's what I see at ext/opcache/ZendAccelerator.h which just got a similar patch for GNU/Hurd support (commit f90483001236c863abe1070d05ee2214db5a0a97). If that sounds OK, I'll try to do the change (although I'm not a developer). Kaplan
[PHP-DEV] Remove requirement to escape delimiters in regular expression in PCRE functions
Hi, Someone pointed out to me recently that since the delimiters are not a requirement of PCRE, and thus should not be considered a part of the regular expression, there really is no need to escape them inside of the regular expression such as that provided to preg_match functions and similar. I propose removing this requirement by seeking out the delimiter from the end of the regex string (ignoring modifiers) and working backwards to find the closing delimiter. Currently the implementation seeks out the closing modifiers by iterating through the entire regex string from start to end (thus requiring us to escape the delimiter inside the expression). The change introduces no BC breakage as far as I can tell and offers a number of advantages. 1) Regular expressions supplied to preg_match functions become portable across PCRE implementations since escaping the delimiter inside of the regular expression really isn't required. (i.e. it may work from PHP to Perl, but may not work from Perl to PHP). This makes things a lot easier to port between PHP and other PCRE implementations. 2) The regular expression is easier to read by a human if we remove the requirement to escape delimiters. 3) It becomes clearer that the delimiters are not a part of the regular expression both in the implementation and from userspace code. It's not a big change so I propose merging into 5.5 or 5.4 up into 5.5. Thoughts, objections, etc?
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
... ESPECIALLY since userland implementation is so trivial. Trivial for most users means copy-paste an unmaintained class library you found somewhere so you haven't solved the problem. Unless something comes from one of the few trusted security extensions or from a top framework, it's doubtful it'll be thoroughly reviewed and/or correctly implemented. I think security measures belong in the preprocessor if possible. If they are known to be useful, yet rejected only because they're trivial -- despite not being commonly available to the majority of PHP developers -- you are failing the community. On the other hand, if they are known to be useful, yet rejected because they're complex, requiring too many config options, new classes/functions, core documentation, AND user education to write companion logic in userland then I think that's better reasoning. And that's *clearly* the case here. This is not a simple implementation; it requires flexible control from userland and some delicate app logic to interact with the user, and the language can't do the last part AFAICS. As sketched out so far, it is outright harmful. I could publish a post now about the vulnerability it creates, where sniffing a session allows you to force an elevated login, from which you can sniff credentials. (Maybe my first vuln note was tl;dr but please consider this.) The core of the problem is education, not lack of tools by the side of the language. And that's where the focus should be. How do we do it? I don't know. Blog posts? PHP manual? Conferences? Maybe. The first round of objections showed that senior developers *on Internals* didn't understand how PHP session regeneration works! How do you solve that? If the language offered features like this in the first place, PHP users would have known about for years. The fact that it wasn't grokked here reveals that no matter how trivial' it seems, most people aren't doing it (as yohgaki noted) and not because they understand the consequences, they just don't get it at all. Again, if it were simple to implement and didn't have unintended security consequences of its own, the fact that the sharpest users don't totally get it would *prove* that it should be left to the internals team. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
