bugtraq - Re: Intresting case of SQL Injection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sat, 06 Dec 2003 11:38:47 +1300
From: Nick FitzGerald <nick@...us-l.demon.co.uk>
To: "'bugtraq@...urityfocus.com'" <bugtraq@...urityfocus.com>
Subject: Re: Intresting case of SQL Injection

Sys Sec <syssec@...igsa.com> 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