Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Don’t Blame SQL
SECURITY SHELF

Don’t Blame SQL 

It is no surprise that injection attacks retained the top spot in the Open Web Application Security Project (OWASP) Top 10 for 2017. Their report summarizes the issue well:

“An application is vulnerable to attack when:

• User-supplied data is not validated, filtered, or sanitized by the application.

• Dynamic queries or non-parameterized calls without context aware escaping are used directly in the interpreter.

• Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.

• Hostile data is directly used or concatenated, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored procedures.”

Injection vulnerabilities usually result from avoidable software errors that can be easily identified during code reviews. Penetration testing and automated test tools can help, but examining source code remains the least expensive and most reliable approach.

Poor security architectures contribute to the prevalence and often devastating impact of injection attacks. In some cases, they result from adapters (and similar modules) that connect applications to databases or LDAP directories without considering end-to-end security requirements. This is particularly common when database and directory connectivity is optional or added as an afterthought to meet customer requirements.

Popular SQL databases, such as MySQL, provide efficient, reliable, and cost-effective data storage. They include flexible and robust access controls, but many deployments do not take advantage of them. Instead, credentials with all privileges on the database are often provided to applications requiring access. When those credentials are stored on a web server, or similar first tier, the stage is set for mass data exfiltration.

Security architecture deficiencies are unfortunately common. WordPress, which currently powers about 30 per cent of web sites, is a prime example of a successful product with a terrible security architecture. Database credentials are stored within a .php file inside the web server document root. A simple configuration error, injection vulnerability, or code execution issue will provide an attacker with the ability to dump — or modify — the contents of the entire database.

Corporate websites and blogs may store only published public information and administrator credentials in the WordPress database. Assuming appropriate backup and disaster recovery processes are in place, this may limit the impact of an intrusion to downtime and reputation damage. However, if users authenticate to comment or access restricted content, a breach could trigger notification obligations, especially in light of the GDPR. Ultimately every business using WordPress needs to weigh the benefits of using the world’s leading free content management system against the potential costs of a breach.

Unfortunately, the same two-tier design pattern is very common in other types of web applications that collect large volumes of consumer information, including e-commerce. These systems are literally one configuration or coding mistake away from a total database breach.

Solving this problem requires a shift toward multi-tiered designs with additional security layers. Some web application architectures place a RESTful API between the web app and back-end services. From a security perspective, this is definitely a move in the right direction. A carefully-designed, well implemented API will help narrow the scope of a breach to individual users. 

Compromising the web server may allow attackers to steal credentials and impersonate users, but instead of downloading entire database tables with a single SQL query, criminals will be forced to authenticate to the API as each individual user. This, in turn, provides the opportunity for application security logic or a SIEM to identify unusual behaviour patterns and limit the number of users that are impacted.

Databases and web applications aren’t going away. In fact, if the last few years are any indication, their exponential growth will continue and expand into additional facets of business and daily life. The question is whether application developers and security professionals will work together to build more secure and intrusion-resistant systems, or whether the escalating slew of data breaches will continue. In any event, don’t blame SQL.

Have a security question you’d like answered in a future column? Eric would love to hear from you.

Related posts