Vulnerability in Parameterized Queries
See original GitHub issueHi, I came across the same issue as below where my filter terms were being erroneously picked up by the blacklist check:
https://github.com/groveco/django-sql-explorer/issues/454
My query:
SELECT * from logentry WHERE logentry.action = 'delete';
Error displayed:
Query failed the SQL blacklist: DELETE
I used parameterized queries as a workaround instead of concat:
SELECT * from logentry WHERE logentry.action = $$action$$;
{"action": "'delete'"}
Then I realised this could be used to bypass the blacklist anywhere in the query string, for instance:
$$cmd$$ FROM logentry;
{"cmd": "DELETE"}
Obviously this is rather undesirable behaviour.
Issue Analytics
- State:
- Created 10 months ago
- Reactions:2
- Comments:7 (3 by maintainers)
Top Results From Across the Web
Query Parameterization - OWASP Cheat Sheet Series
Query Parameterization Cheat Sheet SQL Injection is one of the most dangerous web vulnerabilities. So much so that it was the #1 item...
Read more >Using parameterized queries to avoid SQL injection
Several bad practices make your application vulnerable to SQL injection attacks: While interpreting the input values, dynamic queries and ...
Read more >Mitigation of SQL Injection Attack using Prepared Statements ...
As explained in this article, an SQL Injection attack, or an SQLi, is a way of exploiting the underlying vulnerability of an SQL...
Read more >Part 4 - Validate everything, Parameterize SQL queries
Parameterize SQL queries SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both ...
Read more >SQL statement in request parameter - PortSwigger
HTTP requests sometimes contain SQL syntax. If this is incorporated into a SQL query and executed by the server, then the application is...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I confirm I was able to delete row in table.
Blacklist issue and vulnerability are two different problems. Let’s say the problem with the blacklist is solved and everything works correctly. To solve the vulnerability problem, need to take two steps.
"$$cmd$$ FROM logentry;"
to"Delete FROM logentry;"
. In other words, need to apply all parameters first"Delete FROM logentry;"
through the blacklist checks.