NYCPHP Meetup

[Jim Hendricks]

> Ah.  From the initial post, it wasn't clear you were talking about an
> intranet.  Sure, that secures you from outside crackers.  But, that
> doesn't save you from malicious employees, which are responsible for the
> vast majority of attacks.
Aparently not vast enough for my clients to pay for increased security.  I'm
also not dealing strictly intranet.  Some of the systems I have been a part
of
have included subscription services over the internet, data query systems,
and specialized e-commerce solutions.  In all cases my clients have always
asked for a login process which allows tracking who is doing what & allows
an admin choosing what parts of the system a user can get to.

> > Can someone meet the bill?  Sure.  But how about calculating the odds.
> Agreed.  All of what I'm talking about is unlikely, but possible.
Yes, possible.  But not such a rampant problem as to dismiss out of hand
the use of JavaScript validation without server side validation as a huge
problem.  Depending on what my client wants and is willing to pay determines
what level of validations they will get.  My initial low cost approach is
server
side validation only.  If they don't want the refresh between validation and
the error, or want field level validations rather than form level
validations, then
I go for the javascript validations.  If they want both the cleaner GUI and
the extra security of ensuring a malicious person doesn't attempt to put in
stuff, then I go for both.

> I'm not talking about putting in bogus data.  I'm talking about totally
> screwing up the system.  Let's say your intranet form updates the name of
> a user.  The user input is used to create a query string:
>
>   UPDATE Users SET Name='$Name' WHERE UserID=$UserID
>
> $UserID is usually a number.  But, what if the system allows me to alter
> $UserID to be "3; DELETE FROM Users WHERE 1=1"  If your db permits
> multiple queries in one request, then there goes all your data.
This is relying on a knowledge of the code on the server.  The assumption
is that multiple queries can be done in one request.  I must admit, all the
work
I have done in the past has been via ASP, JSP, and proprietary Java Servers
in which multiple queries is not an option.  PHP is a newer technology for
my
company, and I was unaware that a PHP query could allow multiple queries in
one statement.  Your vulnerability also assumes that the data field is at
the
end of the statement. Without knowledge of the server side code, an intruder
is just playing in the dark in the hopes of finding a field that ends the
statement
so they can tag along another malicious query.  Once again, it comes down
to all things are possible, but if I am always programming for every
possibility, I
will never get a completed application.  As a programmer I must choose the
level of safety in my code that I am attempting to achieve & program for
that.
Once again also, what the client is willing to pay certainly determines how
much
code safety they will get.

> Or, if someone puts "'3'" into $UserID and your database doesn't like that
> and your script doesn't gracefully capture the error, sensitive server
> configuration information could be revealed.
Yes.  In any situation where we have rules defined on the server we require
proper error handling to insolate the user from the internals.

> Then there are buffer overflow possibilities.  If the size of user input
> isn't checked, they could sumit some outrageiously long string which could
> trip up some function in the receiving script or database server _IF_ (of
> course) one of those components has a vulnerability.  But, as we all know,
> vulnerabilities do pop up all the time.
Yes. And there are every other possiblity as well.  I would hate to see the
code
that deals with every possiblity.


> > That
> > doesn't mean I can forget about security, it's just that why build Fort
Knox
> > to ensure
> > someone doesn't steal my penny?
>
> But putting data validation into an application doesn't add all that much
> to a development effort.
I put no more effort into an application than what the customer is willing
to pay.
And this whole thing started with your attitude that maintaining 2 code sets
were unacceptable, that having javascript validations on the client, and php
or
some other validation on the server is a waste of time and effort.  If you
are
successful at your business ignoring the benefits of Javascript, than that
is your
business.  I am glad you are so successful.  But don't denegrate the
successes of
others who use Javascript on the client, or who choose to safety down their
code
because that's what a client wants.  Especially when this thread was started
by
a request for a newsgroup which deals in Javascript.  Your response seemed
very negative against Javascript as if a programmer is not worth his salt if
he
chooses to use javascript.


> Misunderstanding here...  I'm not talking about my hiring you to design a
> site for me.  I'm talking about retail websites I come across on the net.
> They're in business to sell things to the public.  If I need JS to do
> buisiness with them, I take my business elsewhere.
Yes, misunderstanding.  But your taking your business elsewhere just because
a web vendor requires JS is your choice and a choice I am sure web vendors
consider when they choose to put JS into their web apps.  Seeing the
preponderance of JS assisted web sites, I would be led to beleive that the
average vendor considers this of little importance, or have the money to
provide
both a rich JS assisted GUI and a less rich HTML only GUI.  Just the same,
this is not of my concern, I do not make my money off the apps, I make my
money off the development of the apps.  My client chooses the technology
they
are comfortable with.  BTW, I had an ASP client who was anti-JS. I developed
and app or 2 for them that has a pure HTML GUI with some CSS mixed in.
They asked for a particular type of application which my company has done
before so I pointed them to the URL to see the app.  They saw the app, loved
it,
wanted a similar app.  As we discussed the app, they would say they wanted
it to work like the other app, but we would have to say, well, that feature
is done
with Javascript, so we would have to rewrite that feature without the
Javascript
and we couldn't guarantee that the replacement GUI would be as responsive
or user friendly.  They initially accepted that until they saw the time
estimate.
It's funny how a price tag can change a clients mind about a technology.  We
ended up doing the project with the JS.

> > > Nope.  If a firm doesn't trust my professional judgement, we're not
meant
> > > to be doing business together.
> > Dan, I'm sorry you take such a hostile approach to application
development.
> > Our
> > clients pay to have applications developed the way they want them.  If
my
> > clients
> > don't want to respect my professional judgement, that's thier business,
>
> I hear you.  I don't like having my name associated with projects I can't
> stand behind.
>
> I do have one, though.  The backend and interface I created rocks, but the
> stuff the client is doing is lame.  But I'm getting _PAID_, if you know
> what I mean. :)
Yes, and that's my whole point.  I don't always like what I have to develop,
I don't
always like what my clients are willing to settle for.  I have developed
applications
that I WILL NOT use as promo for future reference.  But the bottom line is,
I am
a computing whore.  You pay me the money, I give you what YOU want, not what
I want.

Hey, hope I haven't come on too strong, this is all in the name of open
discussion
on development strategy etc.

Have a great JS free weekend.  ( although right now in NJ it's dumping major
buckets of water, boo hoo )

Jim