I hadn't thought about the implicit guarantee -- good point. But it
seems to me that where the spec is silent, developers can implement
however they want. It would not surprise me at all to see
implementations of PreparedStatement backed by a regular Statement.

For example, check the MySQL driver. In the
PreparedStatement.setString() method below, the parameter string is just
copied into storage (escaping certain characters). Later when the query
is assembled, the strings are all just written to the database without
any further checking. Apparently the MySQL database doesn't support
precompiled queries, so this implementation isn't surprising.

Call this noncompliant if you want -- that's arguable. But I'm not
convinced that the use of PreparedStatement alone guarantees anything
regarding SQL injection or piggybacking.

public void setString(int parameterIndex, String x) throws
java.sql.SQLException
{
  // if the passed string is null, then set this column to null

  if (x == null)
  {
   set(parameterIndex, "null");
  }
  else
  {
   StringBuffer B = new StringBuffer(x.length() * 2);
   int i;

   B.append('\'');

   for (i = 0; i < x.length(); ++i)
   {
    char c = x.charAt(i);

    if (c == '\\' || c == '\'' || c == '"')
    {
     B.append((char) '\\');
    }
    B.append(c);
   }

   B.append('\'');
   set(parameterIndex, B.toString());
  }
}

--Jeff

----- Original Message -----
From: "Ben Mord" <benmordearthlink.net>
To: "Jeff Williams" <jeff.williamsaspectsecurity.com>;
<webappsecsecurityfocus.com>; <secprogsecurityfocus.com>
Sent: Wednesday, August 07, 2002 11:24 PM
Subject: Re: SQL Injections and JDBC

> Actually, the JDBC spec implicitly guarantees that you don't have to
escape
> parameters to prepared statements. Look at it the other way - if
certain
> characters had to be escaped, the spec would have to say so. If SQL
injection
> attacks were possible on a JDBC driver when you were using the
prepared
> statement syntax, then I would definitely consider the driver non
compliant
> with the spec. Not to say all drivers are compliant and bug free, of
course.
>
> When just building your own SQL string, however, then the JDBC spec
says that
> you're using SQL syntax, and the SQL spec takes over. And there, you
do have
> to escape certain characters.
>
> In-band signaling - what an evil shortcut. You see it *everywhere*,
and it is
> responsible for more security holes... Data and code must always be
> delineated. It seems like most real-world security attacks can be
viewed as
> an attack on the data/code dichotomy, including XSS, SQL injection,
buffer
> overflows, etc.
>
> Ben

On Wednesday 07 August 2002 08:12 pm, Jeff Williams wrote:
> You can use the JDBC API with ODBC using the JDBC-ODBC Bridge
>
(http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/bridge.doc.html),
> but it's not recommended for production systems. As far as what goes
on
> inside the bowels of a JDBC driver, it's anyone's guess. A
> PreparedStatement could be doing checking on the parameters and
limiting
> the query to a single statement *OR* it could just be plugging the
> parameters blindly into the statement and sending it on to the
database.
> The JDBC spec does not make any guarantees that I can find.
>
> --Jeff
>
>
> Jeff Williams
> Aspect Security, Inc.
> Securing the Last Mile of the Internet
> www.aspectsecurity.com
>
> ----- Original Message -----
> From: "Kevin Spett" <kspettspidynamics.com>
> To: "Ben Mord" <bmordicon-nicholson.com>; "Bob Lee"
> <crazybobcrazybob.org>; <webappsecsecurityfocus.com>;
> <secprogsecurityfocus.com>
> Sent: Wednesday, August 07, 2002 7:48 PM
> Subject: Re: SQL Injections and JDBC
>
> > I've heard this before and am very curious about the use of
>
> prepared
>
> > statements. Are they merely an object-oriented stored procedure
>
> model,
>
> > which could possibly allow client-supplied input to interfere with
>
> syntax,
>
> > or does it really make this impossible? Is there an equivalent for
>
> people
>
> > using ODBC or other APIs?
> >
> >
> > Kevin Spett
> > SPI Dynamics, Inc.
> > http://www.spidynamics.com/
> >
> > (cross-posted to secprog because of programming implications)
> > ----- Original Message -----
> > From: "Ben Mord" <bmordicon-nicholson.com>
> > To: "Bob Lee" <crazybobcrazybob.org>; <webappsecsecurityfocus.com>
> > Sent: Wednesday, August 07, 2002 5:36 PM
> > Subject: RE: SQL Injections and JDBC
> >
> > > Bob,
> > >
> > > There are two ways to use the JDBC API. One way is to piece
together
>
> your
>
> > > own string, including perhaps some user-supplied data, into a
giant
>
> SQL or
>
> > > DML string. This is dangerous, and forces you to do your own
tedious
> > > escaping. If you mess up, then you've got a security hole.
> > >
> > > Or, you can use prepared statements (or stored procedures) and
pass
>
> the
>
> > > user-supplied arguments separately from the SQL or DML. Not only
can
>
> this
>
> > > result in performance gains, but it also delineates data from
> > > query/manipulation language, protecting you from (I think) all sql
> >
> > injection
> >
> > > attacks. (Or am I missing something here?)
> > >
> > > Ben
> > >
> > > -----Original Message-----
> > > From: Bob Lee [mailto:crazybobcrazybob.org]
> > > Sent: Wednesday, August 07, 2002 3:22 PM
> > > To: webappsecsecurityfocus.com
> > > Subject: SQL Injections and JDBC
> > >
> > >
> > > What kind of SQL injections do I need to look out for when using
>
> JDBC?
>
> > > I've tried a couple of exploits that I thought might work, but
they
> >
> > bombed.
> >
> > > For example, I tried modifying a value so that a ';' and another
>
> statement
>
> > > would get tacked on to the end, but I get an SQLException when
there
>
> is
>
> > more
> >
> > > than one statement (using both executeQuery() and
executeUpdate()).
>
> I
>
> > tried
> >
> > > this using Oracle.
> > >
> > > Thanks,
> > > Bob

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]