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. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
