Protect your SQL Server data from SQL Injection Attacks

It is so vitally important to protect your SQL Server data from SQL Injection attacks and this article is written to explain why and the efforts you must make.

Why is SQLi a problem?

Injection of SQL server data is an issue that web users have had to contend with for over 15 years now. The solutions provided online are still pretty much the same, so many years on. You will receive a list of best practices in coding, a few points detailing patching and web application firewalls (WAF).

However, the main problem remains because protecting your code and applications through best practices only covers the smallest part of the threat you might be facing and does not fully protect your SQL Server data from SQL Injection attacks. We do not need to remind you about the Heartbleed and Shellshock attacks.

In particular, the Shellshock attack demonstrated how having a vulnerable point within the rootkit can make every other security measure applied invalid. Because of this vulnerability, hackers gained access and took over web servers, and using high-level credentials were able to gain access to a host of databases and servers within specific networks.

We now know that the question to ask is not whether you may get SQLi attempts. Theft of data is a serious profession, so if you don’t take caution to keep yourself fully protected you WILL be breached.

Why should I have a database firewall?

The ultimate goal for any cyber attacker is to acquire information. A majority of security breaches today result in loss of personal data for individuals in thousands of lines, including login information, credit card data and other personal info.

You may feel protected to the best of your knowledge, but the issue at hand is that there are so many different potential vectors of attack; it may be hard to cover or even know all of them. Take for instance these vulnerabilities within IT systems, all of which introduce a level of risk:

• Open named pipes
• Open RPC points
• Open sockets
• Services running as SYSTEM
• Services running by default
• Services in general
• Active ISAPI filters
• Active web handlers
• Executable vdirs
• Dynamic webpages
• Enabled accounts in admin group
• Enabled guest accounts
• Enabled accounts
• Null sessions to pipes and shares
• Weak ACLS in shares
• Weak ACLS in registry
• Weak ACLS in FS
• ActiveX enabled
• JScript enabled
• VBScript enabled
• Third party applications

Given so many attack points, it is virtually impossible to secure yourself against all threats. However, you can have granular security to protect the database itself, and the data it contains. That is where a web application firewall (WAF) comes in to secure your data.

And if I have WAF?

Having a WAF is a vital component of ensuring protection from internal threats, internal rogue access, network-level attacks and a few more of the previously mentioned potential attack vectors. It is essential, but nowhere near sufficient to protect your SQL Server data from SQL Injection attacks.

Protection in real-time

A real-time database firewall is the best way to protect your data. In other words, the firewall safeguards the data in its location, regardless of the direction of attack. A truly effective database firewall operates by acting as a proxy between the data held in the database and all external forces. It will review every query to determine if it is authorized and coming from authorized entities before allowing it to read, change or retrieve data in the database.

The database firewall will perform the following actions, all of which together provide security to your system. Contact Remotedba.com for further assistance with database protection:

Profiling and filtering

Identifying and filtering the most common unauthorized/unusual queries and blacklisting them are the first steps in the prevention of SQLi attacks. Every firewall comes with a predefined list of activities in the black and white lists. The firewalls also provide for the admin to set specific rules that govern access into the database – by column, table or database. This way you full control what is and is not permissible on the database. With continuous monitoring, you should now be able to define and improve your policies following the baseline behavior for your enterprise, site and apps.

Separation of duties

This is especially useful is safeguarding the database against a variety of malicious threats, not just SQLi. In essence, separation of duties involves ensuring that the correct entities get the correct permissions. For instance, an app should have permission to access only the table it needs, reading and writing to the actual columns that it should only. It should not be able to retrieve an entire table or copy the entire database.

Even within the organization, the people should have the right permissions depending on their jobs – DBAs, sysadmins, auditors, testers and developers – all of whom access and use the database in different ways. In addition to the apps, interconnected databases, reporting and backup services, it is important to have accurate knowledge of each entity or process and ensure it has the right permissions. Accurate knowledge of the system is essential to this process. For example, there should be controls to prevent authorized entities from running unauthorized queries.

Learning mode with query grouping for SQLi

Selecting the learning mode will enable the activity of the firewall to improve over time; blocking SQLi attacks more effectively i.e. with minimal to no interruptions to the production systems. Grouping and exploring queries to the database will help the firewall to identify and implement policies useful to every database it protects, fine-tuning these policies as it gains new information.

Risk-based policies

You can implement these policies manually or according to industry standards. It involves identification of suspicious behavior or queries and blocking them e.g. multiple login attempts with different user IDs from the same IP address. You can even tag specific locations as suspicious, as well as implementing policies derived through analysis of pertinent factors. Breaches are also preventable by identifying specific attack patterns and blocking them, so that once there is identification of an attacker, there is information preventing his gaining access to every other database that has the software installed.

Data masking

This allows developers and administrators to be able to access database tables or data without running the risk of exposing PII or any other sensitive information. This means that even the developer or DBA will not be able to see any personal information stored within the database. Data will be masked after retrieval from the database, ensuring that it cannot be deciphered in any way (unlike encryption), and preventing changes to the original data in the database.