|
|
Posted by shimmyshack on 05/03/07 11:45
On May 3, 10:59 am, MIUSS <m...@seznam.cz> wrote:
> shimmyshack napsal:
>
> > On Apr 29, 8:51 pm, MIUSS <m...@seznam.cz> wrote:
> > > Thank you very much, it works!
>
> > > Have a cnice day!
>
> > if you want to use another perhaps more secure method, you could go
> > and try http_auth from pear.
> > heres the class and the "test" directory where the examples are:
> >http://cvs.php.net/viewvc.cgi/pear/Auth_HTTP/
>
> > exmple of basic authentiation using sqlite here:
> >http://cvs.php.net/viewvc.cgi/pear/Auth_HTTP/tests/test_basic_simple....
>
> Hello,
> As you wrote that if I want more secure code, I would ask, do you
> think that the code I recently show up isn't secure enough? I'm
> beginner and I think I better use some code I almost understand than
> some else. The code I use is from some learning book, so I think it
> should be secure... I wonder that it may be unsecure only when I use
> some weak password. But I off-course won't. What exactly in that code
> seems unsecure to you?
>
> Thanks in advance for your repply:-)
well firstly the select statement selects * which might return more
than one row, this doesnt make sense in the context of selecting a
username password pair which should be unique.
username should be unique
so the query is too ambiguous for my taste.
It then uses a LIKE, which again seems ambiguous why use like when a
simple = would do, either the username is given or it is not, no need
to use a LIKE here.
Also the query does not escape $_SERVER['PHP_AUTH_USER'] which means
that a user name with some SQL inside would be injected straight into
the query, if your permissions for the php user on that table allow
altering/dropping then your table could be altered maliciously to
contain a false user and password/dropped
image is the user entered
you should therefore use mysql_real_escape_string on all php5, or take
steps to filter the character set you allow to be present in the
username.
Injection isnt possible into the AUTH_PASSWORD variable here, because
it is md5() so thats OK, however its good practise to escape
everything before it reaches the query, in this case a user could find
the md5 passwords from the table, and then log in as any uesr -
including admin - without the need for an offline dictionary attack.
The type of sql injection allowed here could mean that a few hundred
thousand fake queries could be performed in order to gather every bit
of data in your whole database, let alone the table, everything this
application user has access to on the database.
Navigation:
[Reply to this message]
|