0

I'm in a discussion with Information Security team about a legacy Desktop Application accessing a SQL Server database directly using LINQtoSQL.

The Information Security team insists that there are many security vulnerabilities in a Desktop application and a SQL Server with open port to network communication.

As a +10 experience developer I can only list this risks involved:

  1. Unsigned Application: company's authority can't be certified allowing attacker to create a copy of the app with malicious codes.
  2. Unobfuscated code: the attacker can decompile the app change its code an inject malicious codes.
  3. Open port: can be exploited with an stolen SQL SERVER user + password to Data leak

But I know how we can mitigate all this issues instead of spending the enormous effort to migrate the whole desktop app (+8 years old) to (intranet) web app.

Do you guys have further arguments against this client server architecture?

  • Maybe see this question security.stackexchange.com/q/229954/90657 Your problem is a bit different since it's internal, but end users directly connecting to the database is similar. – multithr3at3d May 2 at 20:20
  • Got you. But this is not my point. The options here are: – RobertoOSantos May 2 at 20:45
  • 1. How can I make my desktop app secure or 2. What are the risks that justifies rewriting and test the whole app? – RobertoOSantos May 2 at 20:47
  • 1. It's not about making the desktop app secure; the backend (SQL server or whatever) needs to be secured 2. See my answer and the answers in the other question – multithr3at3d May 2 at 21:25
0

Unsigned Application: company's authority can't be certified allowing attacker to create a copy of the app with malicious codes.

Keep in mind an attacker could do the same with a web application if it isn't properly secured with TLS.

Unobfuscated code: the attacker can decompile the app change its code an inject malicious codes.

Obfuscated code is a relatively small hurdle for somebody who is already motivated enough to reverse engineer it. I'm not really sure what would be changed or injected in this case.

Open port: can be exploited with an stolen SQL SERVER user + password to Data leak

Your users likely have access to credentials for the database, whether they are hardcoded in the app or user provided.

I think the real issue is that the database is directly exposed, and your infosec team is probably worried about access controls and auditability. A web application abstracts away the database and allows for business logic to be put in place. You don't want users to, for example, either maliciously or accidentally, delete the entire database, modify all records, add questionable/unvalidated data etc. Or maybe users should have these permissions, but you want a detailed log of who, what, and when.

While some/all of these things may be possible with the database's built-in controls, it will likely be much more complex to manage and more error-prone. I think it depends how much effort you are willing to spend configuring a database versus creating a web application. It also depends on the trust level of the users who have access.

This question and the answers discusses this issue in much further detail.

Also, a desktop application is not sufficient to employ controls and validations, as it is under control by the [untrusted] user. Client-side logic can be modified or bypassed entirely with a direct connection to the server or by changing the application. Credentials and other "secret" information buried in a client-side application can almost always be recovered. If it's encrypted, it can easily be grabbed out of memory when it is used. Or, if network comms to the database aren't encrypted, it could be sniffed there. For these reasons, any important logic must always be validated on some sort of server backend.

| improve this answer | |
  • There is a corporate component used inside the desktop app to connect to the database. The application users do not have SQL SERVER users. There is a generic user with encrypted password and connection string to avoid the credentials leak – RobertoOSantos May 3 at 6:18
  • This generic users has a role to DML only and there are controls and validations on the application to avoid unwanted changes to the data. – RobertoOSantos May 3 at 6:22
  • @RobertoOSantos answer updated to address that – multithr3at3d May 3 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.