To restore a database using the procedure SP_RESTOREDATABASE or AdsBackup utility, you need to provide the ADSSYS password as a parameter. We have secured our database using encryption and access is resctrited to specific users. But anyone using Data Architect can retrieve the ADSSYS password while the restore is taking place in the ACTIVE QUERIES tab under the Remote Server Info/Advantage Management Utility. The password appears as clear text. If query logging was enabled, I suppose it would be available in the log as well.
Is there a way to prevent a query from being shown in the log or the active queries window?
You should use a parameterized query. In that case, the parameter values will not be visible:
execute procedure sp_restoredatabase( :backuploc, :password, :restoreloc, null );
Then supply the values for the parameters backuploc, password, and restoreloc.
Note too that v11.0 restricts the visibility of that information in general. It requires a DB:Admin connection to a dictionary in order to view any statements executed on that dictionary.
Related
I am using OpenLDAP provided in osixia/openldap docker image (https://github.com/osixia/docker-openldap) but it is storing all passwords hashed.
Normally it will be desirable but I am planning to hash passwords on front end (with salting and MD5) so no person in the organization never gets to see the users passwords, but when I try saving them they are hash again, I have not find a way to prevent this behavior.
I try deleting (using user cn=admin,cn=config) an entry that comes with the image called cn={4}ppolicy,cn=schema,cn=config which I think may be the culprit but ldapdelete returns Server is unwilling to perform (53).
Any help is deeply appreciated.
If you store the password in plain text you can retrieve them in plain text.
You just need to check in the ACL that the user you use to read them have the correct rights to do it.
The password policy entry you are talking about is just a schema definition which allows you to define a password policy but does not enforce anything. (The 53 error is because you can't remove a schema from a running OpenLDAP to prevent removing a schema which could be used by an entry)
According to what I can see in github about the docker image you use, the ACL used is :
olcAccess: to attrs=userPassword,shadowLastChange
by self write
by dn="cn=admin,{{ LDAP_BASE_DN }}" write
by anonymous auth
by * none
Which means that only the user himself or the admin account can read the password field userPassword
It is this ACL that you need to modify to suit your needs. The ACL should be located here :
dn: olcDatabase={1}{{ LDAP_BACKEND }},cn=config
Windows 10, Access 2016
I am moving a very small database (14 tables and 40-50 stored procedures) from SQL Server to Access. I have tried to recreate the stored procedures from code using an OLEDB command object. This is a sample of a CommandText…
CREATE PROCEDURE DeleteOrderDetailByOrderID
([#ID] int)
AS
DELETE FROM OrderDetails
WHERE (OrderID = #ID);
I get an error message that the Data Type of #ID is incorrect. It is not. When I remove the brackets from #ID all is forgiven and the code runs. However, Access strips the # from #ID in the parameter section (not in the Where clause). I have had to go into Access and manually correct this. I do not like the idea of going through almost 5000 lines of code to correct parameter names in my program. I thought I could use the direct approach by pasting the SQL directly into Access but I get an error with this route saying syntax error in CREATE TABLE and it highlights the word PROCEDURE. This leads me to believe that you cannot use CREATE PROCEDURE directly in Access. Is this true? Is there another approach that I am missing?
You are missing, that T-SQL of SQL Server is not Access SQL.
Access has UDFs - user defined functions - that can be used in queries also, but that is VBA code.
If you just need a single-user file based database to hold your data, you may get away with the SQL Server Compact Edition which supports a subset of T-SQL.
I have a User's information which I have stored in a Hash. I have his permission information stored in a Set.
I want to test for a condition on the Set, retrieve the Key and then fetch the actual Value using the retrieved Key from the Hash.
How can I do this?
Do I have to use Lua scripting to achieve the above goal or is there any other way?
You'll have to do it using multiple requests in that case. While Lua appears to be the way, your requirements - namely fetch a key based on the value of another key - rule out a single script since key names should be passed explicitly.
I had the same requirement and I couldn't find any other way to do this. Redis pipeline and transaction functions are other tools to execute multiple commands in single step but for your situation where you want to get a value and execute a command based on it, the only way remains is LUA!!
you can use a hash to handle user information and his permissions (in the same hash). In this case, when you have a userId you can retrieve the permissions with one shot by using userId and permissionKey. See example below, I put the permissions as string (in your case put it as Set):
redis> HSET userId permissionKey "perm1, perm2, perm3"
redis> HGET userId permissionKey
"perm1, perm2, perm3"
Hope this help you.
We ran the Fortify scan and had some Access Control: Database issues. The code is getting the textbox value and setting it to a string variable. In this case, it's passing the value from the TextBox to the stored procedure in a database. Any ideas on how I can get around this Access Control: Database issue?
Without proper access control, the method ExecuteNonQuery() in DataBase.cs
can execute a SQL statement on line 320 that contains an attacker-controlled primary
key, thereby allowing the attacker to access unauthorized records.
Source: Tool.ascx.cs:591 System.Web.UI.WebControls.TextBox.get_Text()
rptItem.FindControl("lblClmInvalidEntry").Visible = false;
ToolDataAccess.UpdateToolData(strSDN, strSSNum, strRANC, strAdvRecDate, strAdvSubDate, strClmRecDate, strClmAuth, strClmSubDate, strAdvAuth, txtNoteEntry.Text);
Sink: DataBase.cs:278
System.Data.SqlClient.SqlParameterCollection.Add()
// Add parameters
foreach (SqlParameter parameter in parameters)
cmd.Parameters.Add(parameter);
The point of "Access Control: Database" is where it isn't being specific enough in the query and so could potentially allow a user to see information that they're not supposed to.
An easy example of this vulnerability would be a payroll database where there is a textbox that says the ID of the employee and gives their salary, this could potentially allow the user to change the ID and see the salary of other employees.
Another example where this is often intended functionality is in a website URL where the product ID is used in a parameter, meaning a user could go through every product you have on your site. But as this only allows users to see information they're supposed to be able to, it's not particularly a security issue.
For instance:
"SELECT account_balance FROM accounts WHERE account_number = " + $input_from_attacker + ";"
// even if we safely build the query above, preventing change to the query structure,
// the attacker can still send someone else's account number, and read Grandma's balance!
As this is pretty context based, it's difficult to determine statically so there are lots of examples where Fortify may catch this but it's actually intended functionality. That's not to say the tool is broken, it's just one of the limitations of static analysis and depending on what your program is supposed to be doing it may or may not be intended.
If this is intended to work like this, then I would suggest auditing it as not an issue or suppressing the issue.
If you can see that this is definitely an issue and users can see information that they shouldn't be able to, then the stored procedure needs to be more specific so that users can only see information they should be able to. However SCA will likely still pick this up in a latter scan so you would still then need to audit it as fixed and no longer an issue.
I would like to create a generic logging solution for my stored procedures, allowing me to log the values of input parameters. Currently I am doing this more or less by hand and I am very unhappy with this approach. Ideally, I would like to say something like the following:
"given my spid, what are my input parameters and their values?"
This is the same information exposed to me when I run SQL Profiler -- the stored procedure's name, all input params and all input VALUES are listed for me. How can I get my hands on these values from within a stored procedure?
Thanks;
Duncan
That is going to be difficult to do within a stored procedure. SQL profiler runs under a different SPID and runs a statement like this to capture the other users statements:
DECLARE #handle VARBINARY(64)
SELECT #handle = sql_handle from sys.sysprocesses where spid = #SPID
SELECT text FROM sys.dm_exec_sql_text(#handle)
The problem is if you run this in a stored proc for the current SPID all your going to get back is the statement above. I don't believe SQL server provides a T-SQL construct to execute a batch under a different SPID. I suppose you could write a .Net dll stored procedure that executes a batch on a different connection. to do that sort of thing but it may be more trouble than it's worth.