Javascript validation against data on server

[rcb845]

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]

rc****@yahoo.fr 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.

[Mick White]

Lee wrote:

rc****@yahoo.fr 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.

[Lee]

Mick White said:

Lee wrote:

rc****@yahoo.fr 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.

[Martin Bialasinski]

Mick White <mw***********@rochester.rr.com> 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

[Mick White]

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

[Randy Webb]

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

[Lee]

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.

[Mick White]

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]

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

[Lee]

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.

[Martin Bialasinski]

Mick White <mw***********@rochester.rr.com> 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/swse...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

[Mick White]

Martin Bialasinski wrote:

Mick White <mw***********@rochester.rr.com> 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

[ExGuardianReader]

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.