WEBVTT

0:00:04.080000 --> 0:00:08.640000
 So, now that we have an understanding of
 modern web application architecture,

0:00:08.640000 --> 0:00:12.840000
 what it means, you know why it's important,
 let's take a look at the web

0:00:12.840000 --> 0:00:16.420000
 application architecture model, some
 of which are modern, you know, very

0:00:16.420000 --> 0:00:21.480000
 new or recent just based on the evolution
 of technology and some of them

0:00:21.480000 --> 0:00:22.620000
 are the classic ones.

0:00:22.620000 --> 0:00:23.980000
 So let's get started.

0:00:23.980000 --> 0:00:28.900000
 I've sort of summarized, you know,
 pretty much all of them, I wouldn't

0:00:28.900000 --> 0:00:35.140000
 say all, but some of the more popular
 ones and the most popular at the

0:00:35.140000 --> 0:00:38.180000
 moment or the most prevalent
 are highlighted in red.

0:00:38.180000 --> 0:00:43.620000
 So firstly, we have the led model,
 which is actually the best model to

0:00:43.620000 --> 0:00:49.420000
 use. If, you know, if this is your
 first time, you know, getting into

0:00:49.420000 --> 0:00:54.220000
 web application architecture, led will
 make the most sense based on, let's

0:00:54.220000 --> 0:01:01.660000
 say, your perceived understanding of how
 all of the components come together.

0:01:01.660000 --> 0:01:06.420000
 But let me just summarize this and
 then we can actually take a look at

0:01:06.420000 --> 0:01:07.440000
 what it looks like.

0:01:07.440000 --> 0:01:13.080000
 So the led model organizes components
 into distinct layers.

0:01:13.080000 --> 0:01:21.020000
 These layers have different names, but
 formally, these layers are called,

0:01:21.020000 --> 0:01:24.020000
 you know, the presentation
 layer business logic data.

0:01:24.020000 --> 0:01:28.220000
 Presentation is what you would consider
 client side or the stuff you see

0:01:28.220000 --> 0:01:29.380000
 in your browser.

0:01:29.380000 --> 0:01:33.300000
 Keep that in mind because this may give
 you an idea as to the vulnerabilities

0:01:33.300000 --> 0:01:35.600000
 that affect each of the layers.

0:01:35.600000 --> 0:01:39.980000
 And then you have the business logic
 layer, which is typically your web

0:01:39.980000 --> 0:01:41.880000
 server and application server.

0:01:41.880000 --> 0:01:44.680000
 And then data layer is
 your databases, right?

0:01:44.680000 --> 0:01:49.320000
 This the best use case for the led
 model is the traditional monolithic

0:01:49.320000 --> 0:01:53.140000
 applications. And then of course,
 you have microservices, right?

0:01:53.140000 --> 0:01:58.180000
 So that, you know, what is
 this particular model?

0:01:58.180000 --> 0:02:02.260000
 This is, you know, small independent services
 that handle specific business

0:02:02.260000 --> 0:02:11.040000
 functionalities or, you know, communicating
 with APIs, et cetera.

0:02:11.040000 --> 0:02:15.160000
 It's highlighted in red inferring
 that it's quite popular.

0:02:15.160000 --> 0:02:21.200000
 And then of course, you have SOA, which
 is reusable centralized so service

0:02:21.200000 --> 0:02:26.860000
 on. And then so reusable centralized
 services managed in an enterprise

0:02:26.860000 --> 0:02:32.660000
 service bus. ESB, I'll
 sort of explain this.

0:02:32.660000 --> 0:02:34.840000
 This is really for enterprise
 level integrations.

0:02:34.840000 --> 0:02:36.260000
 And then you have event driven.

0:02:36.260000 --> 0:02:42.520000
 So the in this model processes, you
 know, triggered by users, actions

0:02:42.520000 --> 0:02:46.340000
 or system events, often
 asynchronous sleep.

0:02:46.340000 --> 0:02:51.280000
 So just think of real time systems like
 e-commerce or IoT and then serverless,

0:02:51.280000 --> 0:02:55.240000
 which is becoming more popular now,
 you know, event triggered functions

0:02:55.240000 --> 0:02:56.940000
 managed by a cloud provider.

0:02:56.940000 --> 0:03:02.660000
 So just think of, you know, lightweight
 event driven workloads and then

0:03:02.660000 --> 0:03:07.620000
 monolithic, which is again, applies
 to you hosting your website.

0:03:07.620000 --> 0:03:12.160000
 So all application components bundled
 in, into a single unit.

0:03:12.160000 --> 0:03:15.960000
 So just think of a server hosting WordPress
 where you have the web server

0:03:15.960000 --> 0:03:19.620000
 on the same server, the database
 MySQL on the same server.

0:03:19.620000 --> 0:03:23.080000
 And then of course, the application server,
 which would typically be called

0:03:23.080000 --> 0:03:26.200000
 the back end, would be, you
 know, WordPress is back end.

0:03:26.200000 --> 0:03:30.900000
 So think of small applications
 or early, early stage startups.

0:03:30.900000 --> 0:03:32.740000
 And then you have distributed.

0:03:32.740000 --> 0:03:35.960000
 In this case, the application is spread
 across multiple interconnected

0:03:35.960000 --> 0:03:37.880000
 systems or nodes.

0:03:37.880000 --> 0:03:41.940000
 This is the best use case here is,
 you know, highly scalable and fault

0:03:41.940000 --> 0:03:43.160000
 tolerant system.

0:03:43.160000 --> 0:03:45.320000
 So that's sort of an overview
 of the models.

0:03:45.320000 --> 0:03:49.000000
 Now, as I said, I'll be utilizing the
 layered architecture because in

0:03:49.000000 --> 0:03:55.260000
 most cases, it's the, you can sort of
 juxtapose the layered architecture

0:03:55.260000 --> 0:04:01.120000
 onto most modern web applications from
 the perspective of the organization

0:04:01.120000 --> 0:04:06.340000
 of everything. So this architecture
 model organizes the application into

0:04:06.340000 --> 0:04:07.480000
 distinct layers.

0:04:07.480000 --> 0:04:10.760000
 And each layer is responsible
 for specific tasks.

0:04:10.760000 --> 0:04:14.120000
 So, you know, common layers include
 the presentation layer, which as I

0:04:14.120000 --> 0:04:16.520000
 mentioned is, you know, the client side.

0:04:16.520000 --> 0:04:20.280000
 So this layer is responsible
 or handles use interaction.

0:04:20.280000 --> 0:04:22.880000
 So think of browsers, mobile apps.

0:04:22.880000 --> 0:04:25.920000
 You then have the business logic layer,
 which is typically the application

0:04:25.920000 --> 0:04:29.780000
 server. So this process is requests,
 applies logic and interacts with

0:04:29.780000 --> 0:04:34.200000
 the database. Then you have the data
 access layer or the data layer, if

0:04:34.200000 --> 0:04:37.660000
 you will. This manages data
 storage and retrieval.

0:04:37.660000 --> 0:04:39.620000
 So think of your databases.

0:04:39.620000 --> 0:04:43.720000
 And then you have another point
 that I want to mention here.

0:04:43.720000 --> 0:04:47.720000
 It's not really, really a layer here,
 but layers communicate with each

0:04:47.720000 --> 0:04:54.300000
 other. And in the layered architecture
 model in a hierarchical manner.

0:04:54.300000 --> 0:04:58.920000
 So typically to, or typically top down.

0:04:58.920000 --> 0:05:04.800000
 Now, an architecture, a web application
 architecture model does not mean

0:05:04.800000 --> 0:05:08.280000
 this is how you have to organize
 stuff in the real world.

0:05:08.280000 --> 0:05:10.920000
 It just is a way of presenting.

0:05:10.920000 --> 0:05:15.060000
 Again, just take a look at
 the word architecture.

0:05:15.060000 --> 0:05:19.700000
 An architect, you know, does not actually,
 you know, do anything physical.

0:05:19.700000 --> 0:05:25.480000
 He just, you know, designs a building,
 let's say, and provides plans and

0:05:25.480000 --> 0:05:31.320000
 specifications to the actual construction
 workers or the contractors,

0:05:31.320000 --> 0:05:38.420000
 right? And so architecture is a way
 of understanding or developing or,

0:05:38.420000 --> 0:05:43.320000
 you know, understanding the the requirements
 of the web application, you

0:05:43.320000 --> 0:05:50.960000
 know, understanding all the components
 that organizing them.

0:05:50.960000 --> 0:05:56.160000
 And you utilize an architecture model
 to, you know, that is best suited

0:05:56.160000 --> 0:06:02.300000
 to the application that you're developing
 and also based on, you know,

0:06:02.300000 --> 0:06:03.680000
 the actual requirements.

0:06:03.680000 --> 0:06:10.360000
 So the layered model or framework is,
 I typically use it because it sort

0:06:10.360000 --> 0:06:15.260000
 of explains or allows you to understand
 why we have other architecture

0:06:15.260000 --> 0:06:17.860000
 models like microservices, right?

0:06:17.860000 --> 0:06:19.660000
 Or even serverless.

0:06:19.660000 --> 0:06:23.300000
 So this is an example of
 the layered architecture.

0:06:23.300000 --> 0:06:28.620000
 So it's top down from, again, an abstracted
 point of view where you have

0:06:28.620000 --> 0:06:29.540000
 the client side.

0:06:29.540000 --> 0:06:34.100000
 So when you're browsing a website, you
 are categorized or your activity

0:06:34.100000 --> 0:06:38.620000
 there is categorized as, you know, client
 side or the presentation layer.

0:06:38.620000 --> 0:06:42.580000
 This can either be in the form of a
 web of a website that you access via

0:06:42.580000 --> 0:06:45.300000
 a browser or a mobile application.

0:06:45.300000 --> 0:06:49.220000
 The bottom line is that then communicates
 with the web server layer or

0:06:49.220000 --> 0:06:50.600000
 tier, if you will.

0:06:50.600000 --> 0:06:56.160000
 This is examples of a web server
 or stuff like nginx, Apache, etc.

0:06:56.160000 --> 0:06:59.820000
 And then you have the app server tier,
 which is typically the back end

0:06:59.820000 --> 0:07:06.720000
 of the, you know, the business layer
 or the actual web application itself.

0:07:06.720000 --> 0:07:10.140000
 So if we think of WordPress, you
 know, you have your browser here.

0:07:10.140000 --> 0:07:14.260000
 So the WordPress site, you
 know, front end, etc.

0:07:14.260000 --> 0:07:17.660000
 And then you have the web server that's
 hosting WordPress, which would

0:07:17.660000 --> 0:07:20.720000
 either be nginx or Apache.

0:07:20.720000 --> 0:07:24.780000
 And then the application server is
 the actual back end of WordPress.

0:07:24.780000 --> 0:07:30.520000
 So you can see that this organization
 is actually quite helpful because

0:07:30.520000 --> 0:07:36.540000
 it allows you to understand, you know,
 what each of these layers is the

0:07:36.540000 --> 0:07:40.680000
 responsibility of each of these layers,
 as well as the connections between

0:07:40.680000 --> 0:07:44.840000
 them. And from a security perspective,
 you know, from a defensive security

0:07:44.840000 --> 0:07:50.320000
 perspective, it can allow developers
 to understand where, you know, where

0:07:50.320000 --> 0:07:54.700000
 vulnerabilities may arise, what vulnerabilities
 affect each layer.

0:07:54.700000 --> 0:07:58.940000
 And from a pen testers perspective,
 this gives you an understanding of,

0:07:58.940000 --> 0:08:03.080000
 again, where to find vulnerabilities,
 what vulnerabilities apply to each

0:08:03.080000 --> 0:08:07.580000
 layer, etc. So layers communicate with
 each other again from a theoretical,

0:08:07.580000 --> 0:08:14.220000
 you know, from a, from a, you know, in
 a theoretical sense, they communicate

0:08:14.220000 --> 0:08:18.280000
 top down. That's, again, just the
 architecture in the real world.

0:08:18.280000 --> 0:08:21.580000
 Obviously, there's no top down structure
 of our services communicate with

0:08:21.580000 --> 0:08:23.720000
 each other, but it follows a hierarchy.

0:08:23.720000 --> 0:08:25.660000
 That's the key thing to understand.

0:08:25.660000 --> 0:08:27.840000
 So you have your app server here.

0:08:27.840000 --> 0:08:29.340000
 And again, I've used to it.

0:08:29.340000 --> 0:08:35.140000
 I've sort of added two to, to sort of account
 for, you know, complex instances,

0:08:35.140000 --> 0:08:41.680000
 but in this case, you know, one for
 the web application or sorry, this

0:08:41.680000 --> 0:08:48.520000
 particular example sort of accounts for
 instances where, you know, a company

0:08:48.520000 --> 0:08:52.520000
 may have a web application
 and a mobile application.

0:08:52.520000 --> 0:08:55.760000
 And sort of showing you that they would
 still follow the same model or

0:08:55.760000 --> 0:08:58.260000
 need to be understood from
 the same perspective.

0:08:58.260000 --> 0:09:01.320000
 So you then may have internal services.

0:09:01.320000 --> 0:09:05.500000
 So an authentication service, this
 is, you typically see in modern web

0:09:05.500000 --> 0:09:10.900000
 applications, that's handled by an API, not
 always, but a separate authentication

0:09:10.900000 --> 0:09:15.840000
 service, your email notification service,
 you know, message queue, that's

0:09:15.840000 --> 0:09:19.660000
 quite common. So think of rabbit MQ
 and then you can also have an API

0:09:19.660000 --> 0:09:23.600000
 layer. APIs need to have their own
 layer because you cannot mix up an

0:09:23.600000 --> 0:09:29.140000
 API with a, a particular service that's
 supposed to do something that

0:09:29.140000 --> 0:09:30.860000
 utilizes the API.

0:09:30.860000 --> 0:09:35.720000
 So API needs to be in its own layer,
 you know, examples here, REST API,

0:09:35.720000 --> 0:09:40.440000
 GraphQL, API, and then of course, your
 database layer, your database layer

0:09:40.440000 --> 0:09:41.820000
 or your data layer.

0:09:41.820000 --> 0:09:45.240000
 So this is where you have your databases
 like, you know, relational database

0:09:45.240000 --> 0:09:46.920000
 examples on MySQL.

0:09:46.920000 --> 0:09:51.860000
 You can also have a NoSQL database like
 MongoDB or even, and this is also

0:09:51.860000 --> 0:09:55.120000
 becoming quite common, a caching
 service like Redis.

0:09:55.120000 --> 0:09:58.200000
 So hopefully that makes sense now.

0:09:58.200000 --> 0:10:01.400000
 Now let's talk about the microservices
 architecture.

0:10:01.400000 --> 0:10:04.580000
 So in this model, or the, you know,
 pretty much when we're talking about

0:10:04.580000 --> 0:10:09.960000
 this particular architecture model, it
 divides the application into small

0:10:09.960000 --> 0:10:16.720000
 independent services, each handling a specific
 business function or capability.

0:10:16.720000 --> 0:10:19.980000
 So use authentication, payment
 processing, etc.

0:10:19.980000 --> 0:10:24.500000
 The key distinguishing factor is that
 each service is loosely coupled

0:10:24.500000 --> 0:10:29.500000
 and more importantly, independently
 deployable.

0:10:29.500000 --> 0:10:33.960000
 So, you know, communicates with
 other services through APIs.

0:10:33.960000 --> 0:10:37.920000
 This is actually the, the, the,
 the, the, um, de facto standard.

0:10:37.920000 --> 0:10:40.680000
 So think of REST, grpc, etc.

0:10:40.680000 --> 0:10:44.660000
 And often uses its own database
 or data storage mechanism.

0:10:44.660000 --> 0:10:50.280000
 This model is ideal for large scale, complex
 applications requiring flexibility,

0:10:50.280000 --> 0:10:53.520000
 scalability, and continuous deployment.

0:10:53.520000 --> 0:10:58.720000
 And it enables scalability and independent
 updates for each service and

0:10:58.720000 --> 0:11:02.320000
 promotes the use of different technologies
 for different services.

0:11:02.320000 --> 0:11:06.380000
 This is where you now have, you know,
 your polyglot pro, um, the, the

0:11:06.380000 --> 0:11:10.120000
 concept or practice of
 polyglot programming.

0:11:10.120000 --> 0:11:12.420000
 So very, very simple.

0:11:12.420000 --> 0:11:13.860000
 This is what it looks like.

0:11:13.860000 --> 0:11:15.420000
 So again, you still have layers.

0:11:15.420000 --> 0:11:19.580000
 It's not really top down from, you know,
 from the perspective of the actual

0:11:19.580000 --> 0:11:23.100000
 architecture, but I'm just using something
 standardized so you can actually

0:11:23.100000 --> 0:11:27.180000
 understand it. So you have your use
 interaction and then you have your

0:11:27.180000 --> 0:11:30.040000
 microservices, which is sort of the key.

0:11:30.040000 --> 0:11:33.880000
 One thing that doesn't change is the
 presentation layer or the client,

0:11:33.880000 --> 0:11:38.160000
 um, the client side layer, because that's
 always going to be in the, you

0:11:38.160000 --> 0:11:42.740000
 know, um, is always going to involve
 or have, uh, interaction via users

0:11:42.740000 --> 0:11:48.660000
 browser. But from what we would consider
 in, in comparison to the layered

0:11:48.660000 --> 0:11:54.360000
 architecture, the, uh, you know, the
 web server layer and the application

0:11:54.360000 --> 0:12:00.320000
 server layer, that's now replaced by
 the microservices layer, where now

0:12:00.320000 --> 0:12:05.980000
 each is, um, again, each of these services
 that I mentioned, let's think

0:12:05.980000 --> 0:12:08.480000
 of them now exclusively to this diagram.

0:12:08.480000 --> 0:12:12.680000
 You can see we have an authentication
 service, a product service and order

0:12:12.680000 --> 0:12:16.580000
 service. And based on what I described
 in the previous slide, when sort

0:12:16.580000 --> 0:12:21.220000
 of explaining when this model is typically
 used, it actually makes sense,

0:12:21.220000 --> 0:12:27.960000
 uh, to not, um, closely couple or group,
 uh, you know, important services

0:12:27.960000 --> 0:12:33.260000
 like authentication, like an authentication
 service and let it run independently

0:12:33.260000 --> 0:12:38.880000
 so that, um, again, in the event that
 happens, you're able to identify

0:12:38.880000 --> 0:12:42.780000
 what exactly the issue is, but you're,
 you're, you're also able to spin

0:12:42.780000 --> 0:12:47.860000
 up another instance really quickly because,
 again, they can operate independently.

0:12:47.860000 --> 0:12:53.380000
 Um, and what microservices is is just
 think of a web application that

0:12:53.380000 --> 0:12:59.960000
 primarily utilizes, uh, containers or,
 uh, you know, just think of Docker

0:12:59.960000 --> 0:13:03.260000
 containers or containers in general.

0:13:03.260000 --> 0:13:08.000000
 And with that, you get a much more robust
 control over, you know, things

0:13:08.000000 --> 0:13:12.020000
 like resource allocation,
 scalability, et cetera.

0:13:12.020000 --> 0:13:16.760000
 Uh, the data, the data layer will always
 remain regardless of what exactly

0:13:16.760000 --> 0:13:22.860000
 is, regardless of the
 technology being used.

0:13:22.860000 --> 0:13:25.940000
 So whether it's a relational database,
 that's not important.

0:13:25.940000 --> 0:13:31.320000
 They're sorted based on, uh, they're, they're
 sorted from a logical organizational

0:13:31.320000 --> 0:13:36.300000
 perspective. So you store in, you know,
 instead of diving deep into the

0:13:36.300000 --> 0:13:41.140000
 actual technologies here, uh, you may
 have all relational databases or,

0:13:41.140000 --> 0:13:43.300000
 you know, let's say no SQL databases.

0:13:43.300000 --> 0:13:48.180000
 The bottom line is that you have multiple
 databases or data stores that

0:13:48.180000 --> 0:13:50.180000
 are storing different types of data.

0:13:50.180000 --> 0:13:55.980000
 So a user database to store user, uh,
 user credentials or user information,

0:13:55.980000 --> 0:13:58.740000
 a product database to store
 product information.

0:13:58.740000 --> 0:14:03.600000
 So you're, you're, you're trying to separate
 these key datasets from each

0:14:03.600000 --> 0:14:06.900000
 other instead of, you know, just putting,
 just putting everything into

0:14:06.900000 --> 0:14:13.200000
 one database. Now the, the issue that
 arises with microservices is, um,

0:14:13.200000 --> 0:14:17.420000
 and, and will not dive into it here,
 but because you have all of these

0:14:17.420000 --> 0:14:22.200000
 independent, you know, services or indeed
 micro services, they all need

0:14:22.200000 --> 0:14:24.600000
 to communicate with each other.

0:14:24.600000 --> 0:14:28.720000
 Uh, or they, they all need the communication
 between all of these microservices

0:14:28.720000 --> 0:14:31.660000
 needs to be well thought out.

0:14:31.660000 --> 0:14:38.140000
 Um, and, uh, you know, because of that,
 if not done correctly, uh, you,

0:14:38.140000 --> 0:14:41.760000
 you know, you'll typically see issues
 where, you know, a certain aspect

0:14:41.760000 --> 0:14:46.440000
 of the web application or certain functionalities
 working, but you know,

0:14:46.440000 --> 0:14:50.100000
 another, another part of functionality,
 another aspect of the web app

0:14:50.100000 --> 0:14:55.340000
 is not working. So the login functionality
 might be working, but, uh,

0:14:55.340000 --> 0:14:59.720000
 you know, let's say specific service,
 like, um, a specific dashboard or

0:14:59.720000 --> 0:15:03.100000
 a specific feature within the
 web app is not working.

0:15:03.100000 --> 0:15:06.960000
 Uh, that this is very important because
 when you start to see that during

0:15:06.960000 --> 0:15:12.200000
 your testing, you're most likely dealing
 with, you know, um, a web application

0:15:12.200000 --> 0:15:17.280000
 that is utilizing the microservices,
 uh, architecture model, not always

0:15:17.280000 --> 0:15:20.580000
 the case. I'm generalizing, but I'm sort
 of trying to give you an insight

0:15:20.580000 --> 0:15:23.460000
 into why this is important for you.

0:15:23.460000 --> 0:15:28.780000
 So let's take a look at an example of
 a modern web application architecture,

0:15:28.780000 --> 0:15:33.200000
 using an ex, you know, and something
 that's actually tacit.

0:15:33.200000 --> 0:15:41.160000
 So here's a, a detail, and we're looking
 at a very common website that

0:15:41.160000 --> 0:15:43.740000
 uses a layered architecture model.

0:15:43.740000 --> 0:15:46.160000
 So the architecture comprises
 of the following.

0:15:46.160000 --> 0:15:49.580000
 So your presentation layer, this layer
 includes the user's browser or

0:15:49.580000 --> 0:15:53.800000
 front end interface, which handles the
 application's visual elements and

0:15:53.800000 --> 0:15:55.160000
 use interactions.

0:15:55.160000 --> 0:15:59.560000
 It is responsible for sending requests
 to and receiving responses from

0:15:59.560000 --> 0:16:02.420000
 the backend. You have your
 business logic layer.

0:16:02.420000 --> 0:16:10.080000
 So this is the heart of the application
 or this, you know, the heart of

0:16:10.080000 --> 0:16:12.820000
 the presentation layer
 applies business rules.

0:16:12.820000 --> 0:16:17.620000
 So validating user inputs, calculating
 discounts or managing order workflows

0:16:17.620000 --> 0:16:21.760000
 and orchestrates interactions
 with the data access layer.

0:16:21.760000 --> 0:16:23.580000
 You then have the data access layer.

0:16:23.580000 --> 0:16:25.000000
 Just think of it as your database.

0:16:25.000000 --> 0:16:28.360000
 So this layer connects to the database,
 which stores critical data, such

0:16:28.360000 --> 0:16:33.720000
 as user accounts, product catalogs and
 order histories again in this example.

0:16:33.720000 --> 0:16:40.080000
 So it, it also ensures data integrity and
 efficient retrieval of information.

0:16:40.080000 --> 0:16:43.840000
 So we're going to go through
 it in a structured way.

0:16:43.840000 --> 0:16:47.140000
 And you can see I've sort of moved
 away from the top down just to show

0:16:47.140000 --> 0:16:51.840000
 you that this is just a design, just
 think of it as design guidelines

0:16:51.840000 --> 0:16:55.800000
 or a way of it gives
 you a structured way.

0:16:55.800000 --> 0:17:03.200000
 When we talk about the top down, the
 top down format used in in the the

0:17:03.200000 --> 0:17:07.060000
 layered architecture model is just
 there, or is just recommended.

0:17:07.060000 --> 0:17:14.380000
 So you can actually see how everything
 trickles down from the users from

0:17:14.380000 --> 0:17:19.460000
 the client side or presentation
 layer, that makes sense.

0:17:19.460000 --> 0:17:26.960000
 So how you how you go from all of these
 services to the actual presentation

0:17:26.960000 --> 0:17:29.320000
 layer or users browser or vice versa.

0:17:29.320000 --> 0:17:34.200000
 So when a user clicks this, what happens
 and what routes does it take?

0:17:34.200000 --> 0:17:38.180000
 So these models are very, very useful.

0:17:38.180000 --> 0:17:41.820000
 And again, if you're if you've ever
 worked in software development, you

0:17:41.820000 --> 0:17:46.560000
 start off with this, at least, you know,
 from you start off with a very

0:17:46.560000 --> 0:17:51.740000
 basic idea. But if you don't have something
 like this, things can get

0:17:51.740000 --> 0:17:53.060000
 crazy very quickly.

0:17:53.060000 --> 0:17:56.640000
 So the client layer, as I've mentioned,
 this is the front end interface

0:17:56.640000 --> 0:17:59.040000
 that customers interact with.

0:17:59.040000 --> 0:18:03.000000
 You know, the components here are going
 to be an e-commerce website that

0:18:03.000000 --> 0:18:07.700000
 provides product browsing and search functionality,
 shopping cart functionality,

0:18:07.700000 --> 0:18:09.480000
 and user account management.

0:18:09.480000 --> 0:18:13.660000
 So the website runs in web browsers
 and sends HTTP requests to the web

0:18:13.660000 --> 0:18:18.620000
 server. Now, to make it more realistic,
 I've also included your namesake

0:18:18.620000 --> 0:18:21.180000
 intermediary layer, which would be a CDN.


0:18:21.180000 --> 0:18:24.600000
 So think of cloud flare or even
 a reverse proxy, right?

0:18:24.600000 --> 0:18:26.460000
 It can be anything really.

0:18:26.460000 --> 0:18:29.060000
 And then of course, you have
 your web server layer.

0:18:29.060000 --> 0:18:32.820000
 In this case, in the in the case of
 the example is going to be Nginx.

0:18:32.820000 --> 0:18:34.860000
 So what does Nginx do?

0:18:34.860000 --> 0:18:39.860000
 And pay attention, because this was I
 took this based on a web application

0:18:39.860000 --> 0:18:42.160000
 that I developed a few years ago.

0:18:42.160000 --> 0:18:46.160000
 When you start to define each of these
 layers and what they do, it starts

0:18:46.160000 --> 0:18:51.040000
 to make sense, because I said, actually,
 I would need to handle incoming

0:18:51.040000 --> 0:18:53.340000
 HTTP or HTTP requests.

0:18:53.340000 --> 0:18:56.060000
 That's given. That's what
 a web server does.

0:18:56.060000 --> 0:19:02.020000
 But some additional stuff that I also
 wanted to include, or, you know,

0:19:02.020000 --> 0:19:05.080000
 I thought would be very useful would.

0:19:05.080000 --> 0:19:10.420000
 And this actually came back to the way
 I developed the actual web application

0:19:10.420000 --> 0:19:16.120000
 itself. And the fact that it would
 require a reverse proxy, because it

0:19:16.120000 --> 0:19:21.980000
 was built in Python or Django, Nginx
 would act as a reverse proxy fording

0:19:21.980000 --> 0:19:26.340000
 dynamic requests to the application server,
 which in this case, the application

0:19:26.340000 --> 0:19:32.120000
 server that I was using, because it
 was Django, or Python was UWSGI.

0:19:32.120000 --> 0:19:37.720000
 And I would also like it to provide some
 form of load balancing if multiple

0:19:37.720000 --> 0:19:39.620000
 application servers are deployed.

0:19:39.620000 --> 0:19:47.060000
 So if more than one instance of UWS,
 UWSGI was deployed, I didn't really

0:19:47.060000 --> 0:19:50.200000
 need it. But in the event that my web
 application was going to become

0:19:50.200000 --> 0:19:55.380000
 popular, I wanted to factor that in
 or have some scalability built in.

0:19:55.380000 --> 0:19:58.720000
 So hopefully that makes sense there.

0:19:58.720000 --> 0:20:01.060000
 And then you have the application
 server layer.

0:20:01.060000 --> 0:20:05.080000
 In this case, or in the case of this
 example, it's it was a UWSGI.

0:20:05.080000 --> 0:20:10.500000
 So processes dynamic requests received
 from Nginx, executes business logic

0:20:10.500000 --> 0:20:14.440000
 and handles the backend operations
 for the e-commerce website.

0:20:14.440000 --> 0:20:19.780000
 So managers use authentication, shopping
 cart logic, order, order processing,

0:20:19.780000 --> 0:20:23.180000
 etc. You can also have a forward proxy.

0:20:23.180000 --> 0:20:27.700000
 If you're if you have an API, so I
 just added that that again, to give

0:20:27.700000 --> 0:20:32.580000
 you a more realistic understanding
 of how all of this is organized.

0:20:32.580000 --> 0:20:37.260000
 And then of course, you have the API layer,
 so provide structured interfaces

0:20:37.260000 --> 0:20:42.340000
 for communication between the application
 server and external or internal

0:20:42.340000 --> 0:20:47.320000
 systems. So in the case of this example,
 you have the product info API,

0:20:47.320000 --> 0:20:50.960000
 so provides up-to-date information on
 product availability, pricing and

0:20:50.960000 --> 0:20:55.500000
 descriptions. And then the order management
 API, so tracks customer orders

0:20:55.500000 --> 0:20:59.260000
 and provides order status updates.

0:20:59.260000 --> 0:21:01.600000
 And then of course, the database layer.

0:21:01.600000 --> 0:21:06.460000
 So the application server, which was
 UWSGI, connects to MongoDB using

0:21:06.460000 --> 0:21:10.640000
 a database drive or library,
 such as PyMongo for Python.

0:21:10.640000 --> 0:21:15.840000
 And in this case, the database was,
 you know, the database layer has a

0:21:15.840000 --> 0:21:19.080000
 NoSQL database, again, MongoDB.

0:21:19.080000 --> 0:21:24.180000
 So its purpose is to store e-commerce
 data, including product, the product

0:21:24.180000 --> 0:21:29.600000
 catalog, customer information, order
 history and the transaction records.

0:21:29.600000 --> 0:21:33.820000
 And in this case, it was I wanted
 to host it on a separate server.

0:21:33.820000 --> 0:21:36.120000
 It was a microservice in reality.

0:21:36.120000 --> 0:21:38.540000
 What that means is it was a container.

0:21:38.540000 --> 0:21:44.200000
 But again, I utilized the layered architecture
 model because everything

0:21:44.200000 --> 0:21:46.340000
 else was not a microservice.

0:21:46.340000 --> 0:21:50.220000
 So it hosted on a separate server for
 scalability and security because

0:21:50.220000 --> 0:21:55.540000
 I expected the database to
 actually grow quite a bit.

0:21:55.540000 --> 0:21:57.580000
 And this is what it looks now.

0:21:57.580000 --> 0:22:01.520000
 This is what it would look like, you know,
 using the traditional recommended

0:22:01.520000 --> 0:22:10.600000
 top-down when, you know, designing the
 architecture of a web application

0:22:10.600000 --> 0:22:12.560000
 with a layered model.

0:22:12.560000 --> 0:22:17.280000
 So you have your client layer, your
 web server layer, engine X, I remove

0:22:17.280000 --> 0:22:20.360000
 the intermediary services because
 it's not really important.

0:22:20.360000 --> 0:22:24.160000
 And then the application server layer, which
 you can see pretty much everything

0:22:24.160000 --> 0:22:28.080000
 else, you know, it pretty much communicates
 with the internal services

0:22:28.080000 --> 0:22:30.880000
 layer. This is not really important,
 but you'd have an authentication

0:22:30.880000 --> 0:22:33.320000
 service as the product matures.

0:22:33.320000 --> 0:22:36.020000
 This is what it would start to look like.


0:22:36.020000 --> 0:22:40.340000
 The payment processing service, the
 email notification service, search

0:22:40.340000 --> 0:22:44.080000
 service, the database land,
 and then the API layer.

0:22:44.080000 --> 0:22:45.380000
 So there we are.

0:22:45.380000 --> 0:22:51.660000
 With that being said, you know, that's pretty
 much what I wanted to essentially

0:22:51.660000 --> 0:22:54.120000
 cover. Hopefully, you've learned a lot.

0:22:54.120000 --> 0:22:59.460000
 I know that whenever I introduce or
 I'm covering this particular topic,

0:22:59.460000 --> 0:23:05.760000
 this really is you know, I highly recommend
 that you take a look at some

0:23:05.760000 --> 0:23:10.960000
 of the other web application architecture
 models that I outlined in the

0:23:10.960000 --> 0:23:16.820000
 table. And now that we have this, you
 know, shared understanding of what

0:23:16.820000 --> 0:23:22.400000
 modern web applications utilize or how
 they're built from an architecture

0:23:22.400000 --> 0:23:27.840000
 point of view, we can now turn our attention
 to server side attacks, which

0:23:27.840000 --> 0:23:32.160000
 are not what they may seem to be or what
 you may have thought or considered

0:23:32.160000 --> 0:23:38.040000
 them to be. And what we've just covered
 here has already laid the groundwork

0:23:38.040000 --> 0:23:39.520000
 for what we'll be covering.

0:23:39.520000 --> 0:23:43.840000
 So in the next video, we'll get introduced
 formally now to server side

0:23:43.840000 --> 0:23:48.920000
 attacks and we'll be utilizing again,
 these architecture models, more

0:23:48.920000 --> 0:23:52.460000
 specifically the layered model
 to put everything into context.

0:23:52.460000 --> 0:23:57.800000
 So you actually understand, I now understand
 why SSRF is, you know, in

0:23:57.800000 --> 0:24:01.640000
 the application server layer.

0:24:01.640000 --> 0:24:06.220000
 So very, very important, you know,
 that that we actually went through

0:24:06.220000 --> 0:24:09.740000
 this. But that being said, that's
 going to be it for this video.

0:24:09.740000 --> 0:24:11.680000
 And I'll be seeing you in the next video.