Hi,
> The problem may be legacy code.
Of course. There is a lot of legacy code that needs to be made secure
('hardened'). The best solution is to use parameterized queries. To
find out what statements are still not doing that, first disable text
literals only. If some places are incorrect, the r
Hi,
> providing a mode in which the server would reject PQexec strings containing
> more than one query.
That wouldn't help a lot. The simple SQL injection is not detected:
ResultSet rs = stat.executeQuery(
"SELECT * FROM USERS WHERE PASSWORD='" + password + "'");
An attacker would only need
Hi,
> > Wouldn't it be much simpler to have a version of the libpq client lib
> > that only understands prepared queries?
That would be possible. However the problem is not 'prepared queries'
versus 'direct queries'. It is possible to use literals in prepared
queries:
PreparedStatement prep =
Hi,
> I fail to see how the backend could distinguish between a query sent by a
> query tool and a query sent by an "application".
The backend could use a different client library (a client library
that doesn't allow literals). But in this case two or three client
libraries are required.
Probab
Hi,
> but can't the developer allow literals again?
Executing the statement SET ALLOW_LITERALS should be restricted. The
application uses another user name / password and doesn't have to
access rights to enable it. Maybe the user name / password is
configured using JNDI, so the application devel
Hi,
> > The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or
> > by an administrator.
> then it solves nothing...
> what if the developer never SET ALLOW_LITERALS NONE
As I have said, the 'ALLOW_LITERALS NONE' mode is enabled by the
developer itself, or by an administrator. T
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.
> (const
Hi,
As you know, "SQL injection" is the main security problem of databases today.
I think I have a solution: 'disabling literals'. Or you may call it
'enforcing the use of parameterized statements'. This means that SQL
statements with embedded user input are rejected at runtime. My
solution goes
On 05.03.2005 00:24 PFC wrote:
> Every time a row is removed from pwd_name, the ON DELETE CASCADE
> trigger will look in pwd_name_rev if there is a row to delete... Does
> it have an index on pwd_name_rev( rev_of ) ? If not you'll get a full
> table scan for every row deleted in pwd_name...
Hi there,
I have a simple database:
CREATE TABLE pwd_description (
id SERIALNOT NULL UNIQUE PRIMARY KEY,
name varchar(50) NOT NULL
);
CREATE TABLE pwd_name (
id SERIALNOT NULL UNIQUE PRIMARY KEY,
description integer NOT NULL REFERENCES pwd_descri
10 matches
Mail list logo
