GitLab Secure Stage, 14 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab SAST Customize Rulesets Demo

Description

Backend Engineer Lucas Charles demonstrates the use of GitLab's Static Application Security Testing support for customizing pre-packaged security rulesets, using javascript and eslint security analyzer.

- GitLab SAST docs on customizing rulesets https://docs.gitlab.com/ee/user/application_security/sast/index.html#customize-rulesets
- Customizing Rulesets epic for upcoming capabilities https://gitlab.com/groups/gitlab-org/-/epics/4179

A

Hello, my name is lucas, charles. I am a back-end engineer on the static application security testing team at gitlab. So today we will be covering how to use customized rule sets for gitlab stag application security testing. Let's first start by pulling up the documentation.

A

So our sas documentation here outlines both how to set up sas as well as how to customize it for your individual project. Today we will be looking at customizing. Rule sets right here now. The first thing here will be: we will need a project, so let's go ahead and create one: let's go ahead and create from templates on gitlab.com we're going to choose a express template and we will call this customized.

A

Google sets.

A

A

Okay, so now that we have our project here, we're going to go ahead and add some code, we'll go to our routes and our users file and open this up in the web ide.

A

Now what we're going to first need is a authentication function. So let's go ahead and write one real, quick, fetch user password from db. It takes a user and we will return hunter to.

A

Let's add it to here to add an orm later now we need an additional is authenticated function that will take a user and a password and return true or false, depending on the current authentication. So we're going to fetch user password from the db using our user object and we are going to.

A

Check if that password is valid, so correct, password return. True else return false.

A

Now, let's quickly wrap our route here in this new authentication function and we're going to pass in a user id and programs password.

A

Move our response into the body: okay, now I know that we're going to also need some kind of uh email validation later. So I'm also just going to paste this regex up here that we're going to use.

A

Now, that's a good enough start, and once this authentication works, then we can go ahead and move on to some better code. Now, let's add one more file here, we'll add the gitlab ci yaml and go back to the documentation now for setting up our project, we'll hit configuration here. We see this here and we'll go ahead and copy that we can also use auto devops here, but in this case we're going to want a speedy pipeline to demo. So we'll stick with our ci configuration so just to review our changes.

A

We added a regex for later. We have a fetching function and a comparison function to make sure that the password we receive from our front end is correct.

A

Okay, let's go and create a new branch and we'll say, add basic password.

A

A

Now we have a pipeline running since we added this new ci configuration, go ahead and open that and we have both node.js scan and eslint running, because both detected javascript.

A

Now, if we give these just a second, we can go ahead and click through. If we want to see the progress of this.

A

Job okay looks like we're successful: let's go ahead and go back to our pipeline view. We see a new security tab here and it looks like eslint detected, two issues unsafe regular expression and the potential timing attack. If we go ahead and click through here, we can see these here line four, which is the regex we added and for the potential timing attack 13 through 17. Here we're doing this comparison.

A

Okay, so we can all see. This is a low severity finding here and a high one for the regular expression. So this looks like a pretty serious issue, so we should probably deal with that one. um We don't really care too much about the potential timing attack. However, so, even though the severity is low, we don't want to even see this one show up. So if we go back to our sas configuration here, we can see about customizing. Rule sets now there's a couple ways. We could go about this within our view.

A

We could go ahead and dismiss this finding and never see it again. But in this case we don't really put a lot of stock in this rule. Tiny attacks aren't really a big issue. It's an internal application so because of that, we're just going to disable this entire rule altogether.

A

The way that we go about that is first by going here and opening our web ide we're going to change to the branch that we'll be affecting here.

A

And let's go back to the docs and see what they say so rule set customization supports two capabilities: disabling predefined rules and modifying the behavior. This is the one that we're going to be dealing with today so to create a custom rule set. We need to create a gitlab directory and then create a sas real estate tamil file within that directory and then paste in something akin to the following and tomml format.

A

So let's go ahead and create this directory and this file, I'm going to say new directory gitlab and then within this I'm going to create a new file called sast. We will set toml.

A

Okay, let's go back and let's go ahead and just copy this example and work from there.

A

So it looks like in this example we're customizing two different analyzers, but in this case we only really care about eslint. So let's go ahead and drop that reading. Through this we see for the eslint analyzer for this specific rule set. We need to disable it and to disable. We need to know how to identify it. So we need to look at this identifier here.

A

The type is esl rule id and the value here is secret, uh detect object injection, so let's go ahead and go back here and we see our rule id for this. One is detect possible timing attacks. Let's go ahead and copy that paste. That in here.

A

And then I'm going to commit it and we'll say disable timing attack reporting from eslint sast.

A

Okay, now, let's go ahead and click the pipeline view here, and we can already see that this is firing off, go ahead and click on that.

A

A

And wait for this to run and it finished okay, let's go ahead and go back to the pipeline. Then.

A

And our security tab and we now see only the regular expression vulnerability. We are no longer seeing our possible timing attack.

A

Vulnerability now we could also modify this one as well. um In the future, there will actually be a capability we're working on in order to customize the vulnerabilities. So if we look at our gitlab custom rule sets epic.

A

We can actually see some additional work that we're working on in the future in the next one to three releases will be overriding properties.

A

In this case, we will allow setting the severity directly on the rule set in the case of something like predictable random. It would be overriding the default rule severity with the severity of low. With that capability upcoming. We will be able to modify this, and if we consider this vulnerability here to be a critical or even low, uh either raising or hiring that severity, then we can actually set that within our tamil file as well, and that's how to customize rule sets using gitlab zest.

A

Now, an additional thing that we can customize is any other identifier really. So if we look at this one here unsafe, regular expression, we see that this has two identifiers both detect unsafe regex and cwe 400..

A

Now cwe 400 could be used across a variety of different analyzers. So if there's a specific cwe that we don't really care about, we could customize that as well.

A

Now, if we go back to our ide, we can do this with a similar rule here. So we're going to copy this one and instead of disabling possible tiny attacks, we're going to use cwe 400 like that, let's go ahead and commit this change.

A

Also disable cw 400.

A

And in just a second, we should see our new pipeline fire off right here.

A

And by disabling both of these rules, we should no longer see any vulnerabilities being reported from.

A

Eslint now it looks like we had a fail here, um looks like there is an invalid syntax in our tommel configuration. So we see the following error: duplicate tables: let's go ahead and look back again what we did here now with tomml. It looks like we are trying to override this table with itself here and redefine it, um just to double check that we can go to tomo lintz configuration checker, let's go ahead and throw this in here and validate.

A

It looks like that's our problem here, so let's go ahead and remove that line and that's valid. Let's go ahead and throw this back in.

A

Fix tunnel syntax.

A

A

Cwd type value.

A

A

Okay and let's go ahead and go back to our pipeline team check our security tab and we no longer have any vulnerabilities reported from eslint, and that is how you use customize. Your rule sets with gitlab zest.