On Thu, Jul 17, 2008 at 2:48 PM, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > 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. No, not unless you really need that level of security. Simply by creating procedures and granting execute permissions only to a single web user account would go a long way to eliminating SQL injection. The query will fail if a malicious user tries to insert anything that doesn't fit into the parameter. Even if someone tried to truncate your SQL statement by sending something like "; DELETE * FROM users" it would fail because that account would not have permission to run the ad hoc statement. I know there are some cases where the number of possible permutations of search parameters means you pretty much have to allow ad hoc queries, but you can make that the exception rather than the rule. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
