[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