SQLi is an attack used against web applications. The Open Web Application Security Project (OWASP) has, since 2003, published an ongoing list of the ten most serious web application attacks. Since 2010, injection attacks – including SQLi [CWE-89] – have been ranked as the #1 most serious web application risk. What is it? In general terms, an application is vulnerable to injection attacks when it is not properly equipped to deal with unexpected commands or queries. Any such application or code that accepts input from the user may be subject to injection flaws, allowing the user to inject malicious code via the user interface. Injection vulnerabilities affect protocols used to retrieve data from a database or server, like SQL or LDAP. They can, however, be found in any language used to retrieve specific parcels of data or code, such as data nodes in XML documents via XPath and other XML parsers. SQL vulnerabilities are by far the most common and most frequently exploited injection vulnerabilities because it is such a common language for database management. But, as OWASP’s web risks document says, “The concept is identical among all interpreters”. SQL vulnerabilities are by far the most common and most frequently exploited injection vulnerabilities because it is such a common language for database management. It is most common to see injection being used to maliciously access user data, such as identity details or the account password; but injection attacks are also capable of directly executing OS commands or introducing new code into a system. This could give administrative access to unauthorized new parties, or deny access to legitimate users. The OWASP top 10 document illustrates how injection flaws are exploited, providing two examples of vulnerable code:
The use of “id=’ or ‘1’=‘1″ creates an unexpected use of the database’s syntax, and would return details from all entries referred to by the “account” part of the URL, instead of a specific one.
Why is it bad?
The immediate impact of injection attacks and the goal of most attacks is to gain access to user data– as happened with the Heartland breach in 2008. While the exact numbers were not disclosed, it was for many years touted as the “largest data breach in history” and saw the personal and payment details of many customers compromised due to SQL injection attacks. This should have been a wake-up call for the industry to pay much more attention to security in web applications, and it did prompt greater awareness of the need for app-sec, but not enough to prevent injection attacks being a persistent issue. Regardless of the frequency of injection-based breaches, they can and should be preventable. Sometimes, injection flaws are discovered by researchers and closed by vendors. In September 2017, WordPress version 4.8.2 was released to patch a SQLi vulnerability via plug-ins. In February 2018, Joomla 3.8.4 patched a SQli flaw while SAP patches fixed two separate SQLi flaws.
The TalkTalk breach is again a good example. The exploited flaw was in a legacy database inherited with the 2009 acquisition of Tiscali. It was too late for good coding practices, and there was no chance of a vendor patch. But there was still no excuse. TalkTalk had a responsibility to protect its user data, and should have undertaken its own code review to find any vulnerabilities. This was the view taken by the UK’s data protection regulator (ICO). “Yes, hacking is wrong,” it declared,“but that is not an excuse for companies to abdicate their security obligations. TalkTalk should and could have done more to safeguard its customer information.”
The ICO fined Talktalk 400,000 euros (80 per cent of the maximum then allowable) for failing to prevent its users from the effect of SQLi attack. It is worht noting that GDPR has since dramatically increased potential fines. If the ICO fined TalkTalk 80 percent of the maximum allowable toady (up to 4% of the annual revenue of 1,78 billion euros), that fine would be nearly 57 million euros.
Solutions
Injection attacks do not require great hacking skill. With just a browser and spare time, hackers can find vulnerabilities by simply playing around with an URL’s syntax. People with little or no coding knowledge can find and follow online tutorials, and there are plenty of automated tools for blind SQL injecting. Fortunately, the low barrier of entry for injection attacks has a corresponding simple solution in most cases: the proper testing and securing of any database and how it handles data queries. Use of a good API is essential, controls need to be put in place to protect against mass-disclosure of data and the exploitation of special characters within the code’s syntax. It sounds complicated, but all of this can be achieved with proper modernization of databases and compliance with already-existing guidelines.
The most important part of protecting against injection flaws, however, is diligence; OWASP recommends a thorough manual source code review, and automated testing of “all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs”. The use of both Static and Dynamic Application Security Testing (SAST and DAST) tools, such as the ones incorporated into and used by High-tech Bridge’s ImmuniWeb solution, is suggested to protect against any new vulnerabilities going forward.
The TalkTalk breach is again a good example. The exploited flaw was in a legacy database inherited with the 2009 acquisition of Tiscali. It was too late for good coding practices, and there was no chance of a vendor patch. But there was still no excuse. TalkTalk had a responsibility to protect its user data, and should have undertaken its own code review to find any vulnerabilities. This was the view taken by the UK’s data protection regulator (ICO). “Yes, hacking is wrong,” it declared,“but that is not an excuse for companies to abdicate their security obligations. TalkTalk should and could have done more to safeguard its customer information.”
Read more at: https://www.htbridge.com/blog/OWASP-SQL-injection-attack.html
Copyright © High-Tech Bridge
