Python: Promote modeling of SQLAlchemy #6589
Conversation
I've never seen this being used in real code, and this library doesn't have a lot of traction, so I would rather not commit to supporting it (which includes verifying that it actually makes things safe). Personally I don't think this is the right approach for avoiding SQL injection either.
Due to the split between `src/` and `lib/`, I was not really able to do the next step without having moved the SQLAlchemy modeling over to be in `lib/` as well.
instead of doing this via taint-steps. See description in code/tests.
After we now model `db.text()` calls from Flask-SQLAlchemy
yoff
left a comment
yoff
left a comment
There was a problem hiding this comment.
Quite impressive testing here and also the work to complete the modelling 💪
I thought it over, and it does seem quite reasonable (as in not overly FP-prone) to always alert on text objects being user controlled. If such objects are not executed, the code can probably be simplified and the alert would have been still useful. So the two-query-approach seems fine here.
It might be nice to add an inline style test for the bonus query, but I am happy to merge without it. The requested changes only really comprise the one typo I spotted...
python/ql/src/Security/CWE-089/SQLAlchemyTextClauseInjection.qhelp
Outdated
Show resolved
Hide resolved
| results = session.execute(stmt).scalars().all() | ||
|
|
||
|
|
||
| # All of these should be flagged by query |
There was a problem hiding this comment.
...and they are :-) I guess that would be more clear from an inline test.
Co-authored-by: yoff <lerchedahl@gmail.com>
Yes. I think we have something to learn from JS here, since they have a standard test setup where they use something like |
yoff
left a comment
yoff
left a comment
There was a problem hiding this comment.
LGTM as soon as the subpaths are added to the test expectations.
As discussed in a meeting today, this will end up presenting an query suite that's easier to use for customers. Since github#6589 has JUST been merged, if we get this change in fast enough, no end-user will ever have run `py/sqlalchemy-textclause-injection` as part of LGTM.com or Code Scanning.
2 participants
After creating elaborate tests for how you can use the ORM to construct queries, I realized it would be difficult to make our normal SQL injection query ever flag those, so did a 180 on how to handle it, and ended up adding a new query.
We could also extend our existing SQL-injection query to also flag up TextClause injection. I felt that putting them together would end up being a bit confusing, but I'm very open to changing this if it is cause for concern.