php-general Digest 21 Dec 2012 06:52:34 -0000 Issue 8071
Topics (messages 319908 through 319915):
form validation
319908 by: David Mehler
319909 by: Jim Giner
319910 by: Daniel Brown
319911 by: Jonathan Sundquist
319912 by: Jim Giner
MySQLi
319913 by: Stephen
319914 by: Daniel Brown
Re: Session ?
319915 by: Hakan Can
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 ---
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.
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
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/
--- End Message ---
--- Begin Message ---
On Thu, Dec 20, 2012 at 9: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.
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.
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
I read about the subject in another thread.
Where does PDO fit?
That is what I have used for sometime. Am I good?
--
Stephen
--- End Message ---
--- Begin Message ---
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/
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
