codeaudit 1.1.0__tar.gz → 1.2.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {codeaudit-1.1.0 → codeaudit-1.2.0}/CHANGELOG.md +15 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/PKG-INFO +6 -6
- {codeaudit-1.1.0 → codeaudit-1.2.0}/README.md +5 -5
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/CLIcommands.ipynb +8 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/CONTRIBUTE.md +10 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/_toc.yml +12 -3
- codeaudit-1.2.0/docs/apidocs/api_intro.md +19 -0
- codeaudit-1.2.0/docs/apidocs/codeaudit.rst +12 -0
- {codeaudit-1.1.0/docs → codeaudit-1.2.0/docs/apidocs}/modules.rst +2 -2
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/assert_check.md +37 -5
- codeaudit-1.2.0/docs/checks/builtinfunctions_check.md +138 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/input_check.md +11 -2
- codeaudit-1.2.0/docs/checks/systemcalls_check.md +76 -0
- codeaudit-1.2.0/docs/checks/tarfile_extract_check.md +76 -0
- codeaudit-1.2.0/docs/checksinformation.md +44 -0
- codeaudit-1.2.0/docs/codeauditchecks.md +22 -0
- codeaudit-1.2.0/docs/examples/ca_api_example_basic.ipynb +191 -0
- codeaudit-1.2.0/docs/examples/ca_api_example_json.ipynb +197 -0
- codeaudit-1.2.0/docs/examples/ca_api_example_overview.ipynb +160 -0
- codeaudit-1.2.0/docs/examples/checks.html +637 -0
- codeaudit-1.2.0/docs/examples/demoscan.json +205 -0
- codeaudit-1.2.0/docs/features.md +53 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/filescan.md +8 -5
- codeaudit-1.2.0/docs/implementedvalidations.md +63 -0
- codeaudit-1.2.0/docs/intro.md +76 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/issues.md +1 -1
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/makeitbetter.md +4 -4
- codeaudit-1.2.0/docs/whatissast.md +34 -0
- codeaudit-1.2.0/docs/whysast.md +92 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/__about__.py +1 -1
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/altairplots.py +53 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/api_interfaces.py +74 -14
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/data/sastchecks.csv +2 -2
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/filehelpfunctions.py +2 -2
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/reporting.py +5 -4
- codeaudit-1.2.0/tests/test_apicalls.py +60 -0
- codeaudit-1.2.0/tests/validationfiles/allshit.py +480 -0
- codeaudit-1.2.0/tests/validationfiles/dunderexec_with_parsing_error.py +34 -0
- codeaudit-1.1.0/docs/checks/builtinfunctions_check.md +0 -57
- codeaudit-1.1.0/docs/checks/systemcalls_check.md +0 -38
- codeaudit-1.1.0/docs/checks/tarfile_extract_check.md +0 -31
- codeaudit-1.1.0/docs/checksinformation.md +0 -73
- codeaudit-1.1.0/docs/codeaudit.rst +0 -12
- codeaudit-1.1.0/docs/codeauditchecks.md +0 -21
- codeaudit-1.1.0/docs/examples/checks_example.html +0 -585
- codeaudit-1.1.0/docs/features.md +0 -60
- codeaudit-1.1.0/docs/intro.md +0 -57
- codeaudit-1.1.0/docs/whysast.md +0 -39
- {codeaudit-1.1.0 → codeaudit-1.2.0}/.gitignore +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/CONTRIBUTE.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/LICENSE.txt +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/SECURITY.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/_config.yml +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/_static/nocxstyle.css +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/about.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/astlines.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/astlines2.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/changelog.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/base64_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/binding_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/chmod_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/directorycreation_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/dynamicimport_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/exception_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/hash_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/httpserver_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/loggingconf_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/marshal_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/mktemp_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/multiprocessing_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/pickle_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/random_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/shelve_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/shutil_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/subprocess_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/syscalls_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/xml_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/checks/zipfile_check.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/codeauditcommands.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/codeauditoverview.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/complexitycheck.md +0 -0
- /codeaudit-1.1.0/tests/validationfiles/allshit.py → /codeaudit-1.2.0/docs/examples/demofile.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/examples/directoryscan.html +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/examples/filescan.html +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/examples/modulescan.html +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/examples/overview.html +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/filescan.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/help.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/howtoscan.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/images/OO.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/images/ROI_logo.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/images/YourLogoHere.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/images/codeauditlogo.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/images/nocxbanner.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/images/overview_linkaudit.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/license.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/modulescan.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/overviewplot.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/pca_overview.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/sponsors.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/userguide.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/docs/warnings.md +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/filescan.png +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/pyproject.toml +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/__init__.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/checkmodules.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/codeaudit.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/complexitycheck.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/htmlhelpfunctions.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/issuevalidations.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/security_checks.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/simple.css +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/src/codeaudit/totals.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/__init__.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/count_lines_file1.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_basicpatterns.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_chmod.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_constructspart2.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_correctexceptionuse.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_count_commentlines.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_directorycreation.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_directorycreation2.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_hashstrenght.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_modulecheck.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_obfuscatingbuiltins.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_oschecks.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_random.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_standardlibconstructs.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/test_totalscheck.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/assert.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/base64.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/chmod_things.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/complexitycheck.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/correctcounts.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/directorycreation.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/directorycreation2.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/exception.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/file3.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/file_with_warnings.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/gzip.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/hashcheck.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/httpserver.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/inputstatement.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/marshal.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/modulecheck.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/multiprocessing.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/obfuscating.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/oschecks.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/pickle.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/python2_file_willnotwork.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/random.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/shelve.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/shutil.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/subprocess.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/syslibrary.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/tarfilevalidation.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/tempcheck.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/validation1.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/validation2.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/xml.py +0 -0
- {codeaudit-1.1.0 → codeaudit-1.2.0}/tests/validationfiles/zipfile.py +0 -0
|
@@ -1,5 +1,20 @@
|
|
|
1
1
|
# Change Log
|
|
2
2
|
|
|
3
|
+
# Version 1.2: Changes and Updates
|
|
4
|
+
|
|
5
|
+
* fix: Improved error handling — when performing a file scan on a single Python file that cannot be parsed, the CLI now correctly displays an error message.
|
|
6
|
+
|
|
7
|
+
* fix: Updated API logic to properly handle parsing errors for single Python files.
|
|
8
|
+
|
|
9
|
+
* fix: Corrected validation descriptions for `os.write` and `os.writev`. Writing to unvalidated or unintended file descriptors can lead to data corruption, privilege escalation, or denial of service.
|
|
10
|
+
|
|
11
|
+
* fix: Internal API functions now use a leading underscore (`_`) to clearly distinguish them from public APIs.
|
|
12
|
+
|
|
13
|
+
* **new**: Added a function for weakness visualization. Refer to the examples for usage details.
|
|
14
|
+
|
|
15
|
+
* **new**: Added API documentation and examples for usage details.
|
|
16
|
+
|
|
17
|
+
|
|
3
18
|
## Version 1.1:What's New
|
|
4
19
|
|
|
5
20
|
We've released a new version with several key improvements focused on making your security workflow smoother and providing more detailed security information.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.4
|
|
2
2
|
Name: codeaudit
|
|
3
|
-
Version: 1.
|
|
3
|
+
Version: 1.2.0
|
|
4
4
|
Summary: Simplified static security checks for Python
|
|
5
5
|
Project-URL: Documentation, https://github.com/nocomplexity/codeaudit#readme
|
|
6
6
|
Project-URL: Issues, https://github.com/nocomplexity/codeaudit/issues
|
|
@@ -35,7 +35,8 @@ Description-Content-Type: text/markdown
|
|
|
35
35
|
|
|
36
36
|
Python Code Audit - A modern Python source code analyzer based on distrust.
|
|
37
37
|
|
|
38
|
-
Python Code Audit is a tool to find **security
|
|
38
|
+
Python Code Audit is a tool to find **security weaknesses** in Python code. This static application security testing (SAST) tool has **great** features to simplify the necessary security tasks and make it fun and easy.
|
|
39
|
+
|
|
39
40
|
|
|
40
41
|
This tool is designed for anyone who uses or creates Python programs and wants to understand and mitigate potential security risks.
|
|
41
42
|
|
|
@@ -62,7 +63,7 @@ Python Code Audit has the following features:
|
|
|
62
63
|
|
|
63
64
|
|
|
64
65
|
|
|
65
|
-
> [!
|
|
66
|
+
> [!NOTE]
|
|
66
67
|
> Python Code Audit uses the Python's Abstract Syntax Tree (AST) to get robust and reliable result. Using the Python AST makes contextual Vulnerability Detection possible and false positive are minimized.
|
|
67
68
|
|
|
68
69
|
|
|
@@ -106,9 +107,8 @@ Depending on the command, a directory or file name must be specified. The output
|
|
|
106
107
|
|
|
107
108
|
Commands:
|
|
108
109
|
overview Reports Complexity and statistics per Python file from a directory.
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
modulescan Reports module information per file.
|
|
110
|
+
filescan Scans Python files or directories(packages) for vulnerabilities and reports potential issues.
|
|
111
|
+
modulescan Reports module vulnerability information.
|
|
112
112
|
checks Creates an HTML report of all implemented security checks.
|
|
113
113
|
version Prints the module version. Or use codeaudit [-v] [--v] [-version] or [--version].
|
|
114
114
|
|
|
@@ -9,7 +9,8 @@
|
|
|
9
9
|
|
|
10
10
|
Python Code Audit - A modern Python source code analyzer based on distrust.
|
|
11
11
|
|
|
12
|
-
Python Code Audit is a tool to find **security
|
|
12
|
+
Python Code Audit is a tool to find **security weaknesses** in Python code. This static application security testing (SAST) tool has **great** features to simplify the necessary security tasks and make it fun and easy.
|
|
13
|
+
|
|
13
14
|
|
|
14
15
|
This tool is designed for anyone who uses or creates Python programs and wants to understand and mitigate potential security risks.
|
|
15
16
|
|
|
@@ -36,7 +37,7 @@ Python Code Audit has the following features:
|
|
|
36
37
|
|
|
37
38
|
|
|
38
39
|
|
|
39
|
-
> [!
|
|
40
|
+
> [!NOTE]
|
|
40
41
|
> Python Code Audit uses the Python's Abstract Syntax Tree (AST) to get robust and reliable result. Using the Python AST makes contextual Vulnerability Detection possible and false positive are minimized.
|
|
41
42
|
|
|
42
43
|
|
|
@@ -80,9 +81,8 @@ Depending on the command, a directory or file name must be specified. The output
|
|
|
80
81
|
|
|
81
82
|
Commands:
|
|
82
83
|
overview Reports Complexity and statistics per Python file from a directory.
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
modulescan Reports module information per file.
|
|
84
|
+
filescan Scans Python files or directories(packages) for vulnerabilities and reports potential issues.
|
|
85
|
+
modulescan Reports module vulnerability information.
|
|
86
86
|
checks Creates an HTML report of all implemented security checks.
|
|
87
87
|
version Prints the module version. Or use codeaudit [-v] [--v] [-version] or [--version].
|
|
88
88
|
|
|
@@ -141,6 +141,14 @@
|
|
|
141
141
|
"source": [
|
|
142
142
|
"create_documentation_file(output)"
|
|
143
143
|
]
|
|
144
|
+
},
|
|
145
|
+
{
|
|
146
|
+
"cell_type": "markdown",
|
|
147
|
+
"id": "fd67a8f6-ed99-4f69-ab55-aad6103c7b5c",
|
|
148
|
+
"metadata": {},
|
|
149
|
+
"source": [
|
|
150
|
+
"## Create overview of validation commands for in documentation"
|
|
151
|
+
]
|
|
144
152
|
}
|
|
145
153
|
],
|
|
146
154
|
"metadata": {
|
|
@@ -37,6 +37,16 @@ This project values respect and inclusiveness, and enforces a [Code of Conduct](
|
|
|
37
37
|
This is an open community driven project. Contributors will be mentioned in the documentation.
|
|
38
38
|
:::
|
|
39
39
|
|
|
40
|
+
## Help with development
|
|
41
|
+
|
|
42
|
+
:::{admonition} Start with Code Development
|
|
43
|
+
:class: tip
|
|
44
|
+
Making code contributions to **Python Code Audit** should be fun and simple!
|
|
45
|
+
|
|
46
|
+
See the [section Development](makeitbetter) for to get a head start when making code contributions!
|
|
47
|
+
|
|
48
|
+
:::
|
|
49
|
+
|
|
40
50
|
(CoC-label)=
|
|
41
51
|
## Code of Conduct
|
|
42
52
|
|
|
@@ -12,12 +12,14 @@ parts:
|
|
|
12
12
|
- file: modulescan
|
|
13
13
|
- file: codeauditchecks
|
|
14
14
|
- file: howtoscan
|
|
15
|
+
- file: whatissast
|
|
15
16
|
- file: whysast
|
|
16
17
|
- file: issues
|
|
17
18
|
|
|
18
19
|
|
|
19
20
|
- caption: Security Checks
|
|
20
21
|
chapters:
|
|
22
|
+
- file: implementedvalidations
|
|
21
23
|
- file: checksinformation
|
|
22
24
|
sections:
|
|
23
25
|
- file: checks/assert_check
|
|
@@ -58,9 +60,15 @@ parts:
|
|
|
58
60
|
- file: changelog
|
|
59
61
|
|
|
60
62
|
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
63
|
+
- caption: API Documentation
|
|
64
|
+
chapters:
|
|
65
|
+
- file: apidocs/api_intro
|
|
66
|
+
sections:
|
|
67
|
+
- file: examples/ca_api_example_overview
|
|
68
|
+
- file: examples/ca_api_example_json
|
|
69
|
+
- file: examples/ca_api_example_basic
|
|
70
|
+
- file: apidocs/modules
|
|
71
|
+
|
|
64
72
|
|
|
65
73
|
|
|
66
74
|
- caption: About
|
|
@@ -70,3 +78,4 @@ parts:
|
|
|
70
78
|
- file: sponsors
|
|
71
79
|
- file: license
|
|
72
80
|
- file: about
|
|
81
|
+
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Python Code Audit APIs
|
|
2
|
+
|
|
3
|
+
The **Python Code Audit** APIs make it easy to build your own tools and integrations, such as:
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
* **Reporting dashboard**: Easily create custom dashboards using the APIs. Audit scan results can be exported to a human-readable JSON file for analysis and visualization.
|
|
7
|
+
|
|
8
|
+
* **Statistical Analysis**:
|
|
9
|
+
Use the APIs to identify and study common Python security weaknesses across multiple packages within your organization.
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
* **CI/CD Integration**:
|
|
13
|
+
Integrate the APIs into your continuous integration and deployment pipelines — even when using remote source control systems like `GitHub.com`, `GitLab.com`, `https://codeberg.org/` or https://notabug.org/ and many others!
|
|
14
|
+
|
|
15
|
+
We’ve provided a few simple examples to demonstrate how to use the APIs effectively.
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
```{tableofcontents}
|
|
19
|
+
```
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
The Python `assert` statement itself is not insecure, but its *misuse* can lead to security vulnerabilities.
|
|
4
4
|
|
|
5
5
|
:::{danger}
|
|
6
|
-
Using `assert`
|
|
6
|
+
Using `assert` for checks can introduce **serious security** risks!
|
|
7
7
|
:::
|
|
8
8
|
|
|
9
9
|
|
|
@@ -21,18 +21,50 @@ This means any crucial checks you rely on for security or data integrity will si
|
|
|
21
21
|
|
|
22
22
|
* **Not for graceful error handling:** Assertions are designed to signal "this should never happen, it's a bug." They raise an `AssertionError` which typically halts the program. In a production environment, you usually want to handle anticipated errors gracefully, log them, and potentially recover or inform the user, rather than crashing the application.
|
|
23
23
|
|
|
24
|
-
2.
|
|
24
|
+
2. Dangers of Side effects in assert Statements:
|
|
25
25
|
|
|
26
|
-
* If an
|
|
26
|
+
* If an assert statement contains code with side effects (e.g., modifying a variable or calling a function that performs an action), those side effects will also be skipped when assertions are disabled. For example, when running Python with the -O optimization flag. This can lead to unexpected behaviour and even security vulnerabilities.
|
|
27
27
|
|
|
28
|
-
|
|
28
|
+
* If you rely on `assert` to prevent a `ZeroDivisionError` or validate user input, those checks will silently disappear in optimized environments. As a result, code may behave differently than intended, creating potential security gaps.
|
|
29
|
+
|
|
30
|
+
* Relying on assert for input validation is especially dangerous. If assertions are used to block malicious input (e.g., to prevent SQL injection or enforce type checks), an attacker could exploit the fact that these validations are stripped out in production.
|
|
31
|
+
|
|
32
|
+
* If an `assert` statement contains code with side effects (e.g., modifying a variable, calling a function that performs an action), those side effects will also be skipped when assertions are disabled. This can lead to unexpected behaviour and security gaps.
|
|
33
|
+
|
|
34
|
+
* Instead of catching an AssertionError, a program can run differently. This can have severe security consequences. E.g. if asserts are used to validate user input to prevent sql injections or user input.
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
## Preventive measures
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
1. Use assert for testing code and during development only!
|
|
29
41
|
|
|
30
42
|
* `assert` is good to use for `pytest` or other development constructs.
|
|
31
43
|
|
|
32
44
|
* `Assert` helps to find mistakes during development. But it is not a security fence to protect against external threats or a robust mechanism for handling runtime issues in a live system. For production code, especially when dealing with external inputs or critical business logic, rely on explicit `if/else` checks and robust exception handling.
|
|
33
45
|
|
|
34
46
|
* `Assert` statements should in general only be used for testing and debugging purposes.
|
|
35
|
-
|
|
47
|
+
|
|
48
|
+
`assert` statements **SHOULD** be removed when not running in debug mode. This means when invoking the Python command with the -O or -OO options.
|
|
49
|
+
|
|
50
|
+
2. Use explicit condition checks and raise proper exceptions (e.g., `ValueError`, `TypeError`) for input validation and critical logic.
|
|
51
|
+
|
|
52
|
+
3. **Never ever** use `assert` in production Python code for checks.
|
|
53
|
+
|
|
54
|
+
4. The **only** safe alternative: Explicit Checks!
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
For production code, especially when handling external inputs or executing critical logic, always rely on explicit condition checks and robust exception handling.
|
|
58
|
+
|
|
59
|
+
:::{admonition} Instead of an assert, use standard control flow and exception raising
|
|
60
|
+
:class: hint
|
|
61
|
+
|
|
62
|
+
* Use if/else checks: Explicitly validate inputs and conditions.
|
|
63
|
+
|
|
64
|
+
* Raise proper exceptions: Use dedicated exceptions like `ValueError`, `TypeError`, or a custom exception to signal an issue. This provides a robust mechanism that can be caught and handled gracefully by upstream code, logging a clear error message instead of silently failing or creating a security hole.
|
|
65
|
+
|
|
66
|
+
:::
|
|
67
|
+
|
|
36
68
|
|
|
37
69
|
|
|
38
70
|
## Example
|
|
@@ -0,0 +1,138 @@
|
|
|
1
|
+
# Built-in Functions
|
|
2
|
+
|
|
3
|
+
Some Python built-in functions can cause severe risks.
|
|
4
|
+
|
|
5
|
+
The Python built-in functions:
|
|
6
|
+
* `eval`
|
|
7
|
+
* `exec` and
|
|
8
|
+
* `compile`
|
|
9
|
+
Should always be reviewed within the full context. By default use of this function is a **red** alert from a security perspective.
|
|
10
|
+
|
|
11
|
+
Python Code Audit checks also on Builtin that are 'hidden':
|
|
12
|
+
|
|
13
|
+
* Confusable homoglyphs like: `ℯ𝓍ℯ𝒸("print(2 + 2)")` Statements are detected.
|
|
14
|
+
|
|
15
|
+
* Obfuscating usage of builtins module calls of `eval`, `exec` and `compile` like:
|
|
16
|
+
```python
|
|
17
|
+
import builtins
|
|
18
|
+
b = builtins
|
|
19
|
+
b.exec("2+2")
|
|
20
|
+
```
|
|
21
|
+
Or
|
|
22
|
+
```python
|
|
23
|
+
code_obj = d.compile('x = 5*5\nprint(x)', '<string>', 'exec')
|
|
24
|
+
result = d.exec(code_obj) #Input should not be obfuscated. Code Audit will detect this!
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
## Why check on `eval`
|
|
28
|
+
|
|
29
|
+
:::{admonition} Security risk
|
|
30
|
+
:class: danger
|
|
31
|
+
`eval()` can execute arbitrary Python code.
|
|
32
|
+
|
|
33
|
+
If the input is user-controlled or from an untrusted source, this can be exploited.
|
|
34
|
+
:::
|
|
35
|
+
|
|
36
|
+
So calling `eval` with user-supplied input may lead to security vulnerabilities.
|
|
37
|
+
|
|
38
|
+
The `eval` function can also be used to execute arbitrary code objects (such as those created by `compile()`).
|
|
39
|
+
|
|
40
|
+
Normal Python programs should not need to use this built-in function.
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
The primary security concern with Python’s built-in `eval()` is its potential to enable **Remote Code Execution (RCE)**. Passing untrusted input to `eval()` is effectively the same as letting an attacker run arbitrary Python code on your system.
|
|
44
|
+
|
|
45
|
+
Key Security Risks when using `eval`:
|
|
46
|
+
|
|
47
|
+
1. **Arbitrary Code Execution (RCE)**
|
|
48
|
+
|
|
49
|
+
* `eval()` runs any Python code in the string it receives. If an attacker controls that string, they can execute malicious commands—stealing data, reading files, or invoking dangerous modules like `os` or `subprocess`.
|
|
50
|
+
|
|
51
|
+
2. **Broken Sandboxing**
|
|
52
|
+
|
|
53
|
+
* Attempts to make `eval()` “safe” by restricting variables or the execution environment are unreliable. Attackers often find creative ways to escape these sandboxes and access sensitive data, functions, or the file system.
|
|
54
|
+
|
|
55
|
+
3. **Denial of Service (DoS)**
|
|
56
|
+
|
|
57
|
+
* Even without stealing data, attackers can craft inputs that trigger infinite loops, deep recursion, or memory exhaustion. This can crash the interpreter or take down an entire service.
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
:::{warning}
|
|
62
|
+
This function is capable of executing any Python code given to it. Passing unvalidated external input (such as user input, or file contents , or API retrieved content) is a major security flaw that enables arbitrary code execution.
|
|
63
|
+
|
|
64
|
+
**Never ever not use this function on data from untrusted sources.**
|
|
65
|
+
:::
|
|
66
|
+
|
|
67
|
+
## Why Check on `exec`
|
|
68
|
+
|
|
69
|
+
:::{danger}
|
|
70
|
+
The use of the exec() function in Python should never be permitted from a security perspective.
|
|
71
|
+
|
|
72
|
+
It can executes arbitrary code. Or be called with untrusted input. This is a direct path to a severe security compromise.
|
|
73
|
+
:::
|
|
74
|
+
|
|
75
|
+
This function executes arbitrary code. Calling it with user-supplied input may lead to security vulnerabilities.
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
Using `exec` in Python should never be tolerated from a security perspective. Key risks are:
|
|
79
|
+
|
|
80
|
+
1. **Arbitrary Code Execution:** Executes any string as Python code; untrusted input can lead to full system compromise.
|
|
81
|
+
2. **Sandboxing Fails:** Attempts to restrict execution are often bypassed.
|
|
82
|
+
3. **Denial of Service:** Malicious code can cause infinite loops or memory exhaustion.
|
|
83
|
+
4. **Injection Risk:** Dynamic code with user input creates exploitable injection points.
|
|
84
|
+
5. **Hidden Side Effects:** Alters variables or global state unpredictably, introducing security and reliability issues.
|
|
85
|
+
|
|
86
|
+
|
|
87
|
+
|
|
88
|
+
|
|
89
|
+
|
|
90
|
+
## Why check on `compile`
|
|
91
|
+
|
|
92
|
+
As a general rule:
|
|
93
|
+
* Never trust Python code that uses `compile`. Verify and understand all risks before running such a program.
|
|
94
|
+
|
|
95
|
+
Security reasons to avoid Python’s built-in `compile()`:
|
|
96
|
+
|
|
97
|
+
1. **Arbitrary Code Execution**
|
|
98
|
+
|
|
99
|
+
* `compile()` takes raw strings and turns them into executable Python code objects. If user input is passed to it (directly or indirectly), an attacker can execute arbitrary Python code on your system.
|
|
100
|
+
|
|
101
|
+
2. **Bypassing Sandboxing or Input Validation**
|
|
102
|
+
|
|
103
|
+
* Using `compile()` can allow malicious input to bypass normal validation layers. Even if you sanitise strings for SQL or HTML, a crafted payload compiled into Python bytecode can escape restrictions.
|
|
104
|
+
|
|
105
|
+
3. **Denial of Service (DoS) via Resource Exhaustion**
|
|
106
|
+
|
|
107
|
+
* Large or deeply nested input passed to `compile()` can consume huge amounts of CPU, memory, or recursion depth, potentially crashing the interpreter (e.g., from complex expressions or nested structures).
|
|
108
|
+
|
|
109
|
+
4. **Exposure of Sensitive Data**
|
|
110
|
+
|
|
111
|
+
* Once arbitrary code is compiled and run, it can access system resources, environment variables, secrets in memory, or files on disk—leading to credential leaks or other security breaches.
|
|
112
|
+
|
|
113
|
+
|
|
114
|
+
|
|
115
|
+
:::{warning}
|
|
116
|
+
Compiling very large or deeply nested strings into an AST object can crash the Python interpreter. This happens because Python’s AST compiler has stack depth limitations, which may be exceeded by sufficiently complex input.
|
|
117
|
+
:::
|
|
118
|
+
|
|
119
|
+
:::{warning}
|
|
120
|
+
Also the construct `ast.literal_eval` is not safe!
|
|
121
|
+
Using this construct can still crash the Python interpreter due to stack depth limitations in Python’s AST compiler.
|
|
122
|
+
|
|
123
|
+
[Reference](https://docs.python.org/3/library/ast.html#ast.literal_eval)
|
|
124
|
+
:::
|
|
125
|
+
|
|
126
|
+
## Preventive measures
|
|
127
|
+
|
|
128
|
+
* Avoid using `eval`,`exec` and `compile`: Find a secure way by design, so rethink your design again from a security perspective. There is always a better and safer solution.
|
|
129
|
+
|
|
130
|
+
|
|
131
|
+
|
|
132
|
+
## More information
|
|
133
|
+
|
|
134
|
+
* https://docs.python.org/3/library/functions.html#eval
|
|
135
|
+
|
|
136
|
+
* https://docs.python.org/3/library/functions.html#exec
|
|
137
|
+
|
|
138
|
+
* https://docs.python.org/3/library/functions.html#compile
|
|
@@ -13,7 +13,9 @@ Validate/sanitize all input thoroughly before using it in any part of your appli
|
|
|
13
13
|
:::
|
|
14
14
|
|
|
15
15
|
|
|
16
|
-
##
|
|
16
|
+
## Security concerns
|
|
17
|
+
|
|
18
|
+
Common security concerns with the use of `input()` in Python are:
|
|
17
19
|
|
|
18
20
|
* **Injection Attacks:** If you take user input and directly embed it into:
|
|
19
21
|
* **SQL queries:** SQL Injection (e.g., a user enters `' OR 1=1; --` to bypass login).
|
|
@@ -28,7 +30,9 @@ Validate/sanitize all input thoroughly before using it in any part of your appli
|
|
|
28
30
|
|
|
29
31
|
* **Revealing Sensitive Information:** If your error handling is too verbose and displays raw error messages that include sensitive system paths or internal details based on user input, attackers can use this information for further exploitation.
|
|
30
32
|
|
|
31
|
-
##
|
|
33
|
+
## Preventive measures
|
|
34
|
+
|
|
35
|
+
Some simple rules for handling User Input:
|
|
32
36
|
|
|
33
37
|
1. **Always Validate Input:**
|
|
34
38
|
|
|
@@ -57,3 +61,8 @@ Never ever use `eval()` or `exec()` with user-provided strings.
|
|
|
57
61
|
|
|
58
62
|
6. **Secure Error Handling:** Don't display raw error messages to users. Log them for internal review and provide generic, user-friendly error messages instead.
|
|
59
63
|
|
|
64
|
+
## More information
|
|
65
|
+
|
|
66
|
+
* [CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html)
|
|
67
|
+
* [CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html)
|
|
68
|
+
* [CWE-20: Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html)
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# OS System calls
|
|
2
|
+
|
|
3
|
+
:::{danger}
|
|
4
|
+
Be suspicious when direct system calls `os.*` are used in a Python program.
|
|
5
|
+
:::
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
*Never trust always verify!*
|
|
9
|
+
|
|
10
|
+
So direct systems calls from a Python program **SHOULD** always be verified. System calls can be major security risk. But are nice and easy to use. So often these calls are used. But not always in the correct way!
|
|
11
|
+
|
|
12
|
+
`codeaudit` checks on:
|
|
13
|
+
* `os.system` : A nice command to execute OS things are malware in a subshell.
|
|
14
|
+
* os.execl(path, arg0, arg1, ...)
|
|
15
|
+
* os.execle(path, arg0, arg1, ..., env)
|
|
16
|
+
* os.execlp(file, arg0, arg1, ...)
|
|
17
|
+
* os.execlpe(file, arg0, arg1, ..., env)
|
|
18
|
+
* os.execv(path, args)
|
|
19
|
+
* os.execve(path, args, env)
|
|
20
|
+
* os.execvp(file, args)
|
|
21
|
+
* os.execvpe(file, args, env)
|
|
22
|
+
* `os.fork`
|
|
23
|
+
* `os.write`
|
|
24
|
+
* `os.writev`
|
|
25
|
+
* and more!
|
|
26
|
+
|
|
27
|
+
These functions all can execute a new program, replacing the current process; they do not return. On Unix, the new executable is loaded into the current process, and will have the same process id as the caller.
|
|
28
|
+
|
|
29
|
+
:::{tip}
|
|
30
|
+
When shell commands are used, make sure you understand possibly security consequences. Besides malware most common is that the availability is at risks when file systems are filled with files or logfiles.
|
|
31
|
+
:::
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
## Why `os.write` can be Vulnerable: File Descriptor Mismanagement
|
|
35
|
+
|
|
36
|
+
The vulnerability of the `os.write(fd, data)` function in Python stems not from the function itself, but from its **low-level interaction with file descriptors (FDs)**, which bypasses standard, safer I/O abstractions.
|
|
37
|
+
The function writes raw bytes directly to a numerical file descriptor `fd`.
|
|
38
|
+
|
|
39
|
+
The primary risk is the use of an **unvalidated or attacker-controlled file descriptor (FD)**. This can lead to severe security and stability issues:
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
1. Data Corruption and Integrity Compromise 💾
|
|
43
|
+
|
|
44
|
+
If an attacker can control the `fd` argument, they could redirect the output to an unintended file:
|
|
45
|
+
|
|
46
|
+
* **Sensitive File Overwriting:** Writing to critical system files (e.g., configuration files like `/etc/passwd` or `/etc/shadow`, log files, or application binaries) can **corrupt system integrity** or **allow privilege escalation** if the data contains malicious commands or changes authentication data.
|
|
47
|
+
* **Arbitrary File Write:** The attacker can potentially **overwrite any file** the process has write permissions for.
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
2. Information Leakage and Data Injection ✉️
|
|
51
|
+
|
|
52
|
+
File descriptors aren't just for disk files; they can also point to **sockets, pipes, or other inter-process communication (IPC) channels**.
|
|
53
|
+
|
|
54
|
+
* **Inter-Process Data Injection:** Writing to a pipe or socket `fd` used by another process can **inject arbitrary, unvalidated data** into that process's data stream. For example, injecting malicious commands into a shell session or corrupted data into a communication stream.
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
3. Denial of Service (DoS) 🛑
|
|
58
|
+
|
|
59
|
+
Mismanagement of FDs can directly impact system stability or resource availability.
|
|
60
|
+
|
|
61
|
+
* **Resource Exhaustion:** If `fd` points to a device or a pipe that is not being read, excessive writes can fill up buffers, causing the application or system to hang or crash due to resource exhaustion.
|
|
62
|
+
* **Service Interruption:** Writing gibberish to an active and expected stream can immediately crash or hang the receiving application, causing a **denial of service**.
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
### Preventive measures
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
Always ensure that file descriptors used with $\mathtt{os.write}$ are **validated** and **tightly controlled**. It is generally safer to use Python's built-in file handling (e.g., the $\mathtt{open()}$ function and $\mathtt{file.write()}$ method), which operates at a higher level of abstraction and typically includes more robust error and permission handling.
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
## More information
|
|
72
|
+
|
|
73
|
+
* https://docs.python.org/3/library/os.html#os.popen
|
|
74
|
+
* https://cwe.mitre.org/data/definitions/78.html
|
|
75
|
+
* [Python Fork Bomb](https://medium.com/@BuildandDebug/python-fork-bomb-a-one-liner-that-can-crash-your-system-652540c7d89f)
|
|
76
|
+
* [Fork bomb attack (Rabbit virus)](https://www.imperva.com/learn/ddos/fork-bomb/)
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# TarFile Statement
|
|
2
|
+
|
|
3
|
+
The Python `tarfile` module makes it possible to read and write tar archives.
|
|
4
|
+
|
|
5
|
+
Code Audit checks on the use of:
|
|
6
|
+
* `TarFile.extract` and
|
|
7
|
+
* `TarFile.extractall`
|
|
8
|
+
Using these methods in Python code can give serious security concerns.
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
:::{admonition} The default rule is:
|
|
12
|
+
:class: danger
|
|
13
|
+
Assume all input is malicious.
|
|
14
|
+
:::
|
|
15
|
+
|
|
16
|
+
Using these commands in Python code can expose systems to several risks:
|
|
17
|
+
|
|
18
|
+
* Privilege escalation: An attacker can change file permissions on sensitive files (for example, `/etc/shadow` or SSH keys) if the extraction process runs with root or elevated privileges.
|
|
19
|
+
|
|
20
|
+
* Sandbox escape: Many systems rely on extraction directories or temporary paths for isolation; malicious archives can break that isolation and allow code to operate outside the sandbox.
|
|
21
|
+
|
|
22
|
+
* Tampering and log evasion: By modifying file timestamps or other metadata, an attacker can obscure activity, confuse forensic timelines, or mislead incident response.
|
|
23
|
+
|
|
24
|
+
* Easy exploitation: Crafting a malicious tarball is straightforward and requires no specialized tools, making exploitation trivial for an attacker.
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
:::{danger}
|
|
28
|
+
Using `TarFile.extractall` or `TarFile.extract` is dangerous.
|
|
29
|
+
Always. So good mitigation measurement **must** be present in the code!
|
|
30
|
+
:::
|
|
31
|
+
|
|
32
|
+
But besides using these `tarfile` commands in your Python code, there have been some vulnerabilities with the `tarfile` module implementation in CPython in the past.
|
|
33
|
+
|
|
34
|
+
So from a security point of view checking if your code is extracting files using the `tarfile` command is vital.
|
|
35
|
+
|
|
36
|
+
:::{note}
|
|
37
|
+
Use of the `tarfile` extraction methods in Python code should **always** be reviewed in depth!
|
|
38
|
+
|
|
39
|
+
This means:
|
|
40
|
+
* Check if the code uses defence in-depth measures for extracting files.
|
|
41
|
+
|
|
42
|
+
* Check if the files that will be extracted by the Python code can be assumed secure, so not tampered with. If not: validate if enough additional mitigation measurements are in place when using this code.
|
|
43
|
+
|
|
44
|
+
Mitigation measurements are always context dependent, and can be e.g. running the Python program in an isolated environment.
|
|
45
|
+
:::
|
|
46
|
+
|
|
47
|
+
## Preventive measures
|
|
48
|
+
|
|
49
|
+
Never extract archives from untrusted sources without prior inspection. It is possible that files are created outside of path, e.g. members that have absolute filenames starting with `"/"` or filenames with two dots `".."`.
|
|
50
|
+
|
|
51
|
+
Make sure a proper `filter` is set:
|
|
52
|
+
```
|
|
53
|
+
TarFile.extractall(path='.', members=None, *, numeric_owner=False, filter=None)
|
|
54
|
+
```
|
|
55
|
+
The filter argument specifies how members are modified or rejected before extraction. So set minimal `filter='data'` to prevent the most dangerous security issues, and read the Extraction filters section documentation for details.
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
* Do not pass filter="tar" or filter="data" for untrusted archives.
|
|
59
|
+
If you must unpack, force filter="none" and run in a dedicated, non-privileged container/VM.
|
|
60
|
+
|
|
61
|
+
:::{note}
|
|
62
|
+
This validation test requires **always** human inspection if the construct is detected.
|
|
63
|
+
No automatic test can give you enough confidence! So **no AI agent or other GenAI thing** will help you.
|
|
64
|
+
|
|
65
|
+
Using this construct is fine, but make sure you known how to prevent disasters!
|
|
66
|
+
:::
|
|
67
|
+
|
|
68
|
+
## More info
|
|
69
|
+
|
|
70
|
+
* [CVE-2025-4330](https://www.cve.org/CVERecord?id=CVE-2025-4330)
|
|
71
|
+
* [CVE-2024-12718](https://nvd.nist.gov/vuln/detail/CVE-2024-12718)
|
|
72
|
+
* [CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html)
|
|
73
|
+
* https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter
|
|
74
|
+
* [What Is The Tarfile Vulnerability in Python?](https://www.securitycompass.com/kontra/what-is-the-tarfile-vulnerability-in-python/)
|
|
75
|
+
* [Summary of Python tarfile Infinite Loop Vulnerability (CVE-2025-8194)](https://zeropath.com/blog/cve-2025-8194-python-tarfile-infinite-loop)
|
|
76
|
+
* [Tarfile: Exploiting the World With a 15-Year-Old Vulnerability](https://www.trellix.com/blogs/research/tarfile-exploiting-the-world/)
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# Information on checks
|
|
2
|
+
|
|
3
|
+
**Python Code Audit** has many implemented security checks based on possible security threats when using Python Standard Library (PSL) calls.
|
|
4
|
+
|
|
5
|
+
Checks are done to determine:
|
|
6
|
+
* **If** and
|
|
7
|
+
* **Where**
|
|
8
|
+
|
|
9
|
+
Python source code uses functions or classes that are a security weakness.
|
|
10
|
+
|
|
11
|
+
A security weakness is a flaw, design choice, or implementation issue that could potentially lead to a security problem — but isn’t necessarily exploitable by itself.
|
|
12
|
+
|
|
13
|
+
:::{admonition} **Review**, **remediate**, and **validate** all identified security weaknesses in the code!
|
|
14
|
+
:class: tip
|
|
15
|
+
Ensure that all reported **security findings** are fully addressed. The code must be thoroughly reviewed and corrected to eliminate weaknesses and prevent potential exploitation as **vulnerabilities**.
|
|
16
|
+
|
|
17
|
+
:::
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
The majority of validations is done using advanced AST parsing of Python files. Parsed code is **not** compiled or executed. This to prevent security issues when using this tool!
|
|
23
|
+
|
|
24
|
+
Due to using the AST for validations implemented constructs code that use Python Standard Library modules that can be in potential cause a security issue. Also when aliases are used constructs will be detected. Aliases in code are often not directly detected with a 'human' code review. Sometimes even on purpose!
|
|
25
|
+
|
|
26
|
+
To check if an imported function is used several cases of occurrence will be detected. For e.g. `os.access` call:
|
|
27
|
+
* import os
|
|
28
|
+
* import os as alias
|
|
29
|
+
* from os import access
|
|
30
|
+
* from os import access as x
|
|
31
|
+
|
|
32
|
+
So the following `clown` construct is detected, since **Python Code Audit** checks on use of the `system` method of the `os` module.
|
|
33
|
+
```python
|
|
34
|
+
from os import system as clown
|
|
35
|
+
clown('ls -la')
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
## Validations overview
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
In the following subsections detailed information on implemented security validations:
|
|
42
|
+
```{tableofcontents}
|
|
43
|
+
```
|
|
44
|
+
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
# Command `codeaudit checks`
|
|
2
|
+
|
|
3
|
+
The `codeaudit checks` command creates a report with all security validation implemented for that are used for the `filescan` scan command.
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
To use the `codeaudit checks` feature type in the console:
|
|
7
|
+
|
|
8
|
+
```
|
|
9
|
+
codeaudit checks
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
This will generate a HTML report, including the version of Python Code Audit that is installed.
|
|
13
|
+
|
|
14
|
+
Example output as HTML [click to see](examples/checks.html), or see below as embedded HTML:
|
|
15
|
+
|
|
16
|
+
:::{attention}
|
|
17
|
+
Always use the latest version to have the latest security validations!
|
|
18
|
+
|
|
19
|
+
Update your local installation with:
|
|
20
|
+
```bash
|
|
21
|
+
pip install -U codeaudit
|
|
22
|
+
```
|