Hacker working on SQL injection

Prevent SQL Injection Attacks With These Processes

SQL injection is the biggest web application security threat, according to the Open Web Application Security Project. It ranks ahead of other rampant app vulnerabilities such as broken access controls and security misconfigurations.

By injecting a few lines of malicious code into your web applications, hackers can seize control of your organization’s database and network.

Organizations can use security measures such as restricting access to the database and disallowing connections from SA or root accounts. Another elementary measure is to separate databases according to use.

However, to truly insulate yourself from an injection attack, it’s imperative to follow these five processes.

Training and awareness

There is a large human element to cybersecurity, and the strength of your security training programs is a measure of how safe your web application truly is. Many organizations focus on raising awareness of cyberthreats and neglect to focus on behavioral change. Given the wide variety of security threats that exist today, mere awareness isn’t going to do the trick.

Driving behavioral change begins at the top. Your organization’s leadership must realign themselves to place cybersecurity at the top of their priority list. Developers these days are accustomed to continuous delivery models, and this can lead to vulnerabilities being introduced inadvertently. Typically, organizations have security teams check-in at predetermined points to conduct security checks.

As a result, security becomes a hurdle that needs dealing with instead of being a foundational development feature. Create teams with security professionals embedded in them and have your security ops teams create an automated tool to conduct sanity checks on code meant for production.

Create code templates that have been pre-validated for security. Developers can then build on these templates with periodic input from their team’s security lead. Integrating development with security is the best way to change your organization’s outlook towards security.

Verify all user input

User input is an integral part of many web applications. However, this doesn’t mean user input should be trusted by default. User inputs are a vulnerability, but they’re also an essential part of your app’s workflow. Cybercriminals are aware of this and use forms to inject malicious code into your app.

Mitigating this weakness is as simple as conducting data sanitization and validation. SQL is a powerful tool and contains many character operators that can be tough to parse manually. Instead, run all inputs through a function such as MySQL’s mysql_real_escape_string() to sanitize inputs and to prevent them from passing to data. Every SQL database has its idiosyncrasies when it comes to sanitization, so make sure your teams are up to speed with them.

Data validation is a more involved process. For starters, you need to parse inputs to ensure everything entered is an expected character. For example, email addresses should contain at least the “@” sign within them, and integer fields should not have alphanumeric values. Make sure text strings aren’t longer than the maximum limit as well.

You can even block the input of certain characters or strings to dissuade attackers. However, malicious actors can get around these controls. To truly protect your app, validate data on the client as well as the server-side.

Use allow lists and disallow lists

Many security protocols list strings, characters, and other inputs that are disallowed and leave it at that. The problem is that getting past disallow lists requires a little more work on the attacker’s part, and it hardly dissuades them. Relying on disallow lists makes sense when your web application is designed to be used by a large number of people.

However, even these applications need an allow list element. Typically, allow lists are used in applications designed for restricted use. For example, you can allow your web service to perform just one task and restrict it from doing anything else. If the service is compromised by an attacker, it will automatically shut down.

Applying an allow list policy to a widely used app isn’t practical. However, you can combine the two approaches selectively to create a robust framework. For example, you can allow users from trusted regions to access your app and disallow malicious users from those regions as well. You can restrict access from certain IP addresses while managing app behavior using an allow list policy.

Examine your app to figure out how you can implement a combination of these approaches.

Update and upgrade

Many older applications lack SQLi protection. Conduct an audit of all your tools and software to make sure you’re using the latest technology and software in your organization. Using PDO instead of MYSQLi in PHP is an example of a vulnerability you should be avoiding. Make sure your security teams are regularly reviewing vulnerabilities in applications based on common knowledge.

Many external app developers regularly discover flaws after their product is released, so stay up to date with patches and apply them to your third-party tools. Consider using a web application firewall (WAF) to filter malicious data. WAFs can be used to protect your application before a patch is available for a known vulnerability.

Databases and functionality tend to bloat as organizations get bigger. Conduct a deep audit of all functionality and eliminate code that isn’t essential. Streamline your databases and integrate your environments as much as possible. Doing this reduces the attack surface a malicious actor can exploit. Get rid of any functionality that a hacker can use, but you don’t need.

For example, xp_cmdshell in MS SQL spawns a Windows command shell and can be used to pass strings for execution. Given that the spawned process has the same privileges as the MS SQL account, this is a huge vulnerability in high privilege accounts.

Improve on existing knowledge

Large organizations have the resources to build tools from scratch, but this isn’t always a good idea. Instead of reinventing the wheel, it’s better to leverage third-party knowledge and integrate those tools into your legacy systems.

Before accepting any work from a vendor, have your developers review and validate the code you receive.

Following basic security practices goes a long way. Don’t use dynamic SQL queries and change passwords regularly. If possible, use FIDO protocols and ditch the password entirely.

Thorough processes for resilient security

SQL injection vulnerabilities exist everywhere you gather user inputs. This doesn’t mean you need to live in fear of an attack at all times. Install the processes above and you’ll develop a robust security structure that will give your users optimal access and protect your organization’s assets.

 

Staff Writer at CPO Magazine