BIG WARNING - validation controls appear to be ignored.

Discussion in 'ASP .Net Security' started by Andy Fish, Feb 24, 2005.

  1. Andy Fish

    Andy Fish Guest

    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
     
    Andy Fish, Feb 24, 2005
    #1
    1. Advertising

  2. Andy Fish

    Karl Seguin Guest

    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" <> wrote in message
    news:...
    > 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, Feb 24, 2005
    #2
    1. Advertising

  3. Andy Fish

    IPGrunt Guest

    On 24 Feb 2005, "Andy Fish" <> postulated in
    news::

    > 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
     
    IPGrunt, Feb 24, 2005
    #3
  4. 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" <> ¦b¶l¥ó
    news: ¤¤¼¶¼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
    >
    >
     
    Lau Lei Cheong, Feb 25, 2005
    #4
  5. Andy Fish

    PL Guest

    > 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, Feb 25, 2005
    #5
  6. Andy Fish

    PL Guest

    > 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.
     
    PL, Feb 25, 2005
    #6
  7. Andy Fish

    IPGrunt Guest

    On 24 Feb 2005, "PL" <> postulated in
    news::

    > Subject: Re: BIG WARNING - validation controls appear to be ignored.
    > From: "PL" <>
    > 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
     
    IPGrunt, Feb 26, 2005
    #7
  8. Andy Fish

    Andy Fish Guest

    >
    > 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.
     
    Andy Fish, Feb 26, 2005
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andy Fish
    Replies:
    7
    Views:
    288
    Andy Fish
    Feb 26, 2005
  2. Shaguf
    Replies:
    0
    Views:
    357
    Shaguf
    Dec 24, 2008
  3. Shaguf
    Replies:
    0
    Views:
    456
    Shaguf
    Dec 26, 2008
  4. Shaguf
    Replies:
    0
    Views:
    240
    Shaguf
    Dec 26, 2008
  5. Shaguf
    Replies:
    0
    Views:
    218
    Shaguf
    Dec 24, 2008
Loading...

Share This Page