On Monday 06 December 2004 12:31, you wrote:Derek Fountain <[EMAIL PROTECTED]> writes: > If another SQL Injection vulnerability turns up (which it might, given > the state of the website code),
You will never see another SQL injection vulnerability if you simply switch to always using prepared queries and placeholders.
<much wisdom snipped>
Indeed, but I'm still interested in the general answer. The server I have been looking at was hopelessly insecure and SQL injection is only one of its problems. There were several other ways in! Assume, for example, an attacker can write his own script directly into the website document tree. In this case prepared queries don't help protect what's in the database. The attacker can use them himself if he likes!
I don't quite see how encrypted storage of data can solve your problem. Somehow the web application must be able to unlock/decrypt the data. Either on a per session level, or by passing in a key with every query. Giving out the encrypt/decrypt keys to the end users, so that they have to supply them at login time, is probably as secure as putting them in cleartext onto the homepage. So they must be stored readable somewhere by the middleware system.
It does obscure the data a little more. At the same time it might give the Web application developer a completely false feeling of security.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
