BSidesNcl 2021 Map and Conquer application security over cloud Pankaj Mouriya

And here we are about to see from Pagash about the Map and Conquer Application Security over Cloud. They're security analyst at AppSight Co. Consulting. And I'll let you take it away, mate. Yeah. Thank you, Gerard. So all right. Hello, everyone. This is Pankaj Mora. And today, welcome to my talk. This is Map and Conquer Application Security over Cloud. And I really appreciate you guys for taking your time if you are attending this talk. And I'll make sure that this becomes an informative talk and you get to learn a lot of things. So this is me in the picture if you see. And yeah, I work as a security analyst at AppSico Consulting. At AppSico, we test applications for inner web

applications for security issues and also we do cloud-driven cloud infrastructure testing. This is my Twitter handle, pankajmorya, underscore. My DMs are often in case, you know, after that, in case you have anything to talk about, please reach out to me. I will be really happy about that. So today, we will be talking about an exciting, you know, domain, which is, you know, securing your web applications over cloud. And that's why even I kept my title as Map and Conquer Application Security. In this talk, I will be mostly focusing towards AWS cloud service provider. I mean, I really wanted to focus towards other cloud service providers, but let's say that due to scarcity of time and

I had to prepare these slides because the conference was near, I couldn't work on this. But yes, I have one more conference coming on the same topic and I will be working on that. In case you want to attend, you like the talk, please go and attend that also. So what to expect from this talk? I mean, how I will be breaking the next few minutes. Okay, so I'll just check my time. Okay, so we'll start with, basically there will be three different sections and we'll start with the Web App Sample application architecture and it's a modern AWS based application. It will be a modern AWS based application. I'll introduce guys with that application and I'll be using that application as a reference

throughout the talk, okay? And then we'll talk about, you know, step by step, the things we need to, what are the things that we need to secure the application? we'll use that same sample application, it's called Mythical Markets, and it's available on AWS, I'll mention in one of the future slides. And we'll discuss the approach to secure that sample application, and I hope that once the talk is finished, you can use the same approach to, when you are deploying an application in your own home, or in your own AWS platform, so you can follow the same approach, and you can deploy a secure application. Okay, and the last comes the mapping. In this we'll quickly discuss about the OWASP top 10. We'll discuss about the

potential attack surfaces or you can say the key security requirements which our application should have in order to deploy a secure application over to the cloud.

We will also talk about what can go wrong, we will be talking about what are the key requirements which we require to secure our application and then we will also talk about if we are using AWS services to encounter those potential security issues then what can go wrong with those AWS services, what misconfigurations can a human being do and can introduce more attacks. So we will be also discussing those things. So we'll start with the shared responsibility model. I mean, this is a fundamental thing which we should talk about because it helps us to know or it helps us to define the balance between, the security balance between the customers and the cloud service providers, you can say like AWS

in case. So we know, I mean, this is nobody, this is we all talk about either platform as a service or software as a service, nobody's on premises or infrastructure as a service. If you are crazy, you might be. But for now, in this talk, we'll be talking about platform-based service and software service. If you see the layers there, you will see that from OS or from the application, in physical layer, everything is handled by the cloud service providers. So, I mean, things have changed now. And if you talk about the difference, then we have reduced scope. We do not need to manage the completely the whole server thing. and there is no network troubleshoot

required at a hardware level or at a physical level. There is no, I mean, when I say physical level, I mean the network level or the data layer level. We do not need to spend money in terms of buying the hardware or you can say the hard disk for the memory and RAM because it's all managed by AWS or it's all managed by the cloud service providers. But still, even after these things being managed by AWS or any cloud service provider, We still need to manage the identity and access. We need to manage, you know, need to secure our code, the application's code. We need to secure the storage in case like, let's say we are using, you know, S3 to store our top data or we are using

databases. We do need to secure them. We also need to monitor the events or data flow because in case if there is an unauthorized access or, you know, excessive API request, then we definitely need to manage those. So we can say that, okay, I mean, we still have a lot of responsibilities which we need to take care of while we are deploying, you know, or while we are building an application onto the cloud. Now, in this talk, I'll mention three, we'll go with the flow where I'll mention three components which I think you should consider while deploying a secure application. And those will be, we'll start with the security domains, assets and services. We'll define all these three important components

and then we will discuss that how these security domains and how these assets and how these services all together can help us to identify what are the key requirements or what can be the potential security issues which we need to be aware about. So we'll start with security domains. Okay, before that I'll introduce to the this modern sample application which I mentioned earlier in one of my slides. So this is basically called MythicalMyFits. It's available if you see the URL on the bottom, github.com, AWS samples, AWS Modern Application Workshop. You can go to this URL, you can practice yourself. It has a GitHub repo. It has all the documentation available on AWS. You can also navigate to the mythicalmyfits.com. This

application, if you are not aware about, I will just say this application is built to find homes for abandoned or you can say almost extinct mythical creatures which you see in this picture you will see a few creatures here. So these are the creatures which they are looking for some home and you people if you have a big heart you can just go and adopt these creatures and they will have a home. This application also has a login and logout feature, I mean, a registration and login feature. It also allows users to like these creatures. I mean, there's a button where you can click like and it will like, it will, these creatures will be like and they will have some count over

it. So there are multiple things which this application does. Now we will, okay, let's proceed further with the architecture. Let's understand what this application is using first. I mean, every application which you will deploy over to the cloud, it will have some architecture. which you need to define obviously, so that you know what your application requirement is and what AWS services can be used to leverage those requirements. In this case, Mythical MyFits has, you know, as three buckets where the whole website content is being stored. It uses Amazon Cognito, it uses Lambda, it uses API Gateway. It also uses DynamoDB and CI CD pipelines. But for now, in this talk, because we are mostly concerned about the security, So we will be talking about Amazon Cognito, we'll talk

about Amazon API Gateway, we'll talk about the Lambda and S3 bucket and maybe database related things. Okay. So let's start with the security domains. I mean, if you have to deploy an application or if you are planning to deploy an application, the first thing I would say you to consider is that define the security domains for an application.

We have our data. We know that. Everything inside our application, whatever we are planning, will be considered a data. And then we will have identity and access management because we will have a user. Because even in this case of our mythical MyFix, it has an option for users to register and log in. So we will have our identity and access management. We'll have our code, the application code, basically. And then we also need some kind of logging and monitoring And at the end, we have our infrastructure, obviously. Although we are not basically talking, when I say infrastructure, we are not talking about the hardware level things, just that you can have the DNS record, so

you might be using, you can say, the DNS service route 53, such kind of things. So now, once you have defined your security domains, next thing will be to define your assets. what your application, what are the important assets inside the application? So, we will have PII, I mean if user is registering or a user is using the login feature, obviously they will have their first name, last name and maybe their password and all. And maybe they might, if the application has a phone number, then you might also need to fill the phone number. In case of Mythical MyFix, it has a login where you can just register and login inside the application. We have our PII data, which is an important asset.

And then we have Mythical MyFix, I mean, the creatures, which are really important for us because the whole application revolves around them. I mean, if they are not there, then the application, Mythical MyFix, is of no use, right? And we can't, and if you talk about security, I mean, these creatures are important for us because, I mean, they, people will come to adopt them and if they are not present there, and if they are, you know, hacked or if they are, being adopted by anonymous people without registering and all, then again that becomes a big factor for us, right? We can't let anybody, just random person to come and adopt. We do require some information

about them. Then we have our code. Basically, all the application code is again an important asset because that's what defines the whole process of the application. As I mentioned earlier, that Mythical MyFits has a like feature where you can like these mythical creatures. And then In Mythical MyFits, right now there is no processing of financial data, but in case you are planning to use credit card, accept payments and all, then obviously you need to, then financial data will be an important asset also. Now we know what are our security domains. We also know

what are our important assets. Now let's talk about services which use our data. I mean, in this case, if you see the table, We have our infrastructure where we are using the AWS service route 53. We have PI access control. I mean, PI basically, if you talk about the again personal identifiable information, then Amazon Cognito comes into place. If you are not aware about Amazon Cognito, I'll introduce you in one of the future slides. We will use S3 to store our code. I mean, the HTML or the static code, you can say. And then all the last three services like the API Gateway, the Lambda, and even DynamDB, they also interact with, they all will interact with the API, the mythical MyFix creatures, and the code, and

the likes, and maybe multiple other things. So now we have defined what are our security domains. We also know that, what are our important assets, and we also know our data. So, Next thing is, once we are using AWS services to secure our data, you can say, the AWS services are using our important assets, but the next question comes is, have you configured your services perfectly? And obviously there is no word like perfect, but yes, you still, you can configure your services at a level that there are no security issues, but that's what we have to talk about and that's what the whole talk will revolve around. So moving further, Oh yeah, this slide. I just wanted to mention this. I mean, the main focus was towards OWASP Top

10 2017, where I wanted to introduce you guys in case you are not familiar with OWASP. So just wanted to introduce you that, okay, OWASP basically manages top 10 security risks starting from A1 to A10. And these are the top 10 security risks which organizations, communities, or people or corporate follow. and they map these security risks with the potential security issues which they find and that's what all the OWASP top 10 does. But mentioning this 2021, the main purpose was just to introduce you guys that yes, OWASP has released some guidelines, documentation around the 2021 version of OWASP top 10, although it is still I guess in the review stage. So let's see what happens. But yes, you

should be aware about that something new is coming and we do have SSRF and cryptographic, I guess, failures and all in the list. Okay, so now let's map, now that you are familiar with the OWASP top 10, let's map the security domains with the OWASP top 10. So we know our security domains, we know that what are the key domains which we need to secure. Let's say in this case identity and then we have forward logging and infrastructure. and data. So if you go to previous slide, just go through it once, you know A1, A2, A3, A4, A5, A6, A7, A9, A10. We have all the security risks here, injection and insufficient logging and monitoring. Now in this case,

we are dividing the identity and access into two security risks, that is local authentication and local access control.

Basically, we do require authentication and authorization. So that's where we manage this. We have our code, which is A1, that is injection. Obviously, your code can have injection related issues if there is no input validation in place. It can have XSS, XSE. It can have insecure deserilization. And obviously, we can have using, if you're using third party libraries, we can have components with non-vulnerabilities. Then we have our sensitive data exposure. that is data. Then in terms of infrastructure, we have again using components with non-valerability. In logging, we have security misconfiguration and insufficient logging and monitoring. I mean, this is how I wanted to map it and I guess it makes sense even if you look around it. And it

will make more sense when I show you the future slides.

give you a high level of all these security domains you mentioned and the mapping that in terms of identity and access management, we should have some authorization or some authentication. In terms of code, we should have some input validation in place.

We can't reveal our secrets or put them inside a code which is publicly available. We can't afford to have dependency vulnerabilities. Our data should be encrypted wherever it is stored and then we can have our infrastructure should have some kind of firewall, and then we should have some monitoring in place. For example, you can have CloudWatch, CloudTrail, to track all the events. So this is a, you can say these are our key requirements based on the security domains which you have defined, and this is what you should look for when you are deploying your applications to the cloud. Okay, so let's start with the first, that is identity and access management, and in this case, what should be our requirements if we are

planning to secure application in terms of identity and access. We will authenticate our user, we will authorize our user, we need to manage some kind of access control between the services. You can say backend services, let's say if you're using Lambda, how our accounts are interacting with the function or how our S3 is interacting with the functions. That's what we need to That should be controlled obviously. Now we know that these are our key requirements in terms of identity and access management. But how to achieve them using AWS. So if you are deploying your application to AWS and you are worried about identity and access management, then you have API Gateway. API Gateway, if you are not familiar, I'll

just give you a simple definition of it. It acts like a wall between your, that's what the simple layman thing will be. It acts like a wall between the user and the backend AWS services. That's what you can say. You can create REST APIs and all using this. And there are multiple other things. So in this case, while implementing IAM, you can use API. API Gateway has something called authorization selection, where you can go and you can use Amazon Cognito user pool authorizer, or you can use Lambda custom authorizer to work on the authorization part. If you remember the architecture of Mythical MyFits, which I showed in the earlier slides, you would remember that there was one architecture showed that the requests are

going via Amazon API Gateway to the Cognitor. Because that's where, because the Mythical MyFits is using Amazon Cognitor, user code authorizer. Just use the highlighter. I mean, in our case, the Mythical MyFits is using Amazon Cognito user pool authorizer. You can also use Lambda custom authorizer. That's another thing which you can use. And if your application is not heavily, you know, API dependent or it's, let's say it's a standard application or a serverless application, then you can just go with the Cognito where you have user pools and identity pools. User pools act like a, inside, basically Cognito has these two things and user pool acts like a directory of the users. where you can say users are authenticated

and then identity pool can act like an authorization where you can assign what kind of roles these people should have, what kind of roles you can say the authenticated and the unauthenticated users can have to our AWS services which will be used once the user is logged in. And then we also need to manage, as I mentioned in our key requirement that we also need to manage the access between services. So we have AWS Lambda here where AWS Lambda has two things which is called invocation permissions and execution permissions. Invocation grants an AWS service or another account, you know, other accounts permissions to use a function. And execution role is a kind of IAM role, you can say, that grants

function permissions to access AWS services and resources. So now you see that if you remember the OWASP top 10 risks, you will see that we have mapped In terms of IAM, we have mapped our broken authentication using Cognito and authorization, you know, you can say using the custom Amazon Cognito user flow authorizer or the identity pools. And we have also mapped the access control in terms of Lambda. Now, again, we are using AWS services, but still we are humans, we can make mistakes. And these are the few things which I came across and which I was able to collect and, you know, mention here. The first one is misconfigured AWS Cognito attributes. When you use Cognito, Cognito has something called attributes

and you can configure them to manage access controls and these attributes can also be given read and write permissions. So let's say you are using this custom, you created a custom attribute. Basically there is a feature where you can create your own attributes, which is called custom attributes. These attributes can be like name, role, it can be like a phone number, input, things like that. So these things will be asked while you are filling the form, you can say, of the registration form. So what happens, let's say you are a local business user and you put a Okay, I'll show you the slides. So if you see this first image here, you will see that if you are a low privileged user and

you are using custom attributes, so a low privileged user will have some valuable user, but if you have given your custom attributes write permissions, if you see the below image, write table attributes, and if you check this box and you give write permission to your role, to your custom attribute, then a low privileged user can make a call to the user update user attributes API, YCLI, and they can use their access, low privilege access token, and they can upgrade their role to a, you know, a high privilege user. Let's say in this case, we have admin. Also, these slides are taken from, these images are taken from application group security. There is a website which

has top 10 AWS labs, where they talk about top 10 security, AWS based security issues. So you can refer them. I'll mention the links in the references in the end of the slide. Okay. misconfigured AWS to open the profile self-registration. So what happens that in AWS we have policy section where it has the option where it allows you to either allow only admins to register themselves or allow users to sign themselves up. If you have enabled, if you have kept a default or you have enabled allow users to sign themselves up, then you know, and malicious user has a client ID and I mean, if they are able to fetch this client ID out somewhere, then they will be able to use the

signup API and they can sign up themselves using their own username and password. And you can also, once the signup is done, they can also use the confirmed signup API and they can confirm their signup and they can become a legit user of their application. So these are the two things which you should worry about while using Cognito. Then we have hardcoded identity pool IDs and identity pool ID in the HTTP response. These are basically when you leak your identity pool ID in the JavaScript or in the code, or maybe in the static response. If you do that, then obviously malicious users again can use these identity pool IDs to generate a temporary token, AWS token, and then they can use the temporary AWS token to extract, or you

can say brute force permissions which are associated with that particular ID. We have written, at AppSupport we have written a blog post, this is a cool blog post, covers almost everything. So it says exploiting weak configuration in Amazon Cognito. So in case you want to practice how these two hardcoded and the identity-plotting HTTP response work, or how can they be misconfigured or exploited, then please go ahead, after the talk, just give a look at the blog post. It has a sample application which you can use to practice. And then we have something called granting Lambda invoke permissions to service principle without specifying the source. It's something very specific to Lambda, and it's like, you know, If you do not, you can say, if you do

not define the source inside an organization, then any other account available in that organization can leverage this misconfiguration to use your Lambda function. So it's very specific to Lambda, so I won't go into detail, but yes, I'll do mention the links in the reference in the end, we can go ahead and read about it.

Moving ahead. Next thing is requirements for a secure application in terms of our code. Requirements for a secure application in terms of our code. Let's say now we have our security domain which is our code. What are the key requirements, key security requirements you can say? We need to validate the user input. We can't afford to leak our secrets in the source code. And obviously, if your application is dependent on third-party libraries, then you may have dependency vulnerabilities. In MyFIT's mythical application, we are using input validation. And I mean, that's totally different. These requirements are based on a standard application. It can be any standard application, which you are planning to do. So these are the three things which you can think

about. while implementing or while thinking about a secure implementation or key requirements. So now we know that we need something inside AWS to manage input validation, to manage our secrets in source code, and to manage the dependency vulnerabilities. So let's see that how you can leverage the AWS services to counter these input validation and other key requirements. So in terms of input validation, we have something called AWS WAV. You can use the WAF. It has some conditions like SQL injection rule and access rules. It has multiple other things, but these are the two, I guess, which are relevant to in terms of input validation, I would say. And we also have API Gateway, which has a, you can say, by design thing called request

validation, where it validates the request. It validates all the requests before the request proceeds further to the next integration. whenever the request fails or it doesn't meet that criteria which we have defined inside the API gateway, then it will fail the request, it will return a 400 response to the user who made the request. And the basic visualization which it does is that it checks for the request parameters in the URI, it checks for the query string, it checks for the headers, and it also checks whether the headers are used or not, I mean, if they are blank or not. should not blank if they are mandatory so that's that's the thing and and this is how we you know cover the even injection in terms of

input validation okay now dependency vulnerabilities i i mean i'm not aware about any service in aws which can be used to counter this but yes if you are aware about i mean i haven't done all the complete research yet so please go ahead and do reach out to me and tell me that in Twitter or wherever you are comfortable. So for now, we can use third-party libraries like we can use OWASP dependency check if you're using too many third-party libraries in your application. So you can use these dependency checks or you can use Senac or NPM audit to look for the dependency vulnerabilities in their application. Or you can simply minimize the use of dependencies if that's what you can do. In terms of secrets,

revealing secrets in the code or something, it would be a best practice to use AWS Secret Manager. It's really a good service and you can use this to store your secrets and this way you won't be leaking all these secrets. So now you see we have also covered our sensitive data exposure. We have covered the dependency thing that is the components of non-valuability and we have, oh, we are yet to cover the insecurity, sterilization. So, I mean, if you have ever read that was dropped in serverless documentation, you will see that the documentation mentions that most of the third party libraries, which use, you know, they basically use these third, they use the applications, use the third party libraries to handle the deserialization of

the data. And, you know, even these And such libraries which are used, they can themselves introduce security, insecure digitalization kind of bugs. So best practice will be to review your third party libraries for non-digitalization vulnerabilities. And you should also, you can also, it's a good practice to monitor digitalization uses and all. So what can go wrong here? I mean, we are using these services and all. So I would say, or you can say, what can go wrong, or you can say, what can be missed kind of things. So you may end up, in case you are not using secrets and all, secret manager and all, you may end up leaking your secrets in the source code

or in the repositories, which normally happens these days. And you can, if you're not using encryption or if you're not encrypting your secrets, then that's another issue. So you should, you can use KMS, And then if you're not rotating your secrets, and I mean, there is no rotation available and your secrets are leaked, then if anybody has access to your secrets, then they can use that secret to, obviously, to log in or access your applications, or whatever the secret is intended to do. Then we have the instant dependencies. Again, if your application is heavily dependent and you are not doing the dependency checks, then again, you can introduce different or various kinds of vulnerabilities around it. Then we have our Lambda command injection. To mitigate this, I

mean, if you're using Lambda, you may end up introducing such injection issues. To mitigate this, it would be simply that you always

avoid using user input or user controllable data or input in functions which directly interact with the system call, so you can say directly to the OS level, operating level environment. And that way you can mitigate the command injection kind of issues. There are multiple other things which can go wrong and there are multiple other security issues which I have come across. It's just that I didn't do that complete homework around it, so I couldn't venture it here. But yes, if you go to this application.security, you will see the top 10, top 10 AWS related security risks. You can just go ahead and you can practice them. It has a beautiful lab around it. I mean, I really liked them when I was preparing

these slides and all. So that's why I took the screenshots over here. Okay, so we have, now we come to our data. In terms of data, we do require to secure our data and to have some data privacy. We do require our data to have encryption at rest and in transit. You should have data backup and replication if your application, you know, around your data, right, obviously. So these are the four key requirements which you can think of while you are, again, planning to deploy an application or build an application and you want to use these cloud service providers. So how we can leverage AWS services to come to these things? For encryption at rest, we have something called KMS.

One of the examples I would say is why should you use KMS is let's say that you have a S3 bucket and that hosts some sensitive data around it, sensitive data inside it. And then if some crazy person inside your organization makes that S3 bucket public, then what will happen is that anyone who has knowledge about that S3 bucket URL, they can visit that URL, they can access the objects or data inside it. If you have enabled KMS, then even though the bucket is made public, people won't be able to read the data because that will be encrypted and they need to decrypt the data. And KMS has different kind of algorithms around it like

symmetric and asymmetric encryption. It has AES, DES, triple DES and blowfish in symmetric, I guess. And in asymmetric, it has, there are algorithms like digital, digital algorithm, Diffie-Hellman. and multiple other. One more thing to mention that the KMS uses something called CMK and then further DEKs which is, DEK is basically data encryption keys which are used to encrypt or decrypt your data of any size you can say. And then we talk about, yeah, API gateway encryption in transit By default, Amazon API Gateway only exposes S3TPS end point. So if you're using API Gateway, then your data is already interpreted in transition. And then we have Amazon Certificate Manager. This basically lets you provision DLS certificates for your application. So again, there's a really

useful feature or service you can say. You should have data backup. For S3, you can have which is cross-recent replication, or you can have snapshots of your instances. So these kinds of backups you should be doing, you should have enabled. And then we have data security and privacy, that is Amazon Macy. Amazon Macy is a smart service which uses machine learning and pattern matching to discover and protect your sensitive data in AWS. And it also, it can protect your It can protect your PI data, like your names, your address, it can protect your financial, like your credit card numbers, credit card numbers and all. So it is really useful. You should go ahead and check it out in case you are not aware about this service. And

then what can go wrong or what can be missed here? If you talk, so we, in S3, we have something called where you can enable a read access or write access. And what normally happens that

people want that these objects should be accessible to these people, some level of people. But if you are not defining the conditions or if you're not creating that S3 policy or IAM policy, if you are not using a condition section where you can pass the IP addresses of these people, the people who should access your data. And if you miss that again, then this bucket will become, you know, well readable. I mean, anybody can go and read your data. Also, if you're not following the practice of least privilege, then you may end up giving more actions. I mean, while you define your S3 bucket, you might have seen, if you open the next slide, okay. You define action where you say that, okay,

bucket can be read, bucket can be listed. the bucket can get the object or they can list the object you can say or people can get the object and they can put object basically means write object, write data inside the bucket. If you just wanted to enable write access and then you

allow more actions that also becomes a problem or if you just make it a, in this case if you don't define a particular principle For example, if you do not define the users, the roles or the groups, then again, anybody can access, anybody can write your data into your bucket. So that's the thing which you should be aware about and you should be very careful around it because that's one of the key, you can see, misconfiguration which is seen around. And then we have S3 directed traversal. The best way to explain it would be you go to the same application.sgk.tlabs and you can practice, there is a complete lab around it. So you can practice

that and it will give you idea of how this S3 directory trial could be exploited. And then we have, and also they have mitigation and other things. So you do code, code analysis and mitigation. So you can also use, you can also learn from that. Then we have S3 object unsigned URLs. Basically if you're not using signed URLs, then again, anybody can just browse to your object URLs and they can access your objects. So next we have infrastructure. In infrastructure, we do require data protection, rate limiting also. This side, I just wanted to mention that people these days do come across subdomain takeover and all. So what we can use to protect against these things? You can use AWS Shield, standard or advanced. I mean, it's just

that the difference is that Shield Basically allows protection over layer three and layer four, that is network and transport layer, but she advanced gives you protection over the applications also. And it also allows you real-time metrics, so that's really useful, real-time metrics of the attacks which is going on, so that's really useful. You can use API Gateway Throttling. Basically, it has account level throttling and API stage level throttling, so you can use that. We have AWS WAF, where you can, you know, geographically block some set of IPs or you can use some rate based rules. There is IP reputation. Again, if you want to read about all these services, then just go ahead to the link which I will be mentioning in the references and you can

use that. Just to mention about subdomain takeover here. You know, sometimes it happens that people enable, people use DNS service and then they have some subdomain, you know, or maybe a domain. which they create inside the restry bucket. And what happens that sometimes they delete the bucket, but they forget to remove the DNS entry from their DNS service. Let's say in case of Paytables, it may be around 53. They forget to do that. And then what happens that whenever some random user crosses to that particular URL, then you might see such error and message. You can say 404 not found, the specified bucket does not exist. What a malicious user can do is they can get their own bucket and then they can,

basically you can say the whole domain is taken over and then they can host their own phishing website or they can host malicious files or malwares and all. So this is again one key thing which you should be aware about. And then we have our logging and monitoring. Our application should have application logs. access logs, alarms, and compliance validation. So what AWS services we can use is, we have AWS Config, which acts as an inventory, and it also helps you check for the compliance because it has rules where it says whether your service is compliant or not. And then it has AWS, we have AWS CloudTrail. You can use CloudTrail to, I mean, to identify or report unwanted behavior. For example, if

there is a wrong use of wrong credentials, if there are unauthorized access to resources or excessive execution of functions or usually people sending multiple API requests, then you can track those events. You can also inspect them by going through that detailed report. Detailed whatever the API events you see there. And then you can use, for logging, you can use API gate for access logs and execution logs. Access logs basically enable you to see who has access to the APIs and all. And you can also use CloudWatch in case you want to monitor these things in real time. And hence, we have also covered our insufficient logging and monitoring. So what can go wrong here? I mean, the only

thing is that if you do not enable logging and monitoring, maybe it can become too late that attacker may have already infected your code or might have become the part of the application. So that's all. I mean, we have covered all the top 10. We have already mapped the top 10 security risks with our security domains. So if you have any questions, please, please, please ask. And while you think about the questions, I would say these are the references and thank you. Thank you, B-Sites. And thank you, audience. This is my personal website. This is my Twitter handle and LinkedIn. And my email address, So yeah, I mean, hi, Jeraj. We can have the questions

now.