You are viewing a single comment's thread from:
RE: dPoll development updates: Result filtering and voting audits
Yes, good catch. Code can be refactored into using SQL instead of traversing all available votes.
Yes, good catch. Code can be refactored into using SQL instead of traversing all available votes.
refactored.
Wait, I was talking about a vulnerability called "sql injection", it's a way to introduce malicious sql code in a human filled form.
If you have a field that is concatenated in a sql query, some like:
query = "SELECT * FROM USERS WHERE SP > " + sp;
If I put this in the field:
[1 select password from users --]
I can execute sql code in your app. Even if you use a read/write connection, the code could contain some "drop table " or "drop database". Take a look of this:
Ah, no. Not even close to being vulnerable to SQL injection :)
https://github.com/emre/dpoll.xyz/blob/master/dpoll/polls/utils.py#L271
Also, Django ORM prevents SQL injection attacks with prepared queries as long as the library user doesn't execute raw queries.
The real problem with the current implementation is that the app gets all votes then filter them in a for loop. That doesn't matter in such a small scale like dPoll's but it should be done on database level. (more efficient and less code.)
Perfect! Are you able to use linq to retrieve a filtered dataset in python?