I have followed a couple of your posts and they
are extremely elitist and uninformed.
Its simple, see if the user has/doesnt have javascript
enabled.
If they do, you should *STLL* be validating data server
side.
NEVER trust the data the client is giving you, that is
a rule well followed by almost any big website, try
feeding amazon weird data, see what happens.
Okay, that said how can you trust the client side script
to validate your data? You cant. Plain and simple.
You are talking about writing all of your validation
logic purely in script???
And.. the minute something invalid is fed to you by
someone who has it turned off.. Oops? Sorry sir turn
on script or go away.
You would lose me as a customer if you did something
like that.
Yes, almost every project/program I have written
or seen (a lot) professionally, non professionally
ALWAYS validate the data serverside regardless of
the client.
Why do you think Game servers like DiabloII and
QuakeIII dont trust the client?
Oh yes I actually have 400 health, yeah right, that
is why the server does not trust the client.
That is standard client/server design, dont trust the
client.
From: http://archives.neohapsis.com/archives/bugtraq/2000-02/0055.html
"- A.K.A. server-side
> validation, which should be a normal, healthy, common sense programming
> practice anyway ("NEVER trust the user..."). Moreover, it's more secure
than
> client-side validation, since one who has malicious intent can always
> construct their own form/query and just delete the validating JavaScript
or
> whatever on the client side. "
From:
http://www.securityportal.com/articles/webdev20001103.html#nevertrustincomin
gdata
"Never Trust Incoming Data - Details
It's worth saying it again and in more detail. What can constitute incoming
data for a Web application?
The HTTP request itself. The URL, the method, the cookie if any, and the
HTTP headers. Think what could happen if the URL were different - say, if
any field passed by the client were changed or if the actual URL requested
another page. Could the client see the session of another user? What if the
parameters are not consistent with each other? Does the server application
handle this case or does it fail, possibly with revealing error messages?
Data fields (e.g., form fields). There is so much to do with user-supplied
data that you'll find this point several times in the sections below. They
can overflow buffers. (If you are not sure why this is dangerous, see the
section on C/C++.) If appended to a SQL statement, they can execute code on
the SQL server. For a detailed explanation, see Rain Forrest Puppy's article
in Phrack 54.
http://www.phrack.com/search.phtml?view&article=p54-8"
I could keep pasting references like this.. all day long pointing out
numerous reasosn
for validating data serversideand not trusting the client... but I wont I
will
leave it to everyone else to draw their own conclusions.
Jeremy Allen
elliptIQ Inc.
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, January 18, 2001 5:15 AM
>To: CF-Talk
>Subject: Adam, you got to be kidding?
>
>
>You actually develop with the mindset that a user might not have scripting
>enabled? Ouch!
>
>My guess would be that at a minimum, 98% of all users have scripting
>enabled.
>So, you would forfeit the capability of client-side data validation,
>client-side DOM manipulation, etc.?
>
>You would add unneeded round trips to your server to accomplish scripting,
>validation, etc.? So 98% of your users will pay the Performance price for
>the
>2% of your users? Not to mention the extra load on your server and the
>wasted
>bandwidth.
>
>Not a good idea ... Please!
>
>Bill Reichard
>Willow Gold
>[EMAIL PROTECTED]
>http://www.willowgold.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
