Who knew that after all these years, we’d still be talking about SQL injection? I mean, if you had asked me 20 years ago if we’d still even have SQL, I might have said, nah, surely we’ll SELECT something else by then… (I only feel a little sorry for the SQL pun).
But, here we are.
SQL injection (SQLi) is still alive and well and still important in application security. Despite the advancements in web frameworks and programming languages, SQLi vulnerabilities continue to surface, posing significant risks to the integrity and security of applications. In light of this, DryRun Security has taken a proactive step by integrating SQLi analysis into our AppSec Analyzer, one of several analyzers that give you super-fast security code reviews on GitHub PRs.
[n.b. If you aren’t familiar with our approach of appsec using AI for detection and defense, then I’d love to show you the future of static application security testing with our Contextual SAST tool. It’ll change the way you think about application security. Get you a demo and see what’s possible.]
Understanding SQLi in Modern Frameworks
Python Django and Golang Object-Relational Mapping (GORM) are modern frameworks designed with security in mind. However, even in these environments, developers can inadvertently introduce SQLi vulnerabilities through unsafe queries.
Let’s look at a simple example of each.
SQLi Golang GORM
SQLi vulnerabilities can occur in Golang applications using the GORM library, especially when dynamic SQL queries are constructed improperly. GORM is a popular ORM that aims to simplify database operations. However, just like any tool that interacts with databases, if not used correctly, it can open the door to SQLi attacks. These vulnerabilities primarily arise when inputs are concatenated directly into queries without proper sanitization or parameterization, allowing attackers to inject malicious SQL into the database.
For example, consider the following Golang GORM code snippet:
go
package main
import (
"gorm.io/driver/sqlite"
"gorm.io/gorm"
)
type Product struct {
gorm.Model
Code string
Price uint
}
func main() {
db, err := gorm.Open(sqlite.Open("test.db"), &gorm.Config{})
if err != nil {
panic("failed to connect database")
}
var product Product
userInput := "'; DROP TABLE products; --"
db.Where("code = '" + userInput + "'").First(&product)
}
In this example, the `Where` clause includes a variable `userInput` that is concatenated directly into the SQL query. If `userInput` contains malicious SQL commands, such as `'; DROP TABLE products; --`, it can lead to destructive SQL injection attacks, such as dropping tables or altering database content. This vulnerability stems from the lack of proper input handling and the direct use of user input in constructing the SQL query.
SQLi in Python Django
SQL injection (SQLi) vulnerabilities can also be a concern in applications built using Python Django, particularly when developers bypass Django's ORM by using raw SQL queries or improperly handling user inputs. Django's ORM is designed to help prevent SQL injection by using querysets, which are inherently safe from SQLi because they use parameterized queries. However, when developers opt to use raw SQL queries for complex database operations, they must be vigilant to ensure inputs are sanitized.
Consider this Python Django example where SQLi can occur:
python
from django.db import connection
from django.http import HttpResponse
def unsafe_raw_sql(request):
user_id = request.GET.get('user_id')
# Unsafe SQL query
with connection.cursor() as cursor:
cursor.execute("SELECT * FROM users WHERE id = '%s'" % user_id)
row = cursor.fetchone()
return HttpResponse(row)
In the above code, the `user_id` is directly interpolated into the SQL query string. If `user_id` is manipulated to include SQL commands, it could lead to SQL injection. For example, if `user_id` is input as `0' OR '1'='1`, it could modify the query logic to return all users, exposing sensitive data. The vulnerability arises because the code directly uses string interpolation (`%s`) to include user input in the SQL command without any validation or escaping, highlighting the importance of avoiding such patterns in Django applications.
How the DryRun Security AppSec Analyzer handles SQLi
The secret to getting accurate results so quickly is the way we use AI by incorporating LLMs into the code review. We’ve created a code review and inquiry methodology that mimics a professional code reviewer. Through that process, which really deserves a separate blog post (coming soon!), we determine the context around the change and then assess the risk. By using a mix of advanced AI techniques in tandem with our knowledge base and proprietary code review methodology we are able to deliver highly accurate results at lightning speed.
The Role of Contextual Security Analysis
At DryRun Security, we leverage Contextual Security Analysis (CSA) to enhance the detection and management of SQLi (and more) vulnerabilities. CSA uses the SLIDE model (Surface, Language, Intent, Detection, Environment) to evaluate the risk associated with code changes, providing a more nuanced and effective approach to security analysis.
Take Charge of SQLi Vulnerabilities
SQL injection remains a persistent threat, but with the right tools and approaches, it can be effectively detected. By integrating SQLi analysis into our AppSec Analyzer and leveraging Contextual Security Analysis, DryRun Security is providing developers with a powerful resource to enhance the security of their applications. I encourage you to try out the DryRun Security GitHub app (which includes our updated AppSec Analyzer) and stay tuned for future enhancements that will further streamline and strengthen your security practices.
DryRun Security is a Contextual SAST tool that will change the way you think about application security! Schedule a demo with us and see what’s possible.
At DryRun Security we think Contextual Security Analysis is the future of AppSec. If you're interested in learning more about CSA and how it can benefit your application security efforts, download our free Contextual Security Analysis Guide.
.webp)
