シャドーイング練習: OWASP Top 10 Explained - 動画で英語スピーキングを学ぶ
レッスンを作成中...
1
where we will look at security risk based on the OWASP top 10.
2
So we have these top 10 security risks here, which we are going to dive into.
3
We will be looking at what they are and how we can prevent and protect our web application against them.
4
So first off, we have the injection.
5
And what is injection?
6
An injection of code is when a given user, for example, we see here,
7
are trying to input something into a user input field that is not intended there.
8
In this case we are looking at SQL injection.
9
There are other injection forms, for example OS command.
10
But here we are looking at SQL injection where in a username
11
and password field a user could try to input some SQL statement
12
that will in all cases return true
13
and then the database will just act on that and return all the information in that given table.
14
So for example here he has said that if 1 equals 1 which is always true then this should
15
act upon that and most likely if your web location are vulnerable to that you will be
16
returning information that the users are not intended to see or the malicious users are not intended to see.
17
So this is one of the attacks that is very important to protect against
18
and we still see even larger companies in 2020 being vulnerable to this attack.
19
So this is definitely something to pay attention to.
20
And the way that you can prevent this is to check the input
21
that users are given and not only in the front end
22
but also in the back end because if you take front end
23
verification only and validation then the users can again just manipulate the HTML
24
and JavaScript on the local browser machine
25
and then request your server by going around these validations
26
so you also have to have backend validation to ensure
27
that people are not just going around because then it doesn't make any sense to to have front-end protection.
28
So the second one is broken authentication.
29
And broken authentication is when your application is vulnerable to,
30
for example, session hijacking, where a user is logging in and he is getting an ID which says,
31
okay, this is this particular user and he has these right.
32
But then an attacker somehow using a vulnerability in your web application
33
is capable of getting this ID or this token and then he is acting like he was this user
34
and can thereby make changes to the application in a way that this user has access to.
35
And a way to prevent this is of course never deploy any default credentials, store the passwords
36
using a one-way hash function such that
37
if your database of user accounts is getting leaked you You should not just store these passwords in plain text
38
so that everybody can use other people's credentials.
39
You also need to ensure that there are, for example, a limited attempt of authentication to the server
40
such that you cannot make a script that tries a thousand different password combinations in a minute
41
Because what human will do that if they actually have a real account on your system?
42
Basically no one.
43
So that is another way.
44
And then we have the sensitive data exposure
45
and a good example here is when yahoo got hit by this and they actually
46
confirmed that three billion user accounts were affected by this hacking attack meaning
47
that three billion user accounts got some of their information leaked in different hacking forums
48
and online where it was public for people who knew how to access it to view.
49
And that is of course not something that nobody ever wants for their application.
50
And a good way again to prevent this is use a password hashing function to store passwords
51
because if the database is then leaked you at least are sure that it is not in plain text.
52
and you should also be careful of what protocols you are using in order to check
53
that what is coming in and out of your system is using the right security protocol
54
and is not communicating in plain text.
55
For example, you should never have your web application communicating with the server in plain HTTP,
56
but you should also always use an encrypted protocol, for example, HTTPS.
57
Then we have the XML external entities,
58
and that is something that happens when an application is passing XML inputs and responses back and forth.
59
and when an application is doing this and this is not in an encrypted way,
60
an attacker might be able to manipulate with the input to the server in XML
61
and then request something from the server that was not intended by the developers.
62
So it is very important here that you implement, if you are using XML, that you implement a positive whitelisting such
63
that it is only a limited amount of input that is valid for your XML request.
64
Because then all XML input that is not part of this whitelisting will simply be blocked.
65
and thereby limiting the damage that such attack can inflict on your application.
66
Then we have number five, which is the broken access control.
67
A broken access control is, as we see here, when you have different roles for users,
68
and these roles have different authorization mechanisms mechanisms, for example, a basic user can log in, he can see his profile name,
69
profile page, and he can change his own password.
70
Then you might have an admin role
71
that can view all the other users profiles
72
and he can maybe make changes to the web application itself to make it behave in different ways.
73
And when these are conflicting
74
and you are not have not implemented this in the right way you might risk
75
that malicious users try to exploit this access control by getting
76
by getting themselves into a position where they have in your applications view a higher
77
authentication authorization than intended by you so they will try to get access to admin level
78
where they can do some stuff that they were not intended to because they were only the basic users
79
And a good way to prevent this is always follow the principle of least privileged,
80
meaning that you should never give a given role more access than
81
that needs because there's no reason for for example an admin to be able to change a password
82
and see passwords of the roles beneath him
83
because why should an admin ever go into a web application
84
and see these because the developers will always have access to the main database
85
if they are trusted and can see this information.
86
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.
87
So there are definitely something that you should consider when implementing access control within your web application.
88
Then we have the security misconfiguration and
89
that is pretty much as the name says when you have an application
90
and you have configured in a way that make it vulnerable you are in real problem.
91
For example, that could be that you have unprotected files or that we saw with the web server.
92
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.
93
A good way to prevent against this is to remove
94
and never install any unnecessary features or dependencies into your server
95
or in the development of your application because the less features
96
and the less dependencies and packages and libraries you are having on the server
97
and the web application the easier it is to control
98
and the less likely you are to miss some of these configurations up and make your application vulnerable.
99
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.
✨ おすすめ動画
C13
173 文
STOP Running Code On Your Computer
Business EnglishUniversity StudentsWorking Adults
C11
154 文
Manual Testing: QA Interview Preparation Questions and Answers
Business EnglishInterview EnglishUniversity Students
C11
114 文
Design a File Upload Service Like a Senior Engineer
Business EnglishUniversity StudentsWorking Adults
C130 文
7 Phases of Penetration Testing Explained | Think your system is safe? #cybersecurity #pentesting
Business EnglishUniversity StudentsWorking Adults
C11
207 文
How I Made $30,000 Hacking Broken Access Control
Business EnglishUniversity StudentsWorking Adults
C15
370 文
FullStack Interview Questions (Junior & Mid)
Business EnglishInterview EnglishUniversity Students
C15
94 文
Your AI broke the layout. Now what?
Business EnglishUniversity StudentsWorking Adults
C12
25 文
DNS Explained in 100 Seconds
American AccentBusiness EnglishUniversity StudentsWorking Adults
C11
159 文
Top 5 AI Gateway Use Cases | Solo.io
Business EnglishUniversity StudentsWorking Adults
C11
537 文
Understand Microsoft Entra ID | AZ-104 | Episode 2
Business EnglishUniversity StudentsWorking Adults
C141 文
🚨 Most organizations don't fail ISO/IEC 27001 because they don't understand the standard...
Business EnglishUniversity StudentsWorking Adults
C12
130 文
Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond
Business EnglishUniversity StudentsWorking Adults
この動画でシャドーイングを練習する理由
セキュリティリスクについて説明するこの動画は、shadowspeaksやshadow speechの練習に最適です。専門用語が多いながらも口語的な表現が混ざり、日常的な会話からビジネス向けの説明までの幅広いニュアンスを学べます。「SQLインジェクション」のような技術用語を自然に発音し、論理的に説明するトーンを身につけることで、英語での説明力が向上します。また、英語シャドーイングのサイトでよく使われる「原因と対策」の構造を学ぶことができ、実践的な会話スキルにつながります。
文脈の中の文法と表現
- 「where we will look at...」：関係詞節を使った説明の始まり。「ここで...について見ていきます」という柔らかい導入に適しています。
- 「which we are going to dive into」：「深く掘り下げる」という比喩表現。専門的な話題を親しみやすくするのに効果的です。
- 「such that if...」：条件文を使った因果関係の説明。「...なので、もし...」という論理的な展開に必要な構造です。
発音の注意点
「OWASP」は「オワスプ」と発音し、アクセントは最初の音節に置きます。「injection」の「jec」部分は「ジェク」ではなく「ジェクション」と明確に発音しましょう。「hijacking」の「hij」は「ハイジ」ではなく「ハイジャッキング」と滑らかに繋ぎます。これらの単語はshadowing siteでも頻出するので、正確な発音を覚えることが重要です。また、「So」「But」などの接続詞のイントネーションにも注意し、文の流れを自然に伝えることがポイントです。
この動画の文法
話し手がよく使っている文型を、動画の実際の表現とともに紹介します。
| 文型 | 動画での表現 |
|---|---|
| 条件文 if + 節, will/would + 動詞 — 条件とその結果 | if you are not you will most |
| 受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる | is not intended · are not intended · are given |
| 現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している | has said · have configured · have unprotected |
| 関係詞節 who / which + 節 — 人や物について情報を加える | people who knew · five, which is · same, which is |
シャドーイングとは？英語上達に効果的な理由
シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。