On Thu, 2008-07-17 at 12:32 -0400, Andrew Ballard wrote: > 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. So are you suggesting a web app make multiple different user account connections to the SQL server depending on whether it wants to SELECT, INSERT, DELETE, ETC.? I means that's a fair proposition... just seems a tad heavy duty. Once again though... there's a programmer responsibility here to implement the application with such a scenario in mind. most applications need access to SEELCT, INSERT, and DELETE. In such a case, a single account with restricted access permissions that allow all three isn't going to do anything for the application if a programmer let's an SQL injection through. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
