Page 1 of 3 123 LastLast
Results 1 to 15 of 33
  1. #1
    Join Date
    Jan 2013
    Posts
    35

    SQL Injection and SPs

    Hi,
    I need some information from someone that is an expert in MSSQL and SQLI.
    I wanted to know if SQLI is possible through systematic stored procedures of MSSQL?

    Thanks,

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    14,922
    SQL Injection occurs because of an insecurely written app running on the client. Nothing you can do on the SQL Server can affect SQL Injection because it has already occured before SQL Server even receives the SQL statement from the SQL Client.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  3. #3
    Join Date
    Jan 2013
    Posts
    305
    Your best bet is to keep the interface as procedure calls between the DB and the application code. If the procedure is properly written, it will disallow bad data, free text, etc.

  4. #4
    Join Date
    Jan 2013
    Posts
    35
    Thanks to both replies.
    I have a question for Celko.
    You mean that systematic SPs are safe from injection?

  5. #5
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    14,922
    If your front end code is vulnerable to SQL Injection, then any database is vulnerable to SQL Injection (even if the database doesn't run SQL at all).

    Any application that sends unchecked, unprotected strings to a database server is vulnerable to injection. It doesn't matter what the developer thought that the code ought to do/run/etc. That isn't relevant.

    All code, of any kind on a database server is vulnerable to injection attacks from a weak front end application.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  6. #6
    Join Date
    Jan 2013
    Posts
    35
    Thanks Pat.
    I agree with you but shouldn't systematic SPs be secure? because we have vulnerability where ever human (programmer) comes in the middle.

  7. #7
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,566
    Quote Originally Posted by Pat Phelan View Post
    SQL Injection occurs because of an insecurely written app running on the client. Nothing you can do on the SQL Server can affect SQL Injection because it has already occured before SQL Server even receives the SQL statement from the SQL Client.

    -PatP
    Not "quite" true...
    ...you could disallow all access to the database tables except through sprocs and views.

    I've yet to see an application architect willing to give up these privileges without a fight, though.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  8. #8
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,511
    If your front end does not use command and parameter objects to encapsulate the arguments of the stored procedure, and instead simply concatenates the stored procedure and arguments as a single string, you have a SQL injection vulnerability, no matter what procedure is being called, "systematic" or otherwise.

  9. #9
    Join Date
    Jan 2013
    Posts
    35
    Thanks,
    Do you think I could find a list of systematic SPs that could be vulnerable to injection or I have to manually search?

  10. #10
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,511
    Define "systematic", please.

  11. #11
    Join Date
    Jan 2013
    Posts
    35
    I mean the system SPs (with the sp_ or xp_ prefix) of MSSQL.

  12. #12
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,511
    Anything that the application user has access to is available in a SQL Injection attack. If you run your application as sa, or another admin account, all of them could potentially be invoked. As could any statement like "drop database msdb", or "create backdoor login..."

  13. #13
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,566
    To prevent SQL Injection you would need to lock down all your tables, allow access only through direct calls to stored procedures, and ensure that none of your stored procedures issue dynamic sql statements with concatenated strings created from either procedure parameters or character-based data columns.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  14. #14
    Join Date
    Jan 2013
    Posts
    35
    Thanks to everyone that has sent an answer.
    Many thanks,

    I wanted to ask blindman what do you mean by direct call of SPs?

  15. #15
    Join Date
    Jan 2013
    Posts
    35
    Quote Originally Posted by blindman View Post
    To prevent SQL Injection you would need to lock down all your tables, allow access only through direct calls to stored procedures, and ensure that none of your stored procedures issue dynamic sql statements with concatenated strings created from either procedure parameters or character-based data columns.
    What do you mean by direct call to Sp?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •