[Javascript] action="insert"

[dlovering at gazos.com]

I might mention that most businesses require as part of their security policy
for database front-end interfaces a "three-tier validation", namely

(a) validating the data as it is entered, or immediately after it is entered
using client-side tools (Javascript and Java are among the most common 
choices)
(b) validation of the data aggregation BEFORE sending it on to the server
(c) validating the data as it is received at the server, and before it 
is stored
or acted upon

If you can't demonstrate each of the three tiers in action, your work 
often gets
the boot.

Also, no matter how much confidence you have your applications are unreachable
from the internet, DON'T YOU BELIEVE IT!  I've seen hacks that jumped from the
internet onto a DMZ, into a printer, back down a hole in the firewall for the
DMZ to facilitate DNS, into a VLAN, out another firewall, and into a "secured"
network segment which (and I quote the firewall guy) "... cannot be reached
from the internet".  It took down a major banking system and a checking DB
server.

-- Dave Lovering






Quoting Paul Novitski <paul at novitskisoftware.com>:

> At 08:43 AM 2/10/2006, Shawn Milo wrote:
>> Extremely valid points. However, my applications are not accessible 
>> from the Internet, and the users are very small in number and need 
>> the application to do their jobs day-to-day. Also, the most likely 
>> outcome of invalid data is an error message when they submit the 
>> page because a database INSERT or UPDATE command fails due to 
>> invalid data.
>
> Ouch!  Shawn, it sounds like you're feeding unvalidated user input 
> directly to a database query.  Can you really assume that an 
> uncontrolled query will abort with an error message and not overwrite 
> existing data or select data you thought was private?  Let's hope one 
> of your intranet users doesn't bring their teenager to the office 
> some evening and leave them in front of a terminal for half an hour.
>
> Write this on your blackboard fifty times:
> Step 1: Build basic data validation & functionality server-side.
> Step 2: Add user enhancements client-side.
>
>
>> Obviously, the right thing for me to do is use the methods you 
>> espouse, not only from a security standpoint but also from a simple 
>> compatibility standpoint; the closer the web app looks to boring 
>> HTML, the better it is for most browsers.
>>
>> I guess I'm spoiled in my sandbox.
>
> I don't think anyone here is suggesting that you scrap your lovely 
> JavaScript work -- just that your applications neither assume nor 
> depend on the validity of ANYTHING coming from a client.  Yes, that 
> may mean reproducing validation logic on both ends of the wire.  But 
> the server-side engine is survival gear; the client-side engine is 
> for frills.  Don't send your astronaut to the moon with a perfectly 
> functional espresso maker but faulty landing gear.
>
> Regards,
> Paul _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>