What can help is if one app only has access to it's own DB. Also, for mysql, there is the mysql_real_escape_string function for a reason. Also, for the web app, you can usually disable Administrative functions and grant a minimal set of permissions. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com Robert Cummings 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. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
