Question: Extending Query (UnsafeDeserialization.ql) for CWE-502
- Dominant language
- CodeQL
- Stars
- 10.1k
- Forks
- 2.1k
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 141
Description
Hi,
I am analysing python code in terms of vulnerability CWE-502 and am running query [UnsafeDeserialization.ql](https://github.com/github/codeql/blob/main/python/ql/src/Security/CWE-502/UnsafeDeserialization.ql) for this purpose. Now I would like to adapt the query to extend to more sources of untrusted data, namely:
1. I would like to mark local files as untrusted, marking the following example as vulnerable:
```
import yaml
def unsafe_load(filename):
with open(filename) as untrusted:
return yaml.load(untrusted)
```
2. I would like to mark function parameters as untrusted, marking the following example as vulnerable:
```
import yaml
def unsafe_load(untrusted):
return yaml.load(untrusted)
```
I am new to codeQL and after studying the documentation on how to write codeQL queries in Python and the codeQL repository, I am still not sure how and where I could extend the configuration to add these two sources. Based on [analyzing-data-flow-in-python](https://codeql.github.com/docs/codeql-language-guides/analyzing-data-flow-in-python/) it seems that I can use `Concepts::FileSystemAccess` and `DataFlow::ParameterNode` to model the sources and that I need to append them to the `isSource` predicate in the configuration. However, I am not sure what the current sources are based on `semmle.python.security.dataflow.UnsafeDeserializationQuery` in [UnsafeDeserializationQuery.qll](https://github.com/github/codeql/blob/main/python/ql/lib/semmle/python/security/dataflow/UnsafeDeserializationQuery.qll) and if there is any additional modification step that I need to take to run the new query.
Any help or clarifications would be greatly appreciated!
Contributor guide
Research direction
Start with python/ql/src/Security/CWE-502/UnsafeDeserialization.ql and the referenced python/ql/lib/semmle/python/security/dataflow/UnsafeDeserializationQuery.qll. Read the analyzing-data-flow-in-python guidance, then trace the existing source configuration and relevant data-flow classes. Done means the query recognizes the local-file and function-parameter examples as unsafe deserialization sources and can be run successfully.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devtools, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100