[UPHPU] RE: Javascript form validation [was Re: Posting a form]

[Mac Newbold]

Today at 2:31pm, Jeffrey Moss said:

> Javascript "validation" (at least in the broad sense you're using it) has some 
> pretty awesome uses too, like I did a site that didn't have a security 
> certificate and I set it up to encrypt the password in md5 before submitting 
> the form.  You have to make the md5 algorithm in javascript, you can get that 
> on the web. I think Hotmail and Yahoo mail both use this for their non-ssl 
> login page.

Sending a password hash insecurely usually means that (unless it's salted) 
it can be cracked using a dictionary attack, like those at 
http://www.passcracking.com . See earlier list discussions on the topic, 
and an article on the uphpu.org web site.

The other thing that many people who set up something like that do not 
realize is that if they see your password hash (since it's being sent 
insecurely), they can use it to log in. They no longer need the actual 
password to log in, just the hash, since that's what your page expects to 
see. So you've just made it a different "password" they need to get in, 
but one that is just as easy to see as a plaintext password sent over http 
would be.

Also, for correctness sake, you're not "encrypting" the password in md5, 
you're hashing it with md5. Encrypting is a process that can be reversed 
via decryption to yield the original text. MD5 is not such an algorithm, 
since it was designed to be hard to reverse. Encryption algorithms will 
almost always make use of a key (or a public-private key pair) to do the 
encryption and decryption.

SSL is true encryption, and does use a key to encrypt the data before its 
sent, then the same key is used to decrypt it at the other end, getting 
back the actual bytes that were transferred originally.

The curious may ask "But how do my browser and a web server agree on a key 
to use, without having talked before, or arranged it in advance, and 
without having anyone watching be able to know what the key is?" That 
would be a good question to have. The answer is something called the 
Diffie-Hellman (sp?) technique. It lets two entities set up a shared key, 
even if all their communication is visible by the attacker. That technique 
is the initial part of SSL, as well as SSH communications and I believe 
TLS as well.

>As for the form action being parsed on the fly, sometimes it is necessary 
>when you have two different forms on one page and you need a little of 
>both. This is a problem with the original form specs not being flexible 
>enough for some things, like if you have an iframe with a form in it, and 
>you need to include some data from outside the iframe, you might either 
>have to insert variables into the form or re-parse the action string. 
>They're mostly hacks, but I'd hardly call that validation.

No, they're not validation, but they suffer most of the same problems. 
They don't work when javascript is disabled or unavailable. Some would say 
that having an iframe in a page try to change form values in the 
surrounding page, or vice versa, is not a good idea. I don't fault the 
specs for not being "flexible" enough to allow it.

>One of example of this off the top of my head that I find very useful is 
>this: www.realtor.com, when you type in some parameters and click 
>"advanced options", it captures everything you've already selected and 
>uses that on the advanced options page, which is extremely convenient for 
>me.

Sure. That can be done with a little bit of javascript, and it is 
convinient. But if the page doesn't work without the javascript, then I 
would say they've done it wrong. Prefilling is dandy, but it should be a 
choice between the Javascript Way or No Way.

> If you don't have javascript enabled then maps.google.com won't function at 
> all, and that is one of the best user interfaces I've seen. Same with Google 
> suggest.

I've not used either of them yet. Same for gmail... it _requires_ 
javascript flat out. I would be a little surprised if they didn't work 
_at_all_, but I would expect that performance would be degraded, and some 
features probably unavailable. There are some times where it's a hit 
you're willing to take, but many people IMHO take that hit way too 
lightly, and don't use it as the Absolute Last Resort. If javascript _is_ 
the main point of your UI, then it might be difficult to impossible to 
replace that functionality without it.

>Give a more specific example of how javascript validation prevents access 
>to the site by spiders?  I dont want spiders going into order pages...

Agreed. That's why the spider/robot thing isn't such an issue with 
validation, but is more of a general consideration with using javascript 
on your pages.

>unless I had a site with some sort of navigation gizmo that did funky 
>things with javascript and forms and stuff, spiders can still navigate 
>the site. Can spiders access popup screens? I bet some are designed to 
>bypass the onClick="javascript:popup" subroutines. If I were making a 
>spider I wouldn't want it to trace into form actions.

There you've hit it on the head. Funky navigation gizmos and javascript 
popups can be troubling to a web spider. I would assume that the simplest 
of javascript popups might be followable by some spiders, but I wouldn't 
depend on it. On one of my sites where it mattered a lot, we used the 
get_browser()/brower.ini stuff in php to check the User Agent string and 
determine if it was a bot or other non-js browser. When it is a non-js 
browser, all of the window.open("") popups become <a target=_new href=""> 
links instead.

>I think javascript is at a mature level right now, and the best websites 
>out there are going to make extensive use of it.

I can understand that, and to a degree, I think a lot of good sites will 
make use of it. As we've already seen a lot of bad sites (and sites that 
would have been good) _abuse_ javascript, and that will continue as well.

My problem isn't even with extensive use of javascript... it's with 
javascript that is _required_ for proper functioning of the site. It takes 
an extremely portable medium (HTML) and robs it of many of its virtues, 
much like Microsoft and Internet Explorer have tried to do to HTML and the 
Internet in general. ;)

Mac

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/