New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swift: Query for SQL injection #10757
Conversation
|
QHelp previews: swift/ql/src/queries/Security/CWE-089/SqlInjection.qhelpSQL query built from user-controlled sourcesTODO RecommendationTODO ExampleTODO TODO References
|
The tests make sense to me. sqlite3_exec and sqlite3_prepare* seem to be the appropriate sinks, because they handle raw SQL statements. sqlite3_bind* handle the parameters of prepared statements, which is safe to do even with untrusted data.
This should cover the raw sqlite3 library. Are we planning on covering wrapper libraries on top of it? e.g. https://github.com/stephencelis/SQLite.swift or https://github.com/groue/GRDB.swift.
The tests in Yeah it would be good to cover this library as well. However I'm a bit behind on this task as it is, so I'll create a follow-up ticket rather than addressing this now. --- update: added to the query priorities board. |
|
QHelp previews: swift/ql/src/queries/Security/CWE-089/SqlInjection.qhelperrors/warnings: |
|
QHelp previews: swift/ql/src/queries/Security/CWE-089/SqlInjection.qhelpDatabase query built from user-controlled sourcesIf a database query (such as a SQL query) is built from user-provided data without sufficient sanitization, a user may be able to run malicious database queries. An attacker can craft the part of the query they control to change the overall meaning of the query. RecommendationMost database connector libraries offer a way to safely embed untrusted data into a query using query parameters or prepared statements. You should use these features to build queries, rather than string concatenation or similar methods without sufficient sanitization. ExampleIn the following example, a SQL query is prepared using string interpolation to directly include a user-controlled value A better way to do this is with a prepared statement, binding References
|
|
I've removed draft status from this PR, it's ready to review. I'd like to acknowledge a few issues though. IMO none of these prevent us from merging what we have:
|
|
I've just merged main into this PR - with the extractor fix #10854 that gives us the C API results for this query. We still don't get results through the UTF-16 interface, but that's much less concerning than missing all C API results. I'd be happy to see this reviewed and merged, and deal with the remaining known issues as follow-up. |
| stmt9.bind(remoteString) | ||
| stmt9.bind([remoteString]) | ||
| stmt9.bind(["username": remoteString]) | ||
| try stmt9.run(remoteString) | ||
| try stmt9.run([remoteString]) | ||
| try stmt9.run(["username": remoteString]) | ||
| try stmt9.scalar(remoteString) | ||
| try stmt9.scalar([remoteString]) | ||
| try stmt9.scalar(["username": remoteString]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These I do not quite understand, even after looking at the SQLite.swift docs. Shouldn't these be tagged with // GOOD, or am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this whole block is GOOD, I should probably label each line individually.
This is a very odd thing to do, I'm preparing a statement that contains a parameter (the ? on line 81), binding values to the parameter three times over, then running it six times with new bindings on the parameter each time. The point is simply to check that none of the 9 operations that bind values are flagged even with a tainted value - because binding values to parameters is the 'safe' way to pass tainted data into an SQL statement.
|
Does this still need a doc review? |
|
Oh, good point! |
Hi there @geoffw0, I'm the first responder for the Docs team this week so I've taken a look at this and left some small comments and asked a couple of minor questions. I hope this isn't adding too much overhead
I'll just tag my colleague @felicitymay as well just in case (might not be necessary but I'm still quite new to reviewing CodeQL!
Co-authored-by: Ben Ahmady <32935794+subatoi@users.noreply.github.com>
|
Thanks for the review @subatoi . I believe I've addressed all your points, but please don't hesitate to say if you think it needs more work. |
Co-authored-by: Ben Ahmady <32935794+subatoi@users.noreply.github.com>
|
Thanks - those suggestions definitely help make things read a bit more easily. Please approve the PR if you're happy with the docs now (the code has already been reviewed and approved). |
|
Yep, whenever a change is pushed all reviews of the existing code are dismissed automatically. It makes sense but it can be a bit much sometimes (especially when the change is just accepting a suggestion from the approver!) |
|
Thanks again for the review, suggestions and approval. On to the next query! |
Query for SQL injection in Swift.
Draft: currently there are just test cases, covering the C API that can be used in Swift, and the SQLite.swift wrapper that I believe is commonly used as well. I'd like someone to review these test cases for realism / misconceptions / any important details I've missed before going too much further.@atorralba would you mind taking a look?