4 hours 39 minutes
here in lesson 5.6 isn't gonna be another fun demo it take a look at the contrast Community edition. I asked Tool,
Do you then demonstrated here that I've I loaded it into our job vulnerable app running in our Tomcat server.
And when I had scanned it with it with Iraqi and some zap that other tools I just want to kind of explain the I asked architecture while we're while we're running the demo.
So here's the the link. If you want to take a look at its contract security in their community addition. So it's a free one out there. We can run it against one server again. There's a limited number out there. And so I thought this was the best one just to kind of be able to run it. You can see how how it functions.
Thinking, run a quick demo of the contrast tool, the community addition that I have loaded
just to kind of give you example what it looks like and see what exactly the features are in here.
So I've already I loaded the I asked tool There, there, there, agent into our Tomcat server where the we put the Java vulnerable lab that free, vulnerable tool
and have it running in there and then hooked it up to the portal here. And then I ran some tools of the rain zap in Iraq, me and a couple, and then this is so this is what you're presented with. So I log in and see here. It's saying that my job vulnerable, vulnerable lab is my application.
I have an F score right now because there were so many vulnerabilities and it's kind of what we expect.
and it gives you again some some information about it. We'll talk about these later. I have the protect on and the assess here that protect is actually the rasp tool, which we have mentioned before. We'll talk about later module, but it's one little actually, actively block attacks I had just turned on later,
right now, but I had it turned off during the when I was doing the scanning.
They could take a look here first kind of look at some of the vulnerabilities.
So here it has 15 that it that it identified. There's a high one for a cross site scripting that can actually take a look at this. There's a lot more things you could do. You could label it. You could send it off. You can delete it if you don't want that vulnerability. But who wanna drill down a little bit into it? So that actually show it says
so that it will give you
from the application. Here's where I saw. I see it is ah, search dot jsp has this cross site scripting vulnerability
give you some additional information was detected, last detected to see what's attached. Lee uh, still there or whether it's an old one and they'll actually So you here. So he saw
the issue. Was is the key words he started. You see, this was the SAP tool because it puts its information in there and I give you some. Here's what we tracked the keyword parameter, which was access for the following code on the line. 21 to it actually give you in the jsp sits again. It's running similar to a SAS tool to a connection since the
the applications running or it's running within the application, it could actually see the source code
versus a dash tool, which would only be able to say I saw this results. We couldn't track it. So you can actually track it around to the JSP, which normally wouldn't be able to see from an external perspective
you give you a little bit further details here It says, I see http parameter and this is what happened. So they felt that distrusted are untrusted data. What's was sent back.
You can see this is a
cross site scripting because the data here it solves the words app come in here and then later on it printed Zap back out. So this is obviously a cross site scripting flaw because there was no filtering on it
again. You can see the full HDB info
on, then gives you some information how to fix it.
And then you can add discussions here. If you have multiple users or multiple people looking at that, you can identify or to talk about something together.
There's a there's another one here, just kind of look at it quick. There's a path reversal flaw.
This is one where it's all that this download dot GSP was requesting ah doc file here. Eso it. But it doesn't appear to be doing any filtering, which would allow.
Does somebody malicious to do like a dot dot Attackers have been like that on it
on then Here's gives you a little bit example of the code
and specifically where it was, where it founded and why this is an issue
again. There's a full if you're interested in a full session or request that it's all
and then they give you some information on how to actually fix it. So it is very useful,
especially for the developers
to go back here on the next feature is similar to the S ea that we that we looked at with the, um
the wasp dependency check.
The, uh, the contrast tool can do that as well, so you can see here. It says I. Since it's already loaded, it's running in the application server. It can see what libraries are loaded. So it says, I see you have a Commons collection job jar file. I could see the version you're running here is the latest one that's out there. And then
it pulled down from the N. V D database. All these TV ease that are related to that and then checked by the version and so we could see
this one has a vulnerable has actually three vulnerabilities.
It sees this. This other library has one. And then the my sequel connector that's being used to connect a data base. S u has six vulnerabilities as well.
So this is Ah, Well, take a look just real quick at this, So if you drill down on this commons collection dot jar, then it'll actually pull it out for you. So you can read the Athi. C E V e's here. Just want for 2017 2015.
Um, you get the CVS s score as well. You could take a look at these to see how bad this is on how much effort you need to put into fixing this.
Uh, you drill down to these other ones, but then what was interesting? So you can see all the other libraries that are loaded in here as well,
so you can see which one. So you know which ones are are part of the application and which ones it scanned.
They just want ah ah, pop up a screen here in a minute to compare the dash scanning That was done. I'm sorry. The death the S E a scanning that was done with the O wasp dependency check tool versus the job. Vulnerable lab. I saw a couple different or issues here
where I saw, um, we'll bring it up, but it looks like
the the Dom this Dom library was noted was flagged by the OAS tool, but not flag here as having a vulnerability.
And then the contrast tool had somewhere it found,
uh, one of the libraries that had more vulnerabilities, that then associate here. So this is a good idea or talking about how we want our own multiple tools that have some overlap and discover because they may not be perfect or may 1 might be actually be a false positive. We're not really sure. So you want to kind of bridge that gap?
I have a question. Why run? Dad asked and I asked tools both within your environment
to the I s can confirm results that you were running with it with a dynamic scan or so
you run it and you could see vulnerability and you get and you run and I asked Tool that you can see that you didn't really get a good idea of what? Uh what what? The tools both tool saw whether they are actual vulnerabilities
and so that the issue with the dash to if you're only running that
you may not, you may get a false negative or really, you wouldn't get any results. You wouldn't know that there was a vulnerability within the application.
It may have been expecting some specific result to come back.
Whether was crosscheck scripting Whatever it was, it may have
seen it, and it formatted the text in a way that got through and would have been reflected back. But somehow it something was messed up with encoding or something like that. So I didn't get back what it was expecting. And it may say, like, I didn't see anything so that this is not a vulnerability versus the I s tool sought Come in.
So I go out and it would say this is a cross site scripting
again. So you would have got a false negative or may not have seen anything at all
since I mentioned here is ah, done a script split screen that
just to kind of show the differences. So I mentioned in the when we're looking in the eye as tool the vulnerabilities that were found in the Web library. I'm sorry the third party libraries have done here is at the top. I have the I as tool, the gooey and then
over laid on top of the bottom. Here is from our zap tool that we ran in the Jenkins pipeline. Just we can kind of compare the two.
So looking at the highest tool found three CV ease in the Commons collection and looks like the dependency check found them as well. If I saw three here,
the interesting part that I found here is that in the Dom library,
these at the dependency check tool found one and it really it says it's a high. It's just related to see ve 2018 vs in the eyes tool. It did not flag that. So that is one interesting delta between the two. And I didn't want to drill down that into to see what the issue is, whether it's a false positive or just
a tool are one that couldn't be found.
And then the let's see the Standard Tags library found. One contract found one as well, so that one's good The other discrepancy here between the two is the in the eyes tool, the for the associated. My sequel database connection. It found it found six associated si ves
versus the dependency Check tool found. Five.
So that's another one kind of
identify. What's the difference areas? Is it? Ah, just an error that the one tool couldn't find it Or is it a false positive? So, again, this is This is the value and running two different tools and finding that overlap. Those Delta's to really drill find every vulnerability that's out there.
We looked at the demo. The tool hope we found enjoyable, I think is really interesting to see the code running within the application like that and being able to identify almost like a bridge or a combination of a sass and the deaths tool.
Next, we'll take a look at the def sec ops maturity model from a WASP specific to the delivery censuses. The phase we're working in right now.