> -----Original Message----- > From: Andrew Ballard [mailto:aballard@xxxxxxxxx] > Sent: Thursday, July 17, 2008 11:33 AM > To: PHP General list > Subject: Re: is there a problem with php script pulling HTML out > of database as it writes the page?? > > On Thu, Jul 17, 2008 at 12:02 PM, Stut <stuttle@xxxxxxxxx> wrote: > > > > On 17 Jul 2008, at 15:31, David Giragosian wrote: > > > >> On 7/17/08, Stut <stuttle@xxxxxxxxx> wrote: > >>> > >>> On 17 Jul 2008, at 14:10, tedd wrote: > >>> > >>>> At 10:28 PM +0100 7/16/08, Stut wrote: > >>>> > >>>>> Oh, and you'd be working for me so bear that in mind ;) > >>>>> > >>>>> -Stut > >>>>> > >>>> > >>>> It's no wonder why you haven't found anyone. :-) > >>>> > >>> > >>> Thanks for that tedd. > >>> > >>> Seriously though, I'm wondering if my expectations are too high... > I > >>> expect > >>> them to know that addslashes is not adequate protection against SQL > >>> injection. I even had one tell me "SQL injection? I can't remember > but > >>> I'm > >>> sure I've used it before". And I won't even go into the guy who > asserted > >>> that he's always worked with DB administrators who've dealt with > security > >>> issues so he'd never needed to learn about it. > >>> > >>> Am I expecting too much?!? > >>> > >>> -Stut > >> > >> > >> Surely you're being rhetorical, Stut, but no, you're not expecting > too > >> much. > >> However the guy(s) who worked in a larger organization likely did > have a > >> very clear delineation of roles and responsibilities, as I am > experiencing > >> in a new position, and therefore may not be current on best > practices in > >> areas outside of their role. When my group leader instituted the > current > >> policy regarding job functions, a number of the open source guys > decided > >> their unused skills were eroding and/or they were not being exposed > to new > >> learning, and they left the company. > > > > There's no way I would ever hire anyone who says "security was > somebody > > else's responsibility". I don't care what their previous managers > have said, > > that's never a valid statement in my book. When you then add the fact > that > > no DB admin no matter how good they are can implement adequate > security to > > prevent SQL injection you get a developer who doesn't care about > security > > issues much less know anything about them. > > > > -Stut > > > > A DBA can go pretty far to prevent SQL injection by setting > appropriate rights on the accounts that applications will use to > interact with the database: denying direct access to tables, allowing > access to only the necessary stored procedures, thereby forcing > developers to design products using only those procedures for all data > access. Of course, a lot of developers would complain under this level > of security, and I suspect a lot of frameworks that are out there > would be much less "useful" to lazy programmers. ...and giving procedures that only need read access--wait for it--only read access! I have seen so many pages from work I've done on crowd-sourcing websites that use one (practically) super-user DBMS account to read one or two columns from one or two rows and display them. It boggles the mind. Todd Boyd Web Programmer
