4 hours 39 minutes
here in less than 5.5, we're gonna talk about the interactive app security testing, which is another interesting concept. It's actually embedding the tool within your application server and monitoring the tests and the vulnerabilities from the inside, which is
similar to, ah, the SAS Tool work because you can actually see. Or the SAS tool can actually see the code
expanded so I can see the source code of the method calls and some of the library's.
So the lesson objectives. Just gonna talk about the I asked functionality and and differentiate the I asked assassin and deaths and kind of understand the lanes each one of them run in and the overlap,
and then list some of that. The data sources that the I asked tool uses, and it will take a look at the contrast community. I asked, which is a free tool limited, but it gives you a good sense if you want to play around with and and see what what's available. There's
is a very intense tool when it takes, it's a lot of capabilities, so there aren't really very many free tools out there to look at
what is Ah, I asked Tool. It identifies vulnerabilities inside the application. It's it's not a scanner, so it's just uses instrumentation and it gathers this data and then it sends it to an analysis engine. And then the analysis engine has a rules engine, which identifies the possible vulnerability. So
when we said when you start showing that the contrast tool, you'll see that the tool actually gets embedded we into the apple into your APP server. And then the data is sent to their cloud based you I
and then you can you can see all the information there. So all that analysis has pulled. Performed outside is not actually done in the tool within your the APP server,
and it uses multiple data points, something like the request data coming in any of these tokens that cookies. And then, since it's running within the application server, it can see changes. It's state.
So I could see I see this, you know, that this request came in, sent to the sequel server and then something happened, and I see something coming back out. So there may have been a sequel injection that occurred or
I see a request for a file and Then there was a dot, dot, dot, dot dot In there I could see they're trying to do a path reversal.
And also, since it's running in there, you could see what libraries air loaded so it has a good capability to do some S E a scanning of your third party libraries.
It's a question for you. Do you understand why the the app with the eyes tool still needs to be scanned
by vulnerability skin? Or are dass tool
the easiest tools I mentioned? We just got a refresh here. It only provides notifications or telemetry data specifically about what's going on the application. It doesn't do any scanning. It just sits there and watches.
So what you need to do is you have it running, and then you run your dass tool or whatever vulnerability tests manual against it. And then it uses that telemetry data. Send it off. And then there's the analysis engine. It says, Hey, I see these patterns occurring
so that I mentioned couple times what this I asked telemetry data. So it it says it could look at the source code or the bike code. It can see exactly some of the way the data is flowing.
So it'll look at http traffic coming in. It'll look at the third party libraries that are loaded, the frameworks it look at the application again, some of the data control flow and then the connections back to databases or even to the file system and see what's what what's occurring.
It can look at some of the configuration as well and say, Okay, I see this data. Let me run it through my rules engine. Here's some patterns that that our trouble. So my better notify the the administrator What's going on here?
Here's a screenshot of the contract community version. They call it their assess Comm portion portion. If you're getting the commercial version,
um, it actually has. So it has the eyes tool. It has the rasp, which is what? We'll talk a little bit later, which is so this is just in a monitoring phase. It's saying, Hey, I see this. I see that this is the vulnerability, but what you would want in a production system or if this was using, is to see it and actually block those attacks. So it has that ability.
if you're running it in your development side. You probably don't want to block it because you want to be able to find these vulnerabilities. If it was blocking them you, would you? The dash tool would say
a and I didn't find a vulnerability here. I wouldn't find a vulnerability because it was actually blocked. It wouldn't be able to assess that. Whether it occurred or not
again, like you can. You can validate your desk findings than your s e a findings that you performed in a static analysis phase because you can. It's running, squeaking. It can see the same vulnerabilities and you so you can have ah, good overlap of your tools and some verification and maybe find each one finds something different.
You can go in and look and see. Is this a false positive? Because one found it. Another one didn't find it
versus I have a good verification of two separate tools ran and they both found it
over the next, uh, start for this for this lesson returned that we looked at the eyes tool functionality and the next one I'll demo it. Just show us I've actually loaded it into the APP,
ran a scan against it, and we get we'll take a look through the portal and see what what we see
Fundamentals of Cybersecurity Architecture
This cyber security architecture class aims to give an appreciation of the various aspects of ...
3 CEU/CPE Hours Available
Certificate of Completion Offered