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