Shadowing-Übung: OWASP Top 10 Explained - Englisch Sprechen Lernen mit Video
Lektion wird erstellt...
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.
✨ Empfohlenes Video
C13
173 Sätze
STOP Running Code On Your Computer
Business EnglishUniversity StudentsWorking Adults
C11
154 Sätze
Manual Testing: QA Interview Preparation Questions and Answers
Business EnglishInterview EnglishUniversity Students
C11
114 Sätze
Design a File Upload Service Like a Senior Engineer
Business EnglishUniversity StudentsWorking Adults
C130 Sätze
7 Phases of Penetration Testing Explained | Think your system is safe? #cybersecurity #pentesting
Business EnglishUniversity StudentsWorking Adults
C11
207 Sätze
How I Made $30,000 Hacking Broken Access Control
Business EnglishUniversity StudentsWorking Adults
C15
370 Sätze
FullStack Interview Questions (Junior & Mid)
Business EnglishInterview EnglishUniversity Students
C15
94 Sätze
Your AI broke the layout. Now what?
Business EnglishUniversity StudentsWorking Adults
C12
25 Sätze
DNS Explained in 100 Seconds
American AccentBusiness EnglishUniversity StudentsWorking Adults
C11
159 Sätze
Top 5 AI Gateway Use Cases | Solo.io
Business EnglishUniversity StudentsWorking Adults
C11
537 Sätze
Understand Microsoft Entra ID | AZ-104 | Episode 2
Business EnglishUniversity StudentsWorking Adults
C141 Sätze
🚨 Most organizations don't fail ISO/IEC 27001 because they don't understand the standard...
Business EnglishUniversity StudentsWorking Adults
C12
130 Sätze
Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond
Business EnglishUniversity StudentsWorking Adults
Sprachziele für diesen Clip
Dieser Clip hilft dir, deine Englische Aussprache zu verbessern und komplexe Themen wie IT-Sicherheit flüssig zu verstehen. Du übst, technische Begriffe zu verwenden und Sätze mit klarer Struktur zu formen – ideal fürs Englisch lernen mit YouTube.
Phrasenbank
- "dive into" – vertiefen sich in
- "prevent and protect against" – verhindern und schützen vor
- "input field" – Eingabefeld
- "session hijacking" – Sitzungsdiebstahl
- "one-way hash function" – einweg-Hash-Funktion
- "limited attempt of authentication" – begrenzte Authentifizierungsversuche
Verbessere deine Schwächen
Der Clip eignet sich perfekt für Englisch Shadowing (auch "shadow speak" genannt). Achte darauf, die Betonung bei Wörtern wie "injection" (Injektion) oder "vulnerable" (anfällig) zu kopieren – sie fallen oft flach, wenn man sie falsch betont. Übe auch die Rhythmusänderung bei langen Sätzen: Pausiere nach Kommas, um die Bedeutung klar zu halten. Wiederhole Sätze wie "the way that you can prevent this is to check the input" mehrmals, bis du sie flüssig sagen kannst. So verbesserst du nicht nur deine Aussprache, sondern auch dein Verständnis von komplexen Inhalten.
Was ist die Shadowing-Technik?
Shadowing ist eine wissenschaftlich fundierte Sprachlerntechnik, die ursprünglich für die professionelle Dolmetscherausbildung entwickelt und durch den Polyglotten Dr. Alexander Arguelles populär gemacht wurde. Die Methode ist einfach aber wirkungsvoll: Du hörst englisches Audio von Muttersprachlern und wiederholst es sofort laut — wie ein Schatten, der dem Sprecher mit nur 1–2 Sekunden Verzögerung folgt. Anders als passives Hören oder Grammatikübungen zwingt Shadowing dein Gehirn und deine Mundmuskulatur, gleichzeitig echte Sprachmuster zu verarbeiten und zu reproduzieren. Studien zeigen, dass es Aussprachegenauigkeit, Intonation, Rhythmus, verbundene Sprache, Hörverständnis und Sprechflüssigkeit signifikant verbessert — was es zu einer der effektivsten Methoden für die IELTS Speaking-Vorbereitung und reale englische Kommunikation macht.