Welcome back the lesson 2.2 or and talk about static and dynamic analysis. Take a look at both of them.
It's in this video. The objectives are just different. Shapes that stack a dynamic analysis critique need for one for a static and also for dynamic analysis analysis. And then take a look at third party libraries dependencies because some of the barriers it takes to a system
aesthetic analysis you mentioned before sometimes called white box testing It's called that because you're looking at the source code, there's no secret the hide. You can look directly at the code, and there's no need to, you know, think that something's something's in between you, like a Web application, firewall or anything
has performed UN compiled code. It's also
it could be unknown compel code like Java script python. The are coat languages like that. It can work on it on those as well. Take a look at them.
Sometimes there's some tools that require that it to be compiled, like the spot bugs take job and has to be compiled. But
for this, for this definitions, just it's that before it's built into the applications, the UN compiled code or the I said that Java script or things like that that don't have to be compiled.
So this way most vulnerabilities have found this way again because there's nothing in between. There's no layers of security. There's no controls in place. You're just looking at the raw code and using the tools. Have that or the even a human can. Look at this the patterns of the B A or the way it's set up and see vulnerabilities,
but it's very labor intensive. So I really need tools to automate this process just because the number of languages like I mentioned before and just the size of the code. So if you have millions of lines of code, you just can't go through it individually by my person.
So they dynamic analysis, sometimes called black box testing.
It's the evaluation of the deck, the source code after it's built into the bike code. Or however it's deployed in the application and it's tested through the interface.
So and it's running within environment that's called black box testing A
because you can't see the same way you did within the source code, your only
you're testing for certain known types of, say, like sequel injection across that script, anything that that you're looking for known attacks or trying them to see if you're getting back the response that that did you expect that would be known for a
a vulnerability that way? Sometimes if there's a desire, Uncle Grape gray box testing where you would do static analysis, take the results and then do the dynamic analysis and then compare the results. And to see that I saw this ecstatic analysis. I believe this ***. This is probably a probably an issue.
And when I test it within with dynamic analysis, I can actually see that, Yes,
I was able to complete that more that, uh,
hack against it. I could see that that what I expected happened actually happened. So if I'm doing sequel injection, I sent something. Whether you have whatever result I was expecting, I got it back and say, Yep, I confirmed this is a vulnerability.
So I like to do these every once a while just to kind of stop, make you think about it, said just listening to me talk about it.
So you think sass and *** the static and dynamic analysis are both needed. Or can we just pick one
yet? So we need both of them Static analysis dynamic again, You mentioned you may not. You confined most vulnerabilities of static analysis,
you might be able to find mawr with that dynamic analysis. And the reason is that once the code is deployed into the app there maybe third party libraries, any other components that are built into the application server that may then, uh, exhibit some of these vulnerabilities that you didn't see just in the code. And again, the
35 libraries You easy aren't available
with the when you're doing the static analysis. And so these some of these vulnerabilities may show up.
They have mentioned a couple of times, what exactly are third party libraries? The analysis is called Software Counts Competition Analysis. So you'll see it's S e a around it's dependent libraries or not discovered in static analysis. Like I mentioned, because you're just looking at the source code,
you can sometimes that that's part of analysis. But generally they may not be
with the code, and they may just be available on the application. Or they may be combined at a later date with another portion that you may not see just by doing the source code review.
So something the something these vulnerability appear when chained together. So they said it might be some cross site scripting and some other cross site request forgery, some some vulnerability that needs both of these components together into present a higher level risk.
And sometimes you might see a difference between theme development version, and the production version looks to get into a little bit later. When we do a verification scan once, it's because we test in development. And then, once the vulnerabilities of fixed go to production is, do you have ah,
adrift between these two different Vier mints? If you do, you may not see vulnerability until later on.
Or there's other things, like Java script, where
you'll see it on a Web page where it's not loaded from the Web server of the application server. It may be a reference from an external site, and you may not see that in the static analysis.
Dynamic analysis is performed on the running application is true or false.
True dynamic analysis, Attempt toe, identify exploit to the application is running state. I'm sure you're paying attention. So this was a easy quiz
Did we learn about static dynamic analysis in this module? And in the next one, we're gonna break it down a little bit further and start looking at security in the layers of stack.