[Tfug] Trusting DBMS results

Paul Lemmons paul at lemmons.name
Sun Nov 2 11:13:50 MST 2008


Bexley Hall wrote:
> Hi,
>
> I'm *heavily* integrating a DBMS into an application.
> I.e., things that I would often "hard code" in the
> application have been moved into the database.
>
> As a matter of principle, I "never trust inputs".
> (regardless of whether they come from users or
> "sensors", etc.)
>
> But, how pedantic should I treat the data that "I"
> (i.e., my application) has placed in the database?
>
> For example, tables that are "written during manufacture"
> (and never altered, in theory, at run time)... should I
> have faith in their sanity?  I.e., should I treat the
> DBMS as a reliable medium?  Or, one that is "suspect"?
>
> Note that I implicitly trust values that I "store" in RAM
> from my computations.  Should the integrity of the DBMS
> be considered on a par with that?  I.e., assume the DBMS
> has mechanisms to detect and repair problems just like
> ECC memory catches alpha particles, etc.
>   

I, like you, validate everything the user gives me. If it is a 
configuration file, I insure that what is given to me is sane. I do very 
little programming where the user has actual real-time input but on the 
occasions that I do I validate the data as completely as possible. For 
simple tasks, the code for validation can often be larger than the 
actual work being done.

Programming is as much philosophical as it is technical; as much art as 
it is science. Any programmer worth his/her salt is asking the same 
questions you are asking and have come to some philosophical conclusion 
on how to proceed. The very fact that it is not always a technical 
answer, though, will cause there to be more than one right answer.

With that said here is *my* "right" answer...

I also use databases fairly extensively in the code that I write. In my 
mind, the database is an extension of the programming code itself. Is it 
possible for a person to alter the database? Possibly. That would show 
some level of sophistication of the person though as well as 
authenticated access. That same person may also use a hex editor and 
patch my compiled code. The code itself can be though of as a database 
containing logic. Access to the program code and the database is also 
restricted to trusted people or programs. So, with that in mind, I treat 
the data that I put into the database the same way I treat the code that 
I put into my program. It is golden. I trust it. Data that comes from 
anywhere else must be validated.

Now with that said, most (all?) of the code I write is not being held to 
a standard that must pass a strict security test. My programs are not so 
interesting as to draw the attention of a hacker. My programs generally 
run within a secured environment which would have to be breached before 
my code could even be executed. Were that not the case, though, I would 
be concerned with the data in the database as well as the code I was 
running. I would use checksums and security keys and encrypted data. 
When paranoia gets to that level you need to be concerned about 
everything and in this I have no experience. Only you can decide where 
on the paranoia scale your program lies.

That is the long answer. The short answer is that I trust the data that 
I put into the database to be valid because to get there it would have 
been validated on the front end.

There is also a saying that I learned a long tome ago. It says "You 
can't make anything foolproof because fools are so ingenious."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3296 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20081102/db28b8b3/attachment-0002.bin>


More information about the tfug mailing list