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
[url]http://www.openmymind.net/[/url]


"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
news:OyahI6oGFHA.3472@TK2MSFTNGP09.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" <ajfish@blueyonder.co.uk> postulated in
news:OyahI6oGFHA.3472@TK2MSFTNGP09.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" <ajfish@blueyonder.co.uk> ¦b¶l¥ó
news:OyahI6oGFHA.3472@TK2MSFTNGP09.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.NETFrameworkSDKv1.1/cpguidenf/html/cpconClient-SideValidation.htm

PL.

[IPGrunt]

On 24 Feb 2005, "PL" <pblse2@yahoo.se> postulated in
news:e4M6KwvGFHA.560@TK2MSFTNGP12.phx.gbl:

> Subject: Re: BIG WARNING - validation controls appear to be ignored.
> From: "PL" <pblse2@yahoo.se>
> Newsgroups:

microsoft.public.dotnet.framework.aspnet,microsoft .public.dotnet.framew
ork.aspnet.security

>

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