Javascript validation against data on server

Discussion in 'Javascript' started by rcb845@yahoo.fr, Jan 7, 2005.

  1. Guest

    Hi everybody Javascript specialist,

    I am relatively new in Javascript world. I have a problem to solve and
    I hope one of you can help me.

    I am building a validation system, i.e. I want to validate data entered using
    A normal HTML FORM. Data will be checked using Javascript scripts to
    Have an immediate status, and to prevent user to keep on in case of error.

    But some data must be checked against MySql database accessed through
    PHP scripts. These PHP validate occur after user has hit <submit> button.

    I would like to retrieve MySql data from server and have them available for
    Immediate Javascipt validation on the client workstation.

    Can anyone tell me if it is possible, and if yes, what is the coding to implement.
    Such procedure would avoid having all "validation-against-date" to be defined
    Twice, once on the server where they reside, and once duplicated in all
    Necessary Javascript.

    Thank you very much for your precious help and best regards

    RCB845
    , Jan 7, 2005
    #1
    1. Advertising

  2. Lee Guest

    said:

    >Such procedure would avoid having all "validation-against-date" to be defined
    >Twice, once on the server where they reside, and once duplicated in all
    >Necessary Javascript.


    No it wouldn't, really. Validation on the client side should be for the user's
    convenience, only. Your "real" validation must always be done on the server,
    where you can control the environment. It's too easy for a user to turn off
    Javascript, or for a malicious person to intentionally bypass client side
    validation.
    Lee, Jan 7, 2005
    #2
    1. Advertising

  3. Mick White Guest

    Lee wrote:
    > said:
    >
    >
    >>Such procedure would avoid having all "validation-against-date" to be defined
    >>Twice, once on the server where they reside, and once duplicated in all
    >>Necessary Javascript.

    >
    >
    > No it wouldn't, really. Validation on the client side should be for the user's
    > convenience, only. Your "real" validation must always be done on the server,
    > where you can control the environment. It's too easy for a user to turn off
    > Javascript, or for a malicious person to intentionally bypass client side
    > validation.
    >


    You may, however, set a flag using javascript and a hidden field that
    would decrease processsing time for the server.

    if($flag) {//it's vaidated }
    else { perform validation }

    Mick.
    Mick White, Jan 7, 2005
    #3
  4. Lee Guest

    Mick White said:
    >
    >Lee wrote:
    >> said:
    >>
    >>
    >>>Such procedure would avoid having all "validation-against-date" to be defined
    >>>Twice, once on the server where they reside, and once duplicated in all
    >>>Necessary Javascript.

    >>
    >>
    >>No it wouldn't, really. Validation on the client side should be for the user's
    >> convenience, only. Your "real" validation must always be done on the server,
    >> where you can control the environment. It's too easy for a user to turn off
    >> Javascript, or for a malicious person to intentionally bypass client side
    >> validation.
    >>

    >
    >You may, however, set a flag using javascript and a hidden field that
    >would decrease processsing time for the server.
    >
    >if($flag) {//it's vaidated }
    >else { perform validation }


    That's not much protection from the malicious user, or even the one who becomes
    impatient with your validation. I've hacked my way past defective validations
    more than once.
    Lee, Jan 7, 2005
    #4
  5. Mick White <> wrote:

    > Lee wrote:
    >> Your "real" validation must always be done on the server, where you
    >> can control the environment. It's too easy for a user to turn off
    >> Javascript, or for a malicious person to intentionally bypass
    >> client side validation.

    >
    > You may, however, set a flag using javascript and a hidden field that
    > would decrease processsing time for the server.


    No!

    *Everything* coming in from uncontrolled sources (here: user) must be
    validated on the server.

    I can easily submit anything to the server. Including a faked "is
    validated" field and thous circumvent your validation and feed your
    scripts bogus data. Security breach par excellence.

    Bye,
    Martin
    Martin Bialasinski, Jan 7, 2005
    #5
  6. Mick White Guest

    Martin Bialasinski wrote:

    > No!
    >
    > *Everything* coming in from uncontrolled sources (here: user) must be
    > validated on the server.
    >
    > I can easily submit anything to the server. Including a faked "is
    > validated" field and thous circumvent your validation and feed your
    > scripts bogus data. Security breach par excellence.
    >



    Are we talking about the plans for the atomic bomb?

    And, I doubt that you can circumvent the validation.

    Mick
    Mick White, Jan 7, 2005
    #6
  7. Randy Webb Guest

    Mick White wrote:
    > Martin Bialasinski wrote:
    >
    >> No!
    >>
    >> *Everything* coming in from uncontrolled sources (here: user) must be
    >> validated on the server.
    >>
    >> I can easily submit anything to the server. Including a faked "is
    >> validated" field and thous circumvent your validation and feed your
    >> scripts bogus data. Security breach par excellence.
    >>

    >
    >
    > Are we talking about the plans for the atomic bomb?
    >
    > And, I doubt that you can circumvent the validation.


    javascript:document.forms[0].submit() in the address bar.

    Ummm, yes I can.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq
    Randy Webb, Jan 8, 2005
    #7
  8. Lee Guest

    Mick White said:
    >
    >Martin Bialasinski wrote:
    >
    >> No!
    >>
    >> *Everything* coming in from uncontrolled sources (here: user) must be
    >> validated on the server.
    >>
    >> I can easily submit anything to the server. Including a faked "is
    >> validated" field and thous circumvent your validation and feed your
    >> scripts bogus data. Security breach par excellence.
    >>

    >
    >
    >Are we talking about the plans for the atomic bomb?
    >
    >And, I doubt that you can circumvent the validation.


    We may be talking about bad data that could corrupt a production database,
    bypassing user authentication, or a user awarding themself free shipping.

    It's usually pretty trivial to bypass client-side validation.
    Lee, Jan 8, 2005
    #8
  9. Mick White Guest

    Randy Webb wrote:
    >
    > javascript:document.forms[0].submit() in the address bar.
    >
    > Ummm, yes I can.
    >

    <input type="hidden" value="not_verified">
    Nice try.
    Mick
    Mick White, Jan 8, 2005
    #9
  10. Mick White Guest

    Lee wrote:


    >
    > We may be talking about bad data that could corrupt a production database,
    > bypassing user authentication, or a user awarding themself free shipping.
    >
    > It's usually pretty trivial to bypass client-side validation.
    >


    So how'd you do it in this case?
    Mick
    Mick White, Jan 8, 2005
    #10
  11. Lee Guest

    Mick White said:
    >
    >Lee wrote:
    >
    >
    >>
    >> We may be talking about bad data that could corrupt a production database,
    >> bypassing user authentication, or a user awarding themself free shipping.
    >>
    >> It's usually pretty trivial to bypass client-side validation.
    >>

    >
    >So how'd you do it in this case?


    In what case? We don't know anything about the form in question.
    Lee, Jan 8, 2005
    #11
  12. Mick White <> wrote:

    > Martin Bialasinski wrote:
    >
    >> No!
    >> *Everything* coming in from uncontrolled sources (here: user) must be
    >> validated on the server.


    > Are we talking about the plans for the atomic bomb?


    We are talking about something that securityfocus regulary describes
    as (depending on the affected application):

    These issues may be leveraged to carry out SQL injection attacks,
    HTML injection attacks, arbitrary file uploads, privilege
    escalation, command execution in the context of the vulnerable
    application, and command execution in the context of the affected
    system.

    or

    xNewsletter does not sanitize dangerous characters from form field
    input such as the e-mail address of the newsletter recipient. It has
    been demonstrated that this condition may be exploited to cause
    multiple instances of the same e-mail address to be written to the
    datafile. An attacker may effectively trick the script into mail
    bombing an arbitrary e-mail address.

    It has also been demonstrated that the attacker may cause arbitrary
    data to be written to the datafile in such a way that it cannot be
    removed using the facilities provided by xNewsletter. The malformed
    data must be removed from the datafile manually.

    http://search.securityfocus.com/sws...submit=Search!&metaname=alldoc&sort=swishrank

    > And, I doubt that you can circumvent the validation.


    With a GUI:

    Open the URL in the DOM Inspector. Navigate to the hidden
    field. Change the value.

    Scripted:

    Use wget to submit any data you like.


    Bye,
    Martin
    Martin Bialasinski, Jan 8, 2005
    #12
  13. Mick White Guest

    Martin Bialasinski wrote:

    > Mick White <> wrote:
    >>Are we talking about the plans for the atomic bomb?

    >
    >
    > We are talking about something that securityfocus regulary describes
    > as (depending on the affected application):
    >
    > These issues may be leveraged to carry out SQL injection attacks,
    > HTML injection attacks, arbitrary file uploads, privilege
    > escalation, command execution in the context of the vulnerable
    > application, and command execution in the context of the affected
    > system.

    [...]
    It's a minefield out there, and you need to protect your data. I see
    your point.
    Mick
    Mick White, Jan 8, 2005
    #13
  14. Mick White wrote:

    > Randy Webb wrote:
    >
    >>
    >> javascript:document.forms[0].submit() in the address bar.
    >>
    >> Ummm, yes I can.
    >>

    > <input type="hidden" value="not_verified">
    > Nice try.
    > Mick


    javascript:document.forms[0].elements[n].value="verified";document.forms[0].submit()

    You can't rely on what's coming back from the browser. Ever. It might
    not even BE a browser that's sending a reply. Someone could write a
    script to send any old crap to your server.
    ExGuardianReader, Jan 8, 2005
    #14
    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. Nick Gilbert
    Replies:
    7
    Views:
    403
    Steven Cheng[MSFT]
    May 31, 2004
  2. AFN
    Replies:
    2
    Views:
    746
    Peter Blum
    Feb 1, 2005
  3. Tad McClellan

    Re: XML Validation against a DTD

    Tad McClellan, Aug 13, 2003, in forum: XML
    Replies:
    0
    Views:
    473
    Tad McClellan
    Aug 13, 2003
  4. Michael TEpperis
    Replies:
    1
    Views:
    411
  5. Porthos
    Replies:
    2
    Views:
    340
    Martin Honnen
    Nov 3, 2005
Loading...

Share This Page