Tag Info

Hot answers tagged

19

A database may contain malicious code, possibly a procedure that is going to change a password for the "sa" login or drop every database. However the only way that I can see that causing an issue is for an individual to restore the database, and then manually execute any code within that database. It would not execute in any automated manner. There is no ...


16

No. While the documentation currently has the following arguably ambiguous statement about what this flag means: Password policy is checked. What it really means, and should say, is that the flag serves two purposes: The password policy might have been checked, but only if (a) the password policy was enabled at the time the password was last ...


10

There are some prevention steps that you could do. Make sure no one but one sysadmin has access to the restored database. Put the db in single user mode after the restore is completed. Check the code inside all stored procedures and functions and triggers inside this database. Perform a dbcc checkdb to make sure there are no integrity issues. Check ...


10

Here's the line I like to use - it preserves everyone's dignity and lets everyone escape without finger-pointing: "Yes, that used to be a best practice, and..." It’s almost easier to explain that line in terms of what it DOESN’T do. It doesn’t dispute the speaker’s claim, because you don’t want to go down the rathole of arguing about whether or not the ...


9

I'm reaching here, but I can think of at least one dangerous scenario: if you restore a database that has a filetable, those files are now on your network by default (and specifically, on your SQL Server). You could restore a virus. That by itself won't do anything, of course - the virus doesn't suddenly become sentient - but if your users then try to ...


8

Is there a way to trace a SQL session based on the client's TCP port? Yes. You can query sys.dm_exec_connections to identify a session from the client's TCP port (column client_tcp_port). For example: SELECT DEC.session_id FROM sys.dm_exec_connections AS DEC WHERE DEC.client_net_address = '192.168.0.100' AND DEC.client_tcp_port = 63465;


8

This may not be popular among your users, but I believe the only way you can know for sure is to force a password change for every SQL login with CHECK_POLICY = ON. This will generate a set of ALTER LOGIN commands with blank passwords, you can update the query giving them all a common password or manually update each one with individual passwords - just make ...


6

Please see the reference on BOL for Database-Level Roles: db_owner Members of the db_owner fixed database role can perform all configuration and maintenance activities on the database, and can also drop the database. The easiest way to see all of the permissions is to use the sys.fn_my_permissions() function. First verify you are a member of ...


6

RESTORE VERIFYONLY would seem to be a good first step. The ultimate answer is probably 'restore the database in a sandbox VM with no access to the outside world', but let's assume that option is off the table. What else should be done in this situation? Restore verifyonly verifies integrity of database it WILL NOT tell you whether backup includesa ...


6

The question focuses mostly on a backup containing malware, but it's also possible to get unwanted and potentially malicious behaviour from the restore operation itself. I've accidentally found in the past that it's possible to crash SQL Server by trying to restore a corrupt backup file that causes SQL Server to try to read past the end of the backup file ...


6

From the 12c docs: The SYS user is automatically granted the SYSDBA privilege upon installation. When you log in as user SYS, you must connect to the database as SYSDBA or SYSOPER. Connecting as a SYSDBA user invokes the SYSDBA privilege; connecting as SYSOPER invokes the SYSOPER privilege. Oracle Enterprise Manager Database Control does not permit you ...


6

My goal is to execute a command that requires the sysadmin role (DBCC TRACEON(1224)) You are punching a hole in your security by allowing an unprivileged user run as sysadmin role. If you are trying to set 1224 traceflag, which disables lock escalation based on the number of locks, you can do it on table level using ALTER TABLE e.g. Below enables lock ...


6

Multiple ways to get this information: SELECT APP_NAME(); SELECT PROGRAM_NAME(); SELECT [program_name] FROM sys.dm_exec_sessions WHERE session_id = @@SPID; Just keep in mind that it can be spoofed in the connection string or in Management Studio's connection properties. If I connect using the following parameter, all three of the above will return ...


5

It can be done but it's generally considered fairly dangerous. At a very basic level you set the trustworthy flag on the database and then when use you execute as on the sp it can take advantage of it's server level principals security access. Because of how dangerous this is I don't want to go into any detail here. However I've blogged about it here ...


5

Risk mitigation would indicate creating a separate account for each service on each machine. The level of work required to create the accounts necessary is extremely minimal, but the unknown risks that accompany not doing so are quite high, according to Microsoft's own recommendations. Microsoft Best Practices recommend using separate service accounts for ...


5

we're going to allow an external partner (i.e. not an employee of our org) access to this server, like so: Their credentials will own (belong to db_owner) a couple databases. A concern along with the service account being the same on multiple instances is that an outside entity can escalate their permissions quite easily. Given that outside entity is ...


5

Ensure you have a mountain of documentation, both of your current system's flaws, and how to fix them. It's no use just saying "everything sucks bad" unless you have a plan, and can show real benefits to the business of making the change.


5

You can use a Logon Trigger for that. CREATE TRIGGER TR_check_ip_address ON ALL SERVER FOR LOGON AS BEGIN DECLARE @ip_addr varchar(48) SELECT @ip_addr = client_net_address FROM sys.dm_exec_connections WHERE session_id = @@SPID IF ORIGINAL_LOGIN() = 'bob' AND @ip_addr <> '127.0.0.1' ROLLBACK; END If you try to ...


5

Since you do not know the schema or tables names to grant them to, no to specifically doing it. You can add your AD account to the db_datareader role within the model database, and this should be copied into each database created on that instance. In addition, if databases happen to get created via restore or anything other than create database statement ...


4

For normal roles, permissions for all role memberships are cumulative and DENY takes precedence over GRANT. However, sysadmin is a special case. SQL Server permissions are not checked for sysadmin role members so members of that role have full permissions to all databases on the instance.


4

What risk is there is restoring an unknown database from an unknown source? None. What risk is there in letting an unknown application connect using a sysadmin account to connect to that database and start running code? LOTS! If the application account only has rights within the database and no server level access then there's nothing it can really do ...


4

It's a totally pointless function that executes arbitrary SQL. It isn't SECURITY DEFINER so the only risk I think it can pose is if you allow users to run arbitrary SQL predicates or call arbitrary functions (in which case you're probably already stuffed) but try to block them from running any command they want. As you guessed, it just executes the SQL ...


4

This example shows that your database users can run queries and collect the execution plans within a database where they have been granted SHOWPLAN (and without being added to the db_owner role), as long as the server-level login has not been explicitly denied the ability to ALTER TRACE. It also shows that unless you explicitly grant any trace-related ...


4

Unfortunately no, you can't exclude anything from a backup. If you are talking about Windows Logins then it probably isn't that big a deal. The SIDs won't match anything on their network (very unlikely anyway) so all they will have is the usernames without any of the permissions associated. SQL Logins of course will work fine as long as they create a ...


4

NO, With just Execute permission doesn't allow a user to execute a stored procedure successfully if it contains some DDL (CREATE, ALTER, DROP, TRUNCATE, RENAME) statements.


3

My bias is to use a single table with appropriate row-level security. There are potentially huge maintenance advantages to a single set of tables. If you end up with n copies of each table, that means that you have to run n copies of each script every time you want to make a change. Frequently, that means that you end up with at least a few very slightly ...


3

In Vedran's code which you reference, he also signs the stored procedure in the other database. I do not see in your code that you have taken that final step. Erland Sommarskog has an extensive discussion at http://www.sommarskog.se/grantperm.html of this problem. This includes a discussion of, in his words, "the Problematic EXECUTE AS". In the following ...


3

I took another approach in my case. This is what I did: Create a login and map it to a database. Go to a database an create a schema called Public_View for example. The owner of this schema must be the same owner of the tables that the views are gonna refer. Grant the new user access to the new schema. Create as many views as you want in the new schema and ...


3

If you store encrypted data in the database, the data is not understandable anymore without a layer of code on top. This might seem like a good move, but if one takes a closer look, it complicates things and does not provide more security. An example which becomes a lot more complicated: "Compute the number of phone numbers with a special area code". How to ...


3

If there are faults found since it dropped out of the extended support period then unless you have paid Microsoft for extended extended support you can be pretty sure there is not a fix available to you. Obviously you can mitigate the risk considerably by following standard practise and making sure the only machines that can touch your SQL instance are a ...



Only top voted, non community-wiki answers of a minimum length are eligible