Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Security > BIG WARNING - validation controls appear to be ignored.

Reply
Thread Tools

BIG WARNING - validation controls appear to be ignored.

 
 
Andy Fish
Guest
Posts: n/a
 
      02-24-2005
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


 
Reply With Quote
 
 
 
 
Karl Seguin
Guest
Posts: n/a
 
      02-24-2005
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
>



 
Reply With Quote
 
 
 
 
IPGrunt
Guest
Posts: n/a
 
      02-24-2005
On 24 Feb 2005, "Andy Fish" <(E-Mail Removed)> postulated in
news:(E-Mail Removed):

> 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
 
Reply With Quote
 
Lau Lei Cheong
Guest
Posts: n/a
 
      02-25-2005
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" <(E-Mail Removed)> bl
news:(E-Mail Removed) 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
>
>



 
Reply With Quote
 
PL
Guest
Posts: n/a
 
      02-25-2005
> 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.


 
Reply With Quote
 
PL
Guest
Posts: n/a
 
      02-25-2005
> 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.


 
Reply With Quote
 
IPGrunt
Guest
Posts: n/a
 
      02-26-2005
On 24 Feb 2005, "PL" <(E-Mail Removed)> postulated in
news:(E-Mail Removed):

> Subject: Re: BIG WARNING - validation controls appear to be ignored.
> From: "PL" <(E-Mail Removed)>
> 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
 
Reply With Quote
 
Andy Fish
Guest
Posts: n/a
 
      02-26-2005
>
> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
GIDS 2009 .Net:: Save Big, Win Big, Learn Big: Act Before Dec 29 2008 Shaguf ASP .Net 0 12-26-2008 09:29 AM
GIDS 2009 .Net:: Save Big, Win Big, Learn Big: Act Before Dec 29 2008 Shaguf ASP .Net Web Controls 0 12-26-2008 06:11 AM
GIDS 2009 Java:: Save Big, Win Big, Learn Big: Act Before Dec 29 2008 Shaguf Python 0 12-24-2008 07:35 AM
GIDS 2009 Java:: Save Big, Win Big, Learn Big: Act Before Dec 29 2008 Shaguf Ruby 0 12-24-2008 05:07 AM
BIG WARNING - validation controls appear to be ignored. Andy Fish ASP .Net 7 02-26-2005 05:20 PM



Advertisments