Re: Scripting Languages and Secure Coding + code

[ck () kuckuk com]

You should also get rid of the habbit of using "select * from"
statements. There are several reasons for this:
[Maintenance:]
(1) The order of the result columns is unpredictable. (This won't hit
you when you develop the code but later on when you switch to another
database or somebody cleans us your database schema and reorders
columns)
(2) Somebody might add columns to this table in the future and break
your code
[Speed:]
(3) Communicating with the database is expensive (network traffic). So
why should you ask for all available columns to be transfered to you,
and then just throw them away?
(4) Reading data from the datafiles is expensive for the server. So
the less data your server has to read in order to compute the result
of the query, the better.
(5) Locks: For each datum the database needs in order to compute the
result of your query, it needs to acquire a read lock (on the table,
the column, the row, whatever the lock granularity of your database).
If some other user wants to execute an update or delete statement in
his transaction against the same datum, your lock will block him from
performing his transaction.
[Semantics:]
(6) You are actually just interested in the fact if a row of data that
fulfills your criteria exists. A query like "select count()" would be
fully sufficient.
[Security]
(7) In order to defeat SQL injection you should study the database
API you have available and see if you can use "Prepared Statements"
with placeholders. In this way you don't have to concatenate strings
in order to get at your desired query but you would send the query
template and the parameters to the database separately giving your
hackers little opportunity to inject whole statements into your own
statement.