[whatwg] substantive comment on Web Forms 2.0, and suggestion

[Asbjørn Ulsberg]

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»