Shadowing Practice: OWASP Top 10 Explained - Learn English Speaking with Video

בחר מצב תרגול

כל מצב פותח חדר תרגול במסך מלא.

158 משפטים

אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.

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.

הורד אפליקציה

כל מה שאתה צריך כדי לדבר בשטף

הגיית AIציון לכל משפט

תרגול IPAשלוט בכל צליל

אוצר מיליםבנה את מאגר המילים שלך

משחק אוצר מיליםלמד תוך כדי משחק

סרוק QR

Download on theApp Store Get it onGoogle Play

FOR YOU

המלץ על סרטון

173 משפטים

אוצר מילים והערות הגייה לשיעור הזה

שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “OWASP Top 10 Explained”. המילים שחוזרות הכי הרבה: application, user, web, example, input. בסרטון הזה יש 158 משפטים ו-2140 מילים לתרגול Shadowing. הדיבור נמשך 14:56. הדובר שומר על קצב יציב של כ-143 מילים בדקה, קצב נוח לתרגול Shadowing. 86% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.

אוצר מילים מרכזי בסרטון הזה

15 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:

מילה	הגייה	משמעות
password שם עצם	/ˈpæs.wɜɹd/	סִיסְמָה
injection שם עצם	/ɪnˈd͡ʒɛk.ʃən/	זְרִיקָה
byte שם עצם	/baɪt/	בַּיִת
encrypt פועל	/ɪnˈkɹɪpt/	הצפין
hash שם עצם	/ˈhæʃ/	סוּלָּמִית
leak שם עצם	/liːk/	נְזִילָה
authorization שם עצם	/ˌɔːθəɹaɪˈzeɪʃən/	הַסְמָכָה
temper שם עצם	/ˈtɛmpɚ/	מֶזֶג
verification שם עצם	/ˌvɛ.ɹə.fɪˈkeɪ.ʃən/	וידוא
username שם עצם		שם משתמש
token שם עצם	/ˈtoʊkən/	אֲסִימוֹן, זִ׳יטוֹן
module שם עצם	/ˈmɑd͡ʒul/	מוֹדוּל
execute פועל	/ˈɛksɪˌkjuːt/	להוציא להרוג
behave פועל	/bɪˈheɪv/	הִתְנַהֵג
subscribe פועל	/səbˈskɹaɪb/	נִמְנָה

דקדוק בסרטון הזה

המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:

מבנה	בסרטון
משפטי תנאי (Conditional sentences) if + clause, will/would + verb — תנאי ותוצאה שלו	if you are not you will most
סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה	is not intended · are not intended · are given
הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו	has said · have configured · have unprotected
משפטי זיקה (Relative clauses) who / which + clause — מידע נוסף על אדם או דבר	people who knew · five, which is · same, which is

הגייה ששווה לשים לב אליה

הדובר משתמש ב-4 קיצורים וצורות מקוצרות, כמו doesn't, don't, haven't. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.

הצלילים של “th”: authentication /ɔːˌθɛntɪˈkeɪʃn̩/, authorization /ˌɔːθəɹaɪˈzeɪʃən/, thereby /ðɛɹˈbaɪ/
הצלילים של “sh” ו-“zh”: injection /ɪnˈd͡ʒɛk.ʃən/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, validation /ˌvæl.əˈdeɪ.ʃən/, hash /ˈhæʃ/, malicious /məˈlɪʃəs/
מילים ארוכות — שימו לב להטעמה: authentication /ɔːˌθɛntɪˈkeɪʃn̩/, validation /ˌvæl.əˈdeɪ.ʃən/, vulnerability /ˌvʌln(ə)ɹəˈbɪlɪti/, dependency /dɪˈpɛndənsi/, manipulate /məˈnɪp.jʊ.leɪt/

צלילים שדוברי עברית מתקשים בהם:

/w/ — שפתיים מעוגלות, לא /v/: password /ˈpæs.wɜɹd/, anyways /ˈɛn.iˌweɪz/
/æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: password /ˈpæs.wɜɹd/, validation /ˌvæl.əˈdeɪ.ʃən/, admin /ˈædˌmɪn/, attacker /əˈtækɚ/, hash /ˈhæʃ/
/r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: password /ˈpæs.wɜɹd/, vulnerability /ˌvʌln(ə)ɹəˈbɪlɪti/, encrypt /ɪnˈkɹɪpt/, serialize /ˈsɪɹiəlaɪz/, credential /kɹɪˈdɛnʃəl/

איך לתרגל עם הסרטון הזה

הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
תרגלו Shadowing משפט אחר משפט במהירות רגילה, וחזרו על כל משפט עד שהקצב שלכם תואם את הדובר.
הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו password, injection, byte.

מהי טכניקת השאדואינג?

שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.

טכניקת Shadowing: קרא את המדריך המלא שלב אחר שלב →

Shadowing Practice: OWASP Top 10 Explained - Learn English Speaking with Video

בחר מצב תרגול

הורד אפליקציה

STOP Running Code On Your Computer

Design a File Upload Service Like a Senior Engineer

Video

Understand Microsoft Entra ID | AZ-104 | Episode 2

Helpdesk to Sysadmin - 3 Things You Must Learn First

Every Networking Concept Explained In 20 Minutes

Armchair Architects: Resiliency in the Cloud – Core Patterns

🚫 Java Deadlock Explained: Why Your Code is Stuck 😱 (Beginners Must Watch!)

The Anatomy of Fraud

CAP Theorem Simplified

Seven Testing Principles: Software Testing

Use these CSS features instead of JavaScript