locked
Sql injection problam. RRS feed

  • Question

  •  Guys there is a question in my mind

     please solve if u can.

     If someone hacks my online database from sql injection(After querying from any text box which is supplied on any page of my website for registration purpose or anything else).

    So Can i tress his/her ip address that from where query was supplied.

    Thanks a ton.
    Monday, January 17, 2011 12:58 PM

Answers

  • SQL Server knows only the client IP, which is that of your web server since it is the web code that connects to the database rather than the end client.  If you are using IIS and enable logging, the client IP of the end user will be logged.  The exact log file location may vary depending on your OS.  On my system, the default location is %SystemDrive%\inetpub\logs\LogFiles.

    Regarding SQL injection, you can mitigate security concerns simply by using parameterized statements rather than building SQL strings by concatenating user input.  This is a best practice.  Additionally, other exploits like cross-site scripting can be avoided by encoding untrusted input before sending it to the client browser.  See http://msdn.microsoft.com/en-us/security/aa973814.

     


    Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/
    Monday, January 17, 2011 2:58 PM

All replies

  • You can trace the details of DDL queries by reading the Default Trace and DML queries using Change Data Capture.


    Pradeep Adiga
    Blog: sqldbadiaries.com

    Recent posts on my blog
    Monday, January 17, 2011 1:44 PM
  • SQL Server knows only the client IP, which is that of your web server since it is the web code that connects to the database rather than the end client.  If you are using IIS and enable logging, the client IP of the end user will be logged.  The exact log file location may vary depending on your OS.  On my system, the default location is %SystemDrive%\inetpub\logs\LogFiles.

    Regarding SQL injection, you can mitigate security concerns simply by using parameterized statements rather than building SQL strings by concatenating user input.  This is a best practice.  Additionally, other exploits like cross-site scripting can be avoided by encoding untrusted input before sending it to the client browser.  See http://msdn.microsoft.com/en-us/security/aa973814.

     


    Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/
    Monday, January 17, 2011 2:58 PM