쉐도잉 연습: OWASP Top 10 Explained - 영상으로 영어 말하기 배우기

where we will look at security risk based on the OWASP top 10.

So we have these top 10 security risks here, which we are going to dive into.

We will be looking at what they are and how we can prevent and protect our web application against them.

So first off, we have the injection.

And what is injection?

An injection of code is when a given user, for example, we see here,

are trying to input something into a user input field that is not intended there.

In this case we are looking at SQL injection.

There are other injection forms, for example OS command.

But here we are looking at SQL injection where in a username

and password field a user could try to input some SQL statement

that will in all cases return true

and then the database will just act on that and return all the information in that given table.

So for example here he has said that if 1 equals 1 which is always true then this should

act upon that and most likely if your web location are vulnerable to that you will be

returning information that the users are not intended to see or the malicious users are not intended to see.

So this is one of the attacks that is very important to protect against

and we still see even larger companies in 2020 being vulnerable to this attack.

So this is definitely something to pay attention to.

And the way that you can prevent this is to check the input

that users are given and not only in the front end

but also in the back end because if you take front end

verification only and validation then the users can again just manipulate the HTML

and JavaScript on the local browser machine

and then request your server by going around these validations

so you also have to have backend validation to ensure

that people are not just going around because then it doesn't make any sense to to have front-end protection.

So the second one is broken authentication.

And broken authentication is when your application is vulnerable to,

for example, session hijacking, where a user is logging in and he is getting an ID which says,

okay, this is this particular user and he has these right.

But then an attacker somehow using a vulnerability in your web application

is capable of getting this ID or this token and then he is acting like he was this user

and can thereby make changes to the application in a way that this user has access to.

And a way to prevent this is of course never deploy any default credentials, store the passwords

using a one-way hash function such that

if your database of user accounts is getting leaked you You should not just store these passwords in plain text

so that everybody can use other people's credentials.

You also need to ensure that there are, for example, a limited attempt of authentication to the server

such that you cannot make a script that tries a thousand different password combinations in a minute

Because what human will do that if they actually have a real account on your system?

Basically no one.

So that is another way.

And then we have the sensitive data exposure

and a good example here is when yahoo got hit by this and they actually

confirmed that three billion user accounts were affected by this hacking attack meaning

that three billion user accounts got some of their information leaked in different hacking forums

and online where it was public for people who knew how to access it to view.

And that is of course not something that nobody ever wants for their application.

And a good way again to prevent this is use a password hashing function to store passwords

because if the database is then leaked you at least are sure that it is not in plain text.

and you should also be careful of what protocols you are using in order to check

that what is coming in and out of your system is using the right security protocol

and is not communicating in plain text.

For example, you should never have your web application communicating with the server in plain HTTP,

but you should also always use an encrypted protocol, for example, HTTPS.

Then we have the XML external entities,

and that is something that happens when an application is passing XML inputs and responses back and forth.

and when an application is doing this and this is not in an encrypted way,

an attacker might be able to manipulate with the input to the server in XML

and then request something from the server that was not intended by the developers.

So it is very important here that you implement, if you are using XML, that you implement a positive whitelisting such

that it is only a limited amount of input that is valid for your XML request.

Because then all XML input that is not part of this whitelisting will simply be blocked.

and thereby limiting the damage that such attack can inflict on your application.

Then we have number five, which is the broken access control.

A broken access control is, as we see here, when you have different roles for users,

and these roles have different authorization mechanisms mechanisms, for example, a basic user can log in, he can see his profile name,

profile page, and he can change his own password.

Then you might have an admin role

that can view all the other users profiles

and he can maybe make changes to the web application itself to make it behave in different ways.

And when these are conflicting

and you are not have not implemented this in the right way you might risk

that malicious users try to exploit this access control by getting

by getting themselves into a position where they have in your applications view a higher

authentication authorization than intended by you so they will try to get access to admin level

where they can do some stuff that they were not intended to because they were only the basic users

And a good way to prevent this is always follow the principle of least privileged,

meaning that you should never give a given role more access than

that needs because there's no reason for for example an admin to be able to change a password

and see passwords of the roles beneath him

because why should an admin ever go into a web application

and see these because the developers will always have access to the main database

if they are trusted and can see this information.

And again, if you use a secure way of storing the password, not even the developers will be able to see it because the passwords are hashed.

So there are definitely something that you should consider when implementing access control within your web application.

Then we have the security misconfiguration and

that is pretty much as the name says when you have an application

and you have configured in a way that make it vulnerable you are in real problem.

For example, that could be that you have unprotected files or that we saw with the web server.

If you have files placed on a server that is actually public but you are thinking it's private, then people might get access to this information anyways.

A good way to prevent against this is to remove

and never install any unnecessary features or dependencies into your server

or in the development of your application because the less features

and the less dependencies and packages and libraries you are having on the server

and the web application the easier it is to control

and the less likely you are to miss some of these configurations up and make your application vulnerable.

Then we have the cross-site scripting where people are trying to input stuff into,

100

for example, user input fields similar to when we saw SQL indexing.

101

But here we are seeing it such that people try to, for example, in an input field,

102

inject some scripts that is then going to be saved to the database, for example, in a comment field.

103

And then when another user tries to go into the web page like he normally would,

104

then that comment field is getting loaded from the database and then the script might get executed on his machine,

105

even though the attacker and the user has never interacted directly.

106

He is still getting attacked by this hacker

107

because he managed to save some script in the database

108

and the database and application just loaded it because it thought that it was a basic comment.

109

So it's also important to be very aware of this and also use the right frameworks to protect against this.

110

So again be aware of what framework you are using

111

and try to use the standard within that framework to escape these types of attack.

112

by for example have validation in your input fields and never allow your application to store

113

certain types of signs in the database.

114

It will insecure deserialization when data is stored or transmitted it is done so in bytes and and these are serialized.

115

As we see here, when you have a basic object and you want to transfer that, it is getting serialized into a stream of bytes

116

which is then going into for example the database

117

or into memory on the machine and then

118

when you want to read this again you transfer this from a stream of bytes where it has been stored

119

into the actual object again.

120

If you are not aware of how this is working,

121

you can open up for modification of this when the serialization is happening.

122

So that the object that you serialized is not the same, which is getting transferred back into an object when it is deserialized.

123

And that might damage the application or the data source that you wanted to save.

124

So a good way to prevent against this is to implement integrity checks

125

and encrypt the serialization of the object to prevent that malicious people

126

or people outside the application scope can read and temper with this stream of bytes.

127

And then we have number nine, which is using components with known vulnerabilities.

128

This is also similar to the security misconfiguration.

129

So when you are using different components or libraries in your web application, you should always update them and keep them updated,

130

because new vulnerabilities might be discovered after you build your application.

131

And if you are not updating these, your application will be vulnerable to these attacks attacks and

132

that is also why we keep seeing for us who use windows for example 10 that windows 10 is

133

pushing these security updates because the windows

134

that we have today might be vulnerable to certain attacks just two months ago

135

so if you haven't updated your windows in just two months you might be at risk

136

and it is the same for mobile phones

137

because new attacks is always popping up

138

and people are trying all kind of things to try to break into these different applications

139

and software systems and the vendors are

140

if they are good vendors they are trying to fix these

141

as quickly as possible to avoid their users being affected

142

so you should always try to update and search for dependency

143

and library updates when you have a web application because

144

if you are not you will most likely risk being attacked

145

when the right users discover that you have an unpatched library using an old module on your web application.

146

Then we have number 10 which is insufficient logging and monitoring.

147

As the name says, if you're not logging or monitoring your web application you don't know what is going on.

148

So you need to be aware of what is going on with your web application

149

and have the the right triggers and alarms set up to respond in time.

150

Because those people can just sit for days and try different things out

151

and if you are not discovering that someone is trying to temper with your application, you have no way of stopping them

152

because at one point they will hit the golden button

153

and actually find a vulnerability and you will never discover

154

that they tried to find this and you will never discover that they actually got into the system before it's too late.

155

So always log and monitor your web application.

156

It is crucial in order to stop your web application from being exploited.

157

So this was all for this video.

158

Remember to like and subscribe and then I will see you next time here on Vinsloth Academy.

✨ 추천 영상

173 문장

7 Phases of Penetration Testing Explained | Think your system is safe? #cybersecurity #pentesting

Business EnglishUniversity StudentsWorking Adults

207 문장

How I Made $30,000 Hacking Broken Access Control

Business EnglishUniversity StudentsWorking Adults

370 문장

FullStack Interview Questions (Junior & Mid)

Business EnglishInterview EnglishUniversity Students

94 문장

Your AI broke the layout. Now what?

Business EnglishUniversity StudentsWorking Adults

25 문장

DNS Explained in 100 Seconds

Business EnglishUniversity StudentsWorking Adults

159 문장

Top 5 AI Gateway Use Cases | Solo.io

Business EnglishUniversity StudentsWorking Adults

537 문장

Understand Microsoft Entra ID | AZ-104 | Episode 2

Business EnglishUniversity StudentsWorking Adults

41 문장

🚨 Most organizations don't fail ISO/IEC 27001 because they don't understand the standard...

Business EnglishUniversity StudentsWorking Adults

130 문장

Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond

Business EnglishUniversity StudentsWorking Adults

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: OWASP Top 10 Explained - 영상으로 영어 말하기 배우기

STOP Running Code On Your Computer

Manual Testing: QA Interview Preparation Questions and Answers

Design a File Upload Service Like a Senior Engineer

7 Phases of Penetration Testing Explained | Think your system is safe? #cybersecurity #pentesting

How I Made $30,000 Hacking Broken Access Control

FullStack Interview Questions (Junior & Mid)

Your AI broke the layout. Now what?

DNS Explained in 100 Seconds

Top 5 AI Gateway Use Cases | Solo.io

Understand Microsoft Entra ID | AZ-104 | Episode 2

🚨 Most organizations don't fail ISO/IEC 27001 because they don't understand the standard...

Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond

실생활 시나리오: 보안 위협 설명하는 상황

유용한 구문과 연어

당신의 샤도잉 챌린지

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법