BIG WARNING - validation controls appear to be ignored.

A

Andy Fish

Hi,

Although I have got to the bottom of this problem, it gave me quite a shock
to discover how easy it is to write a very unsafe application with .Net
validators.

The scenario was this: we wrote and tested an application using validators,
but when we deployed the app onto a different server, it accepted and
processed invalid input from the user.

Turns out that in testing the validators were running client-side. When a
client-side validator blocks the input there is no postback and hence
nothing happens on the server. However, if client-side validation is
disabled for any reason, all control events fire on the server even if the
page is invalid. If, like me, you were expecting the page processing to
finish in the event of a validation faliure and not fire button clicks etc,
you are sadly mistaken. If you use validators, you must check manually
Page.IsValid in every "click" event.

I realise this is probably in the documentation (section 34.4b(ii)
subsection 2(i) sub-paragraph 23a.3.64) and many of you gurus will think
this is obvious, but I'm sure that there must be hundreds of apps out there
that are unwittingly relying on client-side validation.

The moral is this: ALWAYS TEST THE APPLICATION WITH CLIENT SIDE VALIDATION
DISABLED. the default configuration could lull you into a false sense of
security and could lead to shipping an unsafe application.

Andy
 
K

Karl Seguin

Yes, we do consider this obvious. But I think all of us would also agree
that we see questions with respect to this all too often. Having said that,
remember that there's atleast two sides to every story (yours, mine and
Kevin's Spe...err I mean the right way). If it behaved otherwise, someone
would likely say "BIG WARNING - unable to manually control validation" and
continue to claim that microsoft removed the flexibility of blah blah
blah...so it depends how you look at it.

anyways, thanks for the heads up, hopefully this message will help someone
doing a google group search one day...

Karl
 
I

IPGrunt

Hi,

Although I have got to the bottom of this problem, it gave me quite a shock
to discover how easy it is to write a very unsafe application with ..Net
validators.

The scenario was this: we wrote and tested an application using validators,
but when we deployed the app onto a different server, it accepted and
processed invalid input from the user.

Turns out that in testing the validators were running client-side. When a
client-side validator blocks the input there is no postback and hence
nothing happens on the server. However, if client-side validation is
disabled for any reason, all control events fire on the server even if the
page is invalid. If, like me, you were expecting the page processing to
finish in the event of a validation faliure and not fire button clicks etc,
you are sadly mistaken. If you use validators, you must check manually
Page.IsValid in every "click" event.

I realise this is probably in the documentation (section 34.4b(ii)
subsection 2(i) sub-paragraph 23a.3.64) and many of you gurus will think
this is obvious, but I'm sure that there must be hundreds of apps out there
that are unwittingly relying on client-side validation.

The moral is this: ALWAYS TEST THE APPLICATION WITH CLIENT SIDE VALIDATION
DISABLED. the default configuration could lull you into a false sense of
security and could lead to shipping an unsafe application.

Andy

Good point, Andy.

No, this is not in the documentation, however, there are plenty of
informative articles available on preventing SQL injection attacks.

Testing is important, but a deliberate practice of defense in depth
is advised to all who use the web as a data aggregator.

I would suggest that if you don't already use parameterized queries,
that you learn what they are and how they can help you prevent data
content attacks against your server.


-- ipgrunt
 
L

Lau Lei Cheong

Just like any client-side checking using vbscript/javascript, they can
always be overrided.

So never just do client-side checking of data, do server-side checking on
the received data as well.

This may seem redundant, but client-side check enables quicker response and
fewer postbacks, while server-side check makes your data safer.
 
P

PL

No, this is not in the documentation, however, there are plenty of
informative articles available on preventing SQL injection attacks.

Is it not in the docs ? You better read it more carefully, what the h do you
think the webuivalidation.js is ???

Come on, dont blaim MS because you are bad programmers.

PL.
 
P

PL

I realise this is probably in the documentation (section 34.4b(ii) subsection 2(i) sub-paragraph 23a.3.64) and many of you gurus
will think this is obvious, but I'm sure that there must be hundreds of apps out there that are unwittingly relying on client-side
validation.

Try reading:
ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpconClient-SideValidation.htm

PL.
 
I

IPGrunt

Subject: Re: BIG WARNING - validation controls appear to be ignored.
From: "PL" <[email protected]>
Newsgroups: microsoft.public.dotnet.framework.aspnet,microsoft.public.dotnet.framew
ork.aspnet.security

Is it not in the docs ? You better read it more carefully, what the h do you
think the webuivalidation.js is ???

Come on, dont blaim MS because you are bad programmers.

PL.


You miss the point of his comment, which has nothing to do with the
docs, and everything to do with not depending on validators to protect
your backend data.

That's called defense in depth, and is the practice of good
programmers.

And don't blame M$ because you're a bad speller.

-- ipgrunt
 
A

Andy Fish

You miss the point of his comment, which has nothing to do with the
docs, and everything to do with not depending on validators to protect
your backend data.

That's called defense in depth, and is the practice of good
programmers.

Just as a follow-up, the point of my original comment was not really
about relying on client-side validation. no programmer worth his salt
would ever do that deliberately.

My point was that the system as a whole (the framework and development
environment) did not "fail-safe". Without reading every word of the
documentation, I wrote and tested an application making what I
beleived to be a reasonable assumption about how it would work. When I
deployed it I found out by accident that it was relying on client side
validation. IMHO this would be worth a big caveat on every page
relating to the valiation, not just a single note.

Better still, I would have click-type events only fire if the form is
valid, unless the developer specifically overrides this behaviour.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top