Is this a security issue

[Ignoramus20689]

While trying to signon at a website, I got the following PHP code
back. I suppose that their apache was mistakenly returning php text
instead of executing it.

<?php
if (!defined("INCL UDED"))
include "include.ph p3";

$sql = mysql_query("se lect * from registrants where Account_Usernam e='$username' AND Account_Passwor d='$password'") ;
if (@mysql_num_row s($sql) == 0) {
include "registrationph p.html";
} else {
include "upcomingregist er.php3";
}

?>

I am not a PHP expert (I do mod_perl), but it would seem that this
code is likely to be a good candidate for SQL injection attack. Is
that the case? If so, I would write to them.

Fo instance, I could supply a password between >>and <<<:

>>>' or 1=1 or a = 'a<<<

and sign on as any known to me username (these are not hard to find
out, this is an auctioneer who displays high bidder id)

i

[Jerry Stuckle]

Ignoramus20689 wrote:

While trying to signon at a website, I got the following PHP code
back. I suppose that their apache was mistakenly returning php text
instead of executing it.

<?php
if (!defined("INCL UDED"))
include "include.ph p3";

$sql = mysql_query("se lect * from registrants where Account_Usernam e='$username' AND Account_Passwor d='$password'") ;
if (@mysql_num_row s($sql) == 0) {
include "registrationph p.html";
} else {
include "upcomingregist er.php3";
}

?>

I am not a PHP expert (I do mod_perl), but it would seem that this
code is likely to be a good candidate for SQL injection attack. Is
that the case? If so, I would write to them.

Fo instance, I could supply a password between >>and <<<:

>>>>' or 1=1 or a = 'a<<<

and sign on as any known to me username (these are not hard to find
out, this is an auctioneer who displays high bidder id)

i

It depends on what validation they've done on the userid and password.
There may be some in the included file, for instance.

Or, they could be running with register_global s being on and doing no
validation, in which case this would be a serious security hole.

But the code's not being executed anyway, which means they have other
problems, also :-)

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Bill Karwin]

Ignoramus20689 wrote:

I am not a PHP expert (I do mod_perl), but it would seem that this
code is likely to be a good candidate for SQL injection attack.

Possibly, unless $username and $password have been filtered already
using mysql_real_esca pe_string
(http://www.php.net/manual/en/functio...ape-string.php) or
something like it. We don't see the code (presumably in include.php3)
that gets these values.

I'd also be worried because it looks like they are storing passwords in
clear text. They should store a hash of the password and compare the
hash of what the user enters to what's stored in the database.

Also, are they forcing this page to connect via HTTPS? Otherwise,
passwords are being sent over the net in clear text.

To say nothing of the fact that they have allowed PHP code to be
returned to the browser.

Regards,
Bill K.

[Chung Leong]

Ignoramus20689 wrote:

I am not a PHP expert (I do mod_perl), but it would seem that this
code is likely to be a good candidate for SQL injection attack. Is
that the case? If so, I would write to them.

That's a definitely a SQL injection vulnerability, as the code is
written for PHP3, where there is no register_global s option (i.e. it's
always on). Whether it can be exploited is another matter. I don't
think you can execute multiple statement through mysql_query().

[Ignoramus20689]

On Tue, 22 Aug 2006 11:56:19 -0400, Jerry Stuckle <js*******@attg lobal.netwrote:

Ignoramus20689 wrote:

>While trying to signon at a website, I got the following PHP code
back. I suppose that their apache was mistakenly returning php text
instead of executing it.

<?php
if (!defined("INCL UDED"))
include "include.ph p3";

$sql = mysql_query("se lect * from registrants where Account_Usernam e='$username' AND Account_Passwor d='$password'") ;
if (@mysql_num_row s($sql) == 0) {
include "registrationph p.html";
} else {
include "upcomingregist er.php3";
}

?>

I am not a PHP expert (I do mod_perl), but it would seem that this
code is likely to be a good candidate for SQL injection attack. Is
that the case? If so, I would write to them.

Fo instance, I could supply a password between >>and <<<:

>>>>>' or 1=1 or a = 'a<<<

and sign on as any known to me username (these are not hard to find
out, this is an auctioneer who displays high bidder id)

i

It depends on what validation they've done on the userid and password.
There may be some in the included file, for instance.

true

Or, they could be running with register_global s being on and doing no
validation, in which case this would be a serious security hole.

I do not know what typically may be in that include file, but I have a
feeling that possibly they simply sump the form contents into
variables.

But the code's not being executed anyway, which means they have other
problems, also :-)

Yeah. :")

[Ignoramus20689]

On Tue, 22 Aug 2006 08:50:44 -0700, Bill Karwin <bi**@karwin.co mwrote:

Ignoramus20689 wrote:

>I am not a PHP expert (I do mod_perl), but it would seem that this
code is likely to be a good candidate for SQL injection attack.

Possibly, unless $username and $password have been filtered already
using mysql_real_esca pe_string
(http://www.php.net/manual/en/functio...ape-string.php) or
something like it. We don't see the code (presumably in include.php3)
that gets these values.

I'd also be worried because it looks like they are storing passwords in
clear text. They should store a hash of the password and compare the
hash of what the user enters to what's stored in the database.

Also true. Possibly useful for "I lost my password" situations though,
though there are better ways to handle that.

Also, are they forcing this page to connect via HTTPS? Otherwise,
passwords are being sent over the net in clear text.

That is in fact true, the protocol is http://, not https://.

To say nothing of the fact that they have allowed PHP code to be
returned to the browser.

That, I think, is just some stupid misconfiguratio n. The other two
issues are those of design.

I hope that my post is not wrongly misinterpreted as an attack on php,
as same mistakes are done with perl as well. (though use of
pre-prepared statements could help in the case of perl, but dumb
programmers would not be likely to use that feature).

I am not sure if I should bother writing to them. It is an auction
house doing industrial liquidations.

i

[Bill Karwin]

Ignoramus20689 wrote:

>I'd also be worried because it looks like they are storing passwords in
clear text. They should store a hash of the password and compare the
hash of what the user enters to what's stored in the database.

Also true. Possibly useful for "I lost my password" situations though,
though there are better ways to handle that.

Right; the better way is to reset the password to something new and
random if a user forgets it. That way one doesn't need to keep it
stored in clear text.

I hope that my post is not wrongly misinterpreted as an attack on php,
as same mistakes are done with perl as well.

Yes, and any other language too! That includes Java, and Ruby, so
zealots of those languages need not respond claiming that their language
solves everything! ;-)

(though use of
pre-prepared statements could help in the case of perl, but dumb
programmers would not be likely to use that feature).

PHP4's mysql interface does not support prepared statements. PHP5
supports prepared statements through the new mysqli interface. So it's
not necessarily that the programmers are dumb. They may be constrained
to use PHP4. Many hosting providers do not support a PHP5 environment.

For the benefit of readers who aren't familiar with prepared statements
-- these allow you to send values to the SQL query via parameters,
instead of interpolating them into the SQL statement string. Using
statement parameters in this way reduces vulnerability to SQL injection.

And to Chung Leong: right, PHP5's mysqli supports executing multiple
statements, while the older mysqli interface does not.

Anyway, whether to email the people who run the site... tough call. It
could fall into the category of "who asked you?" but on the other hand,
spreading awareness of web security is a good thing. You could tell
them they've lost a potential customer -- you aren't going to use their
service because it's obviously not trustworthy!

Regards,
Bill K.

[Toby Inkster]

Jerry Stuckle wrote:

Or, they could be running with register_global s being on and doing no
validation, in which case this would be a serious security hole.

If you assume that register_global s is on, then why not assume that
magic_quotes_gp c is on too?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Toby Inkster]

Ignoramus20689 wrote:

I hope that my post is not wrongly misinterpreted as an attack on php,
as same mistakes are done with perl as well. (though use of
pre-prepared statements could help in the case of perl, but dumb
programmers would not be likely to use that feature).

PHP does support prepared statements, but not in the MySQL module. It's in
the "mysqli" (MySQL Improved) module, PostgreSQL, and a handful of other
database modules though.

Also, the PDO module (Portable Data Objects -- think DBI for PHP) supports
prepared statements, and even emulates them for databases that don't
natively support them.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Richard Levasseur]

Chung Leong wrote:

Ignoramus20689 wrote:

I am not a PHP expert (I do mod_perl), but it would seem that this
code is likely to be a good candidate for SQL injection attack. Is
that the case? If so, I would write to them.

That's a definitely a SQL injection vulnerability, as the code is
written for PHP3, where there is no register_global s option (i.e. it's
always on). Whether it can be exploited is another matter. I don't
think you can execute multiple statement through mysql_query().

IIRC, you can in some obscure way, but I forget. I think it was later
fixed in later release of mysql.

With the code, though, you could easily make the password line be
password='' or '1'='1', thus being able to log in as anyone (a parent
post pointed this out as well)