Fwd: Protection from SQL injection

Hi,

> I think you missed April Fool's Day...

This is absolutely not an April Fool idea :-) I must have made a bad
job explaining my idea.

> This is just silly, as it makes life impossibly painful for users

You mean developers? No, developers should use parameterized queries anyway.

> (constants are hardly a useless part of SQL)

Your are right. But it depends how you define 'constant'. In other
programming languages, constants are not always literals. Instead,
constants are defined like this:

#define ACTIVE 1 // C
final static int ACTIVE=1; // Java

As far as I know, this concept doesn't exist in the SQL. I suggest to
add this concept as well to the database engine:

CREATE CONSTANT [IF NOT EXISTS] newConstantName VALUE expression;
DROP CONSTANT [IF EXISTS] constantName;

Example:

CREATE CONSTANT PI VALUE 3.1415926535;
CREATE CONSTANT ACTIVE VALUE 1;
CREATE CONSTANT INACTIVE VALUE 0;

This also improves the program because you don't need to 'hard code'
numbers in the application:

SELECT * FROM USERS WHERE STATE=ACTIVE AND PASSWORD=?

> it doesn't really plug any holes.

Sure it does.

> As an example:
> select * from tab where intcol = intcol; delete from tab;

How would the application that executed this statement would look like? In Java:

ResultSet rs = stat.executeQuery("select * from tab where " + userInput);

Such a program wouldn't make any sense, right? Do you mean this?

ResultSet rs = stat.executeQuery("select * from tab where state = " +
userInput);

If literals are disabled, the database would reject any number. The
program wouldn't work in the normal case any longer if literals are
disabled. So the developer would have to change it to (otherwise his
application doesn't work) to:

PreparedStatement prep = conn.prepareStatement("select * from tab
where state = ?");
prep.setInt(1, userInput);
...

This is save. There is no way to inject SQL here.

Regards,
Thomas