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

Jeffrey Moss jeff at opendbms.com
Thu Feb 24 19:59:50 MST 2005

Well that's what's clever about this _HASH_ scheme is the seed is unique for each request, sent by the server. Of course a certificate is better but in this case it offers a decent level of protection from http sniffers where none was previously available.

I could make a good analogy between your stance on javascript vs no javascript as windows programming vs cli programming. If you're designing a page that is meant to be functional, like an order form or a search tool, and something could be done on the client, it benefits most people. Here is another great example. I have a small widget that pops up a tiny window where the user selects some data and when they close it it is populated in the opening screen. It makes the root interface very clean and easy to use. It opens a window and uses window.write to populate it with HTML and then writes to the parents elements when you're done. It feels like a windows/mac application in a way, with dialogs and all. It's quick and nimble. Your application is loading the same page over and over, showing confirmation screens and stuff. Some people claim that people who dont have javascript won't order and that you lose money. I'd be willing to bet that that *never* happens, and that people are impressed with a slick order form it boosts sales. Eventually I'd like to master this rpcxmlrequest stuff so that the web application is even closer to a windows app (like google suggest).


On Thu, Feb 24, 2005 at 05:59:40PM -0700, Mac Newbold wrote:
> 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/

More information about the UPHPU mailing list