In this demonstration,
we will use SonarQube
to show the results of a static code analysis scan
on a Python codebase that contains vulnerabilities.
Now, SonarQube is a tool
that helps developers identify bugs,
security vulnerabilities, and code smells,
which are just the bugs in the code.
Now, by running SonarQube on our vulnerable code,
we will highlight some common issues
that static code analysis tools typically find.
I want to note that the purpose of the demonstration
is not to understand how to use this SonarQube tool,
'cause that could be an entire course in itself,
but it's just for you to get familiar with
some of the different tools available
and some of the recommendations that they provide built-in.
Okay, so first we see here,
this is the actual code that was scanned.
It's a Python code that's used for getting information
from a user: username, password,
and passing it on to a backend database.
Now, we see it's highlighted some things here, right?
So first, we have this,
"Make sure allowing safe and unsafe HTTP methods
is safe here."
Here, SonarQube is flagging the use
of both GET and POST methods for the login route.
The concern here is that POST requests
typically used for submitting sensitive data
like login credentials
needs to be handled securely.
This could expose the system
to attacks like cross-site request forgery, or CSRF.
SonarQube is highlighting this
to ensure that the right security measures,
such as CSRF protection, are in place,
especially when allowing both safe and unsafe methods
on this route.
I like this setup.
Right here is Where, What, Assess, How, and Activity.
Now, before we move on
to focus on this one particular vulnerability,
this is why it's important to perform peer review
and manual code analysis
because if you look here,
I made this code vulnerable for a reason.
And even though,
you know, we have hard-coded admin passwords,
we have insecure SQL database connection code here,
this is just to show emphasis
that we need to also be on our p's and q's
when we're reviewing code
to look for these things from a manual analysis standpoint
because the tools are great,
but they do not always cover everything.
And again, we see here
that there was another SQL injection,
so we understand that.
We never want to take information
directly from the user, right?
So if we have a user query
or we receive information from a user,
so, if from the form,
the user can put in their username and password
and it's directly inserted into a statement
that's going to be processed
on the backend by the SQL database,
right here, so it says query,
so this information allows for an attacker
to perform a SQL injection here.
So again, they can input any type of command string
that will allow them to bypass authentication
because it's not being stripped of any of the characters
or using a parameterized input,
which is how you mitigate SQL injection.
There's another cross-site scripting error
that it did not catch.
Again, further emphasizing that these tools are not 100%.
And then also, there's other configurations
that can be used.
This is also the community version.
So, once you pay for the professional version,
it might be a lot better at catching some of these things.
So, let's go back to this.
So, we have Where the risk is,
so it's identified it,
and it's going to say What is the risk, right?
So, it's going to give us information
about what it found and why it's an issue.
So, let's read this really quick.
So, "An HTTP method is safe when used to perform
a read-only operation, such as retrieving information.
In contrast, an unsafe HTTP method
is used to change the state of an application,
for instance, to update a user profile
on a web application."
So, "Common safe HTTP methods are GET, HEAD,
or the OPTIONS."
But, "Common unsafe HTTP methods are POST, PUT, and DELETE."
All right, so let's assess this risk.
So, you have to ask yourself whether the HTTP methods
are not defined at all
for a route or controller of the application
and a safe HTTP methods are defined and used
for a route/controller
that can change the state of an application.
So, it's going to give us an example here
of what bad looks like and what good looks like.
Okay, so it's letting us know that we should,
you know, implement it
if we're using this type of web server,
but we're using Flask,
so, we need to change our code
to use the "methods.route" function,
and that's going to help us prevent all these issues.
All right?
Because if we go back to where the risk is,
we're not using that particular method.
All right, so see how we can fix it.
It's going to give us more specific information
of how to do it,
all the scenarios that we'll use to do this, right?
So, we're going to use the "methods.route" function
for that particular finding, all right?
And then this Activity thing,
this just allows us to add comments
and directly interact with the Development Team,
'cause typically we have Security on one hand
and then we have the Development Team on the other.
And this is just like a mutual interface for us to interact,
let the developer see what's wrong,
and be more specific about how to modify the code
because even if you look at the examples they gave us,
it wasn't specific to our code.
It didn't change the code for us.
Now, of course, today,
with all these new automated and AI-generated tools,
they will be better at modifying and showing you exactly
how to fix your code,
like if you're using Copilot, and Visual Studio,
or something like that.
But in this particular demonstration,
SonarQube is a good tool,
but again, it's not perfect.
So to sum things up, we briefly used SonarQube
to cover a static analysis of a Python script.
We went over some of the things that it misses,
some of the things that it found,
and some of the corrections that it provided for us
to implement.
I hope you enjoyed this demonstration,
and I will see you in the next one.