php-general Digest 20 Dec 2012 15:09:25 -0000 Issue 8070
php-general Digest 20 Dec 2012 15:09:25 - Issue 8070 Topics (messages 319907 through 319907): PHP 5.4.10 and PHP 5.3.20 released! 319907 by: Johannes Schlüter 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 -- ---BeginMessage--- The PHP development team announces the immediate availability of PHP 5.4.10 and PHP 5.3.20. These releases fix about 15 bugs. Please note that the PHP 5.3 series will enter an end of life cycle and receive only critical fixes as of March 2013. All users of PHP are encouraged to upgrade to PHP 5.4. The full list of changes are recorded in the ChangeLog on http://www.php.net/ChangeLog-5.php For source downloads of PHP 5.4.8 and PHP 5.3.18 please visit our downloads page at http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ Stanislav Malyshev Johannes Schlüter PHP 5.4 Release Master PHP 5.3 Release Master ---End Message---
[PHP] PHP 5.4.10 and PHP 5.3.20 released!
The PHP development team announces the immediate availability of PHP 5.4.10 and PHP 5.3.20. These releases fix about 15 bugs. Please note that the PHP 5.3 series will enter an end of life cycle and receive only critical fixes as of March 2013. All users of PHP are encouraged to upgrade to PHP 5.4. The full list of changes are recorded in the ChangeLog on http://www.php.net/ChangeLog-5.php For source downloads of PHP 5.4.8 and PHP 5.3.18 please visit our downloads page at http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ Stanislav Malyshev Johannes Schlüter PHP 5.4 Release Master PHP 5.3 Release Master -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: form validation
On 12/20/2012 10:27 AM, David Mehler wrote: Hello, I just read the Php5 changelog. Legacy features specifically magic quotes were removed, does that mean that any system running php 5.4 or newer does not need to use either addslashes() or stripslashes() when dealing with form input? Thanks. Dave. As I understood it, addslashes was never preferred, nor was magic_quotes=on. Now that magic_quotes is gone, you will have to make sure that you are using some validation/sanitation method on your incoming data. If you are using mysql for a db, then you should already be using mysql_real_escape_string in place of addslashes. The PHP manual has quite a bit on these subjects. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: form validation
On Thu, Dec 20, 2012 at 10:34 AM, Jim Giner jim.gi...@albanyhandball.com wrote: If you are using mysql for a db, then you should already be using mysql_real_escape_string in place of addslashes. Actually, you should start moving toward MySQLi, as mysql_*() is deprecated. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: form validation
On Thu, Dec 20, 2012 at 9:34 AM, Jim Giner jim.gi...@albanyhandball.comwrote: If you are using mysql for a db, then you should already be using mysql_real_escape_string in place of addslashes. You should not be using mysql_real_escape_string going forward as it will be deprecated in php 5.5.0. http://php.net/manual/en/function.mysql-real-escape-string.php. You should be looking to use either mysqli functions or the PDO class.
Re: [PHP] Re: form validation
On 12/20/2012 10:36 AM, Daniel Brown wrote: On Thu, Dec 20, 2012 at 10:34 AM, Jim Giner jim.gi...@albanyhandball.com wrote: If you are using mysql for a db, then you should already be using mysql_real_escape_string in place of addslashes. Actually, you should start moving toward MySQLi, as mysql_*() is deprecated. true dat. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] MySQLi
I read about the subject in another thread. Where does PDO fit? That is what I have used for sometime. Am I good? -- Stephen -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySQLi
On Thu, Dec 20, 2012 at 12:18 PM, Stephen stephe...@rogers.com wrote: I read about the subject in another thread. Where does PDO fit? That is what I have used for sometime. Am I good? Right as rain. PDO is a preferred abstraction layer in PHP and isn't going anywhere anytime soon. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session ?
I've read about passing the session id to a script and using that to opene
up the existing session file. Is this something I could do in this case?
Or am I SOL?
You can pass the session ID and reactivate the session that way,
sure. Not pretty, and it does lead to security considerations, but it
would work.
Hi Daniel,
Your security consideration important for me and I really need to know
what am I missing.
Using your xs(cross-site) request and cookie based authentication with
user-name and password has same level security problems. if you use
tokens they can not reading or using by an other pages. Attacker must
guess a random token(its difficult then guess passwords). if your
browser hacked or your main page has bad js code. This is bigger problem
then using xs request. they can get your password or session id.
I try to clarify my point of view for better discussion,
both servers can use same log-in database or enable to query each other.
after logged-in first.domain or a.first.domain
user has ability to call an other trusted server without password and
user-name.
when hit the page has XS button first.domain server will generate random
key and random value
and send in button code with secure protocol.(before send, you must
check referrer and token for CSRF protection)
detailed client info, secure key and value must store in session
database for later security check.
(you need more 3 columns key value and expire-date)
sample button code in
https://second.domain/need_to_see_without_user_input.php:
//after logged in your-first.domain
echo form
action='https://second.domain/need_to_see_without_user_input.php'
method='post' style='' ;
echo button id='button_1' class='button_1' type='submit'
name='long_random_secure_xs_cookie_name'
value='{$long_random_secure_xs_cookie_value}' style='' ;
echo run script 2 on second.domain ;
echo /button;
echo /form;
clicking that button same as write down password, user name and click
submit. but easier and not less secure then password authentication.
key and value must be long and secure enough (not like unique-id).
second server side:
-check the name and value and expire date IP browser etc.
- if there is any valid session in first server then clear key and value
don't touch server first.domain session data
- create new session on server second.domain width same user.
now same user has different valid session on both servers.
this method looks safe as password and user name authentication
just focus on sending secure key and value to the real client!!!
Of-course some old browsers has security holes
conditions:
-old browsers like Firefox 5
-(not easy but possible; newer browsers with some dangerous add-ons )
-not using tokens every page/form requests (after log-in first.domain)
after logged-in first.domain attacker can use this holes alter the
referrer and can get secure key and value
there is a solution ;they cannot alter post data referrer(if browser not
hacked) if you post back the token you will be quite safe.(check
referrer and token)
I guess this is fit public users who use password authentication.
if you are company user or security guy You must use certificate
authentication with VPN.
There is no absolute security in theory. But we have to discus how will
be improved. Because bad guys already doing that in opposite way.
Thanks,
Hakan Can.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
