<<< Date Index >>>     <<< Thread Index >>>

Re: Intresting case of SQL Injection



Sys Sec <syssec@xxxxxxxxxxx> wrote:

<<snip>>
> Normally you verify data with Javascript in Client ...

I just _love_ seeing this kind of advice...

NOT!

It amounts to you (or your even more security-ignorant client) 
effectively saying to your clients (or to the clients of your even more 
security ignorant client) "we know better than you about how to secure 
_your_ client computers and thus you should trust our judgement that it 
is safe for you to enable JavaScript in your web browser despite you 
having no frigging idea at all who we are, where this code is actually 
hosted, whether the sysadmins of the hosting servers have two clues 
about securing their machines and so on".

Please _stop_ thinking it is reasonable to assume you can make such 
decisions for folk.  Just because the braindead default configuration 
of popular browsers is "ream me seven ways to Sunday" (also known as 
"multiply the effect of many security flaws in this browser several 
fold by enabling JavaScript") does not mean you should assume 
JavaScript is available, and if your web pages should happen to be 
rendered on a sensibly configured machine, fercrissakes do not assume 
you know better than the person who set the machine up -- in such cases 
the odds are not that they are running some ancient or otherwise non-
scripting client version but that they know a lot more than you about 
the acceptable security exposure of _that machine_.

> ... but you must verify data
> in file that receive POST Form. In the file that receive the POST data you
> can use these functions.

Exactly.  The input can be delivered to your server-side app through 
all manner of other channels than your client-side code, so why even 
bother thinking about designing, writing, debugging and maintaining 
client-side sanity-checking code?  The odds -- from a huge repository 
of popular and widely deployed web apps -- that the programmer or team 
behind the app is too retarded to understand the security implications 
of _just_ the server-side of the app, so they should concentrate on 
getting that part better and maintaining that rather than trying to 
dictate their security policies to the clients of the web app.


Regards,

Nick FitzGerald