BIG WARNING - validation controls appear to be ignored.

[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

[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
--
MY ASP.Net tutorials
http://www.openmymind.net/
"Andy Fish" <aj****@blueyon der.co.uk> wrote in message
news:Oy******** ******@TK2MSFTN GP09.phx.gbl...

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

[IPGrunt]

On 24 Feb 2005, "Andy Fish" <aj****@blueyon der.co.uk> postulated in
news:Oy******** ******@TK2MSFTN GP09.phx.gbl:

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

[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.

"Andy Fish" <aj****@blueyon der.co.uk> ¦b¶l¥ó
news:Oy******** ******@TK2MSFTN GP09.phx.gbl ¤¤¼¶¼g...

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

[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.

[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.NETFramework SDKv1.1/cpguidenf/html/cpconClient-SideValidation. htm

PL.

[IPGrunt]

On 24 Feb 2005, "PL" <pb****@yahoo.s e> postulated in
news:e4******** *****@TK2MSFTNG P12.phx.gbl:

Subject: Re: BIG WARNING - validation controls appear to be ignored.
From: "PL" <pb****@yahoo.s e>
Newsgroups: microsoft.publi c.dotnet.framew ork.aspnet,micr osoft.public.do tnet.framew
ork.aspnet.secu rity

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.

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

[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.