Securing .NET Framework Applications Against SQL Injection: Unraveling Windows SSL Vulnerabilities
I have developed a .NET Framework 4.7.2 Windows application that utilizes a SQL Server database. In this application, I have employed the SQLClient package to establish connections to the database. The connection parameters include encryption, ensuring that queries in outbound traffic remain concealed from the Microsoft Network Monitor and Wireshark.
However, a vulnerability was discovered when employing the Echo Mirage tool, enabling SQL injection or hooking into the .NET app process on Windows. This allowed for the viewing and alteration of queries using the tool. Through my analysis of the SQL injection tool's traffic log, I identified three types of hooked modules: Windows Socket, OpenSSL, and Windows SSL.
When configuring Windows Sockets, I observed that the traffic protocol was TCP, and the queries were encrypted, providing a secure environment. However, configuring Windows SSL revealed a vulnerability. I could view and modify queries by injecting the process in Windows, and the protocol was displayed as "???" with source and destination set as 0.0.0.0.
I lack sufficient knowledge about Windows SSL and seek guidance on preventing this vulnerability. Any ideas or suggestions would be greatly appreciated.
17 Replies
You mean your desktop application just connects straight to a database on some remote server?
Yeah
There isn't anything you can do, then
The user could as well just read the application's memory to figure out the connection string
That's why you never connect directly to the database, but rather introduce an API layer
That limits what the user can do, and most importantly, prevents them completely from executing arbitrary SQL code
I have configured the self-signed SSL certificate on the remote server where the SQL Server is hosted and enabled force encryption
Ok
Is there any other workaround to prevent the reading of SQL queries used in a .NET application?
Not that I know of
This is the flow
If you still insist on connecting to the database directly, or if you can't do it any other way since it's a legacy project, maybe people in #security will know more
Raymond Chen calls this "being on the other side of the airtight hatchway"
If an app running on a user's machine can send SQL to a server directly, so can any other app on that same machine
The application was created using VB6, and it is a legacy project. We are currently facing issues, and after conducting a proof of concept (POC), we found that directly connecting the .NET Framework to the database and encrypting it could resolve the problem. Our plan is to use the resulting DLL in the legacy project, ensuring that queries remain hidden. Changing the current architecture is not easily feasible and requires a significant effort. Hence, I am seeking suggestions that involve less effort. Alternatively, I could propose the implementation of an API layer
Your findings are clearly incorrect, then, since it doesn't seem like it prevented the issue.
There's nothing to stop another app from also connecting to the database with an encrypted connection
Thank you for your assistance @ZZZZZZZZZZZZZZZZZZZZZZZZZ and @jcotton42 . I've been working on .NET Windows applications for the past six months, having graduated last year and am still in the process of learning the .NET framework. I would appreciate any project or documentation references for implementing an API layer to connect to a database. This information would be valuable for me to propose a solution.
Create a WebAPI project and go from there
From that project, you connect to the database
And you call the API from the application using, say,
HttpClient
Here's a basic WebAPI tutorial: https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-8.0Thanks
If I create a web API in .NET Core that connects to the database, and I host the API in IIS on remote servers, is it possible to see SQL queries during the API to database communication
Possible for whom?
For you, who can SSH into the server and trace the connection? Yes
For a regular user who's — hopefully — not permitted to SSH into the server? No
The user will just see a request to the API, something like
only things between the API and database could see it, which doesn't include your end users
you hide/secure all of the more sensitive code behind the API so the only way a client could inspect the internals or the resources behind it is to hack your server/infrastructure
any code running directly on a client is more or less up for grabs
Thanks @ZZZZZZZZZZZZZZZZZZZZZZZZZ @jIMMACLE