This page walks you through the basics of running Pysa. If you want exercises to walk you through using Pysa's more advanced features, check out this tutorial.
The setup requires the following 4 types of files.
- Source Code (
*.py): This is your application's code.
- Taint Config (
taint.config): This file declares sources, sinks, features, and rules.
- Taint Models (
.pysa): These files link together the information in your source code and
taint.config. They tell Pysa where in our code there exist sources and sinks.
- Pysa Configuration (
.pyre_configuration): Parts of this file are critical to using Pysa.
source_directoriestells Pysa the directory containing the source code you want to analyze.
taint_models_pathtells Pysa where to find the config and model files.
Let's look at a simple taint analysis example. To follow along, create a
static_analysis_example and navigate to it. Paste the code snippets
into the appropriately named files.
Notice the following:
inputfunction is a taint source since it gets input directly from the user.
os.systemfunction is a taint sink, since we do not want user-controlled values to flow into it.
- The return value of
inputis used as the URL for a
wgetcall, which is executed by
wgetcan therefore be doing anything, out of the programmer's control.
- This data flow should be identified as a potential security issue.
This declares the valid sources and sinks that Pysa should recognize. We
also tell Pysa that data flowing from a
UserControlled source to a
RemoteCodeExecution sink is a possible shell injection.
This file links together the information in
use it to tell Pysa where in our code there exist sources and sinks.
Pysa needs to know what directory to analyze, as well as where to find the config and model files.
Now let's run the static analysis:
Looking at the output, we see that pyre surfaces the tainted data flow that we expected.
Let's run it again and save the results:
--save-results-to option will save more detailed results to