Open gravingPro opened 3 days ago
Hi @gravingPro,
Thanks for the bug report. We will inform the Python team and get back to you on possible further guidance.
Hi @gravingPro,
A quick follow-up question. How is your custom sink defined?
In read_sql
the argument sql
is currently unused.
Hi @gravingPro,
A quick follow-up question. How is your custom sink defined? In
read_sql
the argumentsql
is currently unused.
It's just a simple example. Any sink can be used here, no matter sql injection or ssrf.
I've encountered issues in CodeQL regarding data flow interruption. Here are the details:
1. Function Parameter Passing Interruption
In the code below:
CodeQL fails to detect that the tainted variable
sql
is passed intoread_sql
when using theprocess
function to handle the function call and its argument. This shows an interruption in data flow tracking during function parameter passing and subsequent invocation with variable arguments.2.
*args
and**kwargs
InterruptionThe problem with
*args
(variable positional arguments) and**kwargs
(variable keyword arguments) is that when used in a way that impacts data flow, CodeQL can't track accurately. In the given example, using*args
in theprocess
function leads to incorrect recognition of the data flow forsql
. This issue extends to similar scenarios involving these constructs.Moreover, these problems also occur in functions related to multithreading and multiprocessing like
threading.Thread
,mulitprocess.Process
,concurrent.futures.ThreadPoolExecutor
, andconcurrent.futures.ProcessPoolExecutor
.I hope this description helps in identifying and resolving these problems. Looking forward to a timely fix or further guidance on handling such complex data flow tracking scenarios.
Best regards