SQL Injection Explained in 30 Seconds
SQL injection is still number one on the OWASP list, decades after it was
first documented. Here's the mechanism and the fix.
IT'S NOT SQL'S FAULT
The vulnerability isn't in SQL, and it isn't in "special characters." It's
in how the query gets built:
query = "SELECT * FROM users WHERE email = '" + email + "'"
That `+` is the bug. Because the input is glued into the query string before
the database ever sees it, the database can't tell your SQL from the user's
text. Input stops being data and becomes part of the instruction — the
WHERE clause can be rewritten into something that's always true.
THE FIX — PARAMETERIZED QUERIES
User.where("email = ?", email)
The placeholder and the value travel separately. The database receives the
query structure first, then the value, and treats that value strictly as
data. It is never parsed as SQL. That's what makes this the primary defense
rather than one mitigation among many.
Never build SQL by concatenating or interpolating untrusted input.
THE CATCH NOBODY MENTIONS
Placeholders bind values*. They cannot parameterize SQL *identifiers —
column names, table names, sort direction. So this is still injectable:
User.order(params[:sort]) # unsafe
For identifiers, you need an allowlist:
ALLOWED = %w[name email created_at]
col = ALLOWED.include?(params[:sort]) ? params[:sort] : "name"
This is where a lot of otherwise careful codebases leak — the queries are
parameterized, and then a sort parameter goes straight into ORDER BY.
AND ON VALIDATION
Input validation is worth doing, but it is defence in depth, not the fix.
Blocklists get bypassed, encodings differ, and legitimate input contains
apostrophes — O'Brien is a real surname. Parameterize anyway.
—
#Astmation — #software #systems, #automation, and #AI-powered #applications .
Smart Technology. Secure Solutions.
https://astmation.com/
#Shorts #SQLInjection #AppSec #WebSecurity #SecureCoding #RubyOnRails #OWASP #BackendDevelopment #SoftwareEngineering #CyberSecurity
Watch on YouTube