- From: Asbjørn Ulsberg <asbjorn@tigerstaden.no>
- Date: Thu, 08 Jul 2004 15:02:30 +0200
On Wed, 07 Jul 2004 16:07:46 -0500, Andrew Hagen <xah at myrealbox.com> wrote:
> Nothing would prevent a user with IE from finding such a form and
> entering data into the form with his browser. He can even submit the
> data with IE.
Submitting bad data is not limited to IE. It can be done with old versions
of Opera, Mozilla, Safari et al and by any home-written browser.
JavaScript or any type of client-side validation cannot be trusted. Ever.
You will always have to check the input on the server, no matter how well
you think you have validated the data on the client.
As an example, enumerated values in <select> can't be trusted either. Most
server scripts assume that the 'value="x"' is a range from A to Z or from
0 to 9 (or something similar), and it never occurs to those who write them
that the <select> can be overridden by the client. A really good book on
this subject is ?Innocent Code?[1] which has the following, real life,
example (written from memory):
A web based bank had a web form that could be submitted to transfer money
from one account to the other. This was done with two <select> elements;
one being the source account, and the other being the target:
<select name="source_account">
<option value="1345.35.67897">1345.35.67897</option>
<option value="1345.67.89690">1345.67.89690</option>
</select>
<select name="target_account">
<option value="1345.35.67897">1345.35.67897</option>
<option value="1345.67.89690">1345.67.89690</option>
</select>
<input type="text" name="amount">
When this form was submitted to the server, the values were extracted from
'source_account' and the amount given in 'amount' was transferred to
'target_account'. The 'amount' value was checked to see if it was a
number, and then 'source_account' was checked to see if it had enough
money to allow the transfer to continue.
But one thing, and the most important thing, that wasn't checked, was if
'source_account' was an account number belonging to the individual that
transferred the money. So, just by installing an HTTP proxy server, you
could very simply just replace the value of 'source_account' with any
other valid account number, and the transfer would be done from that
account instead of one of your own.
This proves that you can _never_ trust data coming from the client, no
matter how much JavaScript or other fancy stuff you put into the web
application. You will always, no matter what WHAT WG and other (pseudo)
standards bodies do, have to do server validation.
> That need for another program would defeat the purpose of Web Forms
> 2.0
Not at all. The purpose of WF2, as I see it, is _not_ to make the web more
secure, or to take work off of web developer's shoulders when it comes to
server side validation. Client side validation is only to make the web
page more snappy and user friendly, and have never been to make the web
application more secure. Security is maintained at the server only, and
never anywhere else. At least not on the client.
> so that it doesn't have to be validated on the server end or with
> Javascript.
You know JavaScript can be deactivated by two keystrokes in Opear (F12 |
'j')? JavaScript, as all other client-side validation, have or will never
replace server side validation. I don't know where you've got that idea
from.
> That would make it easy on the server end. All they would have to do
> is look for a "webformsverokay=2" in the submitted data, for example,
> and if they find it, the data is known to have been validated.
Uh. I can write a client that submits 'webformsverokay=2' to the server in
less than ten minutes. Alongside, I could have the client submit huge
amounts of invalid data. How does 'webformsverokay=2' make anything any
more secure?
____
[1] <url: http://innocentcode.thathost.com/>
--
Asbj?rn Ulsberg -=|=- asbjornu at hotmail.com
?He's a loathsome offensive brute, yet I can't look away?
Received on Thursday, 8 July 2004 06:02:30 UTC