NYCPHP Meetup

[Jim Hendricks]

> First, I'm sorry if I've come off as nasty.  That's certainly not my
> intention.  But I _really_ don't like JavaScript.  Allow me to clarify
> exactly why.

And yet as another poster pointed out, you use JavaScript on your website
for flyovers.  I realize that the website will still work with JS turned
off, but for
someone so dead against JS, I would think you would not want to support
even the simplist use of JS especially since you can't even see the JS
impact on your website since JS is turned off in your browser.

> JS has opened up a wide array of vulnerabilities.  Putting the words
> "javascript" and "vulnerability" into Google brought up over 31,000 hits:
> http://www.google.com/search?q=javascript+vulnerability.  The bugs include
> situations where the JS engine in the browser has flaws that cause
> exploitable crashes.  Other problems arise from nasty scripts doing
> nepharious things, such as cross-site scripting vulnerabilities.
> Cross-site errors have arisen in notable programs such as Cold Fusion and
> PHPNuke.  Here are some searches on this matter...

This same thing can be said about alot of technologies, but do we stop
using a technology because there are potential vulnerabilities?

Take for example stylized e-mails.  I can send very professional looking
e-mails with tables, graphics etc.  I have yet to have a customer complain
that they can't see my e-mails the way it was intended to be viewed because
they have stylized text turned off.  And yet even with JS turned off,
stylized
text is relied on by spammers to find active e-mail addresses so they can
spam you some more.  They send an e-mail with graphics that are not
embedded in the e-mail but are linked to a site.  As far as your concerned
it saves on the size of the e-mail on initial delivery.  To the spammer, the
moment you read the e-mail, they get a hit on their web server for you to
DL the picture, and they get your e-mail address which allows them to know
it's active.

> I'd consider a web discussion forum to be down in that low economic impact
> area.  But, if the system doesn't check user input on the server before
> saving it, users can get unpleasant cross-site coding saved that will
> spring up every time someone views their posting.  This has no economic
> impact on the server or the people running it, but it poses problems for
> the people viewing the site.  So, pennies need to be protected.

I did not say pennies do not need to be protected, I implied that pennies do
not need to be protected with a vault with a protected ventilation system
and
a pressure sensitive floor and sound level alarms and walls thick enough
to withstand a nuclear blast and guards out the wazoo.  I'm glad to protect
my penny by putting it into my piggy bank in my house which is locked when
I am not home.  Can someone steal my penny?  Sure, they can break in to
my house & the poor piggy bank is toast.  They can hope to also rely on
me being lazy sometimes and not locking up because I'm just running around
the corner to rent a video.  But I can guarantee that someone desiring to
break into my house is not doing it for the penny, it's not worth their
effort,
they want my VCR & DVD & TV & Stereo & Computer & the wife's jewelry
etc.  And yet, even though all those things are more valuable to me than
that little penny, I still rely on protecting it with a locked house in a
peaceful
safe community.  The statistics of breakins in my neighborhood run in at
under 10 per year in a community of thousands.  Under the circumstances
I would look foolishly parinoid to spend thousands of dollars to get the
best home alarm system available, especially when that money can be
far better spend on important things like my kids college fund.  Yeah, I can
be a little more parinoid without looking foolish, so I can go ahead and
get the el-cheapo alarm system to assuage my parinoia.

This is the same in software development.  There are vulnerabilities around
every corner.  Did you hear the latest PHP vulnerability?  Well maybe we
should stop using PHP because it has proven that it too can be compromised.
It's nice that there was a patch for it very quickly, but the fact that
there was
a potential vulnerability, and hackers could have exploited that
vulnerability
for the few months that it was exposed makes PHP potentially dangerous
and casts the light of doubt that there may be other vulnerabilities that I
am
unaware of but the hackers are.

> > While I don't disagree with the post, I'd just like to point out the the
> > PHP MySQL functions (I don't know about other databases) will only
> > process the first SQL statement passed, preventing such exploits.
>
> True for now.  But, there's no guarantee that'll always be the case -- be
> it intentional or mistakenly.

And that is the case for any technology.  So long as technology continues
to advance, there are new vulnerabilities being built as we speak, and
new existing vulnerabilities being discovered and exploited.  So I might
as well get out of the industry because there's a vulnerability just around
the corner that's going to kill my busness.  I think maybe I'll go into
farming,
now there's a wholesome job where hackers can't destroy my business.
Oh no, there's pests looking to eat my crops, and health extremists who
won't let me use pesticides to protect my crop.  And even mother nature
is standing against me looking to destroy my crop...  Maybe if I just don't
work, yeah, that's the ticket...

> > Yes. And there are every other possiblity as well.  I would hate to see
> > the
> > code that deals with every possiblity.
>
> I don't see what's the big deal about doing some basic validation for each
> bit of user input.  Here's my basic method:

I don't either, but I also don't see the big deal with using JS to do basic
validation on the client because my client wants it.  I make my money
making my clients happy, not making myself happy.

You are also using some basic methods which still can't deal with every
possibility.

  I personally avoid
JS when I can, beyond the visual enhancements, but there are times you
cannot avoid it.  Take for example the guy who took my JS solution over
the server side solutions suggested by us both.  I suspect that he
was having to submit form data to an already existing web site which
meant having to submit the data in the fashion that existing web site
expects.  With a very simple JS he was able to do what he needed. Now
he could have avoided JS and still met the other web sites form interface
by submitting his own form to his own website which then did lookups
or whatever to convert the form data into the expected data, then submit
the form from the server to this existing web site, then retreive the
results
and hand it back to the client, but that is so much more work.

> This process is really simple and eliminates all data corruption.
> In my eyes, it's so easy, there's no reason not to do it.

This doesn't point out the repopulation of the form with the data as entered
by the user, nor does it point out the code necessary to highlight the
fields
in question.  Both of these points on a complicated form can lead to a
few extra hours of development.  These are features that my clients almost
always ask for.  If I am using client side validations, I don't need to
repopulate
the form, the form is never replaced.  with client side validations,
changing
the color of a cell is also quite simple.  If I also do the server side
validations,
I can usually ignore having to code the form repopulation and error
highlighting
because I know that my server side validation is only there to protect
against
a hacker.  I know that the normal use of my form cannot produce invalid data
so why bother with the form repopulation code on the server.

And as simple as your script is, it does not validate the data itself, does
not
take into account range checks, and lookups to see if the data exists( ie.
on
the client I can populate a dropdown with valid choices, that ensures the
user selectes a valid choice.  A hacker can submit whatever they want that
may be the right data type, and in the right range, but not a valid choice )