Javascript validation against data on server

[rcb845@yahoo.fr]

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

[Lee]

Re: Javascript validation against data on server

rcb845@yahoo.fr said:
[color=blue]
>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.[/color]

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.

[Mick White]

Re: Javascript validation against data on server

Lee wrote:[color=blue]
> rcb845@yahoo.fr said:
>
>[color=green]
>>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.[/color]
>
>
> 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.
>[/color]

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.

[Lee]

Re: Javascript validation against data on server

Mick White said:[color=blue]
>
>Lee wrote:[color=green]
>> rcb845@yahoo.fr said:
>>
>>[color=darkred]
>>>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.[/color]
>>
>>
>>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.
>>[/color]
>
>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 }[/color]

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.

[Martin Bialasinski]

Re: Javascript validation against data on server

Mick White <mwhite13BOGUS@ rochester.rr.co m> wrote:
[color=blue]
> Lee wrote:[color=green]
>> 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.[/color]
>
> You may, however, set a flag using javascript and a hidden field that
> would decrease processsing time for the server.[/color]

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

[Mick White]

Re: Javascript validation against data on server

Martin Bialasinski wrote:
[color=blue]
> 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.
>[/color]


Are we talking about the plans for the atomic bomb?

And, I doubt that you can circumvent the validation.

Mick

[Randy Webb]

Re: Javascript validation against data on server

Mick White wrote:[color=blue]
> Martin Bialasinski wrote:
>[color=green]
>> 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.
>>[/color]
>
>
> Are we talking about the plans for the atomic bomb?
>
> And, I doubt that you can circumvent the validation.[/color]

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

Ummm, yes I can.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Lee]

Re: Javascript validation against data on server

Mick White said:[color=blue]
>
>Martin Bialasinski wrote:
>[color=green]
>> 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.
>>[/color]
>
>
>Are we talking about the plans for the atomic bomb?
>
>And, I doubt that you can circumvent the validation.[/color]

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.

[Mick White]

Re: Javascript validation against data on server

Randy Webb wrote:[color=blue]
>
> javascript:docu ment.forms[0].submit() in the address bar.
>
> Ummm, yes I can.
>[/color]
<input type="hidden" value="not_veri fied">
Nice try.
Mick

[Mick White]

Re: Javascript validation against data on server

Lee wrote:

[color=blue]
>
> 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.
>[/color]

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

[Lee]

Re: Javascript validation against data on server

Mick White said:[color=blue]
>
>Lee wrote:
>
>[color=green]
>>
>> 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.
>>[/color]
>
>So how'd you do it in this case?[/color]

In what case? We don't know anything about the form in question.

[Martin Bialasinski]

Re: Javascript validation against data on server

Mick White <mwhite13BOGUS@ rochester.rr.co m> wrote:
[color=blue]
> Martin Bialasinski wrote:
>[color=green]
>> No!
>> *Everything* coming in from uncontrolled sources (here: user) must be
>> validated on the server.[/color][/color]
[color=blue]
> Are we talking about the plans for the atomic bomb?[/color]

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/swsearch?query=input+validation&sbm=bid&submit=Search%21&metaname=alldoc&sort=swishrank

[color=blue]
> And, I doubt that you can circumvent the validation.[/color]

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

[Mick White]

Re: Javascript validation against data on server

Martin Bialasinski wrote:
[color=blue]
> Mick White <mwhite13BOGUS@ rochester.rr.co m> wrote:[color=green]
>>Are we talking about the plans for the atomic bomb?[/color]
>
>
> 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.[/color]
[...]
It's a minefield out there, and you need to protect your data. I see
your point.
Mick

[ExGuardianReader]

Re: Javascript validation against data on server

Mick White wrote:
[color=blue]
> Randy Webb wrote:
>[color=green]
>>
>> javascript:docu ment.forms[0].submit() in the address bar.
>>
>> Ummm, yes I can.
>>[/color]
> <input type="hidden" value="not_veri fied">
> Nice try.
> Mick[/color]

javascript:docu ment.forms[0].elements[n].value="verifie d";document.for ms[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.