• Mike C (6/18/2008)


    dobberteen (6/18/2008)


    we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

    rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"

    style of coding.

    Our solution, though very weak IMO, has been to issue:

    DENY SELECT ON syscolumns TO [username]

    DENY SELECT ON sysobjects TO [username]

    This solution has been successful, though I can't help but be concerned about how vulnerable we are to other types of SQL injection. And of course, no one is willing to give the go-ahead to rewrite our thousands of scripts to utilize parameterized queries, include input validation, etc.

    Can't complain about the job security that this particular exploit has given me though 🙂

    Denying SELECT on the system tables is a good idea, but presumably the this username still has permissions to access other tables. These permissions might be SELECT permissions, or possibly more seriously INSERT, DELETE, UPDATE, TRUNCATE or even DDL statements. What you've implemented sounds like a stop-gap measure to defend against that one particular attack. Just remember that nothing in IT is as permanent as a temporary solution.

    I couldn't agree more about the shaky nature of the 'fix' that we've put in place to stop this *one* type of exploit... Again, we've been lucky as this is the only type of attack that we're seeing. I'd hate to see what would happen if someone decided to start guessing object names and then DROPping them - actually, I wouldn't need to see it, I know exactly what would happen.

    I'm sure it's obvious that I'm not a DBA - my role leans much more to the development side... but since I am the only guy at my office w/a modicum of SQL server experience, I am called on to fulfill a quasi-DBA role from time to time. Ah the joys of working in a tiny shop! 🙂