12

There are many vulnerabilities associated with database management systems. Basic security issues include: Deployment security issues. Application level (DBMS) security issues. Abuse of database features Zero day attacks Data leaks When your application is developed, another attack surface will be added to your database. You can avoid brute-force attacks ...


6

First hoping that IP address control can add strong security is kind of a brave assumption. IP theft should always be considered as a possible attack. Next, if there is no firewall at all in front of a SQL server, the most serious risk is not legimitimate requests (i.e. with a correct username and password) coming from unlegitimate origins, but rogue attacks ...


3

I don't know how much money we are talking about, but your project should be adequately funded and security shouldn't be an afterthought. I am sure there is enough competition and that you should be able to find a suitable alternative. The lack of a configurable firewall is a big downside I must say. You often get what you pay for. If you have a strong ...


3

The moment you hardcore a password in your software, it's effectively exposed to anyone who can run and analyze this EXE file. It's a good idea to store it in a separate file and don't include this file in source code control, but there's not much you can do preventing it from being reverse engineered once the app is distributed. Not only can it be reverse ...


3

This doesn't look like a SQL Injection attack to me. A SQL injection attack would contain SQL keywords like select, update, delete, drop, etc. But, it does look like user input is not being sanitized properly before being written to the database, and this could open the door to other types of attacks such as XSS attacks. So, you might want to take this as a ...


2

Your approach could probably be bypassed as well, maintaining a blacklist is a "why not" but is definitely not efficient. Depending on the technical stack you use, I'd suggest you use an ORM which will reduce your risque (but is not risk-free neither) The best thing you can do is trust no-one: Assume all user-submitted data is evil and validate and ...


2

It is not an issue what kind of data are stored in the column, but what expectations the code using the data has, i.e. what is done with the data. If all the code treats the data as being arbitrary binary from untrusted sources, then fine. If some code assumes that the data are sanitized HTML and plainly merges is with other HTML then this will lead to XSS. ...


1

If you're talking about distributing an application that connects to a SQL server hosted on the end-user system, then you just have the user set database credentials in a config file rather than putting it in the application itself. If, instead, your application's architecture is built around having the applications running on the (untrusted) user systems ...


1

In general: use TLS. Only if the data stays within a limited network that is not accessible from the outside, you might possibly get away to do it without TLS. There are a number of options for creating an encrypted tunnel, among which IPSec and OpenVPN. Although possible, all administrators will first frown upon your lack of TLS support and then curse you ...


1

You don't need to do anything specific in this regard. If you need secure channel to SQL server, just insert encrypt=true in SQL connection string. This will request secure channel. The behavior of connection is controlled using TrustServerCertificate connection parameter. If it is set to True, client will fallback to insecure transport (if SQL server does ...


1

So, I did my own research, and here are my findings: So the first message being sent is always the Pre-Login (§2.2.1.1): Before a login occurs, a Pre-Login handshake occurs between client and server, setting up contexts such as encryption and MARS-enabled. For more details, see section 2.2.6.5. The very first message is a Pre-Login Message, which include ...


1

It sounds like (§2.2.6.4) the password is obfuscated with some simple bit flipping: Before submitting a password from the client to the server, for every byte in the password buffer starting with the position pointed to by ibPassword or ibChangePassword, the client SHOULD first swap the four high bits with the four low bits and then do a bit-XOR with 0xA5 (...


1

You can and should configure the software firewall on your virtual Windows(?) server. Just allow the ports for RDP and SQL server, and only for the IP ranges relevant for you. Also make sure that your SQL server provides TLS-encrypted connections so your credentials and data is encrypted in-transit.


1

If they're on the same host, then there's no real harm in re-using the same certificate for mysql administrative access. There are no cryptographic weaknesses exposed by having two different services present the same certificate. Since you're on the same host, it doesn't cause you to make extra copies of the private key or move them around, so the key ...


1

Directly exposing core services' admin ports and access is not best practice. The better approach is to create a "jump box" which is a remotely accessible workstation (often virtual) where your admins log into to perform admin tasks as if they where on your local network. The jump box can be locked down, monitored, and have additional security. If ...


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