How can I make my SQL statements not to appear in Profiler ?
They contain sensitive information and I don't want them to
show in Profiler.
Thanks for the replies !
The profiler can only be run by someone with proper rights so if your installation is properly secured you should be fine (no users should be able to profile your application).This goes beyond security, since profiler slows down the server considerably.
There is no way. The "text" column in profiler can not be removed from use.
You need rights to run profiler (sysadmin or GRANT ALTER TRACE) so it's not an implicit right.
Note:
sysadmins could decrypt stored procs or add logging code, regardless of whether they run profiler
physical access needs controlled, at least to stop someone taking a copy of the database away
things like sp_password or ALTER LOGIN are not traced anyway
Only way I can think of to do this would be to make them stored procedures (The profiler would only show the call), but if the arguments are what's secure (which is likely) then that won't help you (Edit: As pointed out in comments you can change the config of the profiler to include this anyway, so this won't help much)
Have you considered not giving access to people not allowed to view the data? Access to run the profiler is a pretty high level of access...
Also, have you considered hashing your data before storing/querying it? Sometimes that won't work, but if we're talking passwords then they really should be stored and looked up in an encrypted form anyway.
I've noticed if you use the encryption functions build into SQL (Written about at https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-encryption?view=sql-server-ver15) like ENCRYPTBYPASSPHRASE, the text is not shown in profiler - I'm not sure if this is 100% fool proof but it does fit the question.
Example...
Related
My boss and I have been trying to see what sort of auditing plan we could try for our stored procedures. Currently there're two external applications taking information from our database through stored procedures and we're interested in auditing when they're being executed, and what values are passed as parameters. So far what I've done is simply create a table for the stored procedures one of the apps is using, and as they use the same input parameters, have one column per parameter. Obviously this isn't the best choice, but we wanted to get quick info to see if they were running batch processes and when they were running them. I've tried SQL Server Audit, but it doesn't catch the parameters unless you're executing a SP in a query.
SQL Server Profiler will do this for you; its included for free. Setup a trace and let it run.
You can also apply quite a bit of filtering to the trace, so you don't need to track everything; you can also direct the output to a file, or sql table for later analysis. This is probably your best bet for a time limited audit.
I think I've used the SQL Server Profiler (http://msdn.microsoft.com/en-us/library/ms181091.aspx) in the past to audit SQL execution. It's not something you would run all the time, but you can get a snapshot of what's running and how it's being executed.
I haven't tried using them, but you might look at event notifications and see if they will work for you.
From BOL
Event notifications can be used to do the following:
Log and review changes or activity occurring on the database.
Every time I run a query, my database does not respond to an immediate second query and complains that it is in recovery mode (though it does not show anything beside the database name). This happens for about 5-10 minutes after which everything goes back to being normal.
I am expecting a major crash so I am copying the tables into a different database but anyone knows why this could happen or if there is a permanent fix?
Normally, a database is only in "Recovery" mode during startup - when SQL Server starts up the database. If your database goes into Recovery mode because of a SQL statement, you almost definitely have some sort of corruption.
This corruption can take one of many forms and can be difficult to diagnose. Before you do anything, you need to check a few things.
Make sure you have good backups of your database - copied onto a separate file system/server.
Check Windows Event Log and look for errors. If any critical errors are found, contact Microsoft.
Check SQL Server ERRORLOG and look for errors. If any critical errors are found, contact Microsoft.
Run chkdsk on all the hard drives on the server.
Run dbcc checkdb against your database. If any errors are found, you can attempt to fix the database with the REPAIR_REBUILD option. If any errors could not be fixed, contact Microsoft.
Restore a backup copy of your database onto a different server. This will confirm whether it is a problem within your database or the SQL Server/machine.
After step #4, #5, and #6, run your queries again to see if you can cause the database to go into Recovery mode. Unfortunately, corruption can occur because of an untold number of reasons, but more important than anything is the data. It will confirm whether it is a problem with your data or elsewhere. As long as you have backups that can be restored to a different SQL Server and a restored copy does not continually go into Recovery mode, you don't have to worry too much.
I always put Number 6 last because setting up a separate server with SQL Server and moving/restoring a large database can take an extensive amount of time; but if you already have a backup/test server in place, this might be a good first option. After all, it won't cause any downtime with your live server.
Finally, don't be afraid to contact Microsoft over this. Databases are often mission-critical, and Microsoft has plenty of tools at their disposal to diagnose problems just like this.
Late answer...
Does your database have autoclose set to true? When set, the DBMS has to bring the database online which may account for your symptoms
This can happen when the SQL Server Service has gone down hard in the middle of write operations and sometimes during mode during server startup. Follow the query in this link to monitor
http://errorbank.blogspot.com/2012/09/mssql-server-database-in-recovery.html
I've only had this happen when the service (or the SQL Server Service) has gone down hard in the middle of write operations. Once it came back, everything was fine.
However, if this happening often, then I would suspect a disk level failure of some sort. I would make sure the database is fully backed up and move it to another server while you run diagnostics / rebuild the problem server.
Is there any system defined sp is available in SQL Server 2005, to find what are the tables are got affected when the applicaion is running and we are navigating from one page to other.
There's really no easy way (if any at all) to find that out, unfortunately.
As SQL Server MVP Aaron Bertrand puts it in his excellent blog post When was my database / table last accessed? :
A frequently asked question that surfaced again today is, "how do I see when my data has been accessed last?" SQL Server does not track this information for you. SELECT triggers still do not exist. Third party tools are expensive and can incur unexpected overhead. And people continue to be reluctant or unable to constrain table access via stored procedures, which could otherwise perform simple logging. Even in cases where all table access is via stored procedures, it can be quite cumbersome to modify all the stored procedures to perform logging.
However, with the help of the sys.dm_db_index_usage_stats DMV (dynamic management views) function and some clever T-SQL programming by Aaron, you can find out a few of those answers - check out his very enlightening blog post for details !
However: since this information is based on a DMV and the "D" in DMV stands for dynamic, those values are only valid since the last server reboot and will be wiped out and not preserved when you next have to restart your SQL Server process / reboot your server machine.
I know of none, but Profiler offers a solution. Run Profiler (can be a developer box) and navigate. It will create an output file for you of what is being run.
There are also code tools that show dependencies. I would imagine at least one shows dependencies on SQL objects.
I don't think so. You can run the SQL-profiler to see which commands are fired against the SQL server but you will have to parse them yourself.
You could also try to empty the query cache and then look at it when your navigation is done, but this cache will be contaminated by other queries running on the server (including the ones run by SQL server itself).
Is there any way to confirm that a particular breach of security was done through SQL injection?
There is no easy way here, but if you have the enabled the SQL server you use to log every single sql statement, here is what I would do.
Normally, when I SQL inject somewhere, i use one of these as my always true statement for passing throgh the Where clause, after ending the former string.
1=1
0=0
both being used as :
blahblahblah' or 1=1 --
You would not use this clauses in everyday code. So if you spot one of these in your history, well, it is a high candidate. Test the sql history to find :
(space)(number)(optional spaces)(equal)(optional spaces)(same number)(space)
Keep in mind that is heuristical, and will not always work, but could be the only way to give a hint after it had happened . Also, if you are in doubt about SQL injection, you should check the code for string concatenation and use of parameters.
after the attack has already happened? no. there isn't.
you'll have to check all your sql serevr access point for potential risk.
tere are some tools you can use. Check here under SQL Injection tools section.
SQL injection can happen any time you pass a query back to the database.
SQL Injection
Use mod_security to log POST requests and install an Intrusion Detection System to log/stop suspicious activity from now on. Logging every SQL request is an overhead if you are just looking for the breach points.
There are open source alternatives for IDS these days. I use PHPIDS for all my PHP applications.
Only one reliable way is probably analysing the SQL log files. Those should be done by a DBA who can spot things quickly as the size of logs would be huge.
It is better to prevent those.
There are some tools for that but the best one is the brain of the developer.
Stick with one simple rule - always use parameters when generating SQL query.
Just do the code review and if you find string cocatenations - that is first and highly possible place for SQL Injection.
You can log all http requests and check the requested pages for GET/POST sql injection tryouts.
We have SQL Server 2005 database with full backup and transaction logs. We have a problem with the database - and need the SQL CSI Forensic team to help.
Is there a way to look at the transaction logs and identify whether a stored procedure was executed? We know the time that it happened (if it happened) but there is a dispute whether it happened.
Any suggestions. I know we should have been logging - we are obviously thinking about this now.
For updating & deleting data you may be able to figure out what happened using DBCC LOGINFO There are products like apex sql log that will make this analysis much easier. THis will tell you when it happened, but not what user made the call. Although you make have other application level logs (iis logs for example) that may help in this respect.
For selecting or looking at data i'd say you have no chance.
In future if you need this kind of audit trail i suggest you look at SQL's C2 Auditing feature.
There used to be a company called Lumigent that had a program called Log Explorer. I couldn't find the companies web site...and I am not sure if theyr explorer would be able to tell you if a proc was executed...however it would tell you if the statements insite the proc were executed at the time you think they were. If you could find it, Lumigent Log Explorer would probably help.