Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 New to SQL Server Administration
 Is this safe to do?

Author  Topic 

SergioM
Posting Yak Master

170 Posts

Posted - 2014-04-17 : 18:25:04
My company has created a custom software which is hosted on our server. Our users connect through remote desktop onto the server with the software. That server, then uses windows authentication to query a database on another server & displays the results. The users do not have the ability to install software while remotely connected.

Is this a safe practice?

It feels to me as if someone with enough knowledge could just find a way to query the db with powershell. Is that possible if it's authenticated through windows (as opposed to a login name & pw)?

-Sergio
I use Microsoft SQL 2008

Bustaz Kool
Master Smack Fu Yak Hacker

1834 Posts

Posted - 2014-04-17 : 19:35:45
In general, Windows authentication is considered better than a User/Passsword mechanism for security. A few questions:
1) When the user remote desktops to the Application Server do they connect as themselves or through another account?
2) When the user brings up the application, do they do so as themselves or is there a login?
3) When the Application connects to the database, is it using its own credentials or is it piggybacking on the User's security context?

===============================================================================
“Everyone wants a better life: very few of us want to be better people.”
-Alain de Botton
Go to Top of Page

SergioM
Posting Yak Master

170 Posts

Posted - 2014-04-18 : 10:34:58
quote:
Originally posted by Bustaz Kool
1) When the user remote desktops to the Application Server do they connect as themselves or through another account?

Here the user connects through another account. There is a fancy verification system where a whitelisted phone number has to text a line and is answered with a password.

quote:
Originally posted by Bustaz Kool
2) When the user brings up the application, do they do so as themselves or is there a login?

The application runs without additional authentication. The thing that made me seriously doubt a security issues is that the security for that app is in a plain text XML file with clearly labeled sections. So I created a low level account, then logged in as the user and removed the name from the things that said "block" and the name to the things that said "allow". So security within the tool is worthless. But I'm wondering if anything else was left exposed. It was too expensive to see such a major oversight.

quote:
Originally posted by Bustaz Kool
3) When the Application connects to the database, is it using its own credentials or is it piggybacking on the User's security context?

Piggybacking. I have found the server name & database name in the XML files. I know that it's connecting using windows authentication.

The part that leaves me unsure is that since *I* can't figure out how to do it, maybe it's not possible. But I'm not an expert on network security and these do seem like large holes in security. I'm wondering if restricting the ability to install software is enough to keep the whole thing safe in spite of these holes.

-Sergio
I use Microsoft SQL 2008
Go to Top of Page

Bustaz Kool
Master Smack Fu Yak Hacker

1834 Posts

Posted - 2014-04-18 : 13:31:14
If the security for the "app is in a plain text XML file with clearly labeled sections", I don't think you need to look any further to see if a flaw exists. If the application is using the User's Windows authentication then the database is as exposed as the User has rights. If the User gets to the database directly (easy to do since the Server and Database names are exposed in the XML), they are as dangerous as their rights allow. It's not clear to me what the "block" and "allow" are referencing but it sounds like even a low level user can alter their security profile. This, to be clear, is bad.

===============================================================================
“Everyone wants a better life: very few of us want to be better people.”
-Alain de Botton
Go to Top of Page

SergioM
Posting Yak Master

170 Posts

Posted - 2014-04-18 : 14:34:43
quote:
Originally posted by Bustaz Kool

If the security for the "app is in a plain text XML file with clearly labeled sections", I don't think you need to look any further to see if a flaw exists. If the application is using the User's Windows authentication then the database is as exposed as the User has rights. If the User gets to the database directly (easy to do since the Server and Database names are exposed in the XML), they are as dangerous as their rights allow. It's not clear to me what the "block" and "allow" are referencing but it sounds like even a low level user can alter their security profile. This, to be clear, is bad.


We're on the same page there. But my question is slightly different. I already know that the tool used for querying can be manipulated easily. However the queries can't be changed. So even with the highest privileges within that tool, you are still confined to a small series of tables.

The database which has those tables has others as well. So while it's dangerous to let every user see things like the sales of another user or the discounts, it would be infinitely worse if someone came along and saw all of our costs or our vendors. Those things are stored in tables that the custom software was not designed to view. So escalating the privileges wouldn't change anything. My fear is that (especially using powershell, which I am not familiar with) that someone can query any part of the database having the db name, server & windows authentication

-Sergio
I use Microsoft SQL 2008
Go to Top of Page

Bustaz Kool
Master Smack Fu Yak Hacker

1834 Posts

Posted - 2014-04-18 : 15:51:44
PowerShell is not the issue. It's just another way to run code. You'll still need to Login to the SQL Server. From there, based on your authorization, you connect to a database as a User and are limited by those authorizations. The danger, as I see it, is that the application might, de facto, limit what a User can do. For instance, a User might have SELECT rights to a table (Salary) but the application limits the scope to just "my salary". Once the User connects directly, the available data is not limited; the whole table is visible. This gets worse if the User could UPDATE or DELETE items in the table.

===============================================================================
“Everyone wants a better life: very few of us want to be better people.”
-Alain de Botton
Go to Top of Page
   

- Advertisement -