Parsing and Validating Lambda Parameters, Headers, and Variables

ACM.325 Creating a Validation Function to Mitigate Injection Attacks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Lambda | Container Security | Application Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post we pulled values from Secrets Manager to use in our function and then cleaned up afterwards to mitigate the chance of a credential leak.

In this post, I want to get the repository name from a parameter, but I want to make sure it doesn’t have some nasty characters embedded into it.

Recall that we’re passing in the value of the repository when we run the function. You can do that from the AWS console by passing in test values as I showed you already:

You can also pass in the parameters when invoking the function on the command line like this for local testing:

Either way the value shows up in the events passed into the function by our Bash custom Lambda runtime.

We can echo out the event data to see what’s getting passed in:

Here you can see we get some json in our event data:

To parse the event JSON I’m going to use a program called jq which I installed in the Dockerfile and wrote about in the last post.

RUN yum install jq -y

We used jq to get our secret value like this:

Our secrets are going to be in a common format but our event data could be anything really, and is very function-specific. I’m going to simply add a new bash function to the handler.js file to get the repository from the event.

It’s super simple:

Now I can call this from my function and return after just to verify I’m getting the correct repository name:

And we do. So we’re done right? No.

Take a minute to ponder the injection attacks I wrote about here:

What can I pass into that Lambda function? Well, just about anything. And depending on how that value gets used, the code I’m executing could end up parsing the value in some appropriate way and taking some unwanted action. The attack string would be passed into the github command and perhaps GitHub or that git command has a vulnerability. Or perhaps the attacker tries to terminate the command and run something different after that command executes. The possibilities are endless…for now.

Let’s fix that.

Let’s say someone entered ;

We want to reject that.

I showed you how I fixed some odd value coming out of the AWS ARN from the RIE. Perhaps it was extra spaces or quotes or who knows. I just eradicated whatever it was with his line of code:

I used sed at the end to remove all but the alpha characters and an underscore or a dash. I mentioned we might want to make that generic and that’s what we’re going to do now.

I’m going to make a file called validate.js.

I’m going to create a function to validate a string is only contains alphanumeric values

Invoke the function with the expected value.

Now run the function with our bad value:

We get a very nice message that tells us exactly what the problem is.

Does this fix our problem? Maybe, maybe not. It depends on if someone could insert a value that gets processed. Look at our function to retrieve the value.

What if the invalid value could somehow disrupt the processing performed by jq? If jq has a vulnerability then I could insert something that would cause jq to do something unexpected and unwanted.

That’s why we need to make sure:

• We are using the trusted version of jq.
• jq can be trusted — meaning it doesn’t have any vulnerabilities that could be exploited here.

Have you tested jq for security errors? Who has? Are you using it? Do you know?

This is where validation of the open source libraries we use is very important. You have to understand:

• Which libraries you use.
• If they are the correct libraries.
• If they are up to date.
• If they have been tested by a security researcher or penetration tester.
• And how much code coverage those tests achieved — were the specific code paths you are using tested?

Maybe I’ll get around to testing jq later or looking into what testing has been performed on it. For now I’m moving on.

Just two other notes while we are here.

I read up and cannot seem to find what the version in the AWS CodeCommit repo is used for just yet, so I’m going to leave that hardcoded for now as v1. If I find it needs to change later I’ll adjust it and make it dynamic.

I can get the current region in use from the environment variable AWS_DEFAULT_REGION which is set in the local environment when we apply our local credentials or by the Lambda service when running in that environment. So I have the following variables set now:

I’ll go back and move the validation code for the ARN to my validate.js file.

As you can imagine, I could create many different validation functions in my validate.js file. For example, I could validate that AWS_DEFULT_REGION was set to a proper AWS region by validating that value against a list of valid region strings. The more we validate our values, the less chance that an attack string can slip through.

And I’ll deal with the AWS CodeCommit credentials and hopefully MFA in the next post if nothing else stymies me along the way.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab