Professional Web Applications Themes

Is this a security issue - MySQL

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("INCLUDED")) include "include.php3"; $sql = mysql_query("select * from registrants where Account_Username='$username' AND Account_Password='$password'"); if (mysql_num_rows($sql) == 0) { include "registrationphp.html"; } else { include "upcomingregister.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 ...

  1. #1

    Default Is this a security issue

    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("INCLUDED"))
    include "include.php3";

    $sql = mysql_query("select * from registrants where Account_Username='$username' AND Account_Password='$password'");
    if (mysql_num_rows($sql) == 0) {
    include "registrationphp.html";
    } else {
    include "upcomingregister.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

    Ignoramus20689 Guest

  2. #2

    Default Re: Is this a security issue

    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_escape_string
    ([url]http://www.php.net/manual/en/function.mysql-real-escape-string.php[/url]) 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.
    Bill Karwin Guest

  3. #3

    Default Re: Is this a security issue

    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("INCLUDED"))
    > include "include.php3";
    >
    > $sql = mysql_query("select * from registrants where Account_Username='$username' AND Account_Password='$password'");
    > if (mysql_num_rows($sql) == 0) {
    > include "registrationphp.html";
    > } else {
    > include "upcomingregister.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_globals 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.
    [email]jstucklexattglobal.net[/email]
    ==================
    Jerry Stuckle Guest

  4. #4

    Default Re: Is this a security issue

    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_globals 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().

    Chung Leong Guest

  5. #5

    Default Re: Is this a security issue

    On Tue, 22 Aug 2006 11:56:19 -0400, Jerry Stuckle <jstucklexattglobal.net> wrote:
    > 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("INCLUDED"))
    >> include "include.php3";
    >>
    >> $sql = mysql_query("select * from registrants where Account_Username='$username' AND Account_Password='$password'");
    >> if (mysql_num_rows($sql) == 0) {
    >> include "registrationphp.html";
    >> } else {
    >> include "upcomingregister.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_globals 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 Guest

  6. #6

    Default Re: Is this a security issue

    On Tue, 22 Aug 2006 08:50:44 -0700, Bill Karwin <billkarwin.com> 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.
    >
    > Possibly, unless $username and $password have been filtered already
    > using mysql_real_escape_string
    > ([url]http://www.php.net/manual/en/function.mysql-real-escape-string.php[/url]) 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 [url]http://,[/url] not [url]https://.[/url]
    > 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 misconfiguration. 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

    Ignoramus20689 Guest

  7. #7

    Default Re: Is this a security issue

    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.
    Bill Karwin Guest

  8. #8

    Default Re: Is this a security issue

    Jerry Stuckle wrote:
    > Or, they could be running with register_globals being on and doing no
    > validation, in which case this would be a serious security hole.
    If you assume that register_globals is on, then why not assume that
    magic_quotes_gpc is on too?

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

    Toby Inkster Guest

  9. #9

    Default Re: Is this a security issue

    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 ~ [url]http://tobyinkster.co.uk/contact[/url]

    Toby Inkster Guest

  10. #10

    Default Re: Is this a security issue


    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_globals 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)

    Richard Levasseur Guest

Similar Threads

  1. Odd security issue
    By Vanadael in forum Macromedia Contribute Connection Administrtion
    Replies: 0
    Last Post: April 30th, 05:51 PM
  2. Offline Security Issue!
    By Fred Plaisted in forum Macromedia Flash Player
    Replies: 0
    Last Post: December 1st, 04:50 PM
  3. Major ASP.Net Security Issue?
    By Keith in forum ASP.NET Security
    Replies: 2
    Last Post: February 1st, 10:33 AM
  4. ASPState Bug/Security issue
    By Brian Gambs in forum ASP.NET Security
    Replies: 5
    Last Post: August 4th, 07:08 PM
  5. New security issue
    By Dale McMurtrey in forum Windows Setup, Administration & Security
    Replies: 1
    Last Post: July 22nd, 03:45 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139