Welcome back to my series where I am breaking down application security so that anyone can do it without hiring expensive teams of employees. If you’ve made it this far, we’ve come a long way to get here. Let’s recap:

1. We defined what appsec is

2. We discussed the importance of understanding what you’re trying to protect

3. We emphasized that protecting yourself from the outside in is important from both identifyingand authorizing

4. We understood whyapplications are hackable

5. We understood that not all exploits are the ones from the media. Sometimes people will just abuse coupon codes!

6. We applied previous lessons, and learned to think like an attacker to emulate what bad outcomes could happen through a process called threat modeling

7. We understood that proving that the above analyses was indeed correct was worth the effort

And finally we’re here. Today we get to the final post in our series, which is about fixing your code correctly.

Side effects

When the human body is subjected to a sudden chemical change (aka medicine) it may help remedy their sickness, but it can also introduce side effects. Similarly, when a code is subjected to change, it may fix the problem at hand, but it may affect how that code now behaves. We’ll explore this through an example of when we provide a correct fix to a vulnerability that it can subtly transform into a separate vulnerability.

From Bad to Worse

Let’s explore a short code sample below that we can understand a few things:

1. we have a small flask application setup (ignore the stuff in the black)

2. the Green stars indicate where the model (in our Model View Controller aka MVCarchitecture) comes into play. This allows things like unfurling data structures into an expected structure we desire so that we can interact with databases

3. the red tells you where things can go wrong because taint is able to enter!

4. the yellow tells you that we have hardcoded a role!

So if we follow our example in our /register route, we can see that the name and email attributes, from the form portion, of the request submitted are used directly in the SQL query. This results in SQL injection, where the consequence is really up to the SQL query injected (in this case it’s about changing data, to deleting the db, or even using stored payloads as latent attack vectors [think things like stored XSS and the like], etcetc.).

What is the fix here? We have to parameterize the query! We can either do this manually, or we switch to an ORMsystem where we get the SQL injection security guarantee baked into it! Secure by default which is great!…. or is it?

Let’s observe in the /register_fixed route the ORM fix. We take the whole request.form object and deserialize it into the User class where the green stars are. This prevents any possibility of SQL injection, mission accomplished!

If we observe a bit more carefully at the User model, we can see that it has a role attribute that has no default in the class. It may be that the default value is baked into the table itself as member, but in our example it’s a value that could be manipulated!

In the /register example, where the yellow points to, we hardcoded the role as member. This ensured that any INSERT queries were inserted as members.

Because we have no default role, and we are deserializing into the User class, it also means that an attacker can put a request.form.role value as “admin” or whatever role of their choosing as the role, and now we achieved privilege escalation.

This is the whole point of being careful of vulnerability remediation. You may fix a security vulnerability, but you may also introduce another vulnerability at the same time in a subtle way that may not be immediately clear.

What Do I Do?

Can’t I just use AI agents for fixes?

The answer is a yes and a no.

We’ve discussed previously that it is imperative we must understand our application. If you truly understand your application and can review the code that the AI agent is churning out (they’re quite smart these days), and you can be the critic of its output, then go for it. If you don’t know what the application is doing, and you’re really just trusting the AI agent to fix everything, make no mistakes, you might want to reconsider the usage of AI in your workflows.

It isn’t always clear if AI coding agents are making these mistakes or not at every step. They very well could be, and in fact, there are studies that examine this behavior here, here, and here.

We must be vigilant and working with an understanding of how the codebase is structured, is working right now, and how it ought to work from a security perspective.

Thanks for reading and we’ll be back soon with something new:)

If you’ve made it to the end of our Breaking Down Appsec series, I am grateful for your support!

At Pigeon Labs we have broken down appsec into its core fundamentals and more that go beyond what we have discussed in our series. This is to ensure our mission that all software, agentic or not, is safe so that all companies can continue to worry more about their business and less on security. We use all the methodology we have discussed in our testing and fixing procedures.

If you want to radically improve the security of your software and/or agents, click on this link here!