Re: SQL Injection with JDBC

On Fri, 26 Dec 2008 04:34:42 +0800, Lew wrote
(in article <gj0qp2$csq$1@xxxxxxxxxxxxxxxxx>):

steve wrote:
the best way is NOT do do this from java [sic], but instead put the SQL IN
THE
DATABASE, where it belongs.

That is not a universally-accepted principle.

Neither is taking a holiday on a Sunday.
If the business logic is not in the database then data integrity cannot be
protected, but instead is an the mercy of every noob with a spreadsheet
application and an ODBC driver + pw.


then call out of java [sic] to a function , that returns the data.

The advantage is :

1.that you can update the code in the database, without having to roll out
new applications

Valid for data routines, not true for business logic.

Sorry that is not correct.

2. It is WAY more secure.

Certain aspects of it may be somewhat more secure, but there is plenty of
security in the Java-coded way, too, if done correctly.

3. you pass in values, not SQL.

How is that an advantage?


if you don't know you should not be replying, but for you , "Sql injection"
which wash the whole point of the discussion., by passing in SQL the data
stream can be intercepted and the SQL statement can be modified.
By passing in values or references the SQL is still completely under the
control of the database.

4. you can re-use the functions etc, either in java [sic], pl/sql, or any
other
language you care to mention, so when you stop using java [sic] you have
WAY less
work to do.

Disadvantage: you have centralized all your business logic in the database,
and must grow that single point of access as new logic accretes in the
system.

not a disadvantage, it brings central control to the data repository.
Anyone who thinks they can control the integrity of the database via a
2nd or 3rd tier application is dreaming, when you consider a database can be
accessed by any number of tools NOT related to your beloved application.

Putting the logic in middleware supports scalability and flexibility of
adding
or modifying features.

so does the database, but with added control over the flexibility, once you
take "processing bandwidth" for critical functionality and palm it off on
clients, you open up a path for subversion of the system.

A substantial system written in Java is very unlikely to be rewritten in a
different language.

Sorry that is complete nonsense, it is already happening, please refer to the
web for a significant number of companies that offer this as a service.
A computer language is generally NOT for the life of any business.


If it were, translation of SQL statements would be very little work in
proportion, since the SQL would not change.

not correct, we are talking about dynamic SQL, and potential injection.

5. The Oracle optimiser can pin in the frequently needed routines and
precompile for speed.
...
This is WAY MORE SECURE!!!!, since you do not have to allow the user the
ability to execute raw SQL, but rather execute certain restricted
packages.
Then you set a users rights to the packages which are black boxes, it makes

injection very difficult, since you are using bind variables.

Shouting and excessive use of exclamation points do not substantiate an
argument.

There is nothing wrong with using PreparedStatements in Java code, and there
are a number of arguments against using stored procedures for business logic.

Data logic belongs in the database, but not business logic. Building
queries in Java is more suitable when there are a number of apps using the
same database but with different query needs.
did I say there was anything wrong with prepared statements?, they have their
place , indeed does not the example code use a prepared statement?

You indeed attempt to make some points about " substantiate an argument"
But you do not actually do that, instead you just repeat hearsay and spew
verbage without either example code or references to your points.
Just because some other people stick business logic in the other tiers,
does not make it database law.

Please substantiate your comments with example code , using sql and a
prepared statement, in line with the posters question ,and we will see if
your code can be subverted,







.

Relevant Pages

  • Fixed
    ... I also found this article that gives the proper way to move system dbs in sql 2008: ... The model exists where the master states it exists. ... This is the error log prior to detaching the model database. ...
    (microsoft.public.sqlserver.server)
  • Re: CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to
    ... Go to the Database tab and click on the browse button next to the connection string. ... In the New Database Reference dialog, enter the details for the database where you want to deploy the assembly and create the user defined aggregate. ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to meth
    ... Now register the assembly and the aggregate in the SQL Server database you want ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... But SQL does not have a pointer data type or the ... > being told to design a database. ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: DBMS and lisp, etc.
    ... Naively implemented with SQL, again for 10 ... (1 query for the initial orders, 1 query for each order for its ... soon as you upgrade to the SQL database. ... (eq (order-customer orderA) ...
    (comp.lang.lisp)