NYCPHP Meetup

[Analysis & Solutions]

Hi Jim:

On Fri, Jul 19, 2002 at 11:46:44AM -0400, Jim Hendricks wrote:

> There's everything stopping you.  All my systems are built off a proprietary
> security system which first ensures that the person submitting the form is
> logged
> into our system.

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.


> Can someone meet the bill?  Sure.  But how about calculating the odds.

Agreed.  All of what I'm talking about is unlikely, but possible.


> Then of course there is the database.  Our systems
> have
> many different validation checks on the db server.  From relational
> integrity
> checks to range checks to sequential integrity checks etc.  So now not only
> does this hack need to do all the above, but he must figure out what bogus
> data he can get away with putting into our system.

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.

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.

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.


> 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.


> > Perhaps because they figure it's not worth doing business with such a
> > firm.  I certainly don't.
> I didn't ask you to business with my company.  You have your choice.  I have
> been
> very successful without you so far!  And even if you wanted to do business
> with my
> company, it's totally up to you what tech we use for you.  If you want zero
> javascript,
> so be it.

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.



> > 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. :)

Enough for now...

See you,

--Dan

-- 
               PHP classes that make web design easier
        SQL Solution  |   Layout Solution   |  Form Solution
    sqlsolution.info  | layoutsolution.info |  formsolution.info
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
 4015 7 Av #4AJ, Brooklyn NY     v: 718-854-0335     f: 718-854-0409