#115 SQL Injection vulnerability

BASE
closed-fixed
Kevin Johnson
Database (41)
9
2005-10-28
2005-10-26
Remco
No

base_qry_common.php at line 614, sig[1] is not properly
sanatized. This leads to execution of the sql in sig[1] at
base_qry_sqlcalls.php at line 39.

Discussion

  • Kevin Johnson
    Kevin Johnson
    2005-10-26

    Logged In: YES
    user_id=836228

    This is clearly documented in the README file and has been
    since before BASE was forked from ACID. We are looking into
    how to fix it without rewriting the application, since 2.x
    is being worked on currently and will fix this. As soon as
    a patch is available, we will release it.

    Kevin

     
  • Kevin Johnson
    Kevin Johnson
    2005-10-26

    • status: open --> open-accepted
     
  • Kevin Johnson
    Kevin Johnson
    2005-10-26

    • status: open-accepted --> open
     
  • Kevin Johnson
    Kevin Johnson
    2005-10-26

    Logged In: YES
    user_id=836228

    I am trying to reproduce your report and can't. Could you
    please contact me directly to figure out what needs to be
    done? My email address is kjohnson@secureideas.net

    Thanks
    Kevin

     
  • Kevin Johnson
    Kevin Johnson
    2005-10-28

    • status: open --> closed
     
  • Kevin Johnson
    Kevin Johnson
    2005-10-28

    • priority: 5 --> 9
    • labels: 615361 --> Database
    • assigned_to: nobody --> secureideas
    • status: closed --> closed-fixed
     
  • Kevin Johnson
    Kevin Johnson
    2005-10-28

    Logged In: YES
    user_id=836228

    Hi-

    We have gotten more information on the bug and I believe
    that the code I
    just checked into CVS fixes the problem without breaking
    anything else.
    (I hope<grin>) If everyone can either check out the code
    or apply the
    change I will describe below to their current install and
    run through
    some tests, we can make sure that nothing else is broken by
    this change.
    I would like to get this fix out as soon as possible, so
    please let me
    know the results of your individual tests.

    The change I did was to add the line:

    $sql = eregi_replace(";", " [Possible SQL Injection
    Attack] ", $sql);

    This becomes line 202 in includes/base_db.inc.php. What
    this does is
    replace any semicolons with the " [Possible SQL Injection
    Attack] "
    which will break any sql injection. If you have the SQL
    trace turned on
    in your base_conf.php, you will be able to see the message
    in the log.
    I do not see any where in the code where we execute multiple
    SQL queries
    which is when the semicolon is required, so this should not
    break
    anything.

    Thanks everyone for their testing,
    Kevin