How does a SQL injection attack work?
If you're at all familiar with web development, you've probably heard of SQL injection attacks. An SQL injection is number one on the OWASP Top 10, a list of the most critical web application security risks, and can have a devastating effect.
They’re simple to learn and execute, and so they’re one of the most commonly used forms of cyber attack. They’re also fairly simple to defend against, yet they’re a commonplace attack method on social media sites, online retailers, universities, and against SMBs who don’t have the know-how or resources to prevent these attacks.
The reason SQL injection attacks can prove so fearsome is that a large proportion of the web is built on SQL databases, including the ones provided by the likes of Microsoft, Oracle, and SAP. This makes SQL injection one of the most versatile attack methods in a hacker's arsenal, and it's usually among the first tools used as part of a breach attempt.
What is SQL injection?
To analyze how SQL injection works we first have to establish what SQL is. In short, SQL (or structured query language) is a programming language designed to manage large databases, such as the kind used by web applications. SQL is used to modify, retrieve and re-organize the data within a database with text-based commands.
A SQL injection attack is when a third party is able to use SQL commands to interfere with back-end databases in ways that they shouldn't be allowed to. This is generally the result of websites directly incorporating user-inputted text into a SQL query and then running that query against a database. How this works in a non-malicious context is that the user-inputted text is used to search the database - for example, logging in to a specific account by matching it based on the username and password entered by the user.
In a SQL injection, however, this process is hijacked to perform unauthorized functions. To use a simple example, the attacker could make use of the query process outlined above by using another SQL command to override the query's logic. The standard SQL query is designed to log into an account once it finds one in the database that matches a specific set of inputs; therefore, if the attacker is able to amend the query so that it adds the condition 'OR 1=1', it means that every entry in the table will return a positive result. Under those conditions, the query will log into the first account it finds, which in most databases is a user with admin privileges.
This functions in a very similar way to cross-site scripting, another style of injection attack that involves hackers inputting malicious scripts into web forms to target user browsers.
One of the most common outcomes of a SQL injection attack is the theft of user data. Login credentials, email addresses or personal information can all be sold on the black market or exploited for further cyber attacks. The attack can also be used to knock applications offline by deleting tables from the database, or to add new information to the database.
How to defend against SQL injection
Like all programming languages, SQL is built around the use of certain characters and formatting structures to designate functions. SQL injection exploits this by using text input fields to introduce these elements into otherwise benign queries, but it can be counteracted by 'sanitizing' the user input sections throughout a website or application.
Adding a layer of abstraction allows you to strip out characters that are used in SQL queries, but not whatever the input field concerns. The semicolon, for example, is used in SQL queries, but does not feature in names and is not permitted in email addresses, so anyone entering it into a text field designed to collect names or email addresses is almost certainly attempting a SQL injection attack.
A far more effective way, however, is to use parameterized queries. Rather than directly running a query based on user inputs, this method of database construction involves specifying the structure of the query beforehand and plugging the user input into predefined slots. This ensures that, even if the user does enter malicious SQL code into the text field, it will be safely wrapped within a larger query that doesn't recognize it as such.
It is also best practice to make sure that these safeguards are applied to all text input forms, rather than just those that connect to sensitive databases, as lateral movement and privilege escalation are common hallmarks of SQL injection attacks. You should also make sure that database error messages aren't displayed on public-facing websites, as these can give attackers more information about the structure of your databases to inform further attempts.
SQL injections have been used in multiple cyber attacks over the last 20 years, often as an initial probe before other, more sophisticated tools and techniques are deployed. They’re nothing to scoff at, though. SQL injection can result in a stolen, deleted, or altered sensitive data. Attackers can create fake identities, change transactions, make themselves database administrators, or even go so far as to completely take over the webserver. SQL injection attacks were used in the 2020 Free pick data breach to access 8.3 million users’ records, and in 2015's mammoth Talk-Talk breach, resulting in the theft of over 150,000 customers’ personal data and a £400,000 pound fine against the firm. Back in 2012, a group also used SQL injection attacks to steal 450,000 Yahoo users' login information, in one of a number of breaches that have hit the embattled web company over the past decade. According to a report from web security firm Akamai, SQL injection attacks have accounted for more than 65% of web-based attacks between November 2017 and March 2019, with the US and the UK topping the charts as the most frequently targeted countries.
SQL Injection Fools Speed Traps And Clears Your Record
Typical speed camera traps have built-in OCR software that is used to recognize license plates. A clever hacker decided to see if he could defeat the system by using SQL Injection…
The basic premise of this hack is that the hacker has created a simple SQL statement which will hopefully cause the database to delete any record of his license plate. Or so he (she?) hopes. Talk about getting off scot-free!
The reason this works (or could work?) is because while you would think a traffic camera is only taught to recognize the license plate characters, the developers of the third-party image recognition software simply digitize the entire thing — recognizing any and all of the characters present. While it’s certainly clever, we’re pretty sure you’ll still get pulled over and questioned — but at least it’s not as extreme as building a flashbulb array to blind traffic cameras…
What do you guys think? Did it work? This image has been floating around the net for a few years now if anyone knows the original story let us know!
The Right Way To Shift Right in Application Security
As web applications and application programming interfaces (APIs) continue to be leading attack vectors for breaches, security leaders are seeking new approaches to stem the tide of successful attacks. There is now a consensus that applications must be protected in production as well as in development. But not all existing runtime tools are up to the task. The latest version of the Contrast Protect runtime application protection and observability solution has some unique advantages that offer security leaders a saner, smarter approach to thwarting application threats.
Security Debt Starts in Development
Application vulnerabilities in business applications are a growing component of enterprise risk. Still, most seasoned security and DevOps leaders operate under the realistic assumption that they cannot eliminate every vulnerability. So, their challenge lies in determining which vulnerabilities will go unresolved and for how long. In other words, they assume security debt, with the intention of reducing it as quickly as possible, given the constraints of the business.
The pressures to reduce security debt grow as application development evolves. In waterfall development environments, pen testing can expose critical vulnerabilities by imitating presumed attacker behaviors. But this manual, ad hoc, and expensive process could not scale with digital transformation, as agile development became more common.
So, developers began performing vulnerability scanning in development, essentially shifting application security to the left, with the aim of catching vulnerabilities early in the software development life cycle (SDLC). This is important, because the earlier vulnerabilities are exposed, the sooner security teams can analyze their criticality and make informed decisions about mitigation.
Still, security debt continues to build in development, and vulnerabilities slip into production, where they become targets for cyberattacks. In a State of DevSecOps Report, nearly every respondent admitted that the average application their organization has in production contains four or more vulnerabilities. Further, over a period of 12 months, nearly two-thirds of organizations sustained at least three attacks that successfully exploited software vulnerabilities.
Un-remedied Vulnerabilities Pose Significant Business Risk
There are various reasons why vulnerabilities slip into production code. Some of these relate to deficiencies of legacy static application security testing (SAST) and dynamic application security testing (DAST) tools that produce high volumes of false positives and false negatives. Other reasons are related to the time constraints of the development teams.
To get a sense of the impact of unremedied vulnerabilities, consider a recent Ponemon Institute study commissioned by IBM, which found that 42% of respondents whose companies had suffered a breach attributed the cause to a known but unpatched security vulnerability.
By now, security leaders recognize that vulnerabilities must be addressed, not just in development but also at every stage of the SDLC. That means shifting application security efforts to the right as well, performing testing and mitigation on the runtime code, in the production environment.
Two primary challenges exist in shifting right: 1) knowing what vulnerabilities exist, and 2) knowing how to prioritize remediation efforts to ensure that all the critical vulnerabilities are fixed. These have been two persistent challenges for security leaders.
In our latest DevSecOps survey, nearly every respondent admitted that the average application in production where they work has four or more vulnerabilities, and 61% said they had sustained at least three attacks that successfully exploited vulnerabilities over 12 months.
Perimeter Tools Miss Unknown Threats
With today’s evolving threat landscape, it is impossible to identify all the vulnerabilities that may exist at the time code is released to production. A code feature can be recognized as a vulnerability only if there is a known possible exploit of that feature. So, previously unknown, or zero-day, attacks can only be mitigated, not prevented. And successful mitigation is crucial, as zero-day threats comprise upwards of 50% of all malware.
The known vulnerabilities aren’t any easier to deal with, as they are numerous and rapidly multiplying. Security teams and developers cannot realistically expect to fix them all. In order to prioritize code fixes, they need to know not only which vulnerabilities are present in the application but also which of those are likely to be exploited in production, as well as the impact of each exploit on the organization. Then, they must rely on SecOps to protect any remaining vulnerabilities once applications are in production.
To provide this protection, SecOps has long relied on perimeter-based application security solutions such as web application firewalls (WAFs), which rely on known-attack signatures to block suspicious application-bound traffic. These perimeter solutions are undeniably valuable for protecting the organization from distributed denial of service (DDoS) and other network attacks. However, they lack deep visibility into what happens when application vulnerabilities are exposed to real threats in runtime.
This makes WAFs a rather blunt tool for vulnerability protection. On the one hand, because their rules are only as current as their last update, they miss zero-day exploits. On the other hand, because the rules are signature-based, they erroneously block all behaviors that match the signature, including harmless probes. Thus, they generate a high volume of alerts, with many false positives. This leads to alert fatigue and high staff turnover, both among security teams and among developers, who have to cope with the deluge of security fixes in addition to their other development tasks.
WAFs lack deep visibility into what happens when application vulnerabilities are exposed to real threats in runtime. This makes them a rather blunt tool for vulnerability protection.
Runtime application protection and observability has been recognized as an effective way to fill this gap. The idea is to help an application protect itself by incorporating security into the running application wherever it resides on a server. Runtime application protection and observability tools intercept calls to the application and analyze the application’s response to those calls. If the behavior is interpreted as harmful, alerts can be sent to a security information and event management (SIEM) system.
Industry standards support runtime application protection. Guidelines from the National Institute of Standards and Technology (NIST) specifically require state-of-the-art security instrumentation for “application self-protection at runtime.” Meanwhile, the latest version of the Payment Card Industry Data Security Standards (PCI DSS) includes several control requirements that security teams can satisfy with runtime application protection and observability solutions. The following are some examples:
⬤ Control 6.5: Address common coding vulnerabilities in software-development processes.
⬤ Control 6.6: For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.
⬤ Control 10.2: Implement automated audit trails for all system components.
As a pioneer in runtime application protection, Contrast has also embraced this self-protection concept. The latest evolution of the Contrast Protect runtime application protection and observability solution exceeds industry standards, both in accuracy and performance. Several key features contribute to this ability:
⬤ Instrumentation. Using agents embedded in the application code, Contrast Protect observes potential threats in the runtime environment, analyzes their impact, and blocks and reports on any business-impacting threats. This in-context information enables SecOps teams to prioritize vulnerabilities and DevOps teams to optimally allocate resources to fix them.
⬤ Contrast Protect employs a unique, multistep algorithm we call Runtime Exploit Prevention™ (REP) to analyze application runtime events and confirm exploitability. Then, Contrast Protect automatically blocks confirmed breach attempts during real-time code execution. This significantly improves the likelihood of thwarting zero-day attacks .For example, if a SQL injection attack alters the expected syntax of a SQL query, Contrast Protect instantly blocks this exploitable runtime event without affecting the application before a breach can occur and, optionally, sends an alert to the SIEM system. Conversely, if a SQL injection attack never reaches a SQL query, Contrast Protect recognizes this as a harmless probe, does not block it, and does not trigger a false-positive alert in the SIEM system.
Because of the efficiency of the REP algorithm and the fact that the agent is embedded in the code, the detection, analysis, and blocking happen in sub-millisecond time frames, even under the heaviest attack loads. No external perimeter-based solution can match this.
⬤ Contrast Protect agents deploy easily without requiring security or development staff to make any changes to the source code. Because it is instrumented into the runtime code, Contrast Protect stays with the code through version upgrades, ports to different operating systems, migrates to and from cloud environments, and other changes. It seamlessly scales within every instance of an application, without configuration or tuning, no matter where the application is deployed, on-premises or in the cloud.
The latest evolution of the Contrast Protect runtime application protection and observability solution exceeds industry standards, both in accuracy and performance.
Sharper Tools Lower Cost of Remediation in Production
Shifting right with runtime application protection and observability is essential, not only because a greater proportion of vulnerabilities slip into production code. It is also important due to the growth in the overall number of vulnerabilities to which applications are exposed. Most of these vulnerabilities arise in code that is custom developed for the application, though some come from open-source frameworks and libraries, which developers are increasingly using to shorten their development cycles.
The problem with assessing the risk of vulnerabilities in open-source software is that while the potential pool of Common Vulnerabilities and Exposures (CVEs) is vast, only a fraction of these CVEs actually pose a risk for any particular application. A recent Contrast study on open-source security found that the average application contains 118 third-party libraries. Yet only 38% of libraries in an application are active, and only 31% of classes in active libraries are invoked. The reality is that less than 10% of active code in an application is open-source libraries.
Only CVEs in invoked libraries and classes should be flagged as alerts in a SIEM system and prioritized for mitigation. And the only practical way to identify these CVEs is to observe the application in runtime and intelligently assess CVE risk. With its embedded agents and REP algorithm, Contrast Protect provides this nuanced insight, which maximizes security effectiveness while minimizing the impact on DevOps productivity and application performance.
){kind=link}
0 Comments