4 hours 39 minutes
All right, listen. 2.3 security in the stack
and we're gonna be taken. Look at each one of the components that make up a Web application all the way down to the application Web server and everything in between just to kind of understand what we're trying to protect.
So the addictive is we want to list the components of the Web app, stack, identify vulnerabilities in each of the components and distinguish some of the attack vectors on those components.
So for just starting off kind of low level, where the data is the
and the reason we're listing all days is just kind of make you think about. Here's all the parts we have to think about. Here is everything we need to protect. So,
for example, the database there's there could be my sequel sequel server, post grass. Then you have sequel. Lied on the mobile side. You have peel SQL on Oracle, the stored procedures, all these type of our pieces need to protect it.
Then, on top of that, you have the web application server. So when you're running Apache Tomcat,
I asked node
all these You you need some knowledge to understand each how the security impacts for each one of these Web application servers.
And then, maybe on top of that, you might be running ah, content management system like word path, WordPress drew people Djamila al fresco any thes,
they all require constant updates, specific Kerry, their running, different types of languages where there's PHP, Java and they all have their own configuration settings that that need to be done correctly,
and then even the communication between your APP and the
the client there. There's a lot of different verbs that there's get post cross origin. There's cross site request forgery, whether depending on the type of data, whether it's Jason XML
with your doing out of band Web sockets, that there's a lot of ideas you have to understand and have to protect because the bad guys understand all these.
And so you needed to match those skills.
And, of course, there's a cloud. Now there's Cloud Trail Cloudwatch Lambda. There's the metadata to take care of, and you have docker kubernetes there. There's so many pieces
and of course you have to own the you I side. You have to
trust, uh, anything that that's being sent by the claim
so you can drill down a little bit here. So in the databases, there's obviously is there's different types of different versions.
This the types of sequel injection are dependent on the database and can actually be dependent on the operating system as well.
And I mentioned before store procedures have their own security,
uh, issues that you have to deal with.
Whether you have a relational database where they have no sequel,
there's a again that there's a completely different databases to protect, and we've all seen the stories about the no sequel databases out there on the Internet. That air just plugged in and running with no authentication. And of course, there's
they're secure configurations that that that are available out there with their steak or C. I s for protecting the way they're set up in the rights on them.
So the Web application server, same thing vendor and version have different exploits
again, depending on the operating system and the programming language that they're they're sequel dependencies on them.
And and again there's there's there's good security secure configuration guides out there for the settings. What modules that add on their, which was she should be turning off. So if you just set a default Apache
Web server out there, it's gonna have a lot of modules on that you really don't need
content management systems probably seen all these exploits out there as well. Again, there's they're dependent on the version. Sometimes the operating system again. There's plenty of best practices out there for
thus the settings access rights, how to securely configure it
and which modules to use. Which themes? Keeping them up to date. Because that's what a lot of the exploits have been. Have focused. Honest is these modules Because a lot of times people just say I need this functionality. Let me find a module. Cool. Let me deploy. All right. I never have to look at it again, Which is, of course not. Correct.
so here's a question for you.
Why do we need to understand all the components of the weapons? It's back.
Hopefully you're paid attention. You should understand that the reason we're looking at this is so we understand the complexity, and by understanding that we can, we can then look at when we're setting up our def sec up pipeline and we're sitting up our controls, the tools we need. We need to understand what their threats are, what did what
risk are specific to these components of the of the stack,
and so that when we go to select tools, we know that they're covering what we think are the risks or the threats to our organization, and you don't have to cover it all with one tool of one process. You can have some overlap until he's good to have a little bit overlap so that you can make sure because not all tools or processes air perfect. So it's always good to have a little bit of overlap.
Step back in this I mentioned before. There's Web protocols when you'd understand, get post the lead,
depending which one you use. It has some you can have some impact on and seen this before, where the person developing the application on Lee thought about, say, I get her post or didn't even think about that and didn't implement any of these other verbs. And when it gets an unknown verb,
you have no idea, really what, it? What's going to happen?
Um, there's other ones I've seen where the developers
wanna pull in thes third party libraries from other way from from other sources than the application sitting on there. And then this cross origin
gets in the way. So they relax it just so it works. And then you cause vulnerabilities that way when people can start injecting Java script or other
code into the application.
And there's other issues D. C realization of, like XML and Jason that
that that are big issues as well.
And then you have to understand there's Web socket with which runs out of band
of of the regular requests. And I've seen vulnerabilities with this as well, with specific way back with the spring framework had an issue with Web sockets there. It was a vulnerability, but only if you had Web sockets, he unencrypted. I was testing application, exact what they had and it with a critical vulnerability.
Of course, everybody knows about cloud security. Thes s three buckets left out there,
uh, with no encryption on them, hoping nobody finds them at the lot of the controls or the um in between the VP seas are set up to by default, denying it it's hard to get it working. So I've seen this before to just say, Let me do any any,
get it working and then they forget they leave it out there like that,
and we've seen recently these these servers tried request forgery where you trick thesis Web server into believing that you that's a call from the inside and getting extracting, meditate or other sense of data that shouldn't be descend out there
and course of these
vulnerabilities will not be what will not become apparent until it's actually out production. So you do a lot of these testing, and they may have set up the production environment you heard mention a couple of times. Is this environment drift?
So one of the ways that fixes his infrastructures or code where uses have this repeatable process, but it takes a lot of expertise to do that well as where as well
and again dependent. You might have an expert in AWS, but they might not be an expert in azure so understanding. Getting getting the right expertise is difficult until you know you have toe test for these type of specific vulnerabilities as well.
Again, there is the you I component, so html has injections. Dom attacks
across like scripting with Java script. There's a team L five and cascading style sheets now,
um, malicious ads, which which may not become apparent again again, especially in the developed environment in the production. So these are all kind of different areas we need to think about as well.
And again there's. We focus on the really technical side. But there's a and there's these miscellaneous wanted. We forget about just two standard configuration errors of the software auditing. Is it not done correctly?
The exposure of sensitive information like passwords, keys anytime in the documentation. Sometimes he gets published.
The last one's a little difficult to automate, but some checks you should be going out there, uh, times developers run into an issue, and then they go out and post on stack flow or some other place and say, Hey, I need help and they may post, you know, sensitive information out there that
that could be then used to attack your application.
That's another quiz here.
Seiko injection exploits can depend on the database type or programming languages is true or false.
This is true eso there's the issue with called Stacked Query. Exploit where you can if you can get a semi cooling in there, you can then terminate the the Sequin Gestion and add your own Arab at many on after, which is one of the worst sequel exploits. So I got this table from Nets. Barker blogged that that showing
the cross reference of the database is across the top in the programming languages and everywhere it says yes is. If you have that specific database and that programming language you can, you are susceptible to stack. Query explodes.
So in this model, we just talked about Security House needed for each one of the layers and understanding why we need that.
And in the next module, we're gonna take a look at the Jenkins pipeline orchestration
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