diff --git a/.gitattributes b/.gitattributes
index 987542feafbec48754547949896dbb74330823a0..b4119adb784c7a028ca7912251a6cd91666b48bc 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -107,3 +107,14 @@ saved_model/**/* filter=lfs diff=lfs merge=lfs -text
109[[:space:]]-[[:space:]]Advanced[[:space:]]Code[[:space:]]Review[[:space:]]Strategies/002[[:space:]]Coding[[:space:]]Standards,[[:space:]]Code[[:space:]]Quality[[:space:]]&[[:space:]]Consistency.mp4 filter=lfs diff=lfs merge=lfs -text
109[[:space:]]-[[:space:]]Advanced[[:space:]]Code[[:space:]]Review[[:space:]]Strategies/001[[:space:]]Code[[:space:]]Review[[:space:]]Guidelines[[:space:]]&[[:space:]]Contribution[[:space:]]Policy.mp4 filter=lfs diff=lfs merge=lfs -text
108[[:space:]]-[[:space:]]Tools,[[:space:]]Automation,[[:space:]]and[[:space:]]Industry[[:space:]]Best[[:space:]]Practices/004[[:space:]]PMD[[:space:]]Static[[:space:]]Code[[:space:]]Analysis.mp4 filter=lfs diff=lfs merge=lfs -text
+109[[:space:]]-[[:space:]]Advanced[[:space:]]Code[[:space:]]Review[[:space:]]Strategies/004[[:space:]]Security[[:space:]]Considerations[[:space:]]During[[:space:]]Code[[:space:]]Review.mp4 filter=lfs diff=lfs merge=lfs -text
+109[[:space:]]-[[:space:]]Advanced[[:space:]]Code[[:space:]]Review[[:space:]]Strategies/005[[:space:]]Scalability[[:space:]]Principles[[:space:]]in[[:space:]]Code.mp4 filter=lfs diff=lfs merge=lfs -text
+11[[:space:]]-[[:space:]]Enumerations[[:space:]]in[[:space:]]Java/001[[:space:]]Enumerations[[:space:]]in[[:space:]]Java.mp4 filter=lfs diff=lfs merge=lfs -text
+110[[:space:]]-[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs[[:space:]]to[[:space:]]Monitor[[:space:]]and[[:space:]]Control[[:space:]]Software[[:space:]]Development[[:space:]]Process/004[[:space:]]Introduction[[:space:]]to[[:space:]]Engineering[[:space:]]Excellence[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs.mp4 filter=lfs diff=lfs merge=lfs -text
+110[[:space:]]-[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs[[:space:]]to[[:space:]]Monitor[[:space:]]and[[:space:]]Control[[:space:]]Software[[:space:]]Development[[:space:]]Process/002[[:space:]]Metric,[[:space:]]KPI[[:space:]]&[[:space:]]OKR.mp4 filter=lfs diff=lfs merge=lfs -text
+110[[:space:]]-[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs[[:space:]]to[[:space:]]Monitor[[:space:]]and[[:space:]]Control[[:space:]]Software[[:space:]]Development[[:space:]]Process/006[[:space:]]Development[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs[[:space:]]Unit[[:space:]]Test[[:space:]]Related[[:space:]]Metrics[[:space:]]-[[:space:]]Part[[:space:]]1.mp4 filter=lfs diff=lfs merge=lfs -text
+110[[:space:]]-[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs[[:space:]]to[[:space:]]Monitor[[:space:]]and[[:space:]]Control[[:space:]]Software[[:space:]]Development[[:space:]]Process/007[[:space:]]Development[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs[[:space:]]Unit[[:space:]]Test[[:space:]]Related[[:space:]]Metrics[[:space:]]-[[:space:]]Part[[:space:]]2.mp4 filter=lfs diff=lfs merge=lfs -text
+110[[:space:]]-[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs[[:space:]]to[[:space:]]Monitor[[:space:]]and[[:space:]]Control[[:space:]]Software[[:space:]]Development[[:space:]]Process/005[[:space:]]Development[[:space:]]Metrics[[:space:]]&[[:space:]]KPIs[[:space:]]Tech[[:space:]]Debt[[:space:]]Ratio[[:space:]]&[[:space:]]Index,[[:space:]]Cyclomatic[[:space:]]Complexity.mp4 filter=lfs diff=lfs merge=lfs -text
+12[[:space:]]-[[:space:]]Debugging[[:space:]]Tools/001[[:space:]]How[[:space:]]to[[:space:]]debug[[:space:]]Java[[:space:]]programs.mp4 filter=lfs diff=lfs merge=lfs -text
+13[[:space:]]-[[:space:]]Object-oriented[[:space:]]programming/001[[:space:]]Object-oriented[[:space:]]programming[[:space:]]Basics.mp4 filter=lfs diff=lfs merge=lfs -text
+13[[:space:]]-[[:space:]]Object-oriented[[:space:]]programming/002[[:space:]]Classes[[:space:]]&[[:space:]]Objects.mp4 filter=lfs diff=lfs merge=lfs -text
diff --git a/109 - Advanced Code Review Strategies/004 Security Considerations During Code Review.mp4 b/109 - Advanced Code Review Strategies/004 Security Considerations During Code Review.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..232cafd543f28051e2c54ad239aa77b317b65520
--- /dev/null
+++ b/109 - Advanced Code Review Strategies/004 Security Considerations During Code Review.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:1395d97c8b17d74e474b0f69608b76c6bdde4e4a7249b528c8a801af9f189339
+size 204990071
diff --git a/109 - Advanced Code Review Strategies/005 Scalability Principles in Code.mp4 b/109 - Advanced Code Review Strategies/005 Scalability Principles in Code.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..67b85a6efdb26cc92429476917244f2a45472acf
--- /dev/null
+++ b/109 - Advanced Code Review Strategies/005 Scalability Principles in Code.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:9a773d29b7eabd7c4715bbd28115d31c25f780a08b89ceba35a6b57812d6f35b
+size 149827717
diff --git a/11 - Enumerations in Java/001 Enumerations in Java.mp4 b/11 - Enumerations in Java/001 Enumerations in Java.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..facc029543fd7c080020d694a7472e793df22a1f
--- /dev/null
+++ b/11 - Enumerations in Java/001 Enumerations in Java.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:ded596a4e93149eaae3e58f4348c8e4a1972b8a272d80cce1fd52f76a926706a
+size 92441087
diff --git a/110 - Metrics & KPIs to Monitor and Control Software Development Process/002 Metric, KPI & OKR.mp4 b/110 - Metrics & KPIs to Monitor and Control Software Development Process/002 Metric, KPI & OKR.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..c7656710b2c55d35d9ae08f7a7e2669d266cd02f
--- /dev/null
+++ b/110 - Metrics & KPIs to Monitor and Control Software Development Process/002 Metric, KPI & OKR.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:d75c226d3abece339b553f04d41fef8d08936eee2a186129d6c26c4c0c43bd5d
+size 217538834
diff --git a/110 - Metrics & KPIs to Monitor and Control Software Development Process/004 Introduction to Engineering Excellence Metrics & KPIs.mp4 b/110 - Metrics & KPIs to Monitor and Control Software Development Process/004 Introduction to Engineering Excellence Metrics & KPIs.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..d5c765ef2ae7cc0b00b83fdf81f35805761f7964
--- /dev/null
+++ b/110 - Metrics & KPIs to Monitor and Control Software Development Process/004 Introduction to Engineering Excellence Metrics & KPIs.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:93cf203483fbace1d96d7c3403181e6113af0d38d0acdd57584d060d951eb91c
+size 68969165
diff --git a/110 - Metrics & KPIs to Monitor and Control Software Development Process/005 Development Metrics & KPIs Tech Debt Ratio & Index, Cyclomatic Complexity.mp4 b/110 - Metrics & KPIs to Monitor and Control Software Development Process/005 Development Metrics & KPIs Tech Debt Ratio & Index, Cyclomatic Complexity.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..45f2a50b22ff24d9782de1ac98675ff8c156fdee
--- /dev/null
+++ b/110 - Metrics & KPIs to Monitor and Control Software Development Process/005 Development Metrics & KPIs Tech Debt Ratio & Index, Cyclomatic Complexity.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:c85f6c70536ca981a9e1c1f3a892012f89b6ccb6a0c6b1813bc9c4239955670f
+size 335144349
diff --git a/110 - Metrics & KPIs to Monitor and Control Software Development Process/006 Development Metrics & KPIs Unit Test Related Metrics - Part 1.mp4 b/110 - Metrics & KPIs to Monitor and Control Software Development Process/006 Development Metrics & KPIs Unit Test Related Metrics - Part 1.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..5057033ca64900f6856420d4b76cf59c938d8d52
--- /dev/null
+++ b/110 - Metrics & KPIs to Monitor and Control Software Development Process/006 Development Metrics & KPIs Unit Test Related Metrics - Part 1.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:c8a7d9d3ac0c40039c5ea8de30031bde94387e23c9a4023f330bec3455b91fa8
+size 166941102
diff --git a/110 - Metrics & KPIs to Monitor and Control Software Development Process/007 Development Metrics & KPIs Unit Test Related Metrics - Part 2.mp4 b/110 - Metrics & KPIs to Monitor and Control Software Development Process/007 Development Metrics & KPIs Unit Test Related Metrics - Part 2.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..b98ebc59a419bd103e26fecb173e7f42ccdc5a2b
--- /dev/null
+++ b/110 - Metrics & KPIs to Monitor and Control Software Development Process/007 Development Metrics & KPIs Unit Test Related Metrics - Part 2.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:e840856f190580a727976c427b49d52e4d93aa1092f0fb9eaae7402cd0922607
+size 227066733
diff --git a/12 - Debugging Tools/001 How to debug Java programs.mp4 b/12 - Debugging Tools/001 How to debug Java programs.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..2c94de8aabd3c89deaa71238bf5b31b039374272
--- /dev/null
+++ b/12 - Debugging Tools/001 How to debug Java programs.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:6c17883f1dbd29848226eea576673cc06f4cbff06679f7558340aef04dd11573
+size 52286173
diff --git a/13 - Object-oriented programming/001 Object-oriented programming Basics.mp4 b/13 - Object-oriented programming/001 Object-oriented programming Basics.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..a4a499bd4fbf99f1e927af6b5f9446197cdc15fc
--- /dev/null
+++ b/13 - Object-oriented programming/001 Object-oriented programming Basics.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:859f25602b687c973e436a1e186e0514c676306d6a45eafc31a107b8a6a92668
+size 242868552
diff --git a/13 - Object-oriented programming/002 Classes & Objects.mp4 b/13 - Object-oriented programming/002 Classes & Objects.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..0caf3d30a25ab088bc3cf02c2a72bee81a45f4cf
--- /dev/null
+++ b/13 - Object-oriented programming/002 Classes & Objects.mp4
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:afccd5cad8b66da6f293df189c7a29e99903103e2f2e830d69390c73b5825625
+size 285900932
diff --git a/73 - OWASP Top 10 2021/005 Cryptography Failures (Examples, Password Encryption, Hashing, Salting)_en.srt b/73 - OWASP Top 10 2021/005 Cryptography Failures (Examples, Password Encryption, Hashing, Salting)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..56f9bc1fa79b764956cc711bcf6a8a51074c82ae
--- /dev/null
+++ b/73 - OWASP Top 10 2021/005 Cryptography Failures (Examples, Password Encryption, Hashing, Salting)_en.srt
@@ -0,0 +1,852 @@
+1
+00:00:02,000 --> 00:00:09,000
+Scenario number three, in case passwords are stored in the database, not encrypted, and somebody
+
+2
+00:00:09,000 --> 00:00:13,000
+stole your database, they can access users accounts.
+
+3
+00:00:14,000 --> 00:00:20,000
+And even in case you use simple hashes or salted passwords, they can be hacked.
+
+4
+00:00:21,000 --> 00:00:26,000
+Also insulted how this can be exposed was a rainbow table of three calculated hashes.
+
+5
+00:00:27,000 --> 00:00:35,000
+Hashes generated by a single or fourth hash function may be cracked by GPUs, even if they were salted.
+
+6
+00:00:35,000 --> 00:00:38,000
+Probably it is a lot of new chance.
+
+7
+00:00:38,000 --> 00:00:40,000
+Let me explain each of these.
+
+8
+00:00:41,000 --> 00:00:43,000
+I mentioned some hashes and passwords.
+
+9
+00:00:43,000 --> 00:00:44,000
+What are they?
+
+10
+00:00:45,000 --> 00:00:52,000
+When the password has been hashed, it means it has been turned into a scrambled representation of itself.
+
+11
+00:00:53,000 --> 00:00:55,000
+A user's password, the staking and the using.
+
+12
+00:00:55,000 --> 00:00:57,000
+The key known to the site.
+
+13
+00:00:57,000 --> 00:01:03,000
+The hash value is derived from the combination of both the password and the key.
+
+14
+00:01:04,000 --> 00:01:08,000
+Using a set algorithm to verify users passwords is correct.
+
+15
+00:01:08,000 --> 00:01:14,000
+It is hashed and the value compat was stored on the records each time.
+
+16
+00:01:14,000 --> 00:01:15,000
+Zero again.
+
+17
+00:01:16,000 --> 00:01:18,000
+What is salted and unsealed as passwords?
+
+18
+00:01:19,000 --> 00:01:23,000
+Passwords are often described as hashed and salt.
+
+19
+00:01:23,000 --> 00:01:31,000
+Salted is simple as addition of a new random string of characters known only as a side to each password
+
+20
+00:01:31,000 --> 00:01:33,000
+before it is hashed.
+
+21
+00:01:33,000 --> 00:01:37,000
+Typically this solve is placed in front of each password.
+
+22
+00:01:38,000 --> 00:01:45,000
+The salt value needs to be stored by the side, which means sometimes sites use the same.
+
+23
+00:01:45,000 --> 00:01:52,000
+So for every password this makes it less effective than individual souls used.
+
+24
+00:01:53,000 --> 00:02:01,000
+The use of unique salts means is a common passwords shared by multiple users such as 123456.
+
+25
+00:02:01,000 --> 00:02:10,000
+Password words are not immediately revealed when one such hashed password is identified because despite
+
+26
+00:02:10,000 --> 00:02:15,000
+the passwords B and C, the salt and hash values are not.
+
+27
+00:02:16,000 --> 00:02:24,000
+Large salts also protect against certain masses of attack on hashes, including the rainbow tables,
+
+28
+00:02:24,000 --> 00:02:26,000
+logs or hashed passwords posted broken.
+
+29
+00:02:27,000 --> 00:02:34,000
+Both Hashem and Sultan can be repeated more than once to increase the difficulty in breaking the security.
+
+30
+00:02:35,000 --> 00:02:37,000
+I also mentioned a rainbow table.
+
+31
+00:02:37,000 --> 00:02:45,000
+What is a rainbow table is a computer table for cache and the output of cryptographic hash functions,
+
+32
+00:02:45,000 --> 00:02:47,000
+usually for cracking passwords.
+
+33
+00:02:47,000 --> 00:02:48,000
+Hashes.
+
+34
+00:02:48,000 --> 00:02:52,000
+A rainbow table attack is a password cracking massive.
+
+35
+00:02:52,000 --> 00:02:58,000
+It uses a special table, a rainbow table to correct passwords hashes in a database.
+
+36
+00:02:59,000 --> 00:03:03,000
+The rainbow table itself refers to a computer tables it contains.
+
+37
+00:03:03,000 --> 00:03:10,000
+Is it possible hash value for each plaintext character used during the authentication process?
+
+38
+00:03:10,000 --> 00:03:17,000
+If hackers gain access to the list of passwords hashes, they can track all passwords very quickly.
+
+39
+00:03:17,000 --> 00:03:24,000
+With the rainbow table, the prevalence of rainbow table attacks has dramatically decreased due to a
+
+40
+00:03:24,000 --> 00:03:32,000
+technique known as salting salt and is a modern technique used to thwart a rainbow table attacks.
+
+41
+00:03:33,000 --> 00:03:39,000
+It involves adding an extra random value to every hash password to create a decent hash value.
+
+42
+00:03:40,000 --> 00:03:47,000
+Most modern password syndication systems include salting, which has significantly less and is the number
+
+43
+00:03:47,000 --> 00:03:50,000
+of successful rainbow table attacks.
+
+44
+00:03:51,000 --> 00:03:54,000
+Let's learn more about passion and hashing algorithms.
+
+45
+00:03:55,000 --> 00:04:02,000
+Passion is a process of generating a string or hash from a given message using a massive, magical function
+
+46
+00:04:02,000 --> 00:04:05,000
+known as cryptographic hash function.
+
+47
+00:04:05,000 --> 00:04:10,000
+We can say it's possible to hash and functions should be slow, but not fast.
+
+48
+00:04:11,000 --> 00:04:11,000
+Why?
+
+49
+00:04:12,000 --> 00:04:13,000
+What does this mean?
+
+50
+00:04:13,000 --> 00:04:21,000
+A fast algorithm would aid brute force attacks in which a heart will attempt to guess a password by
+
+51
+00:04:21,000 --> 00:04:26,000
+hashing and comparing billions or trillions of potential passwords per second.
+
+52
+00:04:27,000 --> 00:04:35,000
+There are different hashing algorithms among them, and the five secure hash algorithms is a shuttle
+
+53
+00:04:35,000 --> 00:04:42,000
+name is abbreviation s H, a PPK, the F to Bitcoin and Asquith.
+
+54
+00:04:42,000 --> 00:04:48,000
+Nowadays, it is not recommended to use such hashing algorithms as MD5, says Shay.
+
+55
+00:04:49,000 --> 00:04:54,000
+Even despite the recent opinions of SC chambers, random salt can be a good way to go.
+
+56
+00:04:55,000 --> 00:05:00,000
+I don't recommend you to use this hashing algorithm nowadays.
+
+57
+00:05:00,000 --> 00:05:04,000
+It is actually possible to artificially produce 75 collisions.
+
+58
+00:05:04,000 --> 00:05:06,000
+All you need is time.
+
+59
+00:05:06,000 --> 00:05:08,000
+Hardware and software.
+
+60
+00:05:09,000 --> 00:05:12,000
+That's why AMG five is not recommended to use.
+
+61
+00:05:13,000 --> 00:05:20,000
+A good fish algorithm makes it impossible to reverse the hash value to compute the regional tax.
+
+62
+00:05:21,000 --> 00:05:27,000
+However, customers are very, very sharp by making a guess at the password.
+
+63
+00:05:27,000 --> 00:05:37,000
+The attacker can compare the output of his SLK 256 against the SHC 256 that he finds in the database.
+
+64
+00:05:38,000 --> 00:05:44,000
+And because passwords are so sure, there's too many password guesses, this way is easy for a computer.
+
+65
+00:05:45,000 --> 00:05:53,000
+For a few thousand dollars, you can build a small supercomputer dedicated to SC 56, tested similar
+
+66
+00:05:53,000 --> 00:06:00,000
+to those used for Bitcoin mining, which enables an attacker to test 16 trillion different password
+
+67
+00:06:00,000 --> 00:06:02,000
+gases per second.
+
+68
+00:06:03,000 --> 00:06:07,000
+That is much more effective than trying to break SGI 256.
+
+69
+00:06:08,000 --> 00:06:15,000
+That's why it's a question of which is also not the best option because a slower hash, an algorithm
+
+70
+00:06:15,000 --> 00:06:25,000
+exists nowadays some great hash functions is it is recommended to use nowadays are able to decrypt s
+
+71
+00:06:25,000 --> 00:06:35,000
+crypto using standard JDK tools looking implementation will speed up to algorithm to implement A and
+
+72
+00:06:35,000 --> 00:06:39,000
+ask you to use some external libraries for custom implementations.
+
+73
+00:06:40,000 --> 00:06:41,000
+Let me show you examples.
+
+74
+00:06:41,000 --> 00:06:48,000
+Possible fashion consultant and I'm going to do your homework to improve our online source solution.
+
+75
+00:06:48,000 --> 00:06:54,000
+With encryption of passwords, we need to improve our solution because still today with stores, passwords
+
+76
+00:06:54,000 --> 00:06:57,000
+is a database plaintext.
+
+77
+00:06:57,000 --> 00:07:03,000
+I know this is not good, but we were very busy with maintenance of other things in our online store.
+
+78
+00:07:04,000 --> 00:07:08,000
+Now it is time to make this improvement to secure our application.
+
+79
+00:07:09,000 --> 00:07:15,000
+So let me show you examples and you and your homework will integrate these examples into our online
+
+80
+00:07:15,000 --> 00:07:16,000
+store.
+
+81
+00:07:16,000 --> 00:07:20,000
+Basically, we need to implement two key functions.
+
+82
+00:07:20,000 --> 00:07:26,000
+One function is to encrypt customer, and another function is to check with a password to match to the
+
+83
+00:07:26,000 --> 00:07:28,000
+one stored in the database.
+
+84
+00:07:28,000 --> 00:07:35,000
+Why imagine scenario where the user creates new account in the system and he sends a password for his
+
+85
+00:07:35,000 --> 00:07:42,000
+account before storing passwords is a database when you can create it and the next user flow is the
+
+86
+00:07:42,000 --> 00:07:43,000
+user log in.
+
+87
+00:07:44,000 --> 00:07:51,000
+When the user tries to log in, we extract, we created the password comes into base and we compare
+
+88
+00:07:51,000 --> 00:07:51,000
+passwords.
+
+89
+00:07:51,000 --> 00:07:58,000
+It's user submitted through the for and in the case we can claim that password submitted so the form
+
+90
+00:07:58,000 --> 00:08:03,000
+matches was encrypted one only after that we can log into the user.
+
+91
+00:08:04,000 --> 00:08:15,000
+I open source code of the F two was a charm acc21 demo the key masses here generate password with salt
+
+92
+00:08:15,000 --> 00:08:18,000
+and hash and validate the password key.
+
+93
+00:08:18,000 --> 00:08:20,000
+You can see that I have simple password.
+
+94
+00:08:21,000 --> 00:08:25,000
+I pass it as it generates password message and I should receive values.
+
+95
+00:08:25,000 --> 00:08:30,000
+It is going to be stored in the database after that, when it will be needed.
+
+96
+00:08:30,000 --> 00:08:36,000
+I extract the user from the database and his password and I pass passwords and reads it to the logging
+
+97
+00:08:36,000 --> 00:08:41,000
+form and users password from the database doesn't validate the password.
+
+98
+00:08:41,000 --> 00:08:42,000
+Massive.
+
+99
+00:08:42,000 --> 00:08:49,000
+In this particular example, in the first case I am going to receive true because the password provided
+
+100
+00:08:49,000 --> 00:08:51,000
+is matched with its encrypted version.
+
+101
+00:08:52,000 --> 00:08:58,000
+In the second example, I submit another password which shouldn't march also encrypted version of original
+
+102
+00:08:58,000 --> 00:09:02,000
+password, thus false will be returned.
+
+103
+00:09:02,000 --> 00:09:10,000
+Let me run this program to confirm my statements and so you can see confirmation of what I have just
+
+104
+00:09:10,000 --> 00:09:10,000
+said.
+
+105
+00:09:11,000 --> 00:09:16,000
+I'm going to share with you the source code and I encourage you to review after the lesson.
+
+106
+00:09:16,000 --> 00:09:17,000
+Sorry.
+
+107
+00:09:17,000 --> 00:09:19,000
+So understand how it works.
+
+108
+00:09:19,000 --> 00:09:22,000
+I will just briefly highlight the key points here.
+
+109
+00:09:23,000 --> 00:09:27,000
+I use PBT key spec class instance to create.
+
+110
+00:09:27,000 --> 00:09:30,000
+I cross Charlie off my password string.
+
+111
+00:09:31,000 --> 00:09:33,000
+The next course here is solved.
+
+112
+00:09:34,000 --> 00:09:38,000
+As you can see for generating salt, we have separate mice.
+
+113
+00:09:38,000 --> 00:09:44,000
+Feel free to explore two iterations is a strengths parameter.
+
+114
+00:09:44,000 --> 00:09:51,000
+It indicates how many iterations is this algorithm run for increases the time it takes to produce the
+
+115
+00:09:51,000 --> 00:09:55,000
+hash, and the last target on the set is the length of the hash.
+
+116
+00:09:56,000 --> 00:10:02,000
+My password consists of combination of iteration, salt and hash separated by columns.
+
+117
+00:10:03,000 --> 00:10:08,000
+Lines is I use this suffix when I validate my password.
+
+118
+00:10:08,000 --> 00:10:11,000
+And again, this is not the easiest thing.
+
+119
+00:10:11,000 --> 00:10:13,000
+So spend your time.
+
+120
+00:10:13,000 --> 00:10:14,000
+Understand these lines of code.
+
+121
+00:10:15,000 --> 00:10:17,000
+Before implementing your home task.
+
+122
+00:10:18,000 --> 00:10:24,000
+There is a similar example was quip, but as I said, there is no out of the books of course for be
+
+123
+00:10:25,000 --> 00:10:26,000
+the queue.
+
+124
+00:10:26,000 --> 00:10:32,000
+That's why I prepared for you custom implementations that you are welcome to use for that purposes.
+
+125
+00:10:33,000 --> 00:10:40,000
+The report file contains all necessary information on decryption and in the script Gamma, you can find
+
+126
+00:10:40,000 --> 00:10:42,000
+example of usage.
+
+127
+00:10:42,000 --> 00:10:45,000
+Now you have a lot of interest in use of ensembles.
+
+128
+00:10:46,000 --> 00:10:49,000
+Let me repeat one more time where we need to integrate.
+
+129
+00:10:49,000 --> 00:10:54,000
+This encryption should happen before inserting user into the database.
+
+130
+00:10:55,000 --> 00:11:02,000
+I would put it in the same up so that here one with said password to user object and also we need to
+
+131
+00:11:02,000 --> 00:11:06,000
+make changes inside these so where we verify password.
+
+132
+00:11:07,000 --> 00:11:09,000
+And one more place to adjust.
+
+133
+00:11:09,000 --> 00:11:16,000
+You're going to have a homework to implement, edit page user profile and the need to confirm password
+
+134
+00:11:16,000 --> 00:11:18,000
+when updating user info.
+
+135
+00:11:18,000 --> 00:11:22,000
+So we also need to update added profiles.
+
+136
+00:11:22,000 --> 00:11:24,000
+So this is just a hint.
+
+137
+00:11:24,000 --> 00:11:30,000
+Don't worry, I'm going to share with you my solution too, and you will be able to double check yourself.
+
+138
+00:11:31,000 --> 00:11:34,000
+That's all regarding the most common attacks and error.
+
+139
+00:11:34,000 --> 00:11:42,000
+Let's come to you will resume review of some cases related to encryption of data database and establish
+
+140
+00:11:42,000 --> 00:11:48,000
+and secure its connection and also improvements that can help us to make our solution more robust and
+
+141
+00:11:48,000 --> 00:11:49,000
+secure.
+
+142
+00:11:50,000 --> 00:11:55,000
+But still, there are some general rules that may help you to prevent the cryptographic failures in
+
+143
+00:11:55,000 --> 00:11:55,000
+the future.
+
+144
+00:11:56,000 --> 00:12:00,000
+Let's review the most common rules and recommendations you have to follow.
+
+145
+00:12:00,000 --> 00:12:04,000
+What is related to cryptographic failures?
+
+146
+00:12:04,000 --> 00:12:10,000
+Classified data, processed, stored or transmitted by an application?
+
+147
+00:12:10,000 --> 00:12:18,000
+Identify which data is sensitive according to privacy laws, regulatory requirements or business needs
+
+148
+00:12:18,000 --> 00:12:22,000
+to do with it earns what can be considered as a sensitive data.
+
+149
+00:12:22,000 --> 00:12:28,000
+We also discuss the types of sensitive data when we review sensitive data examples.
+
+150
+00:12:29,000 --> 00:12:32,000
+Another is pretty simple one, but really important.
+
+151
+00:12:33,000 --> 00:12:36,000
+Don't store sensitive data unnecessarily.
+
+152
+00:12:36,000 --> 00:12:41,000
+Data that is not retained can't be stolen is not see.
+
+153
+00:12:42,000 --> 00:12:42,000
+So.
+
+154
+00:12:43,000 --> 00:12:46,000
+So as you understand that you don't need some data for it.
+
+155
+00:12:47,000 --> 00:12:49,000
+Just discard it as soon as possible.
+
+156
+00:12:50,000 --> 00:12:53,000
+Make sure to encrypt all sensitive data that they use.
+
+157
+00:12:53,000 --> 00:12:57,000
+And so that's and we also learn how to encrypt password.
+
+158
+00:12:57,000 --> 00:13:06,000
+One of this store passwords uses strong adaptive and salted hash and functions with a factor unique
+
+159
+00:13:06,000 --> 00:13:13,000
+factor such as are going to ascribe bakery or PB CDF to.
+
+160
+00:13:13,000 --> 00:13:20,000
+Basically, this is something we reviewed today and this encryption technique may be applied not only
+
+161
+00:13:20,000 --> 00:13:21,000
+to passwords.
+
+162
+00:13:21,000 --> 00:13:32,000
+I would deprecated cryptographic functions and part schemes such as modify as a assess risks to ensure
+
+163
+00:13:32,000 --> 00:13:33,000
+they can protect data.
+
+164
+00:13:33,000 --> 00:13:41,000
+Organisations need to know what risks this stored data might face and allocates budgets and the resources
+
+165
+00:13:41,000 --> 00:13:43,000
+to mitigate these risks accordingly.
+
+166
+00:13:44,000 --> 00:13:52,000
+The more valuable data is, the higher the chances that it's not going to harm even the smallest amounts
+
+167
+00:13:52,000 --> 00:13:57,000
+of sensitive data that can have tremendous consequences for the data subjects.
+
+168
+00:13:58,000 --> 00:14:05,000
+Ensure appropriate security to make sure they are able to avoid the cryptographic failure and limited
+
+169
+00:14:05,000 --> 00:14:08,000
+impact that it might have on the associated data subjects.
+
+170
+00:14:08,000 --> 00:14:12,000
+Organisations have to install sufficient security controls.
+
+171
+00:14:13,000 --> 00:14:21,000
+Employ high level security software equipped with a robust software that covers malware and viruses.
+
+172
+00:14:21,000 --> 00:14:27,000
+You should be able to stand strong against most threats, including data exposure.
+
+173
+00:14:28,000 --> 00:14:34,000
+Though sizable organizations are more likely to fall victim to sensitive data exposure, individuals
+
+174
+00:14:34,000 --> 00:14:36,000
+can be vulnerable to them too.
+
+175
+00:14:37,000 --> 00:14:42,000
+Thus, we need also to apply some security measures to secure individual accounts.
+
+176
+00:14:43,000 --> 00:14:50,000
+Make sure that each online account you manage includes a unique and complex enough password that someone
+
+177
+00:14:50,000 --> 00:14:51,000
+would be using now.
+
+178
+00:14:51,000 --> 00:14:52,000
+Application.
+
+179
+00:14:52,000 --> 00:14:57,000
+Let me show you the registration when I want to create a new account.
+
+180
+00:14:58,000 --> 00:15:05,000
+I have a series of checks to make sure that my password is secure and that I can't use a password.
+
+181
+00:15:05,000 --> 00:15:11,000
+Is it as short as an eight characters and I can't use password without at least one special character
+
+182
+00:15:11,000 --> 00:15:12,000
+in it?
+
+183
+00:15:13,000 --> 00:15:14,000
+Let me in the open sign up.
+
+184
+00:15:14,000 --> 00:15:20,000
+So here you can see that I set multiple checks for you and you can mail at the beginning.
+
+185
+00:15:21,000 --> 00:15:23,000
+And after that we have verification of password.
+
+186
+00:15:24,000 --> 00:15:28,000
+For this I implemented password to validate and action.
+
+187
+00:15:28,000 --> 00:15:31,000
+Here you can find some massive is it performs.
+
+188
+00:15:31,000 --> 00:15:38,000
+Is it possible for the nation this will help you to avoid using the standard password for user accounts
+
+189
+00:15:38,000 --> 00:15:46,000
+and this will help you to secure their accounts because there are a lot of open in the internet containing
+
+190
+00:15:46,000 --> 00:15:51,000
+the most common passwords and attackers can try to use them with brute force approach.
+
+191
+00:15:52,000 --> 00:15:52,000
+Basically.
+
+192
+00:15:53,000 --> 00:15:55,000
+That's all what I wanted to share with you in this lesson.
+
+193
+00:15:56,000 --> 00:15:59,000
+It was long, but I am sure a very efficient lesson.
+
+194
+00:16:00,000 --> 00:16:08,000
+Let's recap what we have learned in this lesson we learned were cryptographic failures are also reviewed
+
+195
+00:16:08,000 --> 00:16:10,000
+the most common causes.
+
+196
+00:16:10,000 --> 00:16:17,000
+We compare its cryptographic failures and sensitive data exposures basically as we discussed.
+
+197
+00:16:17,000 --> 00:16:21,000
+This is the same category, but with different names in all of us.
+
+198
+00:16:21,000 --> 00:16:26,000
+Top ten, 2017 and the Top ten 2021.
+
+199
+00:16:26,000 --> 00:16:31,000
+We now have different types of graphics silos also.
+
+200
+00:16:31,000 --> 00:16:38,000
+We discussed what is the difference between personal data and sensitive data on real examples of the
+
+201
+00:16:38,000 --> 00:16:46,000
+most common attack scenarios we learned SQL Injection Kill US and SSL ETPs.
+
+202
+00:16:46,000 --> 00:16:51,000
+Now you know the difference between should be an issue to be asked protocol.
+
+203
+00:16:51,000 --> 00:16:54,000
+We also configure the Aces appears on Tomcat Web server.
+
+204
+00:16:55,000 --> 00:16:57,000
+We learned passwords, encryption.
+
+205
+00:16:58,000 --> 00:16:59,000
+Now you know what's passwords?
+
+206
+00:16:59,000 --> 00:17:01,000
+Hashing and passwords, salt and things.
+
+207
+00:17:02,000 --> 00:17:10,000
+We discussed different hashing algorithms and device SDK P became the effort to decrypt and the past
+
+208
+00:17:10,000 --> 00:17:16,000
+script and after this lesson you have multiple source code examples that can help you to understand
+
+209
+00:17:16,000 --> 00:17:23,000
+the topic better and the examples of lessons we also learned general rules and recommendations that
+
+210
+00:17:23,000 --> 00:17:26,000
+can help us to prevent cryptographic failures.
+
+211
+00:17:27,000 --> 00:17:28,000
+That's all for this lesson.
+
+212
+00:17:29,000 --> 00:17:30,000
+Thanks a lot for your attention.
+
+213
+00:17:30,000 --> 00:17:33,000
+Have a great day and see you in the next lesson.
+
diff --git a/73 - OWASP Top 10 2021/006 Injection (Overview, Fuzzing, CWEs, Impact, Injection Types, Command Injection)_en.srt b/73 - OWASP Top 10 2021/006 Injection (Overview, Fuzzing, CWEs, Impact, Injection Types, Command Injection)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..4e9518a6902b3e926075fb6dfe9b72fca7ab6372
--- /dev/null
+++ b/73 - OWASP Top 10 2021/006 Injection (Overview, Fuzzing, CWEs, Impact, Injection Types, Command Injection)_en.srt
@@ -0,0 +1,788 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello.
+
+2
+00:00:06,000 --> 00:00:06,000
+Yes.
+
+3
+00:00:07,000 --> 00:00:10,000
+In this lesson, we're going to learn the following risk category.
+
+4
+00:00:10,000 --> 00:00:12,000
+This is called injection.
+
+5
+00:00:12,000 --> 00:00:17,000
+We're going to start this lesson from the general overview of injection waste category.
+
+6
+00:00:17,000 --> 00:00:24,000
+I will also share with you not a common weakness enumerations that are associated with this risk category.
+
+7
+00:00:25,000 --> 00:00:31,000
+To help you understand why injection risk category is important, we will discuss potential impacts
+
+8
+00:00:32,000 --> 00:00:34,000
+that may be caused by vulnerabilities problems.
+
+9
+00:00:34,000 --> 00:00:43,000
+This risk category will compare risk category from our last top ten 2021 was top ten 2017.
+
+10
+00:00:43,000 --> 00:00:49,000
+After that, we're going to start a review of different types of injections, namely, we're going to
+
+11
+00:00:49,000 --> 00:00:54,000
+talk about common injection, cross-site scripting, and it's different types.
+
+12
+00:00:54,000 --> 00:01:03,000
+SQL injection injection, no SQL injection, simple pass injection and block injection.
+
+13
+00:01:03,000 --> 00:01:05,000
+We're going to have a lot of examples.
+
+14
+00:01:06,000 --> 00:01:10,000
+I will share with you how to prevent each specific type of injection.
+
+15
+00:01:10,000 --> 00:01:16,000
+And as and those are some we're going to summarize the common rules and guidelines that is recommended
+
+16
+00:01:16,000 --> 00:01:24,000
+to follow to prevent injection vulnerabilities and also will input validation goals and different input
+
+17
+00:01:24,000 --> 00:01:25,000
+validation strategies.
+
+18
+00:01:26,000 --> 00:01:27,000
+Let's start our lesson.
+
+19
+00:01:28,000 --> 00:01:35,000
+Injections are one of the most common vulnerabilities in applications, depending on what environment
+
+20
+00:01:35,000 --> 00:01:36,000
+and the utilities you use.
+
+21
+00:01:37,000 --> 00:01:39,000
+That can be a variety of injection flaws.
+
+22
+00:01:40,000 --> 00:01:45,000
+Among these types, common injection is one of the most dangerous.
+
+23
+00:01:45,000 --> 00:01:49,000
+Some of the most common injections are sequel no.
+
+24
+00:01:49,000 --> 00:01:57,000
+Sequel, operating system, common objects, relational mapping or forum l dub and expression, language
+
+25
+00:01:57,000 --> 00:02:00,000
+or object graph navigation library injection.
+
+26
+00:02:01,000 --> 00:02:06,000
+The concept is identical among all interpreter's source code reviews.
+
+27
+00:02:06,000 --> 00:02:15,000
+The best massive of detecting applications are vulnerable to injections, automated testing of all parameters
+
+28
+00:02:15,000 --> 00:02:18,000
+headers euro cookies jigsaw.
+
+29
+00:02:18,000 --> 00:02:22,000
+So an excellent data input is strongly encouraged.
+
+30
+00:02:23,000 --> 00:02:30,000
+Organizations can include static, dynamic and interactive application security testing those in the
+
+31
+00:02:30,000 --> 00:02:36,000
+CIC pipeline to identify introduce injection flaws before production deployment.
+
+32
+00:02:37,000 --> 00:02:45,000
+An application is vulnerable to attack when user supplied data is not part of the filter or sanitized
+
+33
+00:02:45,000 --> 00:02:46,000
+by the application.
+
+34
+00:02:47,000 --> 00:02:53,000
+Dynamic queries on non parameterized calls without context over escape and are used directly in the
+
+35
+00:02:53,000 --> 00:02:54,000
+interpreter.
+
+36
+00:02:55,000 --> 00:02:58,000
+Hostile data is used within an object.
+
+37
+00:02:58,000 --> 00:03:07,000
+Relational mapping from such parameters to extract additional sensitive rack or hostile data is directly
+
+38
+00:03:07,000 --> 00:03:08,000
+used or concatenated.
+
+39
+00:03:09,000 --> 00:03:16,000
+This equal or common contains distraction and malicious data in dynamic queries, come ons or stored
+
+40
+00:03:16,000 --> 00:03:17,000
+procedures.
+
+41
+00:03:17,000 --> 00:03:22,000
+Injection flaws are very prevalent, particularly in legacy code.
+
+42
+00:03:23,000 --> 00:03:29,000
+Injection vulnerabilities are often found in sequel s pass on those sequel queries.
+
+43
+00:03:29,000 --> 00:03:37,000
+Operating system commands, x amount passes, SMTP gathers expression, languages and forum queries.
+
+44
+00:03:38,000 --> 00:03:46,000
+Injection flows easy to discover Excel money code scanners and those can help attackers find injection
+
+45
+00:03:46,000 --> 00:03:46,000
+flows.
+
+46
+00:03:47,000 --> 00:03:55,000
+What forces are opposed is a program which injects automatically some random data into programs that
+
+47
+00:03:55,000 --> 00:03:57,000
+detect box.
+
+48
+00:03:57,000 --> 00:04:06,000
+The data generation path is made of generators and the ability ID relies on the blogging tools in programming
+
+49
+00:04:06,000 --> 00:04:07,000
+and software development.
+
+50
+00:04:08,000 --> 00:04:16,000
+OSI Foster is an automated software testing technique that involves providing invalid, unexpected or
+
+51
+00:04:16,000 --> 00:04:19,000
+random data as equals to a computer program.
+
+52
+00:04:20,000 --> 00:04:27,000
+Almost any source of data can be an injection vector environment variables, parameters, external and
+
+53
+00:04:27,000 --> 00:04:30,000
+internal web services and all types of users.
+
+54
+00:04:31,000 --> 00:04:37,000
+Injection flows at zero one in that target can send hostile data to an interpreter.
+
+55
+00:04:37,000 --> 00:04:49,000
+Multiple common weakness enumerations included CW E 79 Cross-Site Scripting, CW 89 SQL Injection and
+
+56
+00:04:49,000 --> 00:04:54,000
+CW 73 External control of file name of POS.
+
+57
+00:04:55,000 --> 00:05:01,000
+Why is this lasting is important and why we should know about injection and be very attentive while
+
+58
+00:05:01,000 --> 00:05:03,000
+creating our software.
+
+59
+00:05:03,000 --> 00:05:08,000
+Let's learn what the potential impact can be done by different types of injections.
+
+60
+00:05:09,000 --> 00:05:15,000
+The injection can result in data loss, corruption or disclosure to unauthorized parties.
+
+61
+00:05:16,000 --> 00:05:23,000
+A loss of accountability or denial of access injection can sometimes make the company post takeover.
+
+62
+00:05:24,000 --> 00:05:28,000
+The business impact depends on the needs of the application and data.
+
+63
+00:05:29,000 --> 00:05:36,000
+The impact of command injection can range from stealing data, changing system configurations or even
+
+64
+00:05:36,000 --> 00:05:38,000
+bringing the whole system down.
+
+65
+00:05:38,000 --> 00:05:45,000
+Malicious actors sometimes use command injection to create security weaknesses in the system and then
+
+66
+00:05:45,000 --> 00:05:48,000
+exports and create its weaknesses.
+
+67
+00:05:48,000 --> 00:05:55,000
+A successful injection can also provide attackers with unauthorized access to the database, allowing
+
+68
+00:05:56,000 --> 00:06:04,000
+them to exit mine tables with critical information from them and even acquire administrator access.
+
+69
+00:06:04,000 --> 00:06:09,000
+Let's compare now injection some of us 2021 and 2017.
+
+70
+00:06:10,000 --> 00:06:17,000
+Injections are attacks in which an attacker attempts to send data to a web application to execute thousands
+
+71
+00:06:17,000 --> 00:06:25,000
+of the application was not actually designed to do this can be injection windows is such a cycle operating
+
+72
+00:06:25,000 --> 00:06:34,000
+system or injections is in your top 10.21 update also contains the vulnerability cross-site scripting
+
+73
+00:06:34,000 --> 00:06:38,000
+because this vulnerability is a principle also an injection.
+
+74
+00:06:39,000 --> 00:06:48,000
+Probably this is a key difference if we compare injection in our last top ten 2017 and the top ten 2021.
+
+75
+00:06:49,000 --> 00:06:51,000
+There are different injection types.
+
+76
+00:06:51,000 --> 00:06:52,000
+That's loans them.
+
+77
+00:06:53,000 --> 00:06:56,000
+They are operating system common injection.
+
+78
+00:06:57,000 --> 00:07:02,000
+Even despite in my subjective opinions, this injection is not very popular nowadays.
+
+79
+00:07:02,000 --> 00:07:05,000
+I believe it is still worse to consider because of us.
+
+80
+00:07:05,000 --> 00:07:08,000
+Puts a stress on this type of injection.
+
+81
+00:07:08,000 --> 00:07:16,000
+Based on the statistics, based on my experience and the audits that I do on other software projects
+
+82
+00:07:16,000 --> 00:07:23,000
+and during my consultancy practice, I don't observe a lot of cases applications using the command line
+
+83
+00:07:23,000 --> 00:07:29,000
+directly from the application and expose an API of interaction that was common line.
+
+84
+00:07:29,000 --> 00:07:33,000
+But still, each of us highlights this type of threat.
+
+85
+00:07:33,000 --> 00:07:37,000
+I believe this verse to consider cross-site scripting.
+
+86
+00:07:38,000 --> 00:07:45,000
+This group is also known as the excess SAS injection or otherwise cross-site scripting injection.
+
+87
+00:07:46,000 --> 00:07:52,000
+In my opinion, this is a very interesting type of injection and even nowadays very popular.
+
+88
+00:07:53,000 --> 00:07:59,000
+There are a lot of cases with confirmation of this kind of attacks submitted in cryptocurrency industry.
+
+89
+00:07:59,000 --> 00:08:06,000
+And not only is there a lot of startups, is it a bother it was released in their products as soon as
+
+90
+00:08:06,000 --> 00:08:06,000
+possible.
+
+91
+00:08:07,000 --> 00:08:11,000
+Just ignores the potential risk of cross-site scripting injection.
+
+92
+00:08:12,000 --> 00:08:17,000
+That's why I'd love to draw your extra attention to this category, and we're going to have a lot of
+
+93
+00:08:17,000 --> 00:08:19,000
+examples to discuss.
+
+94
+00:08:19,000 --> 00:08:21,000
+SQL Injection.
+
+95
+00:08:21,000 --> 00:08:29,000
+Injection, no SQL injection like symmetric injection and injection.
+
+96
+00:08:30,000 --> 00:08:33,000
+Let's review these different types of injection wells.
+
+97
+00:08:33,000 --> 00:08:33,000
+Examples.
+
+98
+00:08:34,000 --> 00:08:37,000
+Let's start from the operating system.
+
+99
+00:08:37,000 --> 00:08:38,000
+Come on, injection.
+
+100
+00:08:38,000 --> 00:08:40,000
+Let's understand first.
+
+101
+00:08:40,000 --> 00:08:41,000
+What is it?
+
+102
+00:08:41,000 --> 00:08:42,000
+Come on.
+
+103
+00:08:42,000 --> 00:08:49,000
+Injection is a technique where malicious actor tries to execute the operating system commands on the
+
+104
+00:08:49,000 --> 00:08:51,000
+system person's application.
+
+105
+00:08:51,000 --> 00:08:54,000
+User input is used to execute these commands.
+
+106
+00:08:55,000 --> 00:09:02,000
+For example, a task can execute commands to show a list of files in some directories on the server
+
+107
+00:09:02,000 --> 00:09:02,000
+side.
+
+108
+00:09:03,000 --> 00:09:10,000
+Also, AutoCAD can execute some scripts that will operate in a system like that, using some critical
+
+109
+00:09:10,000 --> 00:09:16,000
+files for a common injection attack to work, the application should make three main conditions.
+
+110
+00:09:17,000 --> 00:09:23,000
+The first one is application should have privileges, permissions to execute system commands.
+
+111
+00:09:24,000 --> 00:09:30,000
+The second, the application should use user provided data as a parts of system commands.
+
+112
+00:09:30,000 --> 00:09:37,000
+And this is a user provided data and should not be escape sanitized before use.
+
+113
+00:09:37,000 --> 00:09:44,000
+If your application meets these conditions, then there's pretty good chance its application is vulnerable
+
+114
+00:09:44,000 --> 00:09:46,000
+to common injections.
+
+115
+00:09:46,000 --> 00:09:48,000
+You can't always trust the user.
+
+116
+00:09:49,000 --> 00:09:52,000
+Let's review an example now to understand it better.
+
+117
+00:09:53,000 --> 00:10:00,000
+Let's imagine that we are, Sarah, that allow us to check the content of the folder that is associated
+
+118
+00:10:00,000 --> 00:10:01,000
+with some sort of category.
+
+119
+00:10:02,000 --> 00:10:06,000
+When I can post product category to get the content of that folder.
+
+120
+00:10:07,000 --> 00:10:08,000
+I opened the browser.
+
+121
+00:10:09,000 --> 00:10:11,000
+I have my web server up and running.
+
+122
+00:10:11,000 --> 00:10:14,000
+I call my service page with product category parameter.
+
+123
+00:10:14,000 --> 00:10:19,000
+It is equal to laptops when I submit this query.
+
+124
+00:10:19,000 --> 00:10:21,000
+Then I see a list of the folder.
+
+125
+00:10:21,000 --> 00:10:23,000
+It is not critically important.
+
+126
+00:10:24,000 --> 00:10:30,000
+The main thing is that this thing that does what I expect it to do, my application has permissions
+
+127
+00:10:30,000 --> 00:10:37,000
+to execute system commands and application uses provided by user data as it was of system.
+
+128
+00:10:37,000 --> 00:10:38,000
+Come on.
+
+129
+00:10:38,000 --> 00:10:41,000
+And we don't verify them in any way.
+
+130
+00:10:41,000 --> 00:10:44,000
+And what if I would execute the following command?
+
+131
+00:10:45,000 --> 00:10:48,000
+I will slightly adjust the value of the parameter cost.
+
+132
+00:10:49,000 --> 00:10:54,000
+I will pass ampersand IP config instead of ampersand.
+
+133
+00:10:54,000 --> 00:10:56,000
+I use person sun 26.
+
+134
+00:10:57,000 --> 00:11:04,000
+I keep ampersand character because otherwise it will be treated as query string parameters separate
+
+135
+00:11:04,000 --> 00:11:04,000
+them.
+
+136
+00:11:04,000 --> 00:11:06,000
+And you see now what is here.
+
+137
+00:11:07,000 --> 00:11:09,000
+Don't pay attention to question marks.
+
+138
+00:11:10,000 --> 00:11:13,000
+I wasn't bother too much was encoding for this example.
+
+139
+00:11:13,000 --> 00:11:19,000
+The main thing is that I managed to get IP address by executing IP config.
+
+140
+00:11:19,000 --> 00:11:22,000
+Command is a command line of my server.
+
+141
+00:11:22,000 --> 00:11:25,000
+But what if I would execute something more dangerous?
+
+142
+00:11:26,000 --> 00:11:33,000
+Not as simple and harmless as chrome on the known IP address was a help of ampersand.
+
+143
+00:11:33,000 --> 00:11:36,000
+I can pass another command to be executed.
+
+144
+00:11:36,000 --> 00:11:39,000
+That is how command injection works.
+
+145
+00:11:39,000 --> 00:11:41,000
+Let me show you the source code.
+
+146
+00:11:42,000 --> 00:11:42,000
+All source code.
+
+147
+00:11:42,000 --> 00:11:46,000
+For this lesson you will be able to find in attachments to the video.
+
+148
+00:11:46,000 --> 00:11:48,000
+I created separate packages.
+
+149
+00:11:48,000 --> 00:11:49,000
+It is called I.
+
+150
+00:11:50,000 --> 00:11:52,000
+I stands for injection.
+
+151
+00:11:52,000 --> 00:11:59,000
+You can see how I built the past as a directory and the reads parameter passed to the of that.
+
+152
+00:11:59,000 --> 00:12:05,000
+But I don't need any validations to validate that the input parameters will not harm my system.
+
+153
+00:12:06,000 --> 00:12:11,000
+I get runtime time and executes a command in case pass was found.
+
+154
+00:12:11,000 --> 00:12:16,000
+We print the content of directory in case pass is invalid.
+
+155
+00:12:16,000 --> 00:12:22,000
+We enter catch block and as you can see, my query parameter is not validated.
+
+156
+00:12:23,000 --> 00:12:25,000
+I just concatenated execute this.
+
+157
+00:12:25,000 --> 00:12:26,000
+Come on.
+
+158
+00:12:27,000 --> 00:12:30,000
+And what shall we do in this case to eliminate this ability?
+
+159
+00:12:31,000 --> 00:12:35,000
+There is no master key to prevent common transactions.
+
+160
+00:12:35,000 --> 00:12:41,000
+It means is that you can just implement one soon and expect to be secure.
+
+161
+00:12:41,000 --> 00:12:47,000
+You need to add multiple layers of security when it comes to security.
+
+162
+00:12:47,000 --> 00:12:48,000
+Is a more z matter?
+
+163
+00:12:49,000 --> 00:12:52,000
+So here are some common uses for prevention methods.
+
+164
+00:12:53,000 --> 00:12:55,000
+The first one is the most simple one.
+
+165
+00:12:56,000 --> 00:13:01,000
+If you are not using system commands that common injections are not possible.
+
+166
+00:13:02,000 --> 00:13:09,000
+The second solution is to substitute common line operations with using some library, for example.
+
+167
+00:13:09,000 --> 00:13:13,000
+In this particular case, why should we use common line?
+
+168
+00:13:13,000 --> 00:13:17,000
+Why don't we use file across Java from Java IO package?
+
+169
+00:13:18,000 --> 00:13:20,000
+Always ask yourself.
+
+170
+00:13:20,000 --> 00:13:24,000
+They used to use command line to execute operations.
+
+171
+00:13:24,000 --> 00:13:28,000
+You need all you have, I think to perform required actions in another way.
+
+172
+00:13:29,000 --> 00:13:33,000
+Another solution might be additional verifications you can validate.
+
+173
+00:13:34,000 --> 00:13:38,000
+You must keep all special characters and leave on the text.
+
+174
+00:13:39,000 --> 00:13:43,000
+The next solution would be implementation of principle of this privilege.
+
+175
+00:13:43,000 --> 00:13:47,000
+Well, you talked about it in our previous classes.
+
+176
+00:13:48,000 --> 00:13:54,000
+The principle of this process is that you should give an entity the least amount of privilege necessary,
+
+177
+00:13:55,000 --> 00:13:57,000
+just enough to do what's needed.
+
+178
+00:13:57,000 --> 00:14:04,000
+For example, if the application or user needs access to just one folder, give access to only that
+
+179
+00:14:04,000 --> 00:14:05,000
+folder.
+
+180
+00:14:06,000 --> 00:14:10,000
+Given the operations of superuser privileges is not at all smart.
+
+181
+00:14:11,000 --> 00:14:13,000
+Implement this principle everywhere.
+
+182
+00:14:14,000 --> 00:14:20,000
+You could also create a separate user for the application and you've only required permissions to zap
+
+183
+00:14:20,000 --> 00:14:20,000
+user.
+
+184
+00:14:21,000 --> 00:14:23,000
+This might not be feasible everywhere.
+
+185
+00:14:24,000 --> 00:14:31,000
+It depends on the use case, but you should consider prepare to allow based on the denialist seamless
+
+186
+00:14:31,000 --> 00:14:35,000
+solution we reviewed in our broken access control lesson.
+
+187
+00:14:35,000 --> 00:14:37,000
+We implemented safely.
+
+188
+00:14:37,000 --> 00:14:40,000
+In that lesson, the principle is very similar.
+
+189
+00:14:41,000 --> 00:14:46,000
+That's why I don't believe that I need to repeat myself and create similar examples.
+
+190
+00:14:47,000 --> 00:14:53,000
+If you know what comments must be used, what commands must not be used, you could allow blocks out.
+
+191
+00:14:54,000 --> 00:15:00,000
+If your application needs to execute only one command, then you could use logic.
+
+192
+00:15:00,000 --> 00:15:01,000
+Caps.
+
+193
+00:15:01,000 --> 00:15:05,000
+Is a command being sent to the coming line for execution?
+
+194
+00:15:05,000 --> 00:15:09,000
+Is that one command you intend to execute?
+
+195
+00:15:09,000 --> 00:15:12,000
+You can implement this with single statement.
+
+196
+00:15:13,000 --> 00:15:17,000
+That's all what I wanted to show you regarding the comment in Jackson.
+
+197
+00:15:17,000 --> 00:15:18,000
+That's my one.
+
diff --git a/73 - OWASP Top 10 2021/006 Source-code-examples-from-the-lesson.url b/73 - OWASP Top 10 2021/006 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..0eb22a6e373db1cf096ee07c856da1f3d9e73483
--- /dev/null
+++ b/73 - OWASP Top 10 2021/006 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/i/problem
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/007 Injection (Cross Site Scripting, Types of XSS, SQL, JPA, NoSQL Injections)_en.srt b/73 - OWASP Top 10 2021/007 Injection (Cross Site Scripting, Types of XSS, SQL, JPA, NoSQL Injections)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..7dcdf58c2a76f5556bedab0e9d86bdd1565dc2be
--- /dev/null
+++ b/73 - OWASP Top 10 2021/007 Injection (Cross Site Scripting, Types of XSS, SQL, JPA, NoSQL Injections)_en.srt
@@ -0,0 +1,740 @@
+1
+00:00:02,000 --> 00:00:04,000
+Let's learn now cross-site scripting.
+
+2
+00:00:05,000 --> 00:00:10,000
+So let's learn first what it is and why we shouldn't advisor about this at all.
+
+3
+00:00:11,000 --> 00:00:18,000
+Cross-Site scripting is an attack performed on vulnerable web applications that manipulates the app
+
+4
+00:00:18,000 --> 00:00:20,000
+to send malicious scripts to users.
+
+5
+00:00:21,000 --> 00:00:25,000
+In short, an attacker injects malicious script into a website.
+
+6
+00:00:26,000 --> 00:00:28,000
+The impact can be different.
+
+7
+00:00:28,000 --> 00:00:37,000
+For example, attacker wants to access personal data of other users, controls a browser or in severe
+
+8
+00:00:37,000 --> 00:00:40,000
+cases, controls the application itself.
+
+9
+00:00:41,000 --> 00:00:45,000
+Cross-Site scripting attacks consist from two parts.
+
+10
+00:00:45,000 --> 00:00:47,000
+Initialization of the attack.
+
+11
+00:00:48,000 --> 00:00:55,000
+The attacker sends the most often a malicious script through a trusted source and web application,
+
+12
+00:00:55,000 --> 00:00:57,000
+like a text field or a URL.
+
+13
+00:00:58,000 --> 00:01:01,000
+Execution of an attack is the second part.
+
+14
+00:01:02,000 --> 00:01:09,000
+The data is received by an unsuspecting user without being followed data as the user opens and executes.
+
+15
+00:01:11,000 --> 00:01:15,000
+Cross-Site scripting attacks are typically written as JavaScript segments.
+
+16
+00:01:16,000 --> 00:01:22,000
+Even something as simple as can be manipulated by attackers, if not handled properly.
+
+17
+00:01:23,000 --> 00:01:26,000
+There are different types of cross-site scripting attacks.
+
+18
+00:01:26,000 --> 00:01:35,000
+The CIA reflected the excess attacks, persistent excess attacks and DOM based excess attacks.
+
+19
+00:01:36,000 --> 00:01:44,000
+Let us briefly review each of these types reflects the excess attacks, also known as non persistent.
+
+20
+00:01:44,000 --> 00:01:49,000
+The excess attacks are considered to be the simplest form of exercise.
+
+21
+00:01:50,000 --> 00:01:57,000
+In these attacks, an attacker poses a malicious script query, which is typically within a euro.
+
+22
+00:01:57,000 --> 00:02:05,000
+Basically, attacker puts JavaScript into zero and the attacker makes a victim to create a euro.
+
+23
+00:02:06,000 --> 00:02:10,000
+This can be done with the help of social engineering techniques.
+
+24
+00:02:11,000 --> 00:02:18,000
+For example, some email was hyper reference or random link on forums or in common somewhere.
+
+25
+00:02:18,000 --> 00:02:25,000
+The main issue here is to make victims click on the euro to execute the malicious script in.
+
+26
+00:02:26,000 --> 00:02:31,000
+In a few minutes I am going to show you an example of a a6's attack.
+
+27
+00:02:32,000 --> 00:02:34,000
+Persistent access attacks.
+
+28
+00:02:34,000 --> 00:02:37,000
+Also known as Thor, the excess SAS attacks.
+
+29
+00:02:38,000 --> 00:02:47,000
+Q Or when an attacker identifies ability in a web application that allows for script injection, the
+
+30
+00:02:47,000 --> 00:02:54,000
+attacker is able to inject a malicious create into verification to make it executed each time.
+
+31
+00:02:54,000 --> 00:02:57,000
+One The victim is open of that page of an application.
+
+32
+00:02:58,000 --> 00:03:02,000
+For example, a target left to comment on your website.
+
+33
+00:03:03,000 --> 00:03:06,000
+And Coleman's content is a JavaScript code.
+
+34
+00:03:07,000 --> 00:03:14,000
+Once com is added, it is stored in the database and law that each time one of the users open a web
+
+35
+00:03:14,000 --> 00:03:17,000
+page with that common script is executed.
+
+36
+00:03:18,000 --> 00:03:22,000
+That's why these kinds of attacks are called persistent.
+
+37
+00:03:22,000 --> 00:03:30,000
+The excess SAS attacks, a document object model, is an interface to treat and document as a logical
+
+38
+00:03:30,000 --> 00:03:34,000
+tree structure where each node represents an object.
+
+39
+00:03:35,000 --> 00:03:41,000
+And because of the document, DOM based excess attacks actually write data to the DOM.
+
+40
+00:03:42,000 --> 00:03:46,000
+Attackers can use this to add a malicious script to that page.
+
+41
+00:03:47,000 --> 00:03:56,000
+DOM based exercise or as it is called in some tax time, all exercise using exercise attack variant
+
+42
+00:03:56,000 --> 00:04:04,000
+at targeting load is executed as a result of modifying the known environment in the victim's browser
+
+43
+00:04:04,000 --> 00:04:12,000
+used by the original client side script so that the inside side code arose in an unexpected manner.
+
+44
+00:04:13,000 --> 00:04:20,000
+That is, the page itself doesn't change, but the client's side code contains the needs of page, executes
+
+45
+00:04:21,000 --> 00:04:26,000
+from the uses and malicious modifications that have a keyword is a DOM environment.
+
+46
+00:04:27,000 --> 00:04:30,000
+Let me demo reflected the excess attack.
+
+47
+00:04:31,000 --> 00:04:38,000
+Just to remind you that this is kind of attack where we use you around to inject JavaScript and we use
+
+48
+00:04:38,000 --> 00:04:43,000
+social engineering techniques to force victim using to use our lead.
+
+49
+00:04:44,000 --> 00:04:46,000
+My server is up and running.
+
+50
+00:04:46,000 --> 00:04:50,000
+Imagine that I'm successfully logged in.
+
+51
+00:04:50,000 --> 00:04:59,000
+Let me use some saved credentials to log in on the side and all of a sudden I receive an email that
+
+52
+00:04:59,000 --> 00:05:04,000
+tells me that I need to use the link from the email to get the 90% discount.
+
+53
+00:05:04,000 --> 00:05:08,000
+I click on it and they're redirected to go to the details page.
+
+54
+00:05:09,000 --> 00:05:09,000
+Here it is.
+
+55
+00:05:10,000 --> 00:05:16,000
+You can see that to request parameters, the ID and discount code.
+
+56
+00:05:16,000 --> 00:05:19,000
+And here is the name of discount coupon.
+
+57
+00:05:19,000 --> 00:05:21,000
+Let's imagine that.
+
+58
+00:05:21,000 --> 00:05:23,000
+And again, this is just an example.
+
+59
+00:05:24,000 --> 00:05:27,000
+There can be different variations in different cases.
+
+60
+00:05:27,000 --> 00:05:32,000
+But the main thing here is that query parameter may be displayed tons of page.
+
+61
+00:05:33,000 --> 00:05:35,000
+This allows the inject script.
+
+62
+00:05:36,000 --> 00:05:44,000
+So I'm logged in user and the margins as you see if you read on your email, it contains injected screen.
+
+63
+00:05:45,000 --> 00:05:46,000
+Let me paste it here.
+
+64
+00:05:47,000 --> 00:05:55,000
+And when a click and the last thing that happened to me at first glance but realize this zero contains
+
+65
+00:05:55,000 --> 00:06:03,000
+JavaScript code that tweets my cookies and sends the analysis server, lets me use the source code of
+
+66
+00:06:03,000 --> 00:06:04,000
+the page.
+
+67
+00:06:04,000 --> 00:06:12,000
+Now let me search for script tag and you can find that my script has been injected into the page.
+
+68
+00:06:13,000 --> 00:06:14,000
+Can you see this?
+
+69
+00:06:14,000 --> 00:06:16,000
+Write those across.
+
+70
+00:06:17,000 --> 00:06:24,000
+I sent the cookies where I post mass does this or that and they print printed the console here largely
+
+71
+00:06:24,000 --> 00:06:26,000
+copies this session.
+
+72
+00:06:26,000 --> 00:06:26,000
+They did.
+
+73
+00:06:27,000 --> 00:06:35,000
+And in that a browser, let's say in Mozilla Firefox, I will open my application what I am going to
+
+74
+00:06:35,000 --> 00:06:35,000
+do next.
+
+75
+00:06:36,000 --> 00:06:44,000
+I open development tools by clicking the F12 key and I find JS session and equal key in the storage
+
+76
+00:06:44,000 --> 00:06:44,000
+tab.
+
+77
+00:06:45,000 --> 00:06:48,000
+I will just substitute the value of our code.
+
+78
+00:06:48,000 --> 00:06:56,000
+Key to the one I received was a help of injection and after that I refresh page and here it is.
+
+79
+00:06:57,000 --> 00:06:59,000
+I logged in was another user.
+
+80
+00:07:00,000 --> 00:07:01,000
+I stole this session.
+
+81
+00:07:02,000 --> 00:07:03,000
+Can you imagine that?
+
+82
+00:07:04,000 --> 00:07:08,000
+That's why cross-site scripting injections are so dangerous.
+
+83
+00:07:08,000 --> 00:07:14,000
+That's why you need to be very cautious with the links that you open in the browser.
+
+84
+00:07:15,000 --> 00:07:16,000
+Let me open the source code.
+
+85
+00:07:17,000 --> 00:07:19,000
+Is there a threat that requires us to read them?
+
+86
+00:07:19,000 --> 00:07:24,000
+First of all, you can find JavaScript code that I injected into the euro.
+
+87
+00:07:25,000 --> 00:07:33,000
+I keep a command and here you can find actually the JavaScript code and then the code euro and they
+
+88
+00:07:33,000 --> 00:07:34,000
+do get massive.
+
+89
+00:07:34,000 --> 00:07:42,000
+You can see that they take parameters and codes into the request code and after that I for once request
+
+90
+00:07:42,000 --> 00:07:49,000
+the my view and discount component is injected into the page in zero number 55.
+
+91
+00:07:50,000 --> 00:07:51,000
+Can you see this?
+
+92
+00:07:52,000 --> 00:07:54,000
+What to do and how to solve this?
+
+93
+00:07:55,000 --> 00:08:04,000
+In most application service default configuration, we can use a response handler to help prevent cross-site
+
+94
+00:08:04,000 --> 00:08:11,000
+scripting attacks and by default we use DPI on the flag for circle be response header.
+
+95
+00:08:12,000 --> 00:08:19,000
+In simple words, that means that cookies can be read and sent or made by a web server.
+
+96
+00:08:19,000 --> 00:08:27,000
+That's why, by default it is hard to extract cookies set by Tomcat Web server, but this easy to store
+
+97
+00:08:27,000 --> 00:08:28,000
+application cookies.
+
+98
+00:08:29,000 --> 00:08:37,000
+I mean cookies that we set from the application and not cookies that were set by web server and also
+
+99
+00:08:37,000 --> 00:08:44,000
+as a sync will consider this course and this class in particular designed not only for Java developers,
+
+100
+00:08:45,000 --> 00:08:46,000
+it can happen.
+
+101
+00:08:46,000 --> 00:08:53,000
+Is that web server that you selected for your application doesn't add a CTP on the flag and by default
+
+102
+00:08:53,000 --> 00:08:57,000
+in said cookie response had it to prevent cross-site scripting.
+
+103
+00:08:58,000 --> 00:09:01,000
+So we be to here and do not forget to check this.
+
+104
+00:09:02,000 --> 00:09:08,000
+I will share with you example of Tomcat configuration and you will be able to find similar configuration
+
+105
+00:09:08,000 --> 00:09:10,000
+on this service.
+
+106
+00:09:10,000 --> 00:09:18,000
+To reproduce a case where I stole your cookies, I set use based on the attributes value to false.
+
+107
+00:09:18,000 --> 00:09:23,000
+We can configure this in the context XML file on the Tomcat level.
+
+108
+00:09:24,000 --> 00:09:33,000
+Context sex symbol is located in the folder of the Tomcat in case you run Tomcat from eclipse context.
+
+109
+00:09:33,000 --> 00:09:36,000
+S.O. is located in the middle is folder.
+
+110
+00:09:36,000 --> 00:09:46,000
+Here you can see I said use only attitude of context element to false and after this tomcat doesn't
+
+111
+00:09:46,000 --> 00:09:50,000
+prevent the cross-site scripting for cookies set by the server.
+
+112
+00:09:51,000 --> 00:09:59,000
+To fix this, I need to remove this attribute because it is true by default or to set true vividly here.
+
+113
+00:10:00,000 --> 00:10:04,000
+I am sure that you can find similar configuration on the web server.
+
+114
+00:10:06,000 --> 00:10:11,000
+Another way of preventing such attacks is a key point of our tools.
+
+115
+00:10:11,000 --> 00:10:20,000
+In this particular example, we use GCP and G isto ingest with out attack that allows us to escape out.
+
+116
+00:10:21,000 --> 00:10:27,000
+Let me on Coleman's slide and I will refresh the page in browser.
+
+117
+00:10:27,000 --> 00:10:35,000
+As you can see, when I escape tax, then JavaScript will not be injected into the page script.
+
+118
+00:10:36,000 --> 00:10:39,000
+It will be injected as text and will not be executed.
+
+119
+00:10:40,000 --> 00:10:47,000
+Talking about persistent exercise, attacks and lives, there is no sense to imitate other cases because
+
+120
+00:10:47,000 --> 00:10:49,000
+they will be almost similar.
+
+121
+00:10:49,000 --> 00:10:57,000
+Imagine that somebody left a comment on the PDP page and the comment contains JavaScript code.
+
+122
+00:10:57,000 --> 00:11:03,000
+This code will be stored in the database and obviously one page will be loaded.
+
+123
+00:11:03,000 --> 00:11:08,000
+The JavaScript code will be loaded on the page and executed.
+
+124
+00:11:08,000 --> 00:11:11,000
+And again, also second examples from this lesson.
+
+125
+00:11:11,000 --> 00:11:13,000
+You can find an attachment to the lesson.
+
+126
+00:11:14,000 --> 00:11:21,000
+Take your time, investigate all examples provided and remember, this is amazing.
+
+127
+00:11:21,000 --> 00:11:27,000
+To Prevent Access Attack is to never trust the data as it comes from outside of the application.
+
+128
+00:11:28,000 --> 00:11:36,000
+Always treat any kind of vehicle as a suspect until you capable to avoid cases like this.
+
+129
+00:11:36,000 --> 00:11:46,000
+Make sure you escape all HTML tags before you store it in the database or when you send data from that
+
+130
+00:11:47,000 --> 00:11:48,000
+before escaping.
+
+131
+00:11:48,000 --> 00:11:51,000
+Input validation is another valuable strategy.
+
+132
+00:11:51,000 --> 00:11:58,000
+When dealing with user input for some kinds of data, it might make sense to use an allow based approach
+
+133
+00:11:59,000 --> 00:12:03,000
+interview to allow this approach few times already, including our previous lesson.
+
+134
+00:12:04,000 --> 00:12:06,000
+One We talked about broken access control.
+
+135
+00:12:07,000 --> 00:12:13,000
+So I believe you are familiar with this technique is allowing the use of at least of the validate as
+
+136
+00:12:13,000 --> 00:12:17,000
+it can be accepted and everyone else is not.
+
+137
+00:12:18,000 --> 00:12:26,000
+And also there are tools that can be integrated into this is useful and can help you to detect and prevent
+
+138
+00:12:26,000 --> 00:12:31,000
+not only excess attacks but also other potential threats.
+
+139
+00:12:32,000 --> 00:12:36,000
+Let's now talk about sequel GP and those sequel injections.
+
+140
+00:12:37,000 --> 00:12:43,000
+I decided to discuss these types of injections together as a group because all of them I am both and
+
+141
+00:12:44,000 --> 00:12:46,000
+seeing all these kinds of injections.
+
+142
+00:12:46,000 --> 00:12:52,000
+The record on Impact and Persistence Stores talking about SQL injections.
+
+143
+00:12:52,000 --> 00:12:54,000
+I would like to do even advice.
+
+144
+00:12:54,000 --> 00:12:58,000
+Please check our previous lesson about cryptographic failures.
+
+145
+00:12:59,000 --> 00:13:07,000
+In that lesson I showed example wisdom of situation of impact of sun passports in the database in not
+
+146
+00:13:07,000 --> 00:13:08,000
+encrypted form.
+
+147
+00:13:08,000 --> 00:13:14,000
+And in the example, I used SQL injection to retrieve data from persistent storage.
+
+148
+00:13:15,000 --> 00:13:19,000
+So please check with those lessons to learn more about SQL injection.
+
+149
+00:13:20,000 --> 00:13:23,000
+And in general, we have not the easiest topics to them.
+
+150
+00:13:24,000 --> 00:13:31,000
+Security questions never very easy once place the notes, skip lessons to not be lost in the context.
+
+151
+00:13:32,000 --> 00:13:38,000
+And again you will be able to find source code of SQL injection examples in the previous lessons.
+
+152
+00:13:39,000 --> 00:13:41,000
+As you can see, vulnerabilities.
+
+153
+00:13:41,000 --> 00:13:43,000
+I used to guess it was possible.
+
+154
+00:13:44,000 --> 00:13:50,000
+For example, SQL injection where immunity may be used to discover cryptographic servers.
+
+155
+00:13:50,000 --> 00:13:57,000
+That's why I don't see and the access to duplicate demo of examples, but instead I will help you to
+
+156
+00:13:57,000 --> 00:13:59,000
+connect the dots together.
+
+157
+00:14:00,000 --> 00:14:01,000
+Ensure.
+
+158
+00:14:01,000 --> 00:14:07,000
+I'd like to recalls the course of injections SQL injection accuracy ones.
+
+159
+00:14:07,000 --> 00:14:15,000
+The application uses untrusted user input to build and SQL query using the string and executable.
+
+160
+00:14:16,000 --> 00:14:20,000
+It is recommended to use query parameters in order to prevent injection.
+
+161
+00:14:21,000 --> 00:14:29,000
+Also use name and also SQL controls was increased to prevent most disclosure of records in case of secure
+
+162
+00:14:29,000 --> 00:14:30,000
+injection.
+
+163
+00:14:31,000 --> 00:14:38,000
+We're going to have a separate lesson about the persistence API and I will cover all the specifics in
+
+164
+00:14:38,000 --> 00:14:39,000
+those lessons.
+
+165
+00:14:40,000 --> 00:14:47,000
+But talking about injections, I can say that the root cause of GP injection is very similar to the
+
+166
+00:14:47,000 --> 00:14:48,000
+sequel injections.
+
+167
+00:14:48,000 --> 00:14:51,000
+GP injection cures ones.
+
+168
+00:14:51,000 --> 00:14:58,000
+The application uses untrusted user to build the GP query using S3 and executed.
+
+169
+00:14:59,000 --> 00:15:06,000
+It's quite similar to sequel injection, but the ultimate language isn't sequel but the GP where it
+
+170
+00:15:06,000 --> 00:15:06,000
+went.
+
+171
+00:15:07,000 --> 00:15:15,000
+And again, to prevent the GP injection, it is recommended to use a persistent square and causation.
+
+172
+00:15:16,000 --> 00:15:23,000
+A few words about no SQL injection injection of this type of queue or was the application uses untrusted
+
+173
+00:15:23,000 --> 00:15:32,000
+use of the input to build and no SQL API call expression as many no of this system and each one to use
+
+174
+00:15:32,000 --> 00:15:33,000
+API for call.
+
+175
+00:15:34,000 --> 00:15:40,000
+It is important to ensure that user input received and is used to build the API.
+
+176
+00:15:40,000 --> 00:15:46,000
+Call expression does not contain any characters that have the special name is a target API.
+
+177
+00:15:46,000 --> 00:15:47,000
+See this.
+
+178
+00:15:48,000 --> 00:15:51,000
+We need to check this in order to avoid that.
+
+179
+00:15:51,000 --> 00:15:59,000
+Some characters will be used to escape the initial call expression in order to create another one based
+
+180
+00:15:59,000 --> 00:16:01,000
+on crafted user input.
+
+181
+00:16:02,000 --> 00:16:10,000
+It is also important to not use String Nation to build API call expression, but to use the API to create
+
+182
+00:16:10,000 --> 00:16:19,000
+an expression similar to the way how we use to prepare a statement instead of statement in Java in example
+
+183
+00:16:19,000 --> 00:16:21,000
+about sequel injections.
+
+184
+00:16:22,000 --> 00:16:24,000
+That states got injections.
+
+185
+00:16:24,000 --> 00:16:26,000
+That can impact our database storage.
+
diff --git a/73 - OWASP Top 10 2021/007 Source-code-examples-from-the-lesson.url b/73 - OWASP Top 10 2021/007 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..0eb22a6e373db1cf096ee07c856da1f3d9e73483
--- /dev/null
+++ b/73 - OWASP Top 10 2021/007 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/i/problem
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/008 Injection (XPath Injection, Log Injection, Input Validation)_en.srt b/73 - OWASP Top 10 2021/008 Injection (XPath Injection, Log Injection, Input Validation)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..35deb345b0e6d3b4cdef1f554731cd50c3e40428
--- /dev/null
+++ b/73 - OWASP Top 10 2021/008 Injection (XPath Injection, Log Injection, Input Validation)_en.srt
@@ -0,0 +1,716 @@
+1
+00:00:02,000 --> 00:00:10,000
+Let's talk now about exports, injection, web applications, store and access data in various ways
+
+2
+00:00:10,000 --> 00:00:13,000
+and for us, dependent upon the use cases.
+
+3
+00:00:14,000 --> 00:00:21,000
+Historically, relational databases have been the popular choice among various databases to store large
+
+4
+00:00:21,000 --> 00:00:22,000
+amounts of data.
+
+5
+00:00:23,000 --> 00:00:29,000
+However, sometimes we still prefer to use Excel for storing some kind of data.
+
+6
+00:00:29,000 --> 00:00:34,000
+It can be configurations, but not only on the using maximum.
+
+7
+00:00:34,000 --> 00:00:41,000
+The data is stored in master structure is a form of trees rather than columns and rows.
+
+8
+00:00:42,000 --> 00:00:50,000
+To understand what each sparse injection we need to understand, what makes us is the data store of
+
+9
+00:00:50,000 --> 00:00:53,000
+the x amount can be queried x plus.
+
+10
+00:00:54,000 --> 00:01:00,000
+It is a query language and is used to locate specific elements in an accidental document.
+
+11
+00:01:00,000 --> 00:01:07,000
+There are no access level permissions and it is possible to refer almost any parts of an excellent document.
+
+12
+00:01:07,000 --> 00:01:15,000
+Unlike SIC, which allows restrictions on databases, tables or columns similar to single injection
+
+13
+00:01:15,000 --> 00:01:23,000
+POS injections operate on websites that use a user supplied information to construct an express query.
+
+14
+00:01:23,000 --> 00:01:31,000
+For example, data by sending intentionally malformed information into the website and a target can
+
+15
+00:01:31,000 --> 00:01:42,000
+find out how x small data is structured or x data that he may not normally have access to experts injections
+
+16
+00:01:42,000 --> 00:01:50,000
+might be even more dangerous than SQL injections since the X Plus Blocks Access Control allows querying
+
+17
+00:01:50,000 --> 00:01:53,000
+of the complete X amount document.
+
+18
+00:01:53,000 --> 00:02:02,000
+Whereas many SQL databases have metal tables that can be accessed by regular queries before reviewing
+
+19
+00:02:02,000 --> 00:02:03,000
+the express injection.
+
+20
+00:02:03,000 --> 00:02:10,000
+Examples, I have to say that it is important to you to know what maximum on the x plus is taking into
+
+21
+00:02:10,000 --> 00:02:11,000
+account.
+
+22
+00:02:11,000 --> 00:02:19,000
+This is why the topic I want to warn you is in this lesson we are not going to loan x amount and x pass.
+
+23
+00:02:19,000 --> 00:02:23,000
+We're going to have a separate lesson about eczema and expose.
+
+24
+00:02:24,000 --> 00:02:26,000
+Let's review X plus injection demo.
+
+25
+00:02:26,000 --> 00:02:31,000
+Now we will use the excellent sequence that you see in the slide for the examples.
+
+26
+00:02:32,000 --> 00:02:38,000
+So this is a collection of employees and believe that excellent example is self describing.
+
+27
+00:02:39,000 --> 00:02:46,000
+Suppose we have a user authentication system on a web page that used a data file of this sort to log
+
+28
+00:02:46,000 --> 00:02:47,000
+in users.
+
+29
+00:02:48,000 --> 00:02:54,000
+Once username and password have been supplied, the software might use x pos to load copies.
+
+30
+00:02:54,000 --> 00:02:57,000
+The user like you can see on this slide.
+
+31
+00:02:57,000 --> 00:03:00,000
+These are examples.
+
+32
+00:03:00,000 --> 00:03:08,000
+You can see that I get username from request and I get the personal request was a normal username and
+
+33
+00:03:08,000 --> 00:03:08,000
+password.
+
+34
+00:03:08,000 --> 00:03:17,000
+This is possible work, but an attacker may send that username and password and they get an example.
+
+35
+00:03:17,000 --> 00:03:17,000
+No.
+
+36
+00:03:17,000 --> 00:03:20,000
+So access will result in a user name or password.
+
+37
+00:03:20,000 --> 00:03:24,000
+Like this you can see example of username and password.
+
+38
+00:03:24,000 --> 00:03:28,000
+Sam Z give us and ASICs expression.
+
+39
+00:03:28,000 --> 00:03:35,000
+The express expression was Well, this now looks like this, which is logically equivalent to what you
+
+40
+00:03:35,000 --> 00:03:36,000
+see on the slide.
+
+41
+00:03:37,000 --> 00:03:41,000
+In this case, one of the first parts of the X plus needs to be true.
+
+42
+00:03:42,000 --> 00:03:50,000
+Is it possible part becomes irrelevant and the username part will match all employees because of the
+
+43
+00:03:50,000 --> 00:03:51,000
+one equal one path.
+
+44
+00:03:52,000 --> 00:03:54,000
+How to prevent x pos injection.
+
+45
+00:03:55,000 --> 00:04:02,000
+Just slides the techniques with secure injection you need to use it tries to expose the interface if
+
+46
+00:04:02,000 --> 00:04:10,000
+one is available or escapes the user input to make it safe to load in dynamically constructed query.
+
+47
+00:04:11,000 --> 00:04:19,000
+If you use calls to terminate untrusted input in a dynamic constructed x POS query, then you use cables
+
+48
+00:04:19,000 --> 00:04:28,000
+that quote these untrusted inputs to ensure that untrusted data can try to break out of that quoted
+
+49
+00:04:28,000 --> 00:04:30,000
+context in the following example.
+
+50
+00:04:30,000 --> 00:04:38,000
+Single quotes are used to terminate the user name and password parameters, and thus a better mitigation
+
+51
+00:04:38,000 --> 00:04:41,000
+option is to use a compiled POS query.
+
+52
+00:04:42,000 --> 00:04:50,000
+Click on coiled expose queries already preset before the program executes, whereas than create on the
+
+53
+00:04:50,000 --> 00:04:54,000
+fly after the user's input has been added to the stream.
+
+54
+00:04:55,000 --> 00:05:01,000
+This is a better world because you don't have to worry about making a character that should have been.
+
+55
+00:05:01,000 --> 00:05:02,000
+Kate.
+
+56
+00:05:03,000 --> 00:05:07,000
+And the last but not least example for today is a log injection.
+
+57
+00:05:07,000 --> 00:05:15,000
+Applications typically used to lock files to store a history of events or transactions for later review
+
+58
+00:05:15,000 --> 00:05:18,000
+statistics, revising or debugging.
+
+59
+00:05:18,000 --> 00:05:25,000
+Dependent on the nature of the application, the task of reviewing the log files may be performed manually
+
+60
+00:05:26,000 --> 00:05:34,000
+on an as needed basis for automated was a tool that automatically calls for important events or trend
+
+61
+00:05:34,000 --> 00:05:35,000
+information.
+
+62
+00:05:36,000 --> 00:05:40,000
+What is a log injection logging action?
+
+63
+00:05:40,000 --> 00:05:47,000
+How often called log forgery is a vulnerability that arises when untrusted and validated.
+
+64
+00:05:48,000 --> 00:05:51,000
+Input is allowed to be created in system log files.
+
+65
+00:05:52,000 --> 00:06:00,000
+As a result, an attacker can insert malicious data and false entries into the logs and also to corrupt
+
+66
+00:06:00,000 --> 00:06:01,000
+the file.
+
+67
+00:06:02,000 --> 00:06:11,000
+The corrupted files can be used to cover the tracks of a heart attack path injection with just a Q when
+
+68
+00:06:11,000 --> 00:06:18,000
+data and there's an application from an and trusted source, the data is written to an application or
+
+69
+00:06:18,000 --> 00:06:19,000
+system log file.
+
+70
+00:06:20,000 --> 00:06:27,000
+Successful lock injection attacks can cause injection of new bogus events.
+
+71
+00:06:28,000 --> 00:06:30,000
+Look for an injection.
+
+72
+00:06:31,000 --> 00:06:38,000
+Injection of excess attacks opens as a malicious or current is of use in a vulnerable web application
+
+73
+00:06:39,000 --> 00:06:45,000
+injection of commands that parsers like HP passes could execute.
+
+74
+00:06:45,000 --> 00:06:48,000
+Let's review log injection demo.
+
+75
+00:06:48,000 --> 00:06:51,000
+Now these are most benign case.
+
+76
+00:06:51,000 --> 00:06:55,000
+An attacker may be able to serve false answers to the log file.
+
+77
+00:06:56,000 --> 00:07:02,000
+By providing that application, we see that we can lose a copy of characters.
+
+78
+00:07:02,000 --> 00:07:10,000
+If the log file is processed automatically, the attacker can render the file unusable by corrupting
+
+79
+00:07:10,000 --> 00:07:16,000
+the format of the file or inject an unexpected characters or more subtle attack.
+
+80
+00:07:16,000 --> 00:07:18,000
+Might be old school.
+
+81
+00:07:18,000 --> 00:07:27,000
+The log file statistics forged or otherwise corrupted log files can be used to cover and attackers tracks
+
+82
+00:07:27,000 --> 00:07:32,000
+or even to implicate another party in the commission of a malicious act.
+
+83
+00:07:32,000 --> 00:07:35,000
+Let's review quote examples was log for you.
+
+84
+00:07:36,000 --> 00:07:40,000
+On this slide you can see the source code of web application.
+
+85
+00:07:40,000 --> 00:07:47,000
+This particular piece of code application reads parameter from the request and passes it to integer.
+
+86
+00:07:48,000 --> 00:07:51,000
+It is parameter can be passed.
+
+87
+00:07:51,000 --> 00:07:57,000
+Xen will input if a user submits just 31234.
+
+88
+00:07:58,000 --> 00:08:03,000
+The following entry is locked, fails to pass and one is me.
+
+89
+00:08:04,000 --> 00:08:15,000
+However, if an attacker submits a313 info user logged out and user name, the following entry is locked.
+
+90
+00:08:16,000 --> 00:08:18,000
+Failed to pass a new one.
+
+91
+00:08:18,000 --> 00:08:20,000
+Sweet user walked out.
+
+92
+00:08:20,000 --> 00:08:23,000
+That got me on it.
+
+93
+00:08:23,000 --> 00:08:27,000
+Attackers can use this same mechanism to insert arbitrary lock.
+
+94
+00:08:27,000 --> 00:08:35,000
+ANDREWS So how to prevent lock injection to prevent an attacker from writing malicious content into
+
+95
+00:08:35,000 --> 00:08:36,000
+the application log?
+
+96
+00:08:36,000 --> 00:08:45,000
+Applied sciences such as as a user input is used to prevent injection of carriage return on the characters
+
+97
+00:08:46,000 --> 00:08:50,000
+limit the size of the user equals value used to create the lock message.
+
+98
+00:08:51,000 --> 00:08:58,000
+Make sure all exercise defenses are applied when you invoke files in the browser that sits with current
+
+99
+00:08:59,000 --> 00:08:59,000
+injection.
+
+100
+00:09:00,000 --> 00:09:01,000
+Let's continue.
+
+101
+00:09:02,000 --> 00:09:09,000
+We reviewed a lot of different injections for ambulances, also learned how to prevent each particular
+
+102
+00:09:09,000 --> 00:09:10,000
+injection.
+
+103
+00:09:10,000 --> 00:09:17,000
+But still, let's sum it up and make some general statements that you need to follow to prevent injections.
+
+104
+00:09:18,000 --> 00:09:23,000
+The following points can be applied in a general way to prevent injection issue.
+
+105
+00:09:24,000 --> 00:09:33,000
+Apply input validation using arrow based approach combined was out with some Tyson plus escape and user
+
+106
+00:09:33,000 --> 00:09:34,000
+input output.
+
+107
+00:09:35,000 --> 00:09:41,000
+If you interact with the system, try to use API features provided by a technology stack.
+
+108
+00:09:42,000 --> 00:09:44,000
+Java but not the key.
+
+109
+00:09:44,000 --> 00:09:49,000
+Instead of give them command and execute an aid in the command line.
+
+110
+00:09:49,000 --> 00:09:49,000
+So.
+
+111
+00:09:50,000 --> 00:09:58,000
+For any residual, then that requires of special characters using the specific escape syntax for that
+
+112
+00:09:58,000 --> 00:09:58,000
+interpreter.
+
+113
+00:09:59,000 --> 00:10:07,000
+So the general idea was, is to work with the input, let's input validation strategies.
+
+114
+00:10:07,000 --> 00:10:13,000
+I believe that by this moment, unless you understand what is the goal of the input validation.
+
+115
+00:10:14,000 --> 00:10:21,000
+But let's make it crystal clear what main goals of input validation are and when we should use information
+
+116
+00:10:21,000 --> 00:10:23,000
+to use input validation.
+
+117
+00:10:23,000 --> 00:10:33,000
+This performed to ensure all of the data is entries of workflow information system programs and malformed
+
+118
+00:10:33,000 --> 00:10:39,000
+data from persistent database and triggering malfunction of various downstream components.
+
+119
+00:10:40,000 --> 00:10:48,000
+Input validation should happen as early as possible and the data flow perform as soon as a data is received
+
+120
+00:10:48,000 --> 00:10:49,000
+from the external party.
+
+121
+00:10:50,000 --> 00:10:57,000
+Data from all potentially untrusted sources should be subject to input validation, including not only
+
+122
+00:10:57,000 --> 00:11:07,000
+internet facing web clients, but also by hand feeds over extra Nats from suppliers or vendors or regulators,
+
+123
+00:11:08,000 --> 00:11:15,000
+each of which may be compromised on their own and starts sending multiple data input.
+
+124
+00:11:15,000 --> 00:11:23,000
+Validation should not be used as a primary method of preventing the excess cycle injection and other
+
+125
+00:11:23,000 --> 00:11:30,000
+attacks which are covered in respective cheat sheets but can significantly contribute to reducing the
+
+126
+00:11:30,000 --> 00:11:32,000
+impact if implemented properly.
+
+127
+00:11:33,000 --> 00:11:37,000
+There are different input validation strategies that we have to consider.
+
+128
+00:11:37,000 --> 00:11:43,000
+Input validation should be applied on both syntactical and semantic level.
+
+129
+00:11:44,000 --> 00:11:49,000
+Syntactic validation should enforce correct syntax of structured fields.
+
+130
+00:11:49,000 --> 00:11:57,000
+For example, date formal semantic validation should enforce correctness of the values in a specific
+
+131
+00:11:57,000 --> 00:11:58,000
+business context.
+
+132
+00:11:59,000 --> 00:12:04,000
+For example, start date is before and the price is wasn't expected to change.
+
+133
+00:12:05,000 --> 00:12:12,000
+It is always recommended to prevent attacks as early as possible as it causes some of the user's attackers
+
+134
+00:12:12,000 --> 00:12:14,000
+request in code.
+
+135
+00:12:14,000 --> 00:12:18,000
+Validation can be used to detect unauthorized input.
+
+136
+00:12:18,000 --> 00:12:21,000
+Before this process was application.
+
+137
+00:12:22,000 --> 00:12:28,000
+You can implement input validation in different programming language by using existing toolset.
+
+138
+00:12:28,000 --> 00:12:37,000
+All external libraries enforce syntactic and semantic correctness validation against the source schema
+
+139
+00:12:37,000 --> 00:12:40,000
+and XML schema x as the four e.
+
+140
+00:12:40,000 --> 00:12:46,000
+In these four months, you stop conversions that is available in your programming language with strict
+
+141
+00:12:46,000 --> 00:12:54,000
+exception handling for example in Java or seems massive in integer type supports integers.
+
+142
+00:12:55,000 --> 00:13:02,000
+Minimum and maximum value rank checks on numerical parameters, some dates minimum and maximum lengths.
+
+143
+00:13:02,000 --> 00:13:08,000
+Check for strings array of allowed values for small sets of string parameters.
+
+144
+00:13:08,000 --> 00:13:15,000
+For example, if you need to validate inputs of days of week, regular expressions for plays and characters
+
+145
+00:13:15,000 --> 00:13:16,000
+if needed.
+
+146
+00:13:16,000 --> 00:13:23,000
+For example, if you need to substitute some content or escape some characters, we also use the zoo
+
+147
+00:13:23,000 --> 00:13:29,000
+technique of allow us to look and never forget about civilization.
+
+148
+00:13:29,000 --> 00:13:36,000
+Remember that a tiger can bypass front and foundation, so never forget to implement flotation on your
+
+149
+00:13:36,000 --> 00:13:36,000
+Samsung.
+
+150
+00:13:38,000 --> 00:13:41,000
+Separately, I'd like to talk about file upload.
+
+151
+00:13:41,000 --> 00:13:47,000
+This is also important that should be validated very often in web applications.
+
+152
+00:13:47,000 --> 00:13:51,000
+We can upload a user profile picture or some archive data.
+
+153
+00:13:52,000 --> 00:13:53,000
+Here are some rules.
+
+154
+00:13:54,000 --> 00:14:00,000
+Use input validation to ensure that upload file name uses and expected extension.
+
+155
+00:14:00,000 --> 00:14:00,000
+But.
+
+156
+00:14:01,000 --> 00:14:06,000
+Ensures that promoted file is not larger than a defined maximum file size.
+
+157
+00:14:07,000 --> 00:14:15,000
+By the way, this is important because attackers can break a server by uploading huge files intentionally.
+
+158
+00:14:15,000 --> 00:14:22,000
+If the website supports zip file, upload the validation check before unzip the file.
+
+159
+00:14:22,000 --> 00:14:32,000
+The check includes a target pass level of compressed estimated zip size use image the writing libraries
+
+160
+00:14:32,000 --> 00:14:40,000
+to verify the image is valid and to strip away extraneous content said the extension of the image could
+
+161
+00:14:40,000 --> 00:14:46,000
+be about the image extension based on the detected content type of the image from the image processing,
+
+162
+00:14:47,000 --> 00:14:54,000
+namely the not just trust is a header from SAP for insurers of the Texas content, part of the image
+
+163
+00:14:54,000 --> 00:14:57,000
+is within a list of defined image types.
+
+164
+00:14:58,000 --> 00:15:01,000
+JPG, dng, etc..
+
+165
+00:15:02,000 --> 00:15:04,000
+That's all what I wanted to share with you in this lesson.
+
+166
+00:15:05,000 --> 00:15:07,000
+Let's recap what we have learned.
+
+167
+00:15:08,000 --> 00:15:16,000
+In this licensing and injection risk category, we make a comparison of the risk category in our top
+
+168
+00:15:16,000 --> 00:15:16,000
+ten.
+
+169
+00:15:16,000 --> 00:15:20,000
+2021 was top ten 2017.
+
+170
+00:15:20,000 --> 00:15:29,000
+We reviewed different injection types, namely command injection, cross-site scripting and by the way,
+
+171
+00:15:29,000 --> 00:15:32,000
+we reviewed different types of cross-site scripting.
+
+172
+00:15:33,000 --> 00:15:40,000
+SQL Injection injection no injection x amount x pass injection, walk injection.
+
+173
+00:15:41,000 --> 00:15:43,000
+And at the end of the lesson was summarized.
+
+174
+00:15:43,000 --> 00:15:50,000
+The key sense is that we need to remember to prevent injection liabilities and relevant input validation
+
+175
+00:15:50,000 --> 00:15:52,000
+strategies and techniques.
+
+176
+00:15:53,000 --> 00:15:55,000
+That's all what I wanted to share with you in this lesson.
+
+177
+00:15:56,000 --> 00:15:57,000
+Thanks a lot for your attention.
+
+178
+00:15:58,000 --> 00:16:00,000
+Have a great day and see things.
+
+179
+00:16:00,000 --> 00:16:01,000
+The next lesson.
+
diff --git a/73 - OWASP Top 10 2021/008 Source-code-examples-from-the-lesson.url b/73 - OWASP Top 10 2021/008 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..0eb22a6e373db1cf096ee07c856da1f3d9e73483
--- /dev/null
+++ b/73 - OWASP Top 10 2021/008 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/i/problem
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/009 Insecure Design (Overivew, CWEs, Shift Left Security, Threat Modeling Manifesto)_en.srt b/73 - OWASP Top 10 2021/009 Insecure Design (Overivew, CWEs, Shift Left Security, Threat Modeling Manifesto)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..6803d79420c8852e12031f1b80a619219df2e7ae
--- /dev/null
+++ b/73 - OWASP Top 10 2021/009 Insecure Design (Overivew, CWEs, Shift Left Security, Threat Modeling Manifesto)_en.srt
@@ -0,0 +1,868 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello.
+
+2
+00:00:06,000 --> 00:00:08,000
+The day we start new topic.
+
+3
+00:00:09,000 --> 00:00:15,000
+This time we're going to discuss insecure design risk category from a loss that as always, we're going
+
+4
+00:00:15,000 --> 00:00:22,000
+to start our lesson from the general overview to help you understand that what this risk category is
+
+5
+00:00:22,000 --> 00:00:23,000
+about.
+
+6
+00:00:23,000 --> 00:00:30,000
+We're going to compare insecure design and insecure implementation and we are going to understand the
+
+7
+00:00:30,000 --> 00:00:31,000
+difference.
+
+8
+00:00:31,000 --> 00:00:37,000
+Your insurance will then you chance, for example, shift left approach.
+
+9
+00:00:37,000 --> 00:00:39,000
+I will explain what it is.
+
+10
+00:00:40,000 --> 00:00:46,000
+We'll discuss the most notable common weakness enumerations that are associated with this risk category.
+
+11
+00:00:47,000 --> 00:00:55,000
+Significant part of our today's lesson will talk about threat modeling will learn what threat modeling
+
+12
+00:00:55,000 --> 00:00:58,000
+manifest is its values and principles.
+
+13
+00:00:58,000 --> 00:01:05,000
+In this lesson, I will teach you how to build and secure design process during the learning of security
+
+14
+00:01:05,000 --> 00:01:06,000
+design process.
+
+15
+00:01:06,000 --> 00:01:10,000
+I will also cover such topic as business impact analysis.
+
+16
+00:01:11,000 --> 00:01:15,000
+I will provide you with a template that you can use during the business impact analysis.
+
+17
+00:01:16,000 --> 00:01:19,000
+We'll review how we can work with Threat Register.
+
+18
+00:01:20,000 --> 00:01:27,000
+Also, I'm going to explain the concept of security controls will learn what security design document
+
+19
+00:01:27,000 --> 00:01:29,000
+is and what it can contain.
+
+20
+00:01:30,000 --> 00:01:37,000
+And on top of all this, I will suggest madness is, as you can imagine, on a regular basis to measure
+
+21
+00:01:37,000 --> 00:01:39,000
+and evaluate security design process.
+
+22
+00:01:39,000 --> 00:01:43,000
+We'll review example of attacks and rules on how to prevent those.
+
+23
+00:01:44,000 --> 00:01:47,000
+As you can see, we have solid agenda for this lesson.
+
+24
+00:01:48,000 --> 00:01:49,000
+Let's get it started.
+
+25
+00:01:50,000 --> 00:01:54,000
+Let's start from the high level overview of this category.
+
+26
+00:01:54,000 --> 00:01:59,000
+The first things that I have to say is that this is a new risk category inside of us.
+
+27
+00:01:59,000 --> 00:02:07,000
+The top ten, 20, 21 zip was absent in our top ten 2017 and was top ten 2021.
+
+28
+00:02:07,000 --> 00:02:14,000
+The risk category directly started on place for it covers architectural flaws and design.
+
+29
+00:02:14,000 --> 00:02:23,000
+The states that result in the mason or use the security control implementation while an insecure implementation
+
+30
+00:02:23,000 --> 00:02:24,000
+could be easily fixed.
+
+31
+00:02:25,000 --> 00:02:29,000
+Fixing and insecure design is no complicated thing to do.
+
+32
+00:02:29,000 --> 00:02:35,000
+Today we're going to discuss processes that we have to follow in order to create secure design.
+
+33
+00:02:35,000 --> 00:02:39,000
+Now understand what insecure design risk category is about.
+
+34
+00:02:40,000 --> 00:02:40,000
+Let me explain.
+
+35
+00:02:40,000 --> 00:02:49,000
+It was example there no such a feature in the web applications as a store password and very often user
+
+36
+00:02:49,000 --> 00:02:57,000
+registration user is asked to name a favorite or name of the path on Mars's maiden name.
+
+37
+00:02:57,000 --> 00:03:05,000
+This is not secure design by default, no matter how it will be implemented because many people know
+
+38
+00:03:05,000 --> 00:03:08,000
+the name of the pad or maiden name of your mesa.
+
+39
+00:03:09,000 --> 00:03:15,000
+In the era of social networks, it is easy to find all necessary information about the person and the
+
+40
+00:03:15,000 --> 00:03:19,000
+security vulnerability is not in the implementation of this feature.
+
+41
+00:03:20,000 --> 00:03:27,000
+No matter how you will implement this part of the application will still remain vulnerable.
+
+42
+00:03:28,000 --> 00:03:35,000
+So you can fix security vulnerability just by implementing it in a normal way.
+
+43
+00:03:36,000 --> 00:03:42,000
+It is insecure, but it's design, and what you can do to make it more secure is to substitute this
+
+44
+00:03:42,000 --> 00:03:46,000
+piece of application, complete with something more secure.
+
+45
+00:03:47,000 --> 00:03:51,000
+We can say that this is a new category is of massive importance.
+
+46
+00:03:52,000 --> 00:03:58,000
+Many projects start without the real design phase and don't have security in focus.
+
+47
+00:03:58,000 --> 00:04:05,000
+Even prototypes and proof of concept implementations with completely different nonfunctional requirements
+
+48
+00:04:05,000 --> 00:04:12,000
+for security and maintainability often go into production mainly because of business priorities and
+
+49
+00:04:12,000 --> 00:04:13,000
+to achieve some business goals.
+
+50
+00:04:14,000 --> 00:04:22,000
+But as I say, technology should go together with business hand to hand, because our goal is to deliver
+
+51
+00:04:22,000 --> 00:04:30,000
+fast wins market and opposite to the leadership by avoiding unsatisfied customers, lawsuits and so
+
+52
+00:04:30,000 --> 00:04:30,000
+on.
+
+53
+00:04:31,000 --> 00:04:38,000
+Work on secure design after implementation and the release can be very expensive and cost a lot of hours
+
+54
+00:04:38,000 --> 00:04:42,000
+of significant factor of completing a work of some modules.
+
+55
+00:04:43,000 --> 00:04:49,000
+And in this sense, label is extremely complicated and needs a lot of expensive refactoring time.
+
+56
+00:04:50,000 --> 00:04:54,000
+You can only prevent insecure design with insecure development.
+
+57
+00:04:54,000 --> 00:05:04,000
+Lifecycle Bootstrap Model Best Practices and Source User Design Face Mask recommends that organizations
+
+58
+00:05:04,000 --> 00:05:07,000
+use threats in order to achieve secure design.
+
+59
+00:05:07,000 --> 00:05:12,000
+Significant parts of our lesson we're going to talk about threat modelling.
+
+60
+00:05:12,000 --> 00:05:19,000
+There is also call for more use of security design patterns and reference architectures.
+
+61
+00:05:19,000 --> 00:05:25,000
+Avast suggests to move beyond shift that is important space the project core that the team.
+
+62
+00:05:26,000 --> 00:05:32,000
+It is critical for the principles of security by design identifying flaw.
+
+63
+00:05:32,000 --> 00:05:39,000
+So the design phase is what we call starting left in security, which is a progression of the popular
+
+64
+00:05:39,000 --> 00:05:42,000
+devsecops same pushing left.
+
+65
+00:05:42,000 --> 00:05:48,000
+In a few minutes I will explain in the details what does she have left means as I was?
+
+66
+00:05:48,000 --> 00:05:54,000
+Highlights Secure design is a management culture as well as methodology.
+
+67
+00:05:54,000 --> 00:06:01,000
+This is about changing the mindset around what stage security needs to end as application development
+
+68
+00:06:01,000 --> 00:06:02,000
+parties.
+
+69
+00:06:02,000 --> 00:06:11,000
+And it is our fundamental belief that true devsecops can only be achieved if security is factored in
+
+70
+00:06:11,000 --> 00:06:12,000
+right at the outset.
+
+71
+00:06:13,000 --> 00:06:20,000
+I would like to highlight one more time the difference between insecure design and insecure implementation.
+
+72
+00:06:20,000 --> 00:06:25,000
+Insecure design is not the source for all of the top primaries categories.
+
+73
+00:06:26,000 --> 00:06:30,000
+There is a difference between insecure design and insecure implementation.
+
+74
+00:06:30,000 --> 00:06:36,000
+I want to differentiates between design flaws and implementation defects for a reason.
+
+75
+00:06:37,000 --> 00:06:44,000
+These two concepts have different causes and remediation and secure design can still have implementation
+
+76
+00:06:44,000 --> 00:06:48,000
+defects leading to abilities that may be exploited.
+
+77
+00:06:49,000 --> 00:06:56,000
+And the security zone can be fixed by perfect implementation as by definition needed.
+
+78
+00:06:56,000 --> 00:07:01,000
+Security controls were never created to defend against specific attacks.
+
+79
+00:07:01,000 --> 00:07:09,000
+One of the factors that contribute to insecure design is the lack of business risk profile inherent
+
+80
+00:07:09,000 --> 00:07:15,000
+in the software or system being developed, and thus is a failure to determine what level of security
+
+81
+00:07:15,000 --> 00:07:17,000
+design is required.
+
+82
+00:07:17,000 --> 00:07:24,000
+Insecure design means risks related to design and architecture flaws with a built in right from the
+
+83
+00:07:24,000 --> 00:07:29,000
+beginning of software development gives up, propensity and mitigations are not taken.
+
+84
+00:07:30,000 --> 00:07:37,000
+I promised to explain what the shift to left approaches to shift left means to move the process to the
+
+85
+00:07:37,000 --> 00:07:42,000
+left of the traditional linear depiction of the software development lifecycle.
+
+86
+00:07:43,000 --> 00:07:50,000
+That's a common subjects of shift left initiatives in DevOps security and testing.
+
+87
+00:07:50,000 --> 00:07:57,000
+The term shift graph refers to the efforts of DevOps teams to guarantee application security at the
+
+88
+00:07:57,000 --> 00:08:00,000
+earliest stages of development lifecycle.
+
+89
+00:08:01,000 --> 00:08:08,000
+As part of an organizational path known as Devsecops collaboration between development, security and
+
+90
+00:08:08,000 --> 00:08:09,000
+operations.
+
+91
+00:08:10,000 --> 00:08:16,000
+Until recently, years security testing was implemented at the end of the development cycle following
+
+92
+00:08:16,000 --> 00:08:18,000
+application testing.
+
+93
+00:08:18,000 --> 00:08:25,000
+At this stage, security teams would perform various types of analysis and security testing, such as
+
+94
+00:08:25,000 --> 00:08:28,000
+static analysis and dynamic analysis.
+
+95
+00:08:28,000 --> 00:08:34,000
+The results of security tests would use a permit application to proceed for deployment into production
+
+96
+00:08:35,000 --> 00:08:39,000
+or reject the application and pass it back to developers for remediation.
+
+97
+00:08:40,000 --> 00:08:47,000
+This resulted in long delays in development or increased risk of revision software without necessary
+
+98
+00:08:47,000 --> 00:08:55,000
+security measures to shift security and left means to implement security measures your entire development
+
+99
+00:08:55,000 --> 00:08:59,000
+lifecycle rather than as the end of the cycle.
+
+100
+00:08:59,000 --> 00:09:06,000
+The goal of shifting security to left is to design software with security best practices built in and
+
+101
+00:09:06,000 --> 00:09:12,000
+to detect and fix potential security issues and vulnerabilities as early as a development process as
+
+102
+00:09:12,000 --> 00:09:19,000
+possible, making it easier, faster, and more affordable to address security issues.
+
+103
+00:09:20,000 --> 00:09:25,000
+The difference from the weakness and limitations that are associated with this category.
+
+104
+00:09:25,000 --> 00:09:29,000
+But as always, let's review on this and multiple common weakness.
+
+105
+00:09:29,000 --> 00:09:39,000
+Enumerations then include but not limited to CW e 209 generation of error message contains sensitive
+
+106
+00:09:39,000 --> 00:09:40,000
+information.
+
+107
+00:09:40,000 --> 00:09:47,000
+This may happen in case you handle exception and you need a full locks of exception.
+
+108
+00:09:48,000 --> 00:09:49,000
+This is just an example.
+
+109
+00:09:49,000 --> 00:09:53,000
+The full walk of exception may contain sensitive information.
+
+110
+00:09:54,000 --> 00:09:59,000
+cwe2 hundred 56 Unprotected storage of credentials.
+
+111
+00:10:00,000 --> 00:10:07,000
+Password management issues appear when the password is stored in plain text, in applications, properties,
+
+112
+00:10:07,000 --> 00:10:09,000
+configuration, file or memory.
+
+113
+00:10:10,000 --> 00:10:17,000
+We partially touched this topic in our lesson about cryptographic failures, and I told you even that
+
+114
+00:10:17,000 --> 00:10:25,000
+the storage sensitive data is in non encrypted form is not the best design decision that you can take.
+
+115
+00:10:25,000 --> 00:10:28,000
+This is also one of the cases of insecure design.
+
+116
+00:10:29,000 --> 00:10:36,000
+Storing the plaintext possible in a configuration file allows anyone who can reads a file accessed as
+
+117
+00:10:36,000 --> 00:10:38,000
+a password protected to source.
+
+118
+00:10:38,000 --> 00:10:46,000
+In some contexts, even storage of a plaintext passwords in memory is considered the security is the
+
+119
+00:10:46,000 --> 00:10:49,000
+password is not immediately updated.
+
+120
+00:10:49,000 --> 00:10:55,000
+ccwe5 hundred one Trust memory violation.
+
+121
+00:10:55,000 --> 00:11:05,000
+A transboundary can be thought of as a line drawn, so a program on one side of the line data is untrusted.
+
+122
+00:11:05,000 --> 00:11:10,000
+On the other side of the line, data is assumed to be trustworthy.
+
+123
+00:11:10,000 --> 00:11:18,000
+The purpose of validation logic is to allow data to safely cross the trust boundary, to move from trusted
+
+124
+00:11:18,000 --> 00:11:19,000
+to trust.
+
+125
+00:11:20,000 --> 00:11:26,000
+A trust boundary violation occurs when a program blurs the line between what is trusted and what isn't
+
+126
+00:11:26,000 --> 00:11:27,000
+trusted.
+
+127
+00:11:28,000 --> 00:11:34,000
+By combining trusted and trusted data in the same data structure, it becomes easier for programmers
+
+128
+00:11:34,000 --> 00:11:37,000
+to mistakenly trust and validate data.
+
+129
+00:11:38,000 --> 00:11:43,000
+ce5 hundred 22 Insufficiently Protected Credentials.
+
+130
+00:11:44,000 --> 00:11:51,000
+The Port of Trust meets all sorts of syndication credentials, but it uses an insecure mass that is
+
+131
+00:11:51,000 --> 00:11:55,000
+susceptible to unauthorized interception and or retrieval.
+
+132
+00:11:57,000 --> 00:12:01,000
+When progress of that now what is insecure design risk category?
+
+133
+00:12:02,000 --> 00:12:06,000
+But let's learn now more what action insecure design is.
+
+134
+00:12:07,000 --> 00:12:13,000
+Secure design is a culture and muscle knowledge is constantly evolving its threats and ensures that
+
+135
+00:12:13,000 --> 00:12:22,000
+code is robustly designed and tested to prevent known attack methods, security design concerns, processes
+
+136
+00:12:22,000 --> 00:12:30,000
+and activities related to how an organization defines goals and creates software within development
+
+137
+00:12:30,000 --> 00:12:31,000
+projects.
+
+138
+00:12:31,000 --> 00:12:39,000
+In general, this includes requirements gathering, high level architecture specifications and detailed
+
+139
+00:12:39,000 --> 00:12:40,000
+design.
+
+140
+00:12:41,000 --> 00:12:46,000
+Secure design is about the whole process where different parties are involved.
+
+141
+00:12:46,000 --> 00:12:53,000
+Namely, threat modelling should be integrated into refinement sessions or other similar activities.
+
+142
+00:12:53,000 --> 00:12:58,000
+We should be advising about security design on the stage and requirements refinement.
+
+143
+00:12:59,000 --> 00:13:07,000
+We should also look for changes in data flows and access control or other security controls, user development
+
+144
+00:13:07,000 --> 00:13:09,000
+and implementation.
+
+145
+00:13:09,000 --> 00:13:14,000
+We should always check different states of the system, including failing states.
+
+146
+00:13:14,000 --> 00:13:21,000
+We need to ensure that they are well-understood and agreed upon by responsible and important parties,
+
+147
+00:13:21,000 --> 00:13:29,000
+analyze assumptions and conditions for expected and failure flows, ensure they are still accurate and
+
+148
+00:13:29,000 --> 00:13:29,000
+desirable.
+
+149
+00:13:30,000 --> 00:13:37,000
+The to learn how to validate the assumptions and enforce conditions needed for proper behaviors, not
+
+150
+00:13:37,000 --> 00:13:41,000
+for mistakes, offer positive incentives to promote improvements.
+
+151
+00:13:42,000 --> 00:13:47,000
+Security design is used and on more tools that we can add to software.
+
+152
+00:13:48,000 --> 00:13:51,000
+We talked a few times already about smart modeling.
+
+153
+00:13:52,000 --> 00:13:55,000
+Let's learn what is it and how it can help us.
+
+154
+00:13:56,000 --> 00:14:03,000
+The Smith model practice focuses on identification and understanding of project model, at least based
+
+155
+00:14:03,000 --> 00:14:09,000
+on the functionality of the software being developed as the characteristics of the runtime environment.
+
+156
+00:14:09,000 --> 00:14:17,000
+From details about smarts and the likely attacks against each project, organization operates more effectively.
+
+157
+00:14:17,000 --> 00:14:22,000
+So better decisions about the prioritization of initiatives for security.
+
+158
+00:14:22,000 --> 00:14:30,000
+Additionally, decisions for these samples are more informed, therefore better aligned to the business
+
+159
+00:14:30,000 --> 00:14:33,000
+at the highest levels of the threat model.
+
+160
+00:14:33,000 --> 00:14:38,000
+We ask four key questions What are we working on?
+
+161
+00:14:38,000 --> 00:14:39,000
+What can go wrong?
+
+162
+00:14:40,000 --> 00:14:42,000
+What are we going to do about it?
+
+163
+00:14:43,000 --> 00:14:51,000
+Did we do a good enough job or was recommends that organizations under threat want them to identify
+
+164
+00:14:51,000 --> 00:14:53,000
+vulnerabilities in the design phase?
+
+165
+00:14:54,000 --> 00:15:01,000
+This allows developers and security teams to avoid those design mistakes that might not be identified,
+
+166
+00:15:01,000 --> 00:15:02,000
+but later down the line.
+
+167
+00:15:03,000 --> 00:15:10,000
+It also saves organizations time and money by finding and addressing all the potential threats.
+
+168
+00:15:11,000 --> 00:15:17,000
+Where do you work with escalations later in the development process by implementing threat models as
+
+169
+00:15:17,000 --> 00:15:18,000
+a design phase.
+
+170
+00:15:19,000 --> 00:15:27,000
+Security starts to be baked into new code first and more so automation and access to comprehensive standards.
+
+171
+00:15:27,000 --> 00:15:28,000
+Libraries.
+
+172
+00:15:28,000 --> 00:15:35,000
+Swet models can go on throughout the secure development lifecycle, ensuring that the owner abilities
+
+173
+00:15:35,000 --> 00:15:38,000
+are continuously mitigated by quantum matters.
+
+174
+00:15:38,000 --> 00:15:41,000
+So why do we have to do threat modeling?
+
+175
+00:15:42,000 --> 00:15:44,000
+What glow we want to achieve?
+
+176
+00:15:44,000 --> 00:15:50,000
+One of the performs threat modeling would begin to recognize what can go wrong in the system.
+
+177
+00:15:50,000 --> 00:15:57,000
+And this is the main role of strength modeling, because knowing what potentially can go wrong, you
+
+178
+00:15:57,000 --> 00:16:03,000
+start thinking about how you would deal with this in your system and you take this into account in your
+
+179
+00:16:03,000 --> 00:16:04,000
+design.
+
+180
+00:16:05,000 --> 00:16:12,000
+The outputs of the sweat model, which are known as threats, informs decisions that you might make
+
+181
+00:16:12,000 --> 00:16:17,000
+in subsequent design, development, testing and post-deployment phases.
+
+182
+00:16:17,000 --> 00:16:25,000
+I also would like to highlight everyone in the team whose concerns about safety and security of your
+
+183
+00:16:25,000 --> 00:16:28,000
+system is empowered to conduct threats.
+
+184
+00:16:28,000 --> 00:16:36,000
+More of them who can work on threats together as a refinement session or during any other similar turbulence.
+
+185
+00:16:37,000 --> 00:16:41,000
+There's also threats, modeling, manifestos that I'd like to discuss with you too.
+
+186
+00:16:42,000 --> 00:16:44,000
+What these threats model the manifesto.
+
+187
+00:16:45,000 --> 00:16:53,000
+First of all, mentions manifesto is a guide to develop or find a missile that best suits your needs
+
+188
+00:16:53,000 --> 00:17:00,000
+greater than manifest, and believe that all of that guidance is a manifesto will result in more effective
+
+189
+00:17:00,000 --> 00:17:04,000
+and more productive threats, one of them in charge.
+
+190
+00:17:04,000 --> 00:17:10,000
+This will help you to successfully develop more secure applications, systems and organizations and
+
+191
+00:17:10,000 --> 00:17:14,000
+protect them from threats and services.
+
+192
+00:17:15,000 --> 00:17:23,000
+The manifesto contains ideas but is not how to handle business and knowledge agnostic the threat model
+
+193
+00:17:24,000 --> 00:17:26,000
+that includes values and principles.
+
+194
+00:17:27,000 --> 00:17:29,000
+Let's review values first.
+
+195
+00:17:29,000 --> 00:17:30,000
+Values threats.
+
+196
+00:17:30,000 --> 00:17:35,000
+Modeling is something that has relative US merit or importance.
+
+197
+00:17:35,000 --> 00:17:42,000
+It is sad and manifest is that while there is a value in the items on the right, you values the items
+
+198
+00:17:42,000 --> 00:17:43,000
+on the left more.
+
+199
+00:17:44,000 --> 00:17:52,000
+A Culture of finding and fixing design issues over check checkbooks, compliance, people, and collaboration
+
+200
+00:17:52,000 --> 00:17:54,000
+over processes for the religious impulse.
+
+201
+00:17:55,000 --> 00:17:59,000
+A journey of understanding of a security or progress.
+
+202
+00:17:59,000 --> 00:18:07,000
+A snapshot bootstrap model of a talking about continuous refinement over a C of the label.
+
+203
+00:18:08,000 --> 00:18:09,000
+If you are from you I was a gentleman.
+
+204
+00:18:09,000 --> 00:18:16,000
+The first thing you can notice that he used similar format as it is used in Agile Manifesto.
+
+205
+00:18:17,000 --> 00:18:21,000
+Let's review principles of stress modeling manifesting now.
+
+206
+00:18:21,000 --> 00:18:25,000
+A principle describes the fundamental truths of sports modelling.
+
+207
+00:18:26,000 --> 00:18:33,000
+There are three types of principles from the manual, primary or general tools that enable successful
+
+208
+00:18:33,000 --> 00:18:39,000
+modelling part of the highly recommended and onto parts that should be avoided.
+
+209
+00:18:40,000 --> 00:18:47,000
+There are the following principles in the manifesto The best use of sweat modelling is to improve the
+
+210
+00:18:47,000 --> 00:18:49,000
+security and privacy of the systems.
+
+211
+00:18:50,000 --> 00:18:58,000
+Early on, analysis threat modelling must align with an organisation's development practices and follow
+
+212
+00:18:58,000 --> 00:19:04,000
+design changes and iterations that each scope to manageable portions of the system.
+
+213
+00:19:05,000 --> 00:19:11,000
+The outcomes of threat model are meaningful once they are of value to stakeholders.
+
+214
+00:19:12,000 --> 00:19:19,000
+Dialogue is key that establishes a common understandings that meet the value, while documents, record
+
+215
+00:19:19,000 --> 00:19:22,000
+results, understandings and enable measurement.
+
+216
+00:19:23,000 --> 00:19:29,000
+As I already said, values and principles is more like these methods that will determine the opportunities.
+
+217
+00:19:30,000 --> 00:19:37,000
+They don't contain any specifics and just to set their actions and their technology agnostic.
+
diff --git a/73 - OWASP Top 10 2021/010 Insecure Design (Secure Design Process, Security Controls, Metrics, Examples)_en.srt b/73 - OWASP Top 10 2021/010 Insecure Design (Secure Design Process, Security Controls, Metrics, Examples)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..8f2cccb714a6282d77d2f41d5aae48506101a9ae
--- /dev/null
+++ b/73 - OWASP Top 10 2021/010 Insecure Design (Secure Design Process, Security Controls, Metrics, Examples)_en.srt
@@ -0,0 +1,1036 @@
+1
+00:00:03,000 --> 00:00:07,000
+I want to highlight that security design is not a one time action.
+
+2
+00:00:08,000 --> 00:00:11,000
+It is not something you can do in one hour or so.
+
+3
+00:00:12,000 --> 00:00:18,000
+It is a systematic, regular set of actions directed on creation of the sea floor design.
+
+4
+00:00:19,000 --> 00:00:21,000
+And I want you on the stands then.
+
+5
+00:00:22,000 --> 00:00:25,000
+That's why now I'd like to start with you.
+
+6
+00:00:25,000 --> 00:00:26,000
+Was you castles?
+
+7
+00:00:26,000 --> 00:00:30,000
+Do you have to build to ensure secure design on your project?
+
+8
+00:00:30,000 --> 00:00:37,000
+This process includes steps and actions and artifacts that will help you to avoid creation of insecure
+
+9
+00:00:37,000 --> 00:00:46,000
+design and will significantly decrease the community of introducing vulnerabilities related to insecure
+
+10
+00:00:46,000 --> 00:00:46,000
+design.
+
+11
+00:00:47,000 --> 00:00:50,000
+The whole process consists of the following steps.
+
+12
+00:00:51,000 --> 00:00:55,000
+Security Requirements Gathering Definition of compliance requirements.
+
+13
+00:00:55,000 --> 00:00:59,000
+According to the Project on the Market, specific actions.
+
+14
+00:00:59,000 --> 00:01:06,000
+Business Impact Analysis Turning security requirements into regular tickets according to the Selected
+
+15
+00:01:06,000 --> 00:01:08,000
+Software Development Lifecycle.
+
+16
+00:01:09,000 --> 00:01:13,000
+Creation of Architecture of Application, Feature or component.
+
+17
+00:01:14,000 --> 00:01:22,000
+Once requirements will summarize the requirements of code, refinement and estimation of security requirements.
+
+18
+00:01:23,000 --> 00:01:25,000
+Holdings, Threat Modeling Activities.
+
+19
+00:01:26,000 --> 00:01:31,000
+Creation of Threat Register Creation of List of Security Controls.
+
+20
+00:01:32,000 --> 00:01:33,000
+Execution of Gap Analysis.
+
+21
+00:01:34,000 --> 00:01:36,000
+Creation of Security Design Document.
+
+22
+00:01:37,000 --> 00:01:43,000
+We're going to review each step in our lesson one by one, probably.
+
+23
+00:01:43,000 --> 00:01:49,000
+If you'll watch my courses and you'll be aware that I have my consultancy company and that I perform
+
+24
+00:01:49,000 --> 00:01:51,000
+audits of software projects.
+
+25
+00:01:52,000 --> 00:01:58,000
+Usually I make the review of different sides of the project maturity level of engineering, excellence
+
+26
+00:01:58,000 --> 00:02:02,000
+practices, engineering, project management courses.
+
+27
+00:02:02,000 --> 00:02:11,000
+I developed my own delivery model to assess software projects and framework that I develop goes together
+
+28
+00:02:11,000 --> 00:02:15,000
+with guidelines it is recommended to follow to build mature courses.
+
+29
+00:02:16,000 --> 00:02:22,000
+Now I'd like to review is your one of such guidelines dedicated to building mature processes in the
+
+30
+00:02:22,000 --> 00:02:30,000
+organization, the delivery team that will ensure secure design, no matter whether you are developer,
+
+31
+00:02:30,000 --> 00:02:37,000
+faculty or delivery manager understanding of suggested guideline will bring the team to the next quality
+
+32
+00:02:38,000 --> 00:02:38,000
+level.
+
+33
+00:02:39,000 --> 00:02:40,000
+Definitely.
+
+34
+00:02:40,000 --> 00:02:46,000
+I will not share with you all the details, including causal samples, process outputs, responsible
+
+35
+00:02:46,000 --> 00:02:52,000
+people, occurrences, arrests and matches because there is no need in this at the moment.
+
+36
+00:02:53,000 --> 00:02:56,000
+So this assumption would encourage you in my consultancy role.
+
+37
+00:02:56,000 --> 00:03:03,000
+But instead I will highlight the main steps and main goals that we want and that we need to achieve
+
+38
+00:03:03,000 --> 00:03:05,000
+while building civil design of our system.
+
+39
+00:03:06,000 --> 00:03:07,000
+Let's stop.
+
+40
+00:03:08,000 --> 00:03:15,000
+The first step in our process is to identify and gather security requirements, collect and negotiate.
+
+41
+00:03:15,000 --> 00:03:21,000
+The business requirements for an application with the business includes the protection requirements
+
+42
+00:03:21,000 --> 00:03:30,000
+concerning confidentiality, integrity of of ability and authenticity of all data assets on the expected
+
+43
+00:03:30,000 --> 00:03:40,000
+business logic take into account how exposed your application will be and conservation of tenants compiles
+
+44
+00:03:40,000 --> 00:03:44,000
+the technical requirements, including functional and nonfunctional security requirements.
+
+45
+00:03:45,000 --> 00:03:50,000
+On this slide, you can see suggested four months for the security requirements list.
+
+46
+00:03:50,000 --> 00:03:59,000
+There are concerns that are used to suggest a template c stands for confidentiality, IE stands for
+
+47
+00:03:59,000 --> 00:04:02,000
+integrity and stands for availability.
+
+48
+00:04:02,000 --> 00:04:08,000
+A use stands for authenticity and stands for repudiation.
+
+49
+00:04:09,000 --> 00:04:17,000
+Not of reconciliation is an assurance that someone can deny the validity of something basic human right,
+
+50
+00:04:17,000 --> 00:04:20,000
+business requirement, functional or nonfunctional.
+
+51
+00:04:20,000 --> 00:04:28,000
+You map it was a component and you specify a requirements associated with this business requirement.
+
+52
+00:04:29,000 --> 00:04:31,000
+All team participates in this process.
+
+53
+00:04:32,000 --> 00:04:37,000
+Separately, I'd like to highlight the role of the compliance team and business analysis team.
+
+54
+00:04:38,000 --> 00:04:44,000
+The business analyst should define the list of compliance requirements, according to the project and
+
+55
+00:04:44,000 --> 00:04:46,000
+market specific achievements.
+
+56
+00:04:46,000 --> 00:04:54,000
+While compliance security requirements, we should also hold a business impact analysis because some
+
+57
+00:04:54,000 --> 00:04:57,000
+of the requirements will come from the business impact analysis.
+
+58
+00:04:58,000 --> 00:05:03,000
+Once you hold, you will be able to understand security requirements better.
+
+59
+00:05:04,000 --> 00:05:12,000
+That's why I believe it's my big idea to show you how impact analysis can be, how on this slide you
+
+60
+00:05:12,000 --> 00:05:14,000
+can see example of business impact analysis.
+
+61
+00:05:15,000 --> 00:05:18,000
+You can think about different business impact types.
+
+62
+00:05:19,000 --> 00:05:24,000
+After that, you can classify level of impact from 0 to 5.
+
+63
+00:05:25,000 --> 00:05:30,000
+Zero means no impact at all and five means catastrophic impact.
+
+64
+00:05:31,000 --> 00:05:38,000
+And you can map specific impact criteria next to each level of impact and having a list of security
+
+65
+00:05:38,000 --> 00:05:39,000
+requirements.
+
+66
+00:05:39,000 --> 00:05:46,000
+You can prioritize those by business, impact the business panels to come the compliance requirements
+
+67
+00:05:46,000 --> 00:05:49,000
+and results of business impact analysis.
+
+68
+00:05:49,000 --> 00:05:52,000
+The full set of internal security requirements.
+
+69
+00:05:53,000 --> 00:05:54,000
+In the move.
+
+70
+00:05:54,000 --> 00:06:02,000
+I'm going to show you where and how we use this impact classification will use it as a threat modeling
+
+71
+00:06:02,000 --> 00:06:09,000
+to feel free to explore a suggested template for business impact analysis.
+
+72
+00:06:10,000 --> 00:06:17,000
+In this particular case, I show the example only for business impact types, legal and financial.
+
+73
+00:06:18,000 --> 00:06:21,000
+But you can also specify all the business impact types.
+
+74
+00:06:22,000 --> 00:06:30,000
+One year that was the view of this slide resumes if you do and let's move on all this that once you
+
+75
+00:06:30,000 --> 00:06:37,000
+gather security requirements in this list it is better to translate into regular status according to
+
+76
+00:06:37,000 --> 00:06:43,000
+the selected software development lifecycle on track implementation of the security requirements on
+
+77
+00:06:43,000 --> 00:06:50,000
+the same level and in the same way as tracking implementation of the functional and functional requirements.
+
+78
+00:06:50,000 --> 00:06:58,000
+Because usually when I ask teams, what are your store security requirements, we find that some security
+
+79
+00:06:58,000 --> 00:07:01,000
+requirements are stored in the emails.
+
+80
+00:07:01,000 --> 00:07:07,000
+Something was discussed in the messenger, something was documented in conference or other kind of knowledge
+
+81
+00:07:07,000 --> 00:07:08,000
+base.
+
+82
+00:07:08,000 --> 00:07:10,000
+Something was captured and taken.
+
+83
+00:07:11,000 --> 00:07:13,000
+This is not how this should work.
+
+84
+00:07:13,000 --> 00:07:19,000
+You should apply the same workflow for security requirements as for other requirements.
+
+85
+00:07:19,000 --> 00:07:21,000
+That is a key to success.
+
+86
+00:07:22,000 --> 00:07:26,000
+Architect should define architecture of your application feature or component.
+
+87
+00:07:27,000 --> 00:07:33,000
+This is designing courses that should already take into account security requirements for events or
+
+88
+00:07:33,000 --> 00:07:34,000
+regular flow.
+
+89
+00:07:34,000 --> 00:07:37,000
+Tickets should be refined and estimated.
+
+90
+00:07:37,000 --> 00:07:44,000
+Sometimes it is hard to separate functional implementation and security inquiries, so it is also possible
+
+91
+00:07:45,000 --> 00:07:50,000
+that most often security requirements will become part of the feature implementation.
+
+92
+00:07:50,000 --> 00:07:51,000
+And that is fine.
+
+93
+00:07:52,000 --> 00:07:53,000
+You shouldn't be afraid of that.
+
+94
+00:07:54,000 --> 00:07:54,000
+Definitely.
+
+95
+00:07:54,000 --> 00:08:02,000
+There will be owners, managers and marketers who ask you to decrease development estimates constantly
+
+96
+00:08:02,000 --> 00:08:03,000
+challenging you.
+
+97
+00:08:03,000 --> 00:08:09,000
+Whether you need to spend some time on the implementation of security controls right now, or it can
+
+98
+00:08:09,000 --> 00:08:16,000
+be put into separate, taken and left as a technical debt, then me, once you create technical date,
+
+99
+00:08:16,000 --> 00:08:18,000
+that means you can forget about it.
+
+100
+00:08:19,000 --> 00:08:25,000
+The dynamic of I.T and software development doesn't allow to look back.
+
+101
+00:08:25,000 --> 00:08:26,000
+Never.
+
+102
+00:08:26,000 --> 00:08:33,000
+That's why I want to ask you to stay strong and highlight the importance and necessity of implementation
+
+103
+00:08:33,000 --> 00:08:37,000
+of security controls and secure design during the future.
+
+104
+00:08:37,000 --> 00:08:45,000
+Development program is always a matter of tradeoffs between business and technology and speed and quality.
+
+105
+00:08:45,000 --> 00:08:52,000
+Let's remember, business and technology should go hand in hand with each other, and you will win the
+
+106
+00:08:52,000 --> 00:08:59,000
+market only if you can find the right balance based on all information, gather the action that can
+
+107
+00:08:59,000 --> 00:09:01,000
+conduct smart modeling.
+
+108
+00:09:01,000 --> 00:09:07,000
+Having all this information means that we have enough information to model different threats.
+
+109
+00:09:07,000 --> 00:09:13,000
+Like I already said, this experience, it can be done by all team or any team member.
+
+110
+00:09:13,000 --> 00:09:19,000
+But definitely if you have security using your team, this person has enough skills.
+
+111
+00:09:19,000 --> 00:09:23,000
+Someone knows threats based on his or her experience.
+
+112
+00:09:24,000 --> 00:09:28,000
+On this slide, you can see an example of Sweat's register and how it can look.
+
+113
+00:09:29,000 --> 00:09:34,000
+Basically you can come up with your own way to search for sweat register.
+
+114
+00:09:34,000 --> 00:09:38,000
+I just suggest the one that I use on my projects.
+
+115
+00:09:39,000 --> 00:09:44,000
+Most of the columns are self-described sweat type and go one of the following.
+
+116
+00:09:44,000 --> 00:09:54,000
+See confidentiality, integrity, a availability, a you authenticity and non reconciliation.
+
+117
+00:09:55,000 --> 00:09:58,000
+The following columns US Red Thread Description.
+
+118
+00:09:59,000 --> 00:10:06,000
+If you don't have any questions regarding Zeus, in case there are any questions, please do not hesitate
+
+119
+00:10:06,000 --> 00:10:11,000
+to ask your questions below this video and I will be happy to answer.
+
+120
+00:10:12,000 --> 00:10:17,000
+And acid is an integral device as a component of an organization's systems.
+
+121
+00:10:18,000 --> 00:10:25,000
+It is valuable often because it contains sensitive data or can be used to access such information,
+
+122
+00:10:26,000 --> 00:10:30,000
+or that impact will review and learns how to classify and pack.
+
+123
+00:10:31,000 --> 00:10:38,000
+For example, you can see that sensitive data leakage is catastrophic, legal and regulatory impact.
+
+124
+00:10:39,000 --> 00:10:44,000
+Thus, this is critical importance of this security requirement.
+
+125
+00:10:44,000 --> 00:10:47,000
+Is it clear that's how it works?
+
+126
+00:10:48,000 --> 00:10:51,000
+Probability is basically probability of stress.
+
+127
+00:10:51,000 --> 00:10:56,000
+Assume in most cases this is most subjective evaluation.
+
+128
+00:10:56,000 --> 00:11:02,000
+Whereas as an objective is a mitigation column, you can just paste idea of security control.
+
+129
+00:11:03,000 --> 00:11:10,000
+In a minute we are going to review how the lethal security controls can look like and basically risk
+
+130
+00:11:10,000 --> 00:11:13,000
+corner is a person who is in charge of managing this threat.
+
+131
+00:11:13,000 --> 00:11:21,000
+Thought the security engineer should identify and understand project level threats based on the functionality
+
+132
+00:11:21,000 --> 00:11:25,000
+of the software being developed on the characteristics of the runtime environment.
+
+133
+00:11:26,000 --> 00:11:31,000
+I also promised to show you how the list of security controls can look good.
+
+134
+00:11:32,000 --> 00:11:36,000
+On this slide, you can see just the structure of the security control list.
+
+135
+00:11:37,000 --> 00:11:40,000
+You can refer to each security control by its ID.
+
+136
+00:11:41,000 --> 00:11:45,000
+So this is also one of the steps in our process to create a design.
+
+137
+00:11:46,000 --> 00:11:50,000
+And this step is called Great List of Security Controls.
+
+138
+00:11:50,000 --> 00:11:57,000
+One more time let's formalize the term of security control and need to define what it is.
+
+139
+00:11:58,000 --> 00:12:06,000
+Security controls are parameters implemented to protect various forms of data and infrastructure important
+
+140
+00:12:06,000 --> 00:12:15,000
+to an organization and any type of safeguard as it used to avoid, detect, contract or minimize security
+
+141
+00:12:15,000 --> 00:12:22,000
+risks to physical property information, computer systems or other assets is considered as security
+
+142
+00:12:22,000 --> 00:12:23,000
+control.
+
+143
+00:12:24,000 --> 00:12:32,000
+There are different types of security controls, zero physical security controls that include such things
+
+144
+00:12:32,000 --> 00:12:39,000
+as Staples Center, perimeter fence and locks, guards access control cards, biometric access control
+
+145
+00:12:39,000 --> 00:12:45,000
+systems, surveillance cameras and intrusion detection sensors.
+
+146
+00:12:46,000 --> 00:12:51,000
+Digital security controls include such things as usernames and passwords.
+
+147
+00:12:51,000 --> 00:12:56,000
+Two factor authentication antivirus software and firewalls.
+
+148
+00:12:57,000 --> 00:13:04,000
+Cybersecurity controls include anything specifically designed to prevent attacks on data, including
+
+149
+00:13:04,000 --> 00:13:08,000
+the loss mitigation and intrusion prevention systems.
+
+150
+00:13:09,000 --> 00:13:17,000
+Cloud security controls include measures it takes in cooperation with a cloud services provider to ensure
+
+151
+00:13:17,000 --> 00:13:20,000
+the necessary protection for data and workloads.
+
+152
+00:13:21,000 --> 00:13:24,000
+Improvisation runs workloads on the cloud.
+
+153
+00:13:25,000 --> 00:13:31,000
+You must needs a corporate or business policy, security requirements and industry regulations.
+
+154
+00:13:32,000 --> 00:13:41,000
+And just as a reference a cloud work log Zen is an application service type ability or a specified amount
+
+155
+00:13:41,000 --> 00:13:47,000
+of work that consumes cloud based resources such as computing or memory power.
+
+156
+00:13:48,000 --> 00:13:54,000
+Also, it is recommended to do a few things to ensure a secure design defines the current status of
+
+157
+00:13:54,000 --> 00:14:02,000
+security controls, covering integrity, confidentiality, access, control, etc. defines the current
+
+158
+00:14:02,000 --> 00:14:08,000
+status of security controls, conference ID, Business Continuity Plan, Disaster Recovery Plan, Project
+
+159
+00:14:08,000 --> 00:14:10,000
+Management, Change Management.
+
+160
+00:14:10,000 --> 00:14:15,000
+So security controls can look like you see on the slide.
+
+161
+00:14:16,000 --> 00:14:20,000
+Security engineers should also perform gap analysis.
+
+162
+00:14:21,000 --> 00:14:28,000
+The security engineer should compare the required security controls and existing legacy controls of
+
+163
+00:14:28,000 --> 00:14:28,000
+the project.
+
+164
+00:14:29,000 --> 00:14:36,000
+On this slide, you can see suggested data structure, whereas the results of this analysis can be stored.
+
+165
+00:14:37,000 --> 00:14:42,000
+After gaps are identified, the team has to work on resolving these gaps.
+
+166
+00:14:43,000 --> 00:14:48,000
+All the steps that we have reviewed should be summarized in the security design document.
+
+167
+00:14:49,000 --> 00:14:56,000
+Security Design document is a comprehensive artifact that I would be able to put on the one single slot.
+
+168
+00:14:57,000 --> 00:14:59,000
+It contains different sections.
+
+169
+00:14:59,000 --> 00:15:07,000
+The main sections should be covered in a document approach conceptual infrastructure security, interview
+
+170
+00:15:07,000 --> 00:15:11,000
+areas, conceptual security design processes.
+
+171
+00:15:11,000 --> 00:15:12,000
+Conceptual Situation.
+
+172
+00:15:12,000 --> 00:15:15,000
+Infrastructure Architecture Design.
+
+173
+00:15:15,000 --> 00:15:16,000
+Security Design.
+
+174
+00:15:17,000 --> 00:15:21,000
+Each of these sections may contain all sections.
+
+175
+00:15:21,000 --> 00:15:28,000
+For example, as a conceptual security infrastructure, architecture design can also cover security
+
+176
+00:15:28,000 --> 00:15:35,000
+policy, security threats, network security, software, application security and others.
+
+177
+00:15:35,000 --> 00:15:42,000
+I would say that the content of this document depends on the actual project that the work on.
+
+178
+00:15:42,000 --> 00:15:49,000
+This is also part of my job as a consultant on the licenses on the project and support team was the
+
+179
+00:15:49,000 --> 00:15:56,000
+summation of the direction where all the team were to go, including software engineering team.
+
+180
+00:15:56,000 --> 00:16:03,000
+All this process that we have discussed should go together with measure and causal metrics and understand
+
+181
+00:16:03,000 --> 00:16:10,000
+that chance and dynamics, because without it, we won't be able to answer whether we are doing a good
+
+182
+00:16:10,000 --> 00:16:11,000
+job or not.
+
+183
+00:16:12,000 --> 00:16:18,000
+Zircon, the different magics applied to measure the effectiveness of the causes of build insecure design.
+
+184
+00:16:19,000 --> 00:16:26,000
+But some of them are metrics of threats, religious, the number of threats, open number of threats,
+
+185
+00:16:26,000 --> 00:16:34,000
+closed number of sites, mitigated metrics of requirements list number of requirements not process number
+
+186
+00:16:34,000 --> 00:16:42,000
+of requirements importance number of requirements done matchups of control list number of controls to
+
+187
+00:16:42,000 --> 00:16:49,000
+do number of controls and process number of controls in review number of controls.
+
+188
+00:16:49,000 --> 00:16:56,000
+Don't measure these metrics, store them, add them into this system or regular reports.
+
+189
+00:16:56,000 --> 00:17:01,000
+Builds trends to understand how efficiency and the team work on secure design.
+
+190
+00:17:02,000 --> 00:17:05,000
+Now let's review example of parts.
+
+191
+00:17:06,000 --> 00:17:12,000
+Example number one will review reviewed with one example as the beginning of this lesson.
+
+192
+00:17:12,000 --> 00:17:19,000
+Let me recall, not so long ago, questions were used to restore access.
+
+193
+00:17:19,000 --> 00:17:25,000
+I if you are familiar with this scenario, you and registration, you are asked about secret question,
+
+194
+00:17:26,000 --> 00:17:28,000
+the name of your pad or something like this.
+
+195
+00:17:29,000 --> 00:17:33,000
+And the answer is used when you need to restore access to your account.
+
+196
+00:17:34,000 --> 00:17:40,000
+It is not a mainstream anymore, primarily because of the potential vulnerabilities caused by insecure
+
+197
+00:17:40,000 --> 00:17:41,000
+design.
+
+198
+00:17:42,000 --> 00:17:45,000
+I must top them, have lots of questions and answers.
+
+199
+00:17:45,000 --> 00:17:53,000
+Can't be trusted as evidence of identity, as more than one person can knows the answers, which is
+
+200
+00:17:53,000 --> 00:17:54,000
+why they are prohibited.
+
+201
+00:17:55,000 --> 00:17:59,000
+Such codes should be removed and replaced with a more secure design.
+
+202
+00:18:00,000 --> 00:18:08,000
+Example number two Imagine that we developed software for cinema chain and according to design required
+
+203
+00:18:08,000 --> 00:18:12,000
+the only in case 50 attendees book tickets together at once.
+
+204
+00:18:13,000 --> 00:18:18,000
+In all other cases, we trust our customers and they can book tickets.
+
+205
+00:18:18,000 --> 00:18:22,000
+And why the ticket office once they will come to the cinema.
+
+206
+00:18:23,000 --> 00:18:25,000
+This is also an example of insecure design.
+
+207
+00:18:26,000 --> 00:18:33,000
+If all of the analyzed business impact, discuss different scenarios, gather security requirements
+
+208
+00:18:33,000 --> 00:18:40,000
+and hold threats more, then we will discover that using this behavior, attackers can cause significant
+
+209
+00:18:40,000 --> 00:18:42,000
+impact on our business.
+
+210
+00:18:42,000 --> 00:18:50,000
+I can create a script that will book 1000 seats in the cinema chain, placing orders for 14 tickets
+
+211
+00:18:50,000 --> 00:18:51,000
+for major cinema.
+
+212
+00:18:51,000 --> 00:18:54,000
+This will cause a massive loss of income.
+
+213
+00:18:55,000 --> 00:19:04,000
+Example number three A retail chain e-commerce website doesn't have protection against was run by scalpers
+
+214
+00:19:04,000 --> 00:19:07,000
+buying high end video cards to sell them.
+
+215
+00:19:08,000 --> 00:19:15,000
+This creates terrible publicity for the video parts makers and retail chain owners and doesn't allow
+
+216
+00:19:15,000 --> 00:19:18,000
+people to buy video cards for analysis.
+
+217
+00:19:18,000 --> 00:19:25,000
+And their attackers can write a script, registers accounts and constantly place orders without binds
+
+218
+00:19:25,000 --> 00:19:25,000
+them.
+
+219
+00:19:26,000 --> 00:19:31,000
+Thus, the product is always not in stock and also not sold.
+
+220
+00:19:32,000 --> 00:19:39,000
+People can't buy product because there was 20 minutes to pay order once it was placed.
+
+221
+00:19:40,000 --> 00:19:44,000
+This is also insecure design and attackers can use zuse.
+
+222
+00:19:44,000 --> 00:19:52,000
+When I do this careful and towards design and domain logic rules such as purchases made within a few
+
+223
+00:19:52,000 --> 00:19:59,000
+seconds of availability might identify email sending purchases and reject such transactions.
+
+224
+00:19:59,000 --> 00:20:08,000
+Even this part we have discussed already how to setup causes of any ensure secure design and avoid vulnerability
+
+225
+00:20:08,000 --> 00:20:15,000
+simulated was insecure design even despite all this still, I would like to summarize rules, guides
+
+226
+00:20:15,000 --> 00:20:18,000
+and viruses how to prevent insecure design.
+
+227
+00:20:19,000 --> 00:20:26,000
+Establish and use a secure development lifecycle with security professionals to help evaluate and design
+
+228
+00:20:26,000 --> 00:20:29,000
+security and privacy related controls.
+
+229
+00:20:30,000 --> 00:20:33,000
+This is something we have talked about in all the lesson.
+
+230
+00:20:34,000 --> 00:20:41,000
+Use threat modeling for critical authentication, access control, business logic and key flows.
+
+231
+00:20:41,000 --> 00:20:46,000
+Integrate security and controls into user stories.
+
+232
+00:20:46,000 --> 00:20:48,000
+I also highlighted this one.
+
+233
+00:20:48,000 --> 00:20:55,000
+We talked about the causes we should make work on security items, part of our general development flow.
+
+234
+00:20:56,000 --> 00:21:03,000
+Write an integration test to validate that all critical flows are resistant to this threat model.
+
+235
+00:21:04,000 --> 00:21:04,000
+Compound.
+
+236
+00:21:04,000 --> 00:21:10,000
+Use cases and misuse cases for each type of application.
+
+237
+00:21:10,000 --> 00:21:17,000
+Segregate tilers on the system that requires dependent on the exposure and protection needs.
+
+238
+00:21:18,000 --> 00:21:21,000
+That's all what I wanted to share with you in this lesson.
+
+239
+00:21:22,000 --> 00:21:24,000
+Let's recap what we have learned.
+
+240
+00:21:25,000 --> 00:21:28,000
+This was long, but I'm sure a very useful lesson.
+
+241
+00:21:29,000 --> 00:21:30,000
+I hope you enjoyed it.
+
+242
+00:21:31,000 --> 00:21:37,000
+Today we learned what insecure design is after this lesson, even though there's a difference between
+
+243
+00:21:37,000 --> 00:21:41,000
+insecure design and insecure implementation.
+
+244
+00:21:42,000 --> 00:21:49,000
+Goodman's shift left approach, I explained, is a most notable common defense enumerations.
+
+245
+00:21:50,000 --> 00:21:58,000
+We also learned what a secure design is significant because of our less educated to smart modern vendors,
+
+246
+00:21:58,000 --> 00:22:04,000
+whether this is go freelance or model and manifesto.
+
+247
+00:22:05,000 --> 00:22:06,000
+Now you know what it is.
+
+248
+00:22:06,000 --> 00:22:09,000
+We learned its values and principles.
+
+249
+00:22:10,000 --> 00:22:17,000
+Also use the lesson I explained to how to build a secure design process while talking about security
+
+250
+00:22:17,000 --> 00:22:18,000
+and process.
+
+251
+00:22:18,000 --> 00:22:21,000
+We learned what a business impact analysis is.
+
+252
+00:22:22,000 --> 00:22:27,000
+I even shared a template that you can use as a business impact analysis.
+
+253
+00:22:28,000 --> 00:22:35,000
+I showed you on example how works in a work with sweats, register the learn the concept of security
+
+254
+00:22:35,000 --> 00:22:39,000
+controls and we learned how to create a list of security controls.
+
+255
+00:22:40,000 --> 00:22:44,000
+I explained what a security design document is.
+
+256
+00:22:44,000 --> 00:22:49,000
+We have used examples of attacks and we learned how to prevent them.
+
+257
+00:22:50,000 --> 00:22:51,000
+That's all for this lesson.
+
+258
+00:22:52,000 --> 00:22:53,000
+Thanks for your attention.
+
+259
+00:22:54,000 --> 00:22:56,000
+Have a great day and see you in the next lesson.
+
diff --git a/73 - OWASP Top 10 2021/011 NIST-800-123-Guide-to-General-Server-Security.url b/73 - OWASP Top 10 2021/011 NIST-800-123-Guide-to-General-Server-Security.url
new file mode 100644
index 0000000000000000000000000000000000000000..b9a54332b6c450429c41014297cd08691974eeb4
--- /dev/null
+++ b/73 - OWASP Top 10 2021/011 NIST-800-123-Guide-to-General-Server-Security.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-123.pdf
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/011 NIST-800-207-Zero-Trust-Architecture.url b/73 - OWASP Top 10 2021/011 NIST-800-207-Zero-Trust-Architecture.url
new file mode 100644
index 0000000000000000000000000000000000000000..865c0f1106b6178c0a9b40dc49473a2d35688e31
--- /dev/null
+++ b/73 - OWASP Top 10 2021/011 NIST-800-207-Zero-Trust-Architecture.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/011 Security Misconfiguration (Overview, CWEs, Types, Real-life attacks)_en.srt b/73 - OWASP Top 10 2021/011 Security Misconfiguration (Overview, CWEs, Types, Real-life attacks)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..b02f374fe3dc427c9fb088b3c97ed59df3f7341a
--- /dev/null
+++ b/73 - OWASP Top 10 2021/011 Security Misconfiguration (Overview, CWEs, Types, Real-life attacks)_en.srt
@@ -0,0 +1,828 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello Tim.
+
+2
+00:00:06,000 --> 00:00:13,000
+And this has background to talk about security misconfiguration risk category from a wasp top ten will
+
+3
+00:00:13,000 --> 00:00:17,000
+start the lesson from the general overview of this risk category.
+
+4
+00:00:17,000 --> 00:00:22,000
+Probably explain what the potential impact may be caused by security in this configuration.
+
+5
+00:00:23,000 --> 00:00:26,000
+To gather, we'll review the most notable common weakness.
+
+6
+00:00:26,000 --> 00:00:34,000
+Enumerations, as always, will make a comparison between of US Top ten, 20, 21 and 2017.
+
+7
+00:00:35,000 --> 00:00:38,000
+I will explain the different types of security in this configuration.
+
+8
+00:00:39,000 --> 00:00:45,000
+Will reviews the most popular examples of attacks that says Cessful because of the security in this
+
+9
+00:00:45,000 --> 00:00:46,000
+configuration.
+
+10
+00:00:46,000 --> 00:00:54,000
+Also, as we will keep on new topic, I will explain what security hardening is, what zero trust security
+
+11
+00:00:54,000 --> 00:01:03,000
+model is, and what defense and gaps this will learn these new concepts because I believe it is really
+
+12
+00:01:03,000 --> 00:01:08,000
+important to know that will also review best practices for system hardening.
+
+13
+00:01:09,000 --> 00:01:16,000
+And after all this, I'm going to show you them on the example of general web application and review,
+
+14
+00:01:16,000 --> 00:01:22,000
+as is some examples of security misconfiguration vulnerabilities and the zant of this lesson.
+
+15
+00:01:22,000 --> 00:01:28,000
+We're going to make a summary with all what we have learned and will discuss how to prevent security.
+
+16
+00:01:28,000 --> 00:01:32,000
+Misconfigurations Let's start our lesson.
+
+17
+00:01:32,000 --> 00:01:36,000
+Let's name first what security Misconfigurations category is all about.
+
+18
+00:01:37,000 --> 00:01:43,000
+Security Misconfiguration happens when security settings are not properly set during the configuration
+
+19
+00:01:43,000 --> 00:01:48,000
+process or deployed and mine was default settings.
+
+20
+00:01:48,000 --> 00:01:55,000
+One of the most common and frequent occurrence is to configure systems that could affect any of the
+
+21
+00:01:55,000 --> 00:02:02,000
+applications stack, network, layer and cloud misconfigured cloud central core.
+
+22
+00:02:02,000 --> 00:02:09,000
+So data breaches customer organizations millions of dollars common misconfiguration vulnerabilities
+
+23
+00:02:09,000 --> 00:02:16,000
+arise was the use of the following default passwords open database instances.
+
+24
+00:02:16,000 --> 00:02:22,000
+This mode allows any valid user to connect as a database and perform data access operations.
+
+25
+00:02:23,000 --> 00:02:31,000
+Deprecate the protocols and encryption error messages, revealing sensitive information, directly enabled
+
+26
+00:02:32,000 --> 00:02:40,000
+default certificates, misconfigured cloud settings and necessary features such as pages, ports services
+
+27
+00:02:40,000 --> 00:02:48,000
+enabled due to default installation leading to force browsing comments, injection, brute force credential,
+
+28
+00:02:48,000 --> 00:02:49,000
+stuffing, etc..
+
+29
+00:02:50,000 --> 00:02:56,000
+To understand better why security misconfiguration may be dangerous, let's review just some of the
+
+30
+00:02:56,000 --> 00:02:59,000
+potential impacts that may be caused by security.
+
+31
+00:02:59,000 --> 00:03:00,000
+Misconfiguration.
+
+32
+00:03:01,000 --> 00:03:09,000
+Misconfiguration of web server database storage buckets, applications libraries, operating system
+
+33
+00:03:09,000 --> 00:03:15,000
+coding frameworks platforms, virtual machines certificates, encryption settings.
+
+34
+00:03:15,000 --> 00:03:23,000
+Cloud impacts different aspects of vulnerability, integrity and confidentiality triad.
+
+35
+00:03:23,000 --> 00:03:31,000
+Depending on the nature of the vulnerability, this could lead to unauthorized access, account takeover,
+
+36
+00:03:31,000 --> 00:03:39,000
+sensitive data exposure, data, system compromise, and legal and financial implications.
+
+37
+00:03:39,000 --> 00:03:46,000
+As a result of this vulnerability, security misconfigurations can be a result of relatively simple
+
+38
+00:03:46,000 --> 00:03:52,000
+oversights, but can expose an application to attack in certain instances.
+
+39
+00:03:53,000 --> 00:04:01,000
+Use configuration mainly information in schools so a cybercriminal won't even need to carry out an active
+
+40
+00:04:01,000 --> 00:04:02,000
+attack.
+
+41
+00:04:03,000 --> 00:04:09,000
+The low code and data exposed to users big Uris for application security.
+
+42
+00:04:10,000 --> 00:04:17,000
+For example, a misconfigured database server can cause data to be accessible through a basic web search.
+
+43
+00:04:17,000 --> 00:04:25,000
+If this dating pools, administrator, credentials and attack may be able to access the data beyond
+
+44
+00:04:25,000 --> 00:04:29,000
+a database or launch another attack on the company's service.
+
+45
+00:04:30,000 --> 00:04:38,000
+In the case of misconfigured apps and security controls and storage devices, huge amounts of sensitive
+
+46
+00:04:38,000 --> 00:04:41,000
+and personal data can be exposed to the general public.
+
+47
+00:04:41,000 --> 00:04:49,000
+With the internet generally, there is no way of discovering who might have access to this information
+
+48
+00:04:49,000 --> 00:04:50,000
+before it was secure.
+
+49
+00:04:51,000 --> 00:05:00,000
+If you can't block access an application structure attackers can exploit to modify parts of our reverse
+
+50
+00:05:00,000 --> 00:05:03,000
+engineer application attackers.
+
+51
+00:05:03,000 --> 00:05:08,000
+Can exploit it to modify parts of or reverse engineer the application.
+
+52
+00:05:09,000 --> 00:05:15,000
+This might be hard to control if an application is meant for delivery to mobile devices.
+
+53
+00:05:16,000 --> 00:05:22,000
+These are just some potential impacts that may be caused by security misconfiguration.
+
+54
+00:05:22,000 --> 00:05:29,000
+During the last year we're going to review different cases and examples and you will be able to understand
+
+55
+00:05:29,000 --> 00:05:32,000
+all potential impact data by the end of the lesson.
+
+56
+00:05:32,000 --> 00:05:39,000
+As always, let's review notable common weakness enumerations that are associated with this risk category.
+
+57
+00:05:40,000 --> 00:05:40,000
+Zero.
+
+58
+00:05:41,000 --> 00:05:45,000
+CW e6 sim configuration weakness.
+
+59
+00:05:46,000 --> 00:05:50,000
+In this category, I typically introduce as a configuration of the software.
+
+60
+00:05:51,000 --> 00:06:00,000
+This includes but not limited to such vulnerabilities as remote code execution, insecure proxy configuration,
+
+61
+00:06:00,000 --> 00:06:03,000
+denial of service, etc..
+
+62
+00:06:04,000 --> 00:06:06,000
+S.W.A.T. 611.
+
+63
+00:06:07,000 --> 00:06:15,000
+Improper restriction of X amount external entity reference the software processes and excellent documents
+
+64
+00:06:15,000 --> 00:06:23,000
+that contain excellent entities was your eyes that resolve the documents outside of the intense sphere
+
+65
+00:06:23,000 --> 00:06:31,000
+of control, causing all of them that incorrect documents entities output x amount documents optionally
+
+66
+00:06:31,000 --> 00:06:40,000
+contain and document type definition date to the which among closet features labels is a definition
+
+67
+00:06:40,000 --> 00:06:42,000
+of external entities.
+
+68
+00:06:42,000 --> 00:06:50,000
+It is possible to define an entity by providing a substitution string in the form of a you arrive at
+
+69
+00:06:50,000 --> 00:06:59,000
+smoke pass can access the contents of this array and and that this contents back into excellent documents
+
+70
+00:06:59,000 --> 00:07:00,000
+for further processing.
+
+71
+00:07:01,000 --> 00:07:09,000
+Once the content of the you write is read, it is fed back into the application this process since the
+
+72
+00:07:09,000 --> 00:07:10,000
+x amount.
+
+73
+00:07:10,000 --> 00:07:19,000
+This application may echo bags of data, for example, in an error message is thereby exposing the file
+
+74
+00:07:19,000 --> 00:07:20,000
+contents.
+
+75
+00:07:21,000 --> 00:07:25,000
+Let's compare was top ten, 20, 21 and 2017.
+
+76
+00:07:26,000 --> 00:07:29,000
+Mother in software gets increasingly complex.
+
+77
+00:07:30,000 --> 00:07:38,000
+We moved from Simple Systems was one web server and one database to microservice architecture where
+
+78
+00:07:38,000 --> 00:07:41,000
+we have several services deployed on multiple servers.
+
+79
+00:07:42,000 --> 00:07:50,000
+These are connected to the Internet by clusters of reverse proxies and load balancers, Amazon's reusable
+
+80
+00:07:50,000 --> 00:07:56,000
+and used configurations to fit into different environments and applications with increasing amounts
+
+81
+00:07:56,000 --> 00:07:58,000
+of configuration options.
+
+82
+00:07:58,000 --> 00:08:04,000
+It's no wonder that this category moved up in the top ten 2021.
+
+83
+00:08:04,000 --> 00:08:12,000
+Talking about differences, I want to highlight that I was largest external external entities from OWASP
+
+84
+00:08:12,000 --> 00:08:19,000
+top ten 2017 into security misconfiguration this category in our top ten 2021.
+
+85
+00:08:20,000 --> 00:08:26,000
+We already talked with you about the most common reasons of security in this configuration of the beginning
+
+86
+00:08:26,000 --> 00:08:27,000
+of the lesson.
+
+87
+00:08:27,000 --> 00:08:32,000
+I just suggest you use those in more details and more thoroughly.
+
+88
+00:08:32,000 --> 00:08:34,000
+So let's go one by one.
+
+89
+00:08:35,000 --> 00:08:39,000
+Default accounts, passwords, enabled use.
+
+90
+00:08:39,000 --> 00:08:45,000
+And then this five defaults for system accounts and passwords is a common security misconfiguration
+
+91
+00:08:46,000 --> 00:08:50,000
+and may allow attackers to gain unauthorized access to the system.
+
+92
+00:08:51,000 --> 00:08:54,000
+Secure password policy is not implemented.
+
+93
+00:08:54,000 --> 00:09:01,000
+Failure to implement a password policy may allow attackers to gain unauthorized access to the system
+
+94
+00:09:01,000 --> 00:09:09,000
+by masses, such as using this common username and password to brute force the username and password
+
+95
+00:09:09,000 --> 00:09:19,000
+field until successful authentication software is out of date and loss on failure to update software
+
+96
+00:09:19,000 --> 00:09:19,000
+consciousness.
+
+97
+00:09:19,000 --> 00:09:27,000
+Parts of the software management process might allow attackers to use techniques such as code injection
+
+98
+00:09:27,000 --> 00:09:28,000
+to inject malicious code.
+
+99
+00:09:29,000 --> 00:09:35,000
+The applications executes files and directories unprotected.
+
+100
+00:09:35,000 --> 00:09:43,000
+Leaving files and directories unprotected may allow attackers to use techniques such as forceful browsing
+
+101
+00:09:43,000 --> 00:09:52,000
+to gain access to restricted files or areas in the server director and used features enabled or installed.
+
+102
+00:09:53,000 --> 00:09:59,000
+Failing to remove unnecessary features, components, documentation and samples makes the application
+
+103
+00:09:59,000 --> 00:10:06,000
+susceptible to misconfiguration vulnerabilities and may allow attackers to use techniques such as code
+
+104
+00:10:06,000 --> 00:10:11,000
+injection to inject malicious code creations in executes.
+
+105
+00:10:12,000 --> 00:10:16,000
+Security features not maintained or concealed properly.
+
+106
+00:10:17,000 --> 00:10:23,000
+Failure to properly configure and maintain security features makes the application vulnerable in this
+
+107
+00:10:23,000 --> 00:10:24,000
+configuration.
+
+108
+00:10:24,000 --> 00:10:32,000
+Attacks on published URLs are not blocked from receiving traffic from ordinary users, and published
+
+109
+00:10:33,000 --> 00:10:40,000
+URLs accessed by those who are making applications are not intended to receive traffic from ordinary
+
+110
+00:10:40,000 --> 00:10:41,000
+users.
+
+111
+00:10:41,000 --> 00:10:47,000
+Failure to block this use can pose a significant risk when attackers counsel them.
+
+112
+00:10:49,000 --> 00:10:52,000
+Improper or poor application coding practices.
+
+113
+00:10:53,000 --> 00:10:58,000
+Improper coding practices can lead to security misconfiguration attacks, for example.
+
+114
+00:10:59,000 --> 00:11:06,000
+The lack of proper input out data validation may lead to code injection attacks, which work by injecting
+
+115
+00:11:06,000 --> 00:11:08,000
+codes as application executes.
+
+116
+00:11:09,000 --> 00:11:14,000
+By the way, we have separate less involved injection risk category.
+
+117
+00:11:14,000 --> 00:11:16,000
+Feel free to watch it.
+
+118
+00:11:17,000 --> 00:11:25,000
+Directory traversal allows an attacker to access the directories, files and commands that the outside
+
+119
+00:11:25,000 --> 00:11:32,000
+of the directory arm was to access the application source code or configuration and critical system
+
+120
+00:11:32,000 --> 00:11:33,000
+files.
+
+121
+00:11:33,000 --> 00:11:41,000
+Cybercriminal can change a euro in such a way that the creation could execute or displayed the contents
+
+122
+00:11:41,000 --> 00:11:50,000
+of arbitrary files on the server and any device or application reveals an issue based interface is possible
+
+123
+00:11:50,000 --> 00:11:53,000
+vulnerable to the directory traversal attack.
+
+124
+00:11:54,000 --> 00:12:00,000
+As I always say, it is better to use the experience of other organizations rather than advocacy on
+
+125
+00:12:00,000 --> 00:12:01,000
+your own.
+
+126
+00:12:02,000 --> 00:12:09,000
+That's why I believe it will be interesting and very helpful to review the most popular real life configuration
+
+127
+00:12:09,000 --> 00:12:11,000
+attacks from history.
+
+128
+00:12:11,000 --> 00:12:16,000
+By the way, it is also rule of thumb the storage of lessons learned.
+
+129
+00:12:16,000 --> 00:12:23,000
+You can have such storage in the scope of your all organization or in the scope of just one single project.
+
+130
+00:12:24,000 --> 00:12:31,000
+Archive of Lessons Learned is a priceless knowledge base that can help you with repeatable mistakes
+
+131
+00:12:31,000 --> 00:12:33,000
+and avoid the challenges in the future.
+
+132
+00:12:34,000 --> 00:12:43,000
+Example number one Nossa and Gira the first real examples of a or avidity is about not so humble if
+
+133
+00:12:43,000 --> 00:12:51,000
+you no such organization, Zebra Aviation stands for the National Aeronautics and Space Administration.
+
+134
+00:12:51,000 --> 00:12:58,000
+It is an independent agency of the US federal government responsible for the civil space program.
+
+135
+00:12:59,000 --> 00:13:07,000
+I run Multics research and Space Research and Security Research and discovered a security misconfiguration
+
+136
+00:13:07,000 --> 00:13:09,000
+in the collaboration tool JIRA.
+
+137
+00:13:10,000 --> 00:13:19,000
+This single misconfiguration made many Fortune 500 companies and also vulnerable to the release of personal
+
+138
+00:13:19,000 --> 00:13:24,000
+and corporate data and authorization misconfiguration in the global permissions settings.
+
+139
+00:13:24,000 --> 00:13:33,000
+Of course, this data disclosure ones, the dashboards and filters for the projects developed in JIRA
+
+140
+00:13:33,000 --> 00:13:42,000
+Xen by default is a visibility settings of all users and everyone, rather than sharing road map tasks
+
+141
+00:13:42,000 --> 00:13:44,000
+and the like within the organization.
+
+142
+00:13:45,000 --> 00:13:47,000
+Each shared zoom was a problem.
+
+143
+00:13:47,000 --> 00:13:48,000
+Lessons learned.
+
+144
+00:13:49,000 --> 00:13:56,000
+Look at the file sharing configurations in each software as a service to make sure confidential data
+
+145
+00:13:56,000 --> 00:13:58,000
+is not revealed publicly.
+
+146
+00:13:58,000 --> 00:14:02,000
+Example number two Amazon and data breaches.
+
+147
+00:14:03,000 --> 00:14:11,000
+Many organizations experienced data breaches as a result of unsecured storage buckets on Amazon's popular
+
+148
+00:14:11,000 --> 00:14:13,000
+S3 storage service.
+
+149
+00:14:14,000 --> 00:14:21,000
+For example, the U.S. Army Intelligence and Security Command inadvertently stored sensitive database
+
+150
+00:14:21,000 --> 00:14:28,000
+files, some of them marked top secret in S3 authentication.
+
+151
+00:14:29,000 --> 00:14:36,000
+Some organizations complained about the leakage of hashed passwords, internal resources and keys.
+
+152
+00:14:36,000 --> 00:14:43,000
+Other companies complained about leakage of some vacation information, which included certificates,
+
+153
+00:14:43,000 --> 00:14:48,000
+plaintext passwords, keys and sensitive customer information.
+
+154
+00:14:49,000 --> 00:14:58,000
+Last year, many organizations rely on the data storage technology of Amazon S3, including military
+
+155
+00:14:58,000 --> 00:15:00,000
+and government agencies.
+
+156
+00:15:00,000 --> 00:15:08,000
+However, past security advance indicate that this is a pervasive problem and as we association, should
+
+157
+00:15:08,000 --> 00:15:10,000
+be carefully monitored.
+
+158
+00:15:11,000 --> 00:15:21,000
+Example number three Citrix legacy protocols attacked Citrix use and I'm based cloud email server and
+
+159
+00:15:21,000 --> 00:15:25,000
+became the target of lab based password spraying.
+
+160
+00:15:26,000 --> 00:15:35,000
+I map is the insecure legacy protocol and attackers exploit to get access to cloud based accounts and
+
+161
+00:15:35,000 --> 00:15:40,000
+software as a service applications just as a reference.
+
+162
+00:15:40,000 --> 00:15:41,000
+Few words, but Citrix.
+
+163
+00:15:42,000 --> 00:15:50,000
+Citrix Systems is an American local national cloud computing and virtualization technology company that
+
+164
+00:15:50,000 --> 00:15:58,000
+provides server application and desktop virtualization networking software as a service and cloud computing
+
+165
+00:15:58,000 --> 00:15:59,000
+technologies.
+
+166
+00:15:59,000 --> 00:16:08,000
+And majority of Microsoft Office 365 and GC panels have been the target of my map based password spraying
+
+167
+00:16:08,000 --> 00:16:09,000
+attacks.
+
+168
+00:16:10,000 --> 00:16:12,000
+Few new words in this sentence.
+
+169
+00:16:12,000 --> 00:16:13,000
+Let me explain.
+
+170
+00:16:14,000 --> 00:16:16,000
+First of all, what is.
+
+171
+00:16:16,000 --> 00:16:26,000
+Math in computing the internet message access protocol zebra aviation is I am a p is an Internet standard
+
+172
+00:16:26,000 --> 00:16:35,000
+protocol used by email clients to retrieve email messages from a mail server over to sip IP connection.
+
+173
+00:16:35,000 --> 00:16:42,000
+A password screen attack is a type of brute force attack that a malicious actor attempts is the same
+
+174
+00:16:42,000 --> 00:16:48,000
+password on many accounts before moving on to another one and repeating the process.
+
+175
+00:16:49,000 --> 00:16:58,000
+The cybercriminals target the insecure legacy IMAP protocol to get past multifactor authentication settings.
+
+176
+00:16:58,000 --> 00:17:07,000
+I will refer to them as MFA settings and expose cloud based accounts given access to software as a service
+
+177
+00:17:07,000 --> 00:17:07,000
+applications.
+
+178
+00:17:08,000 --> 00:17:15,000
+Citrix, which specializes in federated architectures, was the target of such attack.
+
+179
+00:17:16,000 --> 00:17:18,000
+What is federated architectures?
+
+180
+00:17:19,000 --> 00:17:27,000
+Federated architecture is upon an enterprise architecture that allows interoperability and information
+
+181
+00:17:27,000 --> 00:17:34,000
+sharing within segment autonomously, that centrally organized slice of business information technology
+
+182
+00:17:34,000 --> 00:17:36,000
+systems and applications.
+
+183
+00:17:37,000 --> 00:17:46,000
+The proposed cybercriminals achieved a foothold by password splitting, and Xen were able to bypass
+
+184
+00:17:46,000 --> 00:17:47,000
+all the layers of security.
+
+185
+00:17:48,000 --> 00:17:56,000
+The termination of legacy protocols, including IMAP and Pop, makes it hard for system administrators
+
+186
+00:17:56,000 --> 00:17:59,000
+to establish and activate MFA.
+
+187
+00:18:00,000 --> 00:18:08,000
+Sure, mailboxes and service cycles can be especially vulnerable and it can be difficult to use MFA
+
+188
+00:18:08,000 --> 00:18:14,000
+to protect GC Cloud and Office 365 accounts easy to use.
+
+189
+00:18:14,000 --> 00:18:24,000
+Now let's make sure that multi-factor authentication is activated for every user in every application,
+
+190
+00:18:24,000 --> 00:18:27,000
+including super administrators.
+
+191
+00:18:27,000 --> 00:18:30,000
+Example number four Mirai.
+
+192
+00:18:30,000 --> 00:18:39,000
+But now Mirai is a type of malware that infects network devices after devices are in fact that they
+
+193
+00:18:39,000 --> 00:18:45,000
+can be remotely controlled by the operator, which uses them as bots.
+
+194
+00:18:45,000 --> 00:18:54,000
+That extends the power of a button that Mirai targeted, namely Iot devices, and managed to execute
+
+195
+00:18:54,000 --> 00:19:01,000
+several high profile attacks even after it was discovered in August 2016.
+
+196
+00:19:01,000 --> 00:19:11,000
+Dimension A released release code as open source on the IN and the technique has since been used in
+
+197
+00:19:11,000 --> 00:19:12,000
+other malware projects.
+
+198
+00:19:13,000 --> 00:19:21,000
+Mirai managed to infect and run on CCTV cameras, home rotors and DVR.
+
+199
+00:19:22,000 --> 00:19:26,000
+It succeeded by trying commonly used passwords.
+
+200
+00:19:26,000 --> 00:19:36,000
+This simple massive enables a new whiteboard to produce 218 minutes of beats per second and 102nd megapixels
+
+201
+00:19:36,000 --> 00:19:37,000
+per second.
+
+202
+00:19:37,000 --> 00:19:42,000
+Indeed, those ability and attack is a genius provided.
+
+203
+00:19:44,000 --> 00:19:53,000
+I also rendered several notable sites inaccessible, including GitHub, Reddit, Airbnb, Netflix and
+
+204
+00:19:53,000 --> 00:19:53,000
+Twitter.
+
+205
+00:19:53,000 --> 00:20:03,000
+The learned and the most common security misconfiguration threat actors actively look for systems and
+
+206
+00:20:03,000 --> 00:20:11,000
+devices thought that making use of lists of commonly used passwords and of course this can quickly include
+
+207
+00:20:11,000 --> 00:20:13,000
+a large number of passwords.
+
diff --git a/73 - OWASP Top 10 2021/012 NIST-800-123-Guide-to-General-Server-Security.url b/73 - OWASP Top 10 2021/012 NIST-800-123-Guide-to-General-Server-Security.url
new file mode 100644
index 0000000000000000000000000000000000000000..b9a54332b6c450429c41014297cd08691974eeb4
--- /dev/null
+++ b/73 - OWASP Top 10 2021/012 NIST-800-123-Guide-to-General-Server-Security.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-123.pdf
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/012 NIST-800-207-Zero-Trust-Architecture.url b/73 - OWASP Top 10 2021/012 NIST-800-207-Zero-Trust-Architecture.url
new file mode 100644
index 0000000000000000000000000000000000000000..865c0f1106b6178c0a9b40dc49473a2d35688e31
--- /dev/null
+++ b/73 - OWASP Top 10 2021/012 NIST-800-207-Zero-Trust-Architecture.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/012 Security Misconfiguration (Hardening, Zero Trust, Defense in Depth, Practice)_en.srt b/73 - OWASP Top 10 2021/012 Security Misconfiguration (Hardening, Zero Trust, Defense in Depth, Practice)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..17bf291f9ae47cb9ef23263cfa99f8f25366e259
--- /dev/null
+++ b/73 - OWASP Top 10 2021/012 Security Misconfiguration (Hardening, Zero Trust, Defense in Depth, Practice)_en.srt
@@ -0,0 +1,1200 @@
+1
+00:00:02,000 --> 00:00:03,000
+In scope of this lesson.
+
+2
+00:00:03,000 --> 00:00:07,000
+We're also going to talk about security hardening.
+
+3
+00:00:07,000 --> 00:00:09,000
+But what does it mean?
+
+4
+00:00:09,000 --> 00:00:10,000
+Let me explain.
+
+5
+00:00:11,000 --> 00:00:19,000
+Hardening when applied to computing is a practice of reducing a system's vulnerability by reducing its
+
+6
+00:00:19,000 --> 00:00:21,000
+attack surface.
+
+7
+00:00:22,000 --> 00:00:28,000
+In principle, a single function system is more secure than a multipurpose one.
+
+8
+00:00:29,000 --> 00:00:36,000
+Reducing available ways of attack typically includes changing default passwords, the removal of unnecessary
+
+9
+00:00:36,000 --> 00:00:44,000
+software, unnecessary use or logging, and the disabling or removal of unnecessary services.
+
+10
+00:00:45,000 --> 00:00:47,000
+What is attack surface?
+
+11
+00:00:48,000 --> 00:00:55,000
+The attacks surface is a combination of all the potential flaws and backdoors and technology that can
+
+12
+00:00:55,000 --> 00:00:57,000
+be exploited by hackers.
+
+13
+00:00:57,000 --> 00:00:58,000
+This.
+
+14
+00:00:58,000 --> 00:01:07,000
+This can occur in multiple ways, including default and hardcoded passwords, passwords and credentials
+
+15
+00:01:07,000 --> 00:01:16,000
+stored in plain text files, unpatched software and firmware vulnerabilities only configure the BIOS,
+
+16
+00:01:16,000 --> 00:01:24,000
+firewalls, ports, servers, switches, routers, or other parts of the infrastructure block or deficiency
+
+17
+00:01:24,000 --> 00:01:27,000
+of privileged access controls.
+
+18
+00:01:27,000 --> 00:01:35,000
+System hardening in the North and the South Dakota approach to identify those and control potential
+
+19
+00:01:35,000 --> 00:01:39,000
+security vulnerabilities throughout your organization.
+
+20
+00:01:40,000 --> 00:01:47,000
+There are several types of system hardening activities, including application harbor, operating system,
+
+21
+00:01:47,000 --> 00:01:57,000
+hardening server, hardening database, and that hardening halving may involve a reduction in attack
+
+22
+00:01:57,000 --> 00:02:03,000
+vectors by cordons at pathways or vectors attackers would use.
+
+23
+00:02:03,000 --> 00:02:06,000
+It may range from adhering to planning.
+
+24
+00:02:06,000 --> 00:02:15,000
+Policies such as zero trust is a principle of this privilege or defence in deps, but also may include
+
+25
+00:02:15,000 --> 00:02:22,000
+such activities as implementation of workforce training, segmentation of resources, automation of
+
+26
+00:02:22,000 --> 00:02:30,000
+security updates, resetting default passwords, asking passwords and stopping storage or transmission
+
+27
+00:02:30,000 --> 00:02:38,000
+of data unless it is encrypted or using attack vectors through hardening and also involves system owners,
+
+28
+00:02:39,000 --> 00:02:41,000
+unnecessary services or processes.
+
+29
+00:02:42,000 --> 00:02:47,000
+Overall, a system that provides most services has a much broader attack.
+
+30
+00:02:47,000 --> 00:02:51,000
+Face is one performing just one function.
+
+31
+00:02:52,000 --> 00:02:59,000
+While explaining this slide, I mentioned some interesting and useful policies in my opinion that I'd
+
+32
+00:02:59,000 --> 00:03:01,000
+like also to discuss with you.
+
+33
+00:03:02,000 --> 00:03:06,000
+Let me explain what zero prosecution model is.
+
+34
+00:03:06,000 --> 00:03:14,000
+The zero trust security model, sometimes known as variance or less security, describes an approach
+
+35
+00:03:14,000 --> 00:03:18,000
+to the design and implementation of I.T systems.
+
+36
+00:03:18,000 --> 00:03:27,000
+The main concept behind the Zero Trust Security model is not trust all this verify, which means that
+
+37
+00:03:27,000 --> 00:03:35,000
+devices should not be trusted by default, even if they are connected to permissioned networks such
+
+38
+00:03:35,000 --> 00:03:39,000
+as corporate along and even invisible privacy.
+
+39
+00:03:39,000 --> 00:03:49,000
+Five zero Trust is a security framework requiring all users was in or outside the organization's network
+
+40
+00:03:49,000 --> 00:03:57,000
+to be authenticated, authorized and continuously validated for security configuration before being
+
+41
+00:03:57,000 --> 00:04:01,000
+granted open access to applications and data.
+
+42
+00:04:01,000 --> 00:04:04,000
+Zero Trust assumes the use.
+
+43
+00:04:04,000 --> 00:04:13,000
+No traditional network edge networks can be code in the cloud or combination or hybrid with resources
+
+44
+00:04:13,000 --> 00:04:17,000
+anywhere, as well as bunkers in any location.
+
+45
+00:04:18,000 --> 00:04:26,000
+Most modern corporate networks consist of many interconnected zones, cloud services and infrastructure,
+
+46
+00:04:27,000 --> 00:04:35,000
+connections to remote and mobile environments, and connections to non-conventional I.T. such as Iot
+
+47
+00:04:35,000 --> 00:04:35,000
+devices.
+
+48
+00:04:36,000 --> 00:04:43,000
+The reasoning for Zero Trust is that the traditional approach trusts and devices with an emotional corporate
+
+49
+00:04:43,000 --> 00:04:51,000
+perimeter or devices connected to VPN is not relevant in the complex environment of a corporate network.
+
+50
+00:04:52,000 --> 00:05:00,000
+Zero trust approach advocates mutual authentication, including checking the identity and integrity
+
+51
+00:05:00,000 --> 00:05:10,000
+of devices with respect to location and providing access to applications and services based on the confidence
+
+52
+00:05:10,000 --> 00:05:13,000
+of device identity and device house.
+
+53
+00:05:13,000 --> 00:05:21,000
+In combination with user authentication, there is a standard from recognized organization that can
+
+54
+00:05:21,000 --> 00:05:23,000
+help you online.
+
+55
+00:05:23,000 --> 00:05:25,000
+Zero Trust with your organization.
+
+56
+00:05:26,000 --> 00:05:33,000
+The standard I'd like to mention is NIST 800 207.
+
+57
+00:05:34,000 --> 00:05:41,000
+This is funded by National Institute of Standards and Technology, dedicated to zero trust architecture.
+
+58
+00:05:42,000 --> 00:05:47,000
+I don't believe that we need to go over it in details and scope of this lesson.
+
+59
+00:05:47,000 --> 00:05:51,000
+I will leaves the reference in attachments to the lesson for you.
+
+60
+00:05:52,000 --> 00:05:54,000
+Feel free to check it after the lesson.
+
+61
+00:05:55,000 --> 00:06:02,000
+This is the most lending neutral, comprehensive standards, not just for government entities, but
+
+62
+00:06:02,000 --> 00:06:04,000
+for any organization.
+
+63
+00:06:05,000 --> 00:06:13,000
+Zero Trust seeks to address the following key principles based on the guidelines.
+
+64
+00:06:14,000 --> 00:06:23,000
+Continuous verification always verify access all the time for all sources, limit the blast radius,
+
+65
+00:06:24,000 --> 00:06:29,000
+minimize impact if an external or inside breach does occur.
+
+66
+00:06:30,000 --> 00:06:33,000
+Automate context, action and response.
+
+67
+00:06:33,000 --> 00:06:42,000
+Incorporate behavioral data and get context from the client, stack identity and the point workload,
+
+68
+00:06:42,000 --> 00:06:45,000
+etc. for the most accurate response.
+
+69
+00:06:46,000 --> 00:06:53,000
+Execution of this framework combines advanced technologies such as risk based, multi-factor authentication,
+
+70
+00:06:54,000 --> 00:07:02,000
+identity protection, next generation endpoint security, and robust cloud workflow technology to verify
+
+71
+00:07:02,000 --> 00:07:04,000
+a user or systems identity.
+
+72
+00:07:05,000 --> 00:07:11,000
+Consideration of access at that moment in time and the maintenance of system security.
+
+73
+00:07:12,000 --> 00:07:20,000
+Zero Trust also requires consideration of encryption of data, secure email and verifying the hygiene
+
+74
+00:07:20,000 --> 00:07:24,000
+of assets and coins before they connect applications.
+
+75
+00:07:25,000 --> 00:07:30,000
+And also I mentioned such approach as defence in depth.
+
+76
+00:07:30,000 --> 00:07:34,000
+This is a concept that I'd like also to discuss with you.
+
+77
+00:07:35,000 --> 00:07:37,000
+So what is the fancy depth?
+
+78
+00:07:38,000 --> 00:07:46,000
+Defensive maps is an approach to cybersecurity in which a serious of defensive mechanisms layers in
+
+79
+00:07:46,000 --> 00:07:50,000
+order to protect available data and information.
+
+80
+00:07:50,000 --> 00:07:57,000
+If one mechanism fails and the other steps up immediately, this or an attack.
+
+81
+00:07:58,000 --> 00:08:06,000
+This maintenance approach was intentional redundancies and raises the security system as a whole and
+
+82
+00:08:06,000 --> 00:08:11,000
+addresses many different attack vectors, defensive gaps.
+
+83
+00:08:11,000 --> 00:08:15,000
+Is it coming through, as it calls the approach?
+
+84
+00:08:16,000 --> 00:08:18,000
+Because it narrows the landscape.
+
+85
+00:08:18,000 --> 00:08:27,000
+Francis of Medieval Castle Before you can penetrate the castle you faced was the North Rampart, Drawbridge
+
+86
+00:08:28,000 --> 00:08:30,000
+Towers, Gotham Mines and so on.
+
+87
+00:08:32,000 --> 00:08:33,000
+Let's approach the security.
+
+88
+00:08:33,000 --> 00:08:36,000
+It can be applied to all levels of i.t.
+
+89
+00:08:36,000 --> 00:08:41,000
+Systems from a single laptop accesses the internet from the coffee shop.
+
+90
+00:08:41,000 --> 00:08:49,000
+This is a 50,000 user enterprise wide area and that's where the fencing maps can significantly improve
+
+91
+00:08:49,000 --> 00:08:51,000
+your security profile.
+
+92
+00:08:52,000 --> 00:08:57,000
+No organization can be ever fully protected by a single layer of security.
+
+93
+00:08:58,000 --> 00:09:00,000
+Well, one door may be closed.
+
+94
+00:09:00,000 --> 00:09:07,000
+Others will be left wide open, and hackers will find it useful and very quickly.
+
+95
+00:09:08,000 --> 00:09:16,000
+However, when you use a serious of different defenses to gather, such as firewalls, commerce, intrusion
+
+96
+00:09:16,000 --> 00:09:24,000
+detection systems, data encryption and the integrity of these solutions, you effectively close the
+
+97
+00:09:24,000 --> 00:09:32,000
+gaps created by relying on a seamless security solution and the different elements of defense in depth.
+
+98
+00:09:33,000 --> 00:09:37,000
+Some of them are network security controls.
+
+99
+00:09:37,000 --> 00:09:44,000
+For example firewalls, antivirus software, the license of data integrity.
+
+100
+00:09:44,000 --> 00:09:52,000
+Data Integrity Solutions can also check the source IP address to ensure it is from a known and trusted
+
+101
+00:09:52,000 --> 00:09:53,000
+source.
+
+102
+00:09:54,000 --> 00:09:55,000
+Behavioral Analysis.
+
+103
+00:09:56,000 --> 00:10:00,000
+That's what I wanted to share with you again in defense and depth.
+
+104
+00:10:01,000 --> 00:10:01,000
+Let's continue.
+
+105
+00:10:03,000 --> 00:10:03,000
+I believe that.
+
+106
+00:10:03,000 --> 00:10:06,000
+Now you understand what Harding means.
+
+107
+00:10:07,000 --> 00:10:10,000
+I suggest to you best practices for System Harding.
+
+108
+00:10:11,000 --> 00:10:18,000
+The type of Harding you point out, the balance of the risks in the existing technology, the resources
+
+109
+00:10:18,000 --> 00:10:22,000
+we have available, and the priority for making fixes.
+
+110
+00:10:23,000 --> 00:10:31,000
+All due to your existing systems, carry out a comprehensive audit of your existing technology, use
+
+111
+00:10:31,000 --> 00:10:39,000
+penetration testing landings, just common simulation management and other security auditing tools to
+
+112
+00:10:39,000 --> 00:10:42,000
+find flaws in the system and prioritize fixes.
+
+113
+00:10:43,000 --> 00:10:50,000
+Conduct system, hardening assessments against sources using industry standards.
+
+114
+00:10:50,000 --> 00:10:57,000
+For example, the National Institute of Standards and Technology that introduced the old standard.
+
+115
+00:10:58,000 --> 00:11:05,000
+It is called the General Service Security Special Number 800 123.
+
+116
+00:11:07,000 --> 00:11:09,000
+Create a strategy for systems hardening.
+
+117
+00:11:10,000 --> 00:11:14,000
+You do not need to harden all of your systems at once.
+
+118
+00:11:15,000 --> 00:11:24,000
+Instead, create a strategy and based on the risks identified within your technology ecosystem and use
+
+119
+00:11:24,000 --> 00:11:27,000
+a phased approach to remediate the biggest flaws.
+
+120
+00:11:29,000 --> 00:11:38,000
+Partial liabilities immediately ensures that an automated and comprehensive identification and blockchain
+
+121
+00:11:38,000 --> 00:11:39,000
+system in place.
+
+122
+00:11:40,000 --> 00:11:49,000
+Network hardening ensure your firewall is properly configured and that all rules are regular in order
+
+123
+00:11:49,000 --> 00:12:00,000
+to secure remote access points and users block any use or new open network ports, disable and remove
+
+124
+00:12:00,000 --> 00:12:07,000
+unnecessary protocols and services, implement access lists and create networks.
+
+125
+00:12:08,000 --> 00:12:08,000
+Track.
+
+126
+00:12:09,000 --> 00:12:18,000
+Sarah Harding, who's also overseeing the Secure Data Centre, never tests Harding on the production
+
+127
+00:12:18,000 --> 00:12:25,000
+servers, always Harman's service before connections to the Internet or external networks.
+
+128
+00:12:26,000 --> 00:12:32,000
+Avoid installing unnecessary software on a server segregates servers appropriately.
+
+129
+00:12:33,000 --> 00:12:42,000
+And sure, so using an administrative axis is properly set up and that provides on access unlimited
+
+130
+00:12:42,000 --> 00:12:44,000
+in line with the principle of this privilege.
+
+131
+00:12:45,000 --> 00:12:52,000
+Application hardening or any components of functions you do not name.
+
+132
+00:12:52,000 --> 00:13:00,000
+Restrict access to applications based on user roles and contacts such as with application control,
+
+133
+00:13:01,000 --> 00:13:04,000
+removable sample files and defaults passwords.
+
+134
+00:13:05,000 --> 00:13:12,000
+Application parcels should then be managed via an application password management in which the password
+
+135
+00:13:12,000 --> 00:13:19,000
+management solution that enforces password best practices, possible quotation marks, etc..
+
+136
+00:13:20,000 --> 00:13:29,000
+Hardening of applications should also entail inspecting integrations with other applications and systems
+
+137
+00:13:29,000 --> 00:13:34,000
+and removing foreign use and unnecessary integration components and privileges.
+
+138
+00:13:35,000 --> 00:13:44,000
+Database hardening create add new restrictions such as by controlling privileged access on what users
+
+139
+00:13:44,000 --> 00:13:52,000
+can do in a database showing on node, checking to verify applications and users and create database
+
+140
+00:13:52,000 --> 00:13:59,000
+information both in transit and at rest and force secure passwords.
+
+141
+00:14:00,000 --> 00:14:02,000
+Introduce roll based access.
+
+142
+00:14:02,000 --> 00:14:03,000
+Control privileges.
+
+143
+00:14:04,000 --> 00:14:06,000
+Free on used accounts.
+
+144
+00:14:07,000 --> 00:14:15,000
+Operating system hardware apply, operating system updates, service bags and watches automatically
+
+145
+00:14:16,000 --> 00:14:25,000
+freeze unnecessary drivers files, sharing libraries, software services and functionality, and great
+
+146
+00:14:25,000 --> 00:14:29,000
+local storage title registry and other systems.
+
+147
+00:14:29,000 --> 00:14:39,000
+Permissions look all of activity errors and warnings implement user controls and eliminate unnecessary
+
+148
+00:14:39,000 --> 00:14:40,000
+accounts and privileges.
+
+149
+00:14:41,000 --> 00:14:50,000
+Enforce this breach removing unnecessary accounts such as orphan accounts and unused accounts and privileges
+
+150
+00:14:50,000 --> 00:14:52,000
+throughout your i.t.
+
+151
+00:14:52,000 --> 00:14:53,000
+Infrastructure.
+
+152
+00:14:54,000 --> 00:14:59,000
+We have learned enough information to be able to understand the past examples.
+
+153
+00:14:59,000 --> 00:15:02,000
+Let's now discuss different attacks scenarios.
+
+154
+00:15:03,000 --> 00:15:09,000
+Example, number one, imagine that we have our verification of the Web.
+
+155
+00:15:09,000 --> 00:15:18,000
+Seven, In our case, I'm talking about our online store together with my students from scratch in life
+
+156
+00:15:18,000 --> 00:15:28,000
+mode in my course java from zero to first job and never seen looks fine application works but if I would
+
+157
+00:15:28,000 --> 00:15:36,000
+change you throw the manager slash email like this then I will be navigating that is in management console
+
+158
+00:15:36,000 --> 00:15:37,000
+of the server.
+
+159
+00:15:37,000 --> 00:15:46,000
+And this is not only related to Tomcat Web server, it may be related to any other server and its default
+
+160
+00:15:46,000 --> 00:15:47,000
+configurations.
+
+161
+00:15:48,000 --> 00:15:53,000
+I can try to guess which server you use and check default applications.
+
+162
+00:15:53,000 --> 00:15:56,000
+Is it installed on the cell facade?
+
+163
+00:15:57,000 --> 00:16:04,000
+I can control the guest defaults passwords or apply brute force to bypass authentication.
+
+164
+00:16:04,000 --> 00:16:10,000
+For example, in case of thought here admin for logging and admin for possible.
+
+165
+00:16:11,000 --> 00:16:18,000
+I would enter a default application that allows me to manage my deployments on the Tomcat.
+
+166
+00:16:18,000 --> 00:16:28,000
+So what we can do with cases like this never leave default or insecure passwords for admin applications,
+
+167
+00:16:28,000 --> 00:16:35,000
+especially in case the reason used to get access to the configurations of the server.
+
+168
+00:16:35,000 --> 00:16:43,000
+Another solution would be completely remove the full applications from the server in case you know that
+
+169
+00:16:43,000 --> 00:16:46,000
+you are not going to use the full web server applications.
+
+170
+00:16:47,000 --> 00:16:49,000
+Just remove them and that's it.
+
+171
+00:16:49,000 --> 00:16:58,000
+In this particular case was a Tomcat, navigate the Map Apps folder and remove all the applications
+
+172
+00:16:58,000 --> 00:17:03,000
+that exist besides applications that he and.
+
+173
+00:17:04,000 --> 00:17:05,000
+Example.
+
+174
+00:17:05,000 --> 00:17:05,000
+Number two.
+
+175
+00:17:06,000 --> 00:17:13,000
+In the second example, let me show you how direct listing can look like on the Sabbath.
+
+176
+00:17:14,000 --> 00:17:21,000
+Imagine that accidentally or by default you have directly enabled on the server.
+
+177
+00:17:21,000 --> 00:17:22,000
+What is it?
+
+178
+00:17:23,000 --> 00:17:24,000
+How does it look like?
+
+179
+00:17:25,000 --> 00:17:27,000
+For example, here's a link.
+
+180
+00:17:27,000 --> 00:17:28,000
+That image is directly.
+
+181
+00:17:29,000 --> 00:17:31,000
+Here is a reference to zip code.
+
+182
+00:17:31,000 --> 00:17:39,000
+It was JavaScript files and it seems like there is no critical harm in direct release.
+
+183
+00:17:40,000 --> 00:17:49,000
+But imagine now that while navigating the directories I found a direct was a content that external users
+
+184
+00:17:49,000 --> 00:17:51,000
+clients shouldn't have access to.
+
+185
+00:17:52,000 --> 00:17:56,000
+Take into account we use Java on Tomcat.
+
+186
+00:17:56,000 --> 00:17:59,000
+So we are part of the huge community.
+
+187
+00:18:00,000 --> 00:18:07,000
+A lot of security controls implementation by default and it is not so easy to download compiled sources
+
+188
+00:18:07,000 --> 00:18:08,000
+from the server.
+
+189
+00:18:08,000 --> 00:18:15,000
+But with all the languages, for example, speech we increase, I will get access to directory.
+
+190
+00:18:16,000 --> 00:18:25,000
+I can get access to the source code and expose the logic inside in case or compile sources locations
+
+191
+00:18:25,000 --> 00:18:25,000
+on the server.
+
+192
+00:18:26,000 --> 00:18:32,000
+I can that compiles and learns internal logic or just stole some technical decisions.
+
+193
+00:18:33,000 --> 00:18:39,000
+That's why Enabled Director can be treated as a serious security liability.
+
+194
+00:18:40,000 --> 00:18:47,000
+Talking in specifics about Tomcat is over the set of security controls implemented by default.
+
+195
+00:18:48,000 --> 00:18:54,000
+And this is one of these because by default the resolution is disabled.
+
+196
+00:18:55,000 --> 00:18:56,000
+You can control.
+
+197
+00:18:56,000 --> 00:19:02,000
+This is a maximum file from home for one of your Tomcat distribution.
+
+198
+00:19:02,000 --> 00:19:11,000
+Just find the km of the defaults in the scope listings and you can change value here.
+
+199
+00:19:11,000 --> 00:19:14,000
+Use a true or false by default.
+
+200
+00:19:14,000 --> 00:19:19,000
+It is false and I recommend you keep it false for production.
+
+201
+00:19:20,000 --> 00:19:26,000
+But just in case you have just learned where this configuration is located in the Tomcat.
+
+202
+00:19:27,000 --> 00:19:27,000
+Example.
+
+203
+00:19:27,000 --> 00:19:28,000
+Number three.
+
+204
+00:19:28,000 --> 00:19:33,000
+This is the last but not least example in is the case.
+
+205
+00:19:33,000 --> 00:19:41,000
+When accidentally is an error message, you expose some sensitive data that might be used by a doctor.
+
+206
+00:19:42,000 --> 00:19:48,000
+For example, imagine that you want to sign the humanity signing page.
+
+207
+00:19:49,000 --> 00:19:54,000
+You use username also user, but you don't know his or her password.
+
+208
+00:19:55,000 --> 00:20:02,000
+You any password and some reason for it is clear for us that password doesn't work.
+
+209
+00:20:03,000 --> 00:20:11,000
+But in case I would open the console but make an F12, I would see error messages in developers.
+
+210
+00:20:11,000 --> 00:20:12,000
+The last zip code.
+
+211
+00:20:13,000 --> 00:20:23,000
+I see the zip passwords and doesn't match with this username because there is another possible way here
+
+212
+00:20:23,000 --> 00:20:24,000
+at this console.
+
+213
+00:20:25,000 --> 00:20:34,000
+I know I oversimplified things, but even cases like this can happen when developers just left some
+
+214
+00:20:34,000 --> 00:20:34,000
+code.
+
+215
+00:20:34,000 --> 00:20:42,000
+So lots of genes involved and one just missed something that can be different variations of this mistake.
+
+216
+00:20:42,000 --> 00:20:50,000
+But the idea is a similar unit, established, efficient process of reviewing the team in order to with
+
+217
+00:20:50,000 --> 00:20:57,000
+cases like this one, accidentally sensitive information is revealed this sort of error message.
+
+218
+00:20:58,000 --> 00:21:06,000
+And now the examples that you also have about if we talk about Java applications and GCP technology
+
+219
+00:21:06,000 --> 00:21:13,000
+in particular, probably you saw a really stark choice when some error in GCP happens, and this is
+
+220
+00:21:13,000 --> 00:21:17,000
+also one of the places where sensitive data may appear.
+
+221
+00:21:18,000 --> 00:21:27,000
+Also, this gives understanding that this web application uses Java technology stack, which might not
+
+222
+00:21:27,000 --> 00:21:35,000
+be like it will not be listed by itself, but this will give thought thought to additional information
+
+223
+00:21:35,000 --> 00:21:41,000
+about internal structure of the application and potential web server configurations.
+
+224
+00:21:42,000 --> 00:21:47,000
+You know how we can prevent shown error loss this season?
+
+225
+00:21:47,000 --> 00:21:56,000
+Just configure air handlers for different kinds of federal, including internal server errors here and
+
+226
+00:21:56,000 --> 00:21:58,000
+WebEx and all of my application.
+
+227
+00:21:58,000 --> 00:21:59,000
+You can see that.
+
+228
+00:21:59,000 --> 00:22:04,000
+I can see the error handlers for some kinds of fair use.
+
+229
+00:22:04,000 --> 00:22:12,000
+Also very good to go with exposure of error logs and using this all examples that I was about to show
+
+230
+00:22:12,000 --> 00:22:17,000
+you some stuff I would like to talk about Java configurations in particular.
+
+231
+00:22:18,000 --> 00:22:25,000
+In general, we should be aware that your general application configuration is the same important as
+
+232
+00:22:25,000 --> 00:22:27,000
+writing code itself.
+
+233
+00:22:28,000 --> 00:22:34,000
+When using frameworks and libraries, we should be aware of what the default configuration settings
+
+234
+00:22:34,000 --> 00:22:38,000
+are and if certain changes have security implications.
+
+235
+00:22:39,000 --> 00:22:46,000
+This is important in relation to application frameworks, libraries and also for settings.
+
+236
+00:22:47,000 --> 00:22:54,000
+So remind yourself that exposing information might not be harmful at first glance.
+
+237
+00:22:55,000 --> 00:23:02,000
+But if you combine all these bits and pieces of information, you will give an attacker enough information
+
+238
+00:23:02,000 --> 00:23:04,000
+to do something malicious.
+
+239
+00:23:05,000 --> 00:23:15,000
+Using libraries and even application service is very useful, but you should be aware of how the Java
+
+240
+00:23:15,000 --> 00:23:19,000
+configuration and this configuration is a serious sin.
+
+241
+00:23:20,000 --> 00:23:27,000
+Make sure that you are not accidentally giving people access to your application because you forgot
+
+242
+00:23:27,000 --> 00:23:30,000
+to set a specific property in your configuration.
+
+243
+00:23:31,000 --> 00:23:38,000
+Unions in the past used a lot of it, and that belief is based on the examples that we have discussed.
+
+244
+00:23:38,000 --> 00:23:45,000
+You already can make some conclusions and understand how you can avoid vulnerabilities from the security
+
+245
+00:23:45,000 --> 00:23:47,000
+misconfiguration category.
+
+246
+00:23:48,000 --> 00:23:55,000
+Let's summarize all the conclusions that we need and create a list of rules and guidelines to follow
+
+247
+00:23:56,000 --> 00:24:01,000
+that can help us to prevent liabilities related to security misconfiguration.
+
+248
+00:24:02,000 --> 00:24:07,000
+First of all, the golden rule that we discussed in the review, each was category.
+
+249
+00:24:07,000 --> 00:24:14,000
+We have to implement the principle of basically everything is off by default.
+
+250
+00:24:15,000 --> 00:24:24,000
+This is not maintenance is to disable administration interfaces, disable debugging, disable use of
+
+251
+00:24:24,000 --> 00:24:33,000
+default accounts, passwords, change all possible default settings, cloud storage permissions, for
+
+252
+00:24:33,000 --> 00:24:34,000
+example.
+
+253
+00:24:34,000 --> 00:24:44,000
+Else we block permissions and civil servant to prevent unauthorized access directly, etc. Consider
+
+254
+00:24:44,000 --> 00:24:51,000
+running scans on the oldest to help detect future misconfigurations on recent patches.
+
+255
+00:24:52,000 --> 00:24:57,000
+That's a powerful thing to do to prevent the issues related to security.
+
+256
+00:24:57,000 --> 00:25:04,000
+Misconfiguration Is education and training your staff members about the latest security trends.
+
+257
+00:25:04,000 --> 00:25:11,000
+This allows them to make smart decisions and adhere to best practices.
+
+258
+00:25:12,000 --> 00:25:20,000
+Never forget the bottom portion of the store is a persistent storage of hard drawers.
+
+259
+00:25:20,000 --> 00:25:21,000
+Laptops of your own.
+
+260
+00:25:21,000 --> 00:25:22,000
+Please.
+
+261
+00:25:22,000 --> 00:25:27,000
+The tools and techniques that allow us to do that too.
+
+262
+00:25:28,000 --> 00:25:33,000
+You can also apply appropriate access controls to the rentals and files.
+
+263
+00:25:34,000 --> 00:25:39,000
+These measures of size is all you need to of susceptible directories and files.
+
+264
+00:25:40,000 --> 00:25:43,000
+I'm a date, so perhaps is the latest version.
+
+265
+00:25:44,000 --> 00:25:50,000
+The use of all data software remains one of the most prevalent security vulnerabilities.
+
+266
+00:25:51,000 --> 00:25:56,000
+Many companies don't appreciate the need to invest in the use of the latest.
+
+267
+00:25:57,000 --> 00:26:03,000
+They may feel it is more cost effective to continue making use of legacy software.
+
+268
+00:26:04,000 --> 00:26:12,000
+However, using data software can actually place an organization to risk of losing assets, as well
+
+269
+00:26:12,000 --> 00:26:15,000
+as the trust of investors and customers.
+
+270
+00:26:16,000 --> 00:26:25,000
+Establishing consistent cost travel and maintaining updated software is essential to use an organization's
+
+271
+00:26:25,000 --> 00:26:26,000
+strength vectors.
+
+272
+00:26:27,000 --> 00:26:34,000
+Establish rigorous content conventions, securities, accounts and systems is an automated message of
+
+273
+00:26:34,000 --> 00:26:44,000
+easily running such scans on a regular schedule to create an architectural changes is a significant
+
+274
+00:26:44,000 --> 00:26:50,000
+step in improving the overall value being utilized instead of consequences.
+
+275
+00:26:50,000 --> 00:26:58,000
+Before you integrate ZIP code into the production environment, security professionals must also perform
+
+276
+00:26:58,000 --> 00:27:01,000
+manual reviews on dynamic testing.
+
+277
+00:27:02,000 --> 00:27:09,000
+Establish a hardening process because it is repeatable so that it is fast and simple to deploy correctly.
+
+278
+00:27:09,000 --> 00:27:11,000
+Configure new environments.
+
+279
+00:27:12,000 --> 00:27:19,000
+The production, development and key environments must all be configured in the same way, but with
+
+280
+00:27:19,000 --> 00:27:22,000
+distant passwords used in every environment.
+
+281
+00:27:23,000 --> 00:27:28,000
+Automate this process to easily establish a secure environment.
+
+282
+00:27:28,000 --> 00:27:29,000
+That's it.
+
+283
+00:27:30,000 --> 00:27:33,000
+Let's recap for Fifth in this lesson.
+
+284
+00:27:34,000 --> 00:27:39,000
+In this city is a misconfiguration in this category.
+
+285
+00:27:40,000 --> 00:27:46,000
+Williams is a most notable common weakness in the narrations related to this category.
+
+286
+00:27:47,000 --> 00:27:51,000
+We compared across the top ten, 20, 21 and 2017.
+
+287
+00:27:52,000 --> 00:27:54,000
+Williams was excellent.
+
+288
+00:27:54,000 --> 00:28:04,000
+So and this are and we also got mentioned in this category from our top ten 2017 is now included in
+
+289
+00:28:04,000 --> 00:28:06,000
+the security misconfiguration risk category.
+
+290
+00:28:07,000 --> 00:28:11,000
+I explained different types of security misconfiguration.
+
+291
+00:28:12,000 --> 00:28:18,000
+We've reviewed examples of the real life attacks because of security misconfiguration.
+
+292
+00:28:19,000 --> 00:28:21,000
+Also we discussed new concepts.
+
+293
+00:28:22,000 --> 00:28:30,000
+Namely, we know what security hardening is, what the Zero Trust Security Module is, what defense
+
+294
+00:28:30,000 --> 00:28:31,000
+in depth is.
+
+295
+00:28:32,000 --> 00:28:41,000
+I explained best practices for system hardening and after we learned all this we had a live demo and
+
+296
+00:28:41,000 --> 00:28:50,000
+I showed you a few examples of attacks and the of as a conclusion we know how to prevent security and
+
+297
+00:28:50,000 --> 00:28:51,000
+configuration.
+
+298
+00:28:52,000 --> 00:28:54,000
+That's all for this lesson.
+
+299
+00:28:54,000 --> 00:28:56,000
+Thank you for your attention.
+
+300
+00:28:56,000 --> 00:28:59,000
+Have a great day and see you in the next lesson.
+
diff --git a/73 - OWASP Top 10 2021/013 Dependency-check-plugin.url b/73 - OWASP Top 10 2021/013 Dependency-check-plugin.url
new file mode 100644
index 0000000000000000000000000000000000000000..1a0e22c9e2a71b1ec125699a023f3f9c0f0ede08
--- /dev/null
+++ b/73 - OWASP Top 10 2021/013 Dependency-check-plugin.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://mvnrepository.com/artifact/org.owasp/dependency-check-maven/7.1.0
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/013 Vulnerable & Outdated Components_en.srt b/73 - OWASP Top 10 2021/013 Vulnerable & Outdated Components_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..7324c273cc4adee0d9337eb48520e6f69b4e3c19
--- /dev/null
+++ b/73 - OWASP Top 10 2021/013 Vulnerable & Outdated Components_en.srt
@@ -0,0 +1,1056 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello team.
+
+2
+00:00:07,000 --> 00:00:10,000
+We proceed non-secure call and I've asked top that.
+
+3
+00:00:10,000 --> 00:00:17,000
+And in this lesson we're going to talk about such risk category as vulnerable and outdated components.
+
+4
+00:00:18,000 --> 00:00:23,000
+We're going to start the lesson from the general overview about this risk category.
+
+5
+00:00:24,000 --> 00:00:31,000
+After that, I'm going to explain the risk factors that increase the risk of vulnerability of your application.
+
+6
+00:00:32,000 --> 00:00:39,000
+I'm going to explain why it is not so easy to update our data components on a regular basis and the
+
+7
+00:00:39,000 --> 00:00:45,000
+standards a challenge will be easier for us to understand how to avoid it.
+
+8
+00:00:46,000 --> 00:00:51,000
+As usual, we are going to use the most notable common vehicle enumerations.
+
+9
+00:00:52,000 --> 00:00:56,000
+I will explain how attackers use vulnerable components.
+
+10
+00:00:56,000 --> 00:00:59,000
+We'll review real life examples.
+
+11
+00:00:59,000 --> 00:01:08,000
+Also, we're going to compare this risk category and how it was presented in the last ten 2017 versus
+
+12
+00:01:09,000 --> 00:01:10,000
+the top ten, 2021.
+
+13
+00:01:11,000 --> 00:01:17,000
+And that's a very important and useful scenes that you will be able to apply in practice after this
+
+14
+00:01:17,000 --> 00:01:20,000
+lesson is using of the dependency check logging.
+
+15
+00:01:20,000 --> 00:01:26,000
+I'm going to show you how we can integrate that in our online shop web application.
+
+16
+00:01:26,000 --> 00:01:28,000
+We'll discuss security scholars.
+
+17
+00:01:29,000 --> 00:01:36,000
+And at the end of the lesson, we're going to talk about how to prevent abilities from this risk category.
+
+18
+00:01:36,000 --> 00:01:38,000
+Let's start our lesson.
+
+19
+00:01:39,000 --> 00:01:44,000
+Let's hold an overview of colonial and outdated components we have and do it.
+
+20
+00:01:45,000 --> 00:01:51,000
+I will give a little bit more context to help you understand what this risk category is all about.
+
+21
+00:01:52,000 --> 00:01:59,000
+More and more apps are using existing components rather than being quoted completely from scratch.
+
+22
+00:02:00,000 --> 00:02:08,000
+Lab applications often need faster turn around, and with the quantity of open source components available,
+
+23
+00:02:08,000 --> 00:02:11,000
+there is no reason not to make use of them.
+
+24
+00:02:12,000 --> 00:02:19,000
+Analysis indicates that approximately 96% of applications use open source components.
+
+25
+00:02:20,000 --> 00:02:29,000
+On average, more than half of an applications code base consists of open source rather than proprietary
+
+26
+00:02:29,000 --> 00:02:29,000
+code.
+
+27
+00:02:30,000 --> 00:02:38,000
+The interesting thing is that you can write 100% secure code following all the rules, but your program
+
+28
+00:02:38,000 --> 00:02:40,000
+still would remain vulnerable.
+
+29
+00:02:41,000 --> 00:02:42,000
+How it is possible.
+
+30
+00:02:42,000 --> 00:02:49,000
+Unless you are writing a really simple function which doesn't do much, you will reuse software of other
+
+31
+00:02:49,000 --> 00:02:50,000
+people.
+
+32
+00:02:50,000 --> 00:02:57,000
+From development to deployment, you will use libraries, frameworks, technologies, etc. And guess
+
+33
+00:02:57,000 --> 00:02:58,000
+what?
+
+34
+00:02:59,000 --> 00:03:03,000
+Those separate components will also depend on OSR components.
+
+35
+00:03:03,000 --> 00:03:05,000
+This comes at a cost.
+
+36
+00:03:05,000 --> 00:03:12,000
+In fact, part of the third party software components you will re-use will suffer from security vulnerabilities.
+
+37
+00:03:13,000 --> 00:03:18,000
+Besides, you might even be using some malicious components.
+
+38
+00:03:18,000 --> 00:03:26,000
+Therefore, checking your code is a need, not a luxury, and the pressure to deliver at speed.
+
+39
+00:03:27,000 --> 00:03:33,000
+Some components are not sufficiently checked before use as a result can be you.
+
+40
+00:03:33,000 --> 00:03:40,000
+Websites and applications was deeply embedded vulnerabilities known to the application operating.
+
+41
+00:03:41,000 --> 00:03:48,000
+But once that ability is discovered by cybercriminals, applications using the vulnerable component
+
+42
+00:03:49,000 --> 00:03:51,000
+can be found and exploited.
+
+43
+00:03:51,000 --> 00:03:59,000
+It could be a simple flaw in a slow component, but one that ultimately makes the entire system hackable.
+
+44
+00:03:59,000 --> 00:04:05,000
+That's some risk factors related to vulnerabilities, problems of vulnerable and outdated components
+
+45
+00:04:05,000 --> 00:04:06,000
+in this category.
+
+46
+00:04:07,000 --> 00:04:10,000
+First of all, what is a risk factor?
+
+47
+00:04:11,000 --> 00:04:12,000
+Risk factor?
+
+48
+00:04:12,000 --> 00:04:18,000
+Chen widely used in medicine and it is also used in project management and project management.
+
+49
+00:04:18,000 --> 00:04:25,000
+Risk factor may be an issue environment that is associated with an increased risk of consequences.
+
+50
+00:04:26,000 --> 00:04:33,000
+For example, if you are riding a bicycle on the perfect roads, it is less likely to damage your bicycle.
+
+51
+00:04:33,000 --> 00:04:39,000
+Going to mountains on your bike can be already considered as a risk factor, is it?
+
+52
+00:04:39,000 --> 00:04:40,000
+Not necessarily.
+
+53
+00:04:40,000 --> 00:04:48,000
+And the wreck may cause a damage to a bicycle, but this fact significantly increases the risk and probability
+
+54
+00:04:48,000 --> 00:04:50,000
+of negative consequences.
+
+55
+00:04:50,000 --> 00:04:52,000
+In this case is the same as here.
+
+56
+00:04:53,000 --> 00:05:01,000
+Let's review risk factors that can increase risks of becoming vulnerable to threats of finalized security
+
+57
+00:05:02,000 --> 00:05:05,000
+as it can increase the level of utility on your project.
+
+58
+00:05:06,000 --> 00:05:14,000
+So you are likely vulnerable if you don't know the versions of all components you use both client side
+
+59
+00:05:14,000 --> 00:05:15,000
+and Samsung.
+
+60
+00:05:16,000 --> 00:05:23,000
+This includes components you directly use as well as nested dependencies if the software is vulnerable,
+
+61
+00:05:23,000 --> 00:05:25,000
+unsupported or out of date.
+
+62
+00:05:26,000 --> 00:05:33,000
+This includes the operating system, web application server, database management system, applications
+
+63
+00:05:34,000 --> 00:05:39,000
+API and all components, runtime environments and libraries.
+
+64
+00:05:39,000 --> 00:05:48,000
+If you do not have vulnerability to regulatory, if you don't fix or upgrades the underlying platform
+
+65
+00:05:48,000 --> 00:05:52,000
+frameworks and dependencies in the risk based timely fashion.
+
+66
+00:05:53,000 --> 00:06:00,000
+This commonly happens in environments when patching is a monthly or quarterly task on the change control,
+
+67
+00:06:00,000 --> 00:06:08,000
+leaving organizations open two days a month of unnecessary exposure to fixed liabilities.
+
+68
+00:06:08,000 --> 00:06:15,000
+If a software developers don't, does the compatibility of updated upgraded libraries.
+
+69
+00:06:16,000 --> 00:06:23,000
+If you don't secure the components configurations like we discussed in scope of our obsolescence dedicated
+
+70
+00:06:23,000 --> 00:06:25,000
+to security in this configuration.
+
+71
+00:06:26,000 --> 00:06:32,000
+Usually at this point of the class, my students ask me, So what is a big deal out of this?
+
+72
+00:06:33,000 --> 00:06:39,000
+Let's just constantly update our external dependencies to the new versions, and that's it.
+
+73
+00:06:40,000 --> 00:06:46,000
+Each new version should contain patches and updates that should decrease the use of security vulnerabilities.
+
+74
+00:06:47,000 --> 00:06:49,000
+Well, you're right from the one side.
+
+75
+00:06:49,000 --> 00:06:57,000
+If you also see the same one but from another side, let's understand why this behavior is not so common.
+
+76
+00:06:58,000 --> 00:07:01,000
+Keeping our components and modules in the application.
+
+77
+00:07:02,000 --> 00:07:09,000
+It is not so easy to manage all the dependencies and approvals of all the dependency graph and the application
+
+78
+00:07:09,000 --> 00:07:11,000
+and update versions.
+
+79
+00:07:11,000 --> 00:07:17,000
+Each new version of the library may contain renamed masses or removed masses.
+
+80
+00:07:18,000 --> 00:07:22,000
+New version of the library can become incompatible with other dependencies.
+
+81
+00:07:22,000 --> 00:07:26,000
+Since application, some features may become deprecated.
+
+82
+00:07:26,000 --> 00:07:29,000
+Some other features may break existing code.
+
+83
+00:07:30,000 --> 00:07:32,000
+These are just a few examples.
+
+84
+00:07:32,000 --> 00:07:39,000
+The process of updating things and making sure that they remain the latest sounds simple, but it's
+
+85
+00:07:39,000 --> 00:07:47,000
+quite a lot of work and sometimes it is not that straightforward unless you are willing to put in your
+
+86
+00:07:47,000 --> 00:07:52,000
+time and update your code to get it to work well with the latest and greatest updates.
+
+87
+00:07:53,000 --> 00:08:00,000
+At the very least, this is not always feasible and in the worst case, it would be your worst nightmare.
+
+88
+00:08:01,000 --> 00:08:07,000
+At the end of the day, this costs money and like it always happens on practice.
+
+89
+00:08:07,000 --> 00:08:15,000
+Is the responsible person for assigning costs on such activities is technology agnostic and it is hard
+
+90
+00:08:15,000 --> 00:08:22,000
+to convince this person or group of people investing money in something which will not generate income
+
+91
+00:08:22,000 --> 00:08:23,000
+in the near future.
+
+92
+00:08:24,000 --> 00:08:27,000
+If you watched my previous classes, I already sat.
+
+93
+00:08:27,000 --> 00:08:34,000
+The technology should go hand-in-hand with businesses that are supported by such technologies and you
+
+94
+00:08:34,000 --> 00:08:37,000
+have to find this balance within your organisation.
+
+95
+00:08:37,000 --> 00:08:41,000
+I just want to highlight that this was never an easy thing to do.
+
+96
+00:08:42,000 --> 00:08:48,000
+As always, let's discuss the most notable common vehicles, enumerations that are associated with this
+
+97
+00:08:48,000 --> 00:08:56,000
+category c, w e and level for use of online paints or body components.
+
+98
+00:08:57,000 --> 00:09:05,000
+Reliance on components that are no longer maintained can make it difficult or impossible to fix significant
+
+99
+00:09:05,000 --> 00:09:12,000
+bugs or religious or quality issues in the fact and maintained code and become obsolete.
+
+100
+00:09:13,000 --> 00:09:20,000
+The issue makes it more difficult to maintain the software, which indirectly affects security by making
+
+101
+00:09:20,000 --> 00:09:25,000
+it more difficult, time consuming to find smaller abilities.
+
+102
+00:09:26,000 --> 00:09:29,000
+It also might make it easier to introduce vulnerabilities.
+
+103
+00:09:30,000 --> 00:09:36,000
+C w e 1075 using components was known vulnerabilities.
+
+104
+00:09:36,000 --> 00:09:44,000
+Attackers have their own database of vulnerable components and exploits moreover prominent databases.
+
+105
+00:09:45,000 --> 00:09:53,000
+Once attackers would identify that you use outdated components, they will use exploit against your
+
+106
+00:09:53,000 --> 00:09:54,000
+application.
+
+107
+00:09:55,000 --> 00:09:58,000
+In scope of this lesson, I want explain.
+
+108
+00:09:58,000 --> 00:10:01,000
+Use the algorithm that is used by attackers.
+
+109
+00:10:02,000 --> 00:10:03,000
+Learn how they act.
+
+110
+00:10:04,000 --> 00:10:10,000
+We will be able to be better prepared so to detect vulnerable components.
+
+111
+00:10:10,000 --> 00:10:13,000
+Usually attackers follows in next steps.
+
+112
+00:10:14,000 --> 00:10:23,000
+The first one, the tech that as a first step usually attackers one identifier technology stack that
+
+113
+00:10:23,000 --> 00:10:24,000
+is used in application.
+
+114
+00:10:25,000 --> 00:10:28,000
+There are different ways how this can be clarified.
+
+115
+00:10:29,000 --> 00:10:36,000
+For example, an attacker can inspect traffic, focus headers and so on.
+
+116
+00:10:37,000 --> 00:10:44,000
+Based on this, attacker can make an assumption about web server use and thus technologies that use
+
+117
+00:10:45,000 --> 00:10:52,000
+tsarism tools like that provides a browser extension that helps us to identify technologies based on
+
+118
+00:10:52,000 --> 00:10:53,000
+our alliances.
+
+119
+00:10:53,000 --> 00:10:55,000
+Single Page Headers.
+
+120
+00:10:56,000 --> 00:10:59,000
+Such a group of tools are called technology profilers.
+
+121
+00:11:00,000 --> 00:11:03,000
+Also, attacker may trigger an error.
+
+122
+00:11:03,000 --> 00:11:11,000
+Explore this tech trace and get additional information he or she may remove and specify there's some
+
+123
+00:11:11,000 --> 00:11:18,000
+unexpected values, etc. If attacker receives an error, it's usually contains some hints about the
+
+124
+00:11:18,000 --> 00:11:19,000
+stack.
+
+125
+00:11:20,000 --> 00:11:26,000
+If this is an open source project, then attack and explore all the dependencies from your repository.
+
+126
+00:11:27,000 --> 00:11:34,000
+Once technology stack is identified at tack, will try to fund existing exports and vulnerabilities.
+
+127
+00:11:35,000 --> 00:11:38,000
+There are public resources as it describes exports.
+
+128
+00:11:39,000 --> 00:11:45,000
+I will not name such resources at the moment, but just for you to be aware about the potential stress.
+
+129
+00:11:46,000 --> 00:11:52,000
+By the way, this is one of the reasons why secure projects, for example, talk to me.
+
+130
+00:11:52,000 --> 00:11:59,000
+I'm worried of using open source libraries because adding dependencies to your project, you expose
+
+131
+00:11:59,000 --> 00:12:04,000
+yourself to potential abuses that were released with that library.
+
+132
+00:12:04,000 --> 00:12:12,000
+That's why even such an open source framework for Java like screen is not the choice for projects like
+
+133
+00:12:12,000 --> 00:12:13,000
+this.
+
+134
+00:12:13,000 --> 00:12:18,000
+I worked on such projects in different roles and I worked as a consultant.
+
+135
+00:12:18,000 --> 00:12:21,000
+The top syntax pops.
+
+136
+00:12:21,000 --> 00:12:23,000
+I just can't tell you their names.
+
+137
+00:12:23,000 --> 00:12:30,000
+Believe me, these are thin paragraphs that you've heard about, and these are solutions that they use
+
+138
+00:12:30,000 --> 00:12:32,000
+by millions of people worldwide.
+
+139
+00:12:33,000 --> 00:12:35,000
+So believe me, I know what I'm talking about.
+
+140
+00:12:37,000 --> 00:12:42,000
+Let's review example from real life to get experience of our organization.
+
+141
+00:12:42,000 --> 00:12:48,000
+Talking about probably one of the most popular examples among vulnerable and outdated components.
+
+142
+00:12:48,000 --> 00:12:50,000
+Cost significant business impact.
+
+143
+00:12:51,000 --> 00:12:58,000
+With a mansion, Equifax, which is the entry point to this, was a vulnerable version of Struts.
+
+144
+00:12:58,000 --> 00:13:05,000
+Apache Struts is an open source web application framework for developing Java Easy Web applications.
+
+145
+00:13:06,000 --> 00:13:14,000
+It uses and extends the Java API to encourage developers to adopt a model view control architecture.
+
+146
+00:13:15,000 --> 00:13:22,000
+Struts is vulnerable to remote command injection attacks through incorrectly passing and attackers invalid
+
+147
+00:13:22,000 --> 00:13:24,000
+content should be had.
+
+148
+00:13:25,000 --> 00:13:31,000
+This trust vulnerability allows these commands to be executed on the edges of the web server.
+
+149
+00:13:32,000 --> 00:13:34,000
+This is the mode command.
+
+150
+00:13:34,000 --> 00:13:38,000
+Education has been actively exploited from the initial disclosure.
+
+151
+00:13:38,000 --> 00:13:43,000
+You can find more detail about common amenities and exposures.
+
+152
+00:13:43,000 --> 00:13:48,000
+See themselves in 1756 eight.
+
+153
+00:13:49,000 --> 00:13:56,000
+This bridge used to gain access to Equifax Network and steal more than 140 million customers.
+
+154
+00:13:56,000 --> 00:13:58,000
+Personal information.
+
+155
+00:13:59,000 --> 00:14:02,000
+That's also become part of us to stop them.
+
+156
+00:14:02,000 --> 00:14:05,000
+2021 And I was top ten 2017.
+
+157
+00:14:06,000 --> 00:14:14,000
+The risk category, what we are discussing at the moment was also that in the 2017 top ten list, it
+
+158
+00:14:14,000 --> 00:14:20,000
+was in position number nine and different name, as you can see on the slide.
+
+159
+00:14:20,000 --> 00:14:24,000
+It was called using components was no vulnerabilities.
+
+160
+00:14:24,000 --> 00:14:27,000
+While the name is different, the idea is the same.
+
+161
+00:14:28,000 --> 00:14:34,000
+You can see that this risk category placed a higher position in the top ten, 2041.
+
+162
+00:14:35,000 --> 00:14:37,000
+It takes place number six.
+
+163
+00:14:37,000 --> 00:14:44,000
+This is all explained by increased amount of cases vulnerabilities from this risk category we use to
+
+164
+00:14:44,000 --> 00:14:46,000
+attack an application.
+
+165
+00:14:47,000 --> 00:14:48,000
+Now it is time for the demo.
+
+166
+00:14:49,000 --> 00:14:55,000
+In this demo, I'm going to show you the tools that can help you to tax liabilities in the competence.
+
+167
+00:14:56,000 --> 00:15:03,000
+I'm going to start the demo from the great plugins that you can add to your build the scope dependency
+
+168
+00:15:03,000 --> 00:15:11,000
+chat to raise developer awareness and help avoid risks and the technical abilities on early stages of
+
+169
+00:15:11,000 --> 00:15:15,000
+Aosp created plugin for Maven School Dependency Chat.
+
+170
+00:15:16,000 --> 00:15:23,000
+This is a solution which can be used to identify project dependencies and check them against is a national
+
+171
+00:15:23,000 --> 00:15:28,000
+vulnerability database and BD needs reports.
+
+172
+00:15:28,000 --> 00:15:39,000
+Any known publicly disclosed state finds so added to your project just open for maximum fine build plugins.
+
+173
+00:15:39,000 --> 00:15:46,000
+And by the way, if you want to learn more about Maven, please refer to this section about Maven and
+
+174
+00:15:46,000 --> 00:15:50,000
+automation tools in my course Java from 0 to 4 as job.
+
+175
+00:15:51,000 --> 00:15:52,000
+Yeah.
+
+176
+00:15:52,000 --> 00:15:55,000
+We'll just need to add a vast plugin, and that's it.
+
+177
+00:15:56,000 --> 00:15:57,000
+Is a dependency check.
+
+178
+00:15:57,000 --> 00:16:06,000
+Log in is by default tied to the verify or side base, dependent on if it is configured as a build or
+
+179
+00:16:06,000 --> 00:16:07,000
+reporting plugin.
+
+180
+00:16:08,000 --> 00:16:12,000
+In the current case, we can generate a report using and then verify.
+
+181
+00:16:12,000 --> 00:16:14,000
+Come on, I added.
+
+182
+00:16:14,000 --> 00:16:22,000
+This plugin on the top level is a preference for maximum so that all my modules also will be verified.
+
+183
+00:16:23,000 --> 00:16:31,000
+I open the terminal and execute and then verify that it is important to understand is the first time
+
+184
+00:16:31,000 --> 00:16:33,000
+this task is executed.
+
+185
+00:16:33,000 --> 00:16:40,000
+It might take 20 minutes or more as it does loads and processes the data from the National Vulnerability
+
+186
+00:16:40,000 --> 00:16:49,000
+Database hosted by NIST after the first march, though not as long as the plugin is executed at least
+
+187
+00:16:49,000 --> 00:16:54,000
+once every seven days that I'm doing, it will only take a few seconds.
+
+188
+00:16:55,000 --> 00:17:03,000
+Once command is executed, I can navigate the target directory of each of my modules and I will be able
+
+189
+00:17:03,000 --> 00:17:05,000
+to find dependency.
+
+190
+00:17:05,000 --> 00:17:07,000
+Check Report page HTML file.
+
+191
+00:17:07,000 --> 00:17:08,000
+Let's open it.
+
+192
+00:17:09,000 --> 00:17:18,000
+You can find here scan information vulnerabilities detected in each library severity evidence count
+
+193
+00:17:18,000 --> 00:17:23,000
+detailed description of vulnerability and many, many other things.
+
+194
+00:17:23,000 --> 00:17:28,000
+And as I said, you will be able to find such reports in each module.
+
+195
+00:17:29,000 --> 00:17:34,000
+By the way, that can be different variations of consideration of this plugin.
+
+196
+00:17:34,000 --> 00:17:41,000
+For example, you can tell plugin to create the dependency check, report, email and sales and build
+
+197
+00:17:41,000 --> 00:17:47,000
+for CV, assess grateful ZAM or equal to a CV.
+
+198
+00:17:47,000 --> 00:17:55,000
+SS stands for the Common Good Scoring System in the first lesson one we have in front of us and now
+
+199
+00:17:56,000 --> 00:17:59,000
+some basic terms I explain what it is.
+
+200
+00:18:00,000 --> 00:18:05,000
+So just in case you want to refresh in knowledge, just check various classes.
+
+201
+00:18:06,000 --> 00:18:12,000
+Regarding configuration of this body as aberrations are also possible.
+
+202
+00:18:12,000 --> 00:18:20,000
+You can check the temptation of this bargain because really a lot of different court cases that probably
+
+203
+00:18:20,000 --> 00:18:21,000
+is not applicable for everyone.
+
+204
+00:18:22,000 --> 00:18:29,000
+And in all possible cases, you have to use the most common configuration of this plugin and depending
+
+205
+00:18:29,000 --> 00:18:33,000
+on your project specifics, you can configure it in another way.
+
+206
+00:18:34,000 --> 00:18:39,000
+Dependency chart, however, is not the only option available to developers.
+
+207
+00:18:40,000 --> 00:18:44,000
+There are also vulnerability scanners that can help you to scan your code.
+
+208
+00:18:45,000 --> 00:18:49,000
+You can even integrate commerce into your CIC pipeline.
+
+209
+00:18:50,000 --> 00:18:56,000
+For example, let me open the official website of the snake oil snake as a service.
+
+210
+00:18:56,000 --> 00:19:04,000
+It is many things is similar to dependency chat but offers more features in that integration options.
+
+211
+00:19:04,000 --> 00:19:12,000
+For instance, if you are using it, it can forbid merging the request if the changes introduce a new
+
+212
+00:19:12,000 --> 00:19:13,000
+vulnerable dependency.
+
+213
+00:19:14,000 --> 00:19:18,000
+Even more importantly, it suggests a remediation path.
+
+214
+00:19:19,000 --> 00:19:24,000
+This has different pricing models and I am not advertising it.
+
+215
+00:19:24,000 --> 00:19:27,000
+I get nothing from Holdens as some of you really.
+
+216
+00:19:27,000 --> 00:19:32,000
+You can find any similar to and select to utilise the most.
+
+217
+00:19:33,000 --> 00:19:35,000
+Among others, of them religious scholars.
+
+218
+00:19:35,000 --> 00:19:47,000
+I can also name a few of the ones, for example kinetics v secure verbs in Jyothi Lundgaard Frontline
+
+219
+00:19:47,000 --> 00:19:57,000
+NASA's next posts and map open V.A. s, sane, Hannibal and many, many others.
+
+220
+00:19:58,000 --> 00:20:03,000
+It will be really hard to make an overview of each of the mentioned tools because they have a lot of
+
+221
+00:20:03,000 --> 00:20:11,000
+different features and sometimes some unique features so as to make your own research.
+
+222
+00:20:11,000 --> 00:20:14,000
+At least now you have a starting point.
+
+223
+00:20:14,000 --> 00:20:20,000
+And even in case you have any questions, please do not be shy to ask your questions.
+
+224
+00:20:20,000 --> 00:20:24,000
+Below is a video and I will be happy to answer.
+
+225
+00:20:24,000 --> 00:20:25,000
+Let's continue.
+
+226
+00:20:26,000 --> 00:20:33,000
+Let's talk about how to prevent negative consequences that might arise because of vulnerable and outdated
+
+227
+00:20:33,000 --> 00:20:34,000
+components.
+
+228
+00:20:35,000 --> 00:20:42,000
+To prevent this issue, the ideal solution would be to never trust set party components unless you are
+
+229
+00:20:42,000 --> 00:20:44,000
+sure of their safety.
+
+230
+00:20:44,000 --> 00:20:48,000
+Unfortunately, this is easier said than done.
+
+231
+00:20:48,000 --> 00:20:57,000
+In fact, it is not realistic to manually verify all the models you use in your quote have a party management
+
+232
+00:20:57,000 --> 00:21:04,000
+process which helps you sit back and watch all components using public vulnerabilities and exposure
+
+233
+00:21:05,000 --> 00:21:05,000
+databases.
+
+234
+00:21:06,000 --> 00:21:12,000
+Today as a demo, we learned some tools that you can use to detect vulnerabilities.
+
+235
+00:21:13,000 --> 00:21:15,000
+Use services like Snoop IO.
+
+236
+00:21:16,000 --> 00:21:17,000
+Integrate those.
+
+237
+00:21:17,000 --> 00:21:17,000
+And to use the.
+
+238
+00:21:19,000 --> 00:21:22,000
+Use of all logging to check dependencies like.
+
+239
+00:21:22,000 --> 00:21:22,000
+Shows.
+
+240
+00:21:23,000 --> 00:21:24,000
+The use of demo.
+
+241
+00:21:25,000 --> 00:21:32,000
+Installs the components with trusted channels, remove unused dependencies, unnecessary features,
+
+242
+00:21:33,000 --> 00:21:36,000
+components and files to use the surface.
+
+243
+00:21:38,000 --> 00:21:38,000
+Continuous.
+
+244
+00:21:38,000 --> 00:21:43,000
+The inventor is versions of both client side and server side components.
+
+245
+00:21:44,000 --> 00:21:45,000
+For example frameworks.
+
+246
+00:21:45,000 --> 00:21:46,000
+Libraries.
+
+247
+00:21:47,000 --> 00:21:54,000
+Continuous monitoring, monitor sources like common vulnerabilities and exposures and national vulnerability,
+
+248
+00:21:54,000 --> 00:22:01,000
+not the base vulnerabilities in the components use software composition analysis tools to automate the
+
+249
+00:22:01,000 --> 00:22:02,000
+process.
+
+250
+00:22:03,000 --> 00:22:06,000
+That's all what I wanted to discuss with you in this lesson.
+
+251
+00:22:06,000 --> 00:22:09,000
+Let's recap what we have learned today.
+
+252
+00:22:10,000 --> 00:22:17,000
+In this lesson, we have gone for vulnerable and outdated risk categories about redesigned risk factors
+
+253
+00:22:17,000 --> 00:22:21,000
+that can increase probability of negative consequences.
+
+254
+00:22:21,000 --> 00:22:25,000
+Also, you used multiple common vehicles enumerations.
+
+255
+00:22:25,000 --> 00:22:29,000
+I explained how attackers use movable components.
+
+256
+00:22:30,000 --> 00:22:33,000
+You use the real life example of attack.
+
+257
+00:22:33,000 --> 00:22:40,000
+Besides, they compare the risk category in a top down 2017 and 2021.
+
+258
+00:22:41,000 --> 00:22:46,000
+We learned how to use the tendency check login in your application.
+
+259
+00:22:46,000 --> 00:22:53,000
+Now you know what the liability scammers are, and the examples of lesson was summarized what we have
+
+260
+00:22:53,000 --> 00:22:54,000
+learned and discussed.
+
+261
+00:22:54,000 --> 00:22:56,000
+How to prevent vulnerabilities.
+
+262
+00:22:57,000 --> 00:22:59,000
+Central for your attention.
+
+263
+00:22:59,000 --> 00:23:00,000
+Have a great day and see you.
+
+264
+00:23:01,000 --> 00:23:02,000
+Next lesson.
+
diff --git a/73 - OWASP Top 10 2021/013 pom.xml-from-the-lesson-with-OWASP-plugin.url b/73 - OWASP Top 10 2021/013 pom.xml-from-the-lesson-with-OWASP-plugin.url
new file mode 100644
index 0000000000000000000000000000000000000000..a2034d8d45de2ed870fc0a3c338287ec8bfc7c0c
--- /dev/null
+++ b/73 - OWASP Top 10 2021/013 pom.xml-from-the-lesson-with-OWASP-plugin.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/blob/master/pom.xml
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/014 Identification & Authentication Failures_en.srt b/73 - OWASP Top 10 2021/014 Identification & Authentication Failures_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..2622a0a3e25bb1c4cf87f8c110268b19fdd770ad
--- /dev/null
+++ b/73 - OWASP Top 10 2021/014 Identification & Authentication Failures_en.srt
@@ -0,0 +1,1432 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, team.
+
+2
+00:00:06,000 --> 00:00:14,000
+In this last we proceed loans and next risk category from OWASP Top ten, we're going to learn ID and
+
+3
+00:00:14,000 --> 00:00:15,000
+some education payloads.
+
+4
+00:00:16,000 --> 00:00:20,000
+We'll start from the general overview of this risk category.
+
+5
+00:00:21,000 --> 00:00:27,000
+I will explain potential impacts that may be caused by identification and authentication payloads.
+
+6
+00:00:28,000 --> 00:00:30,000
+We're going to review a notable common weakness.
+
+7
+00:00:30,000 --> 00:00:40,000
+Enumerations after that will compare this risk category in August of 2017 versus avast top ten 2021.
+
+8
+00:00:41,000 --> 00:00:49,000
+In the last hour, explain how attackers may exploit broken authentication to gather on new concepts
+
+9
+00:00:49,000 --> 00:00:57,000
+like session fixation, cross-site request, forgery, execution after writing checks specially for
+
+10
+00:00:57,000 --> 00:01:03,000
+this lesson, I guess there is a risk factors that can increase the risk of potential attack.
+
+11
+00:01:04,000 --> 00:01:08,000
+Separately, we're going to talk about multi-factor authentication.
+
+12
+00:01:08,000 --> 00:01:11,000
+I will explain what session ID entropy is.
+
+13
+00:01:12,000 --> 00:01:16,000
+And as always, we're going to review examples of attacks.
+
+14
+00:01:17,000 --> 00:01:23,000
+You will learn what credential stuffing, brute force access and session hijacking are.
+
+15
+00:01:24,000 --> 00:01:30,000
+At the end of the lesson, we're going to discuss how to prevent attacks related to unification and
+
+16
+00:01:30,000 --> 00:01:31,000
+authentication failures.
+
+17
+00:01:32,000 --> 00:01:35,000
+Let's start our lesson as always.
+
+18
+00:01:35,000 --> 00:01:40,000
+Let's start from high level overview to understand what this risk category is all about.
+
+19
+00:01:41,000 --> 00:01:48,000
+Identification and authentication failures can occur when functions are related to a user's identity.
+
+20
+00:01:49,000 --> 00:01:57,000
+Authentication or session management are not implemented correctly or not adequately protected by application.
+
+21
+00:01:58,000 --> 00:02:05,000
+Attackers may be able to exploit identification and authentication failures by compromising passwords,
+
+22
+00:02:06,000 --> 00:02:11,000
+keys, session tokens or exploit OSI implementation flaws.
+
+23
+00:02:11,000 --> 00:02:17,000
+To assume the user's identity is a temporary or permanently broken.
+
+24
+00:02:17,000 --> 00:02:25,000
+Authentication means an attacker can gain access to restricted data by pretending to be a different
+
+25
+00:02:25,000 --> 00:02:25,000
+user.
+
+26
+00:02:26,000 --> 00:02:33,000
+The attacker provides authentication credentials of a different user and logs into the system.
+
+27
+00:02:34,000 --> 00:02:41,000
+In this way, the attack against access to all the data and functionality of the user keeper has to
+
+28
+00:02:41,000 --> 00:02:41,000
+be.
+
+29
+00:02:42,000 --> 00:02:49,000
+For instance, if an attacker provides the credentials of the admin user, he will have total control
+
+30
+00:02:49,000 --> 00:02:51,000
+or was a compromised system.
+
+31
+00:02:52,000 --> 00:02:59,000
+Authentication means you are who you say you are and ID is also the same.
+
+32
+00:03:00,000 --> 00:03:07,000
+That's why in my opinion the name is a little bit confusing so we will not dive deeper.
+
+33
+00:03:07,000 --> 00:03:10,000
+It is a syntactical difference between these two camps.
+
+34
+00:03:11,000 --> 00:03:14,000
+Basically, this risk category describes cases.
+
+35
+00:03:14,000 --> 00:03:22,000
+One attacker acts on behalf of the user because of the broken system or vulnerabilities found in the
+
+36
+00:03:22,000 --> 00:03:23,000
+system.
+
+37
+00:03:24,000 --> 00:03:31,000
+Let's review potential impacts that may be caused by vulnerabilities related to the identification and
+
+38
+00:03:31,000 --> 00:03:35,000
+authentication failures and more potential impact.
+
+39
+00:03:35,000 --> 00:03:36,000
+It is worse.
+
+40
+00:03:36,000 --> 00:03:44,000
+Two names of following ones loss of administrative access in case authentication will be broken and
+
+41
+00:03:44,000 --> 00:03:51,000
+the attacker will get access to the account with admin role, then the whole system may be compromised.
+
+42
+00:03:52,000 --> 00:03:59,000
+It only takes a single account was administrative access to be compromised and the attackers have access
+
+43
+00:03:59,000 --> 00:04:01,000
+to the entire system.
+
+44
+00:04:01,000 --> 00:04:10,000
+On that full disclosure of sensitive information, unauthorized access may disclose sensitive information
+
+45
+00:04:10,000 --> 00:04:15,000
+in the previous lesson learned already what can be considered a sensitive information.
+
+46
+00:04:16,000 --> 00:04:24,000
+That's why I wouldn't stop on this performing actions on behalf of OSI users getting access to accounts
+
+47
+00:04:24,000 --> 00:04:25,000
+of other users.
+
+48
+00:04:25,000 --> 00:04:32,000
+Attackers can perform actions on their behalf depending on the domain of the application.
+
+49
+00:04:32,000 --> 00:04:40,000
+This may lead to losing money his account of the user money laundering, Social Security fraud and identity
+
+50
+00:04:40,000 --> 00:04:46,000
+theft or disclosure of legally protected, highly sensitive information.
+
+51
+00:04:46,000 --> 00:04:52,000
+Any of mentioned impacts can cost a lot to your company and your organization.
+
+52
+00:04:52,000 --> 00:05:01,000
+For example, losing the personal data of European citizens could invoke GBR fines of up to 4% of a
+
+53
+00:05:01,000 --> 00:05:03,000
+company's annual global revenue.
+
+54
+00:05:04,000 --> 00:05:08,000
+For large companies, this could run to billions of dollars.
+
+55
+00:05:08,000 --> 00:05:15,000
+Broken authentication is a serious threat to application and website developers have made.
+
+56
+00:05:15,000 --> 00:05:17,000
+Strikers and owners.
+
+57
+00:05:18,000 --> 00:05:27,000
+Let's discuss now notable common weakness enumerations associated with this category notable c w e included
+
+58
+00:05:27,000 --> 00:05:31,000
+rcwe2 hundred 97.
+
+59
+00:05:32,000 --> 00:05:36,000
+Improper validation of scientific hat was host mismatch.
+
+60
+00:05:37,000 --> 00:05:45,000
+Even if a certificate is well-formed sign and follows the chain of trust, it may simply be a valid
+
+61
+00:05:45,000 --> 00:05:48,000
+certificate for a different site.
+
+62
+00:05:48,000 --> 00:05:57,000
+Then the site is in the software is interacting with user certificates, hosts specific data is not
+
+63
+00:05:57,000 --> 00:06:05,000
+properly checked, such as a common name in the subject or is a subject alternatively extension of an
+
+64
+00:06:05,000 --> 00:06:08,000
+X point 509 certificate.
+
+65
+00:06:08,000 --> 00:06:15,000
+It may be possible for a redirection or spoofing an that allow a malicious host with a valid certificate
+
+66
+00:06:16,000 --> 00:06:17,000
+to provide data.
+
+67
+00:06:18,000 --> 00:06:20,000
+Impersonate a trusted host.
+
+68
+00:06:21,000 --> 00:06:28,000
+In order to ensure data integrity, the certificate must be valid and that must pertain to the site
+
+69
+00:06:29,000 --> 00:06:35,000
+that is being accessed even if the software attempts to check the hostname.
+
+70
+00:06:36,000 --> 00:06:40,000
+It is still possible to incorrectly check the hostname.
+
+71
+00:06:40,000 --> 00:06:48,000
+For example, attackers could create a certificate with a name begins with a trusted name, followed
+
+72
+00:06:48,000 --> 00:06:54,000
+by a load by which could cause some string based comparisons to only eggs and lines.
+
+73
+00:06:54,000 --> 00:06:57,000
+A portion that contains a trusted name.
+
+74
+00:06:58,000 --> 00:06:59,000
+What is new?
+
+75
+00:06:59,000 --> 00:07:02,000
+By also reviewed in our previous lessons.
+
+76
+00:07:03,000 --> 00:07:09,000
+And anyway, in case something is not clear, do not hesitate to ask your questions below.
+
+77
+00:07:09,000 --> 00:07:12,000
+Xavier and I will be happy to answer.
+
+78
+00:07:13,000 --> 00:07:15,000
+cwe2 hundred 87.
+
+79
+00:07:16,000 --> 00:07:18,000
+Improper Authentication.
+
+80
+00:07:19,000 --> 00:07:25,000
+This c describes a case when an actor claims to have a given identity.
+
+81
+00:07:25,000 --> 00:07:32,000
+This software doesn't prove or insufficiently proves that the claim is correct.
+
+82
+00:07:33,000 --> 00:07:37,000
+CWA e 384 session fixation.
+
+83
+00:07:38,000 --> 00:07:47,000
+Such scenario is commonly observed when advocation authenticates a user without first invalidating the
+
+84
+00:07:47,000 --> 00:07:54,000
+existence session, thereby continuing to use the session already associated with the user.
+
+85
+00:07:55,000 --> 00:08:03,000
+An attacker is able to force the null session identifier on the user so that once the user authenticates,
+
+86
+00:08:04,000 --> 00:08:07,000
+that talker has access to the authenticated session.
+
+87
+00:08:08,000 --> 00:08:16,000
+The application will contain the user's projected will session identifiers in the generic excluded of
+
+88
+00:08:16,000 --> 00:08:19,000
+the session fixation or immunities and attack.
+
+89
+00:08:19,000 --> 00:08:27,000
+It creates and use session on a valid location and the recourse associated session identify the attackers
+
+90
+00:08:27,000 --> 00:08:33,000
+and causes the victim to associate and possibly authenticate against the server.
+
+91
+00:08:33,000 --> 00:08:41,000
+Using that session event file gives the attacker access to the user's account through the active session.
+
+92
+00:08:41,000 --> 00:08:45,000
+These are the most notable common vacancies enumerations.
+
+93
+00:08:45,000 --> 00:08:46,000
+Let's move on.
+
+94
+00:08:47,000 --> 00:08:53,000
+Let's compare our last top ten, 2017 versus 2021.
+
+95
+00:08:54,000 --> 00:09:04,000
+As you can see on this slide, broken authentication was on the second position in 2017 inches 2021.
+
+96
+00:09:04,000 --> 00:09:12,000
+It was renamed the identification and Authentication Failures and was moved to the position number seven.
+
+97
+00:09:13,000 --> 00:09:21,000
+Now, this risk category includes common weakness, nominations related to ID failures less known what
+
+98
+00:09:21,000 --> 00:09:29,000
+techniques are used by attackers to exploit broken authentication lines the way how attackers act.
+
+99
+00:09:30,000 --> 00:09:39,000
+We will be ready to react on this and we are going to run source of impacts first and after the lesson
+
+100
+00:09:39,000 --> 00:09:42,000
+we're going to know how to mitigate these attacks.
+
+101
+00:09:43,000 --> 00:09:47,000
+So attackers use a range of techniques, including the fallen.
+
+102
+00:09:49,000 --> 00:09:56,000
+Brute force or credential stuffing in one of the previous last real working years was a brute force
+
+103
+00:09:56,000 --> 00:10:04,000
+is and brute force attack consists of an attacker submitting many passwords or pass phrases with the
+
+104
+00:10:04,000 --> 00:10:07,000
+hope of eventually guessing correctly.
+
+105
+00:10:08,000 --> 00:10:15,000
+Credential stuff is a type of cyber attack in which that target collects stolen account credentials
+
+106
+00:10:16,000 --> 00:10:25,000
+typically consists of lists of usernames and or email addresses and the corresponding passwords, often
+
+107
+00:10:25,000 --> 00:10:32,000
+from a data breach, and then uses the credentials to gain unauthorized access to user accounts.
+
+108
+00:10:32,000 --> 00:10:37,000
+So large scale automated logging requests directed against a web application.
+
+109
+00:10:38,000 --> 00:10:45,000
+Session hijacking, session hijacking, sometimes also known as kook hijacking.
+
+110
+00:10:45,000 --> 00:10:54,000
+It is the exploitation of a valid computer session to gain unauthorized access to information or services
+
+111
+00:10:54,000 --> 00:10:55,000
+in the computer system.
+
+112
+00:10:56,000 --> 00:11:03,000
+In particular, this channel is used to refer to the zest of the cookie used to authenticate the user
+
+113
+00:11:03,000 --> 00:11:04,000
+to a remote server.
+
+114
+00:11:05,000 --> 00:11:07,000
+Do you remember this lesson I showed you?
+
+115
+00:11:07,000 --> 00:11:14,000
+How a topic and steal a session, a cookie, and after that just be authorized in the application.
+
+116
+00:11:15,000 --> 00:11:18,000
+So this is exactly about describe in this case.
+
+117
+00:11:20,000 --> 00:11:27,000
+Session fixation will really talked about session fixation when we reviewed the common vehicles enumerations.
+
+118
+00:11:28,000 --> 00:11:30,000
+But let's recap one more time.
+
+119
+00:11:31,000 --> 00:11:38,000
+Session fixation is a type of attack on web application users, where an attacker is able to trick the
+
+120
+00:11:38,000 --> 00:11:45,000
+victim into using the session they need, which is previously known to zap the attacker.
+
+121
+00:11:45,000 --> 00:11:52,000
+Tweaks the user into using a specific session ID after the user walks into the web application using
+
+122
+00:11:52,000 --> 00:12:00,000
+the provided session and the attacker uses this method session ID to gain access to the user's account.
+
+123
+00:12:01,000 --> 00:12:08,000
+This attack, the first from session hijacking, ends the fact that the session ID is previously known
+
+124
+00:12:08,000 --> 00:12:15,000
+as the attacker and is forced onto the victim as opposed to the attacker discovering the tokens through
+
+125
+00:12:15,000 --> 00:12:17,000
+another ability.
+
+126
+00:12:18,000 --> 00:12:27,000
+Cross sides request forgery in a C as F attack and innocent and user is tweaked by an attack into submitting
+
+127
+00:12:27,000 --> 00:12:31,000
+a web request that they did not intend.
+
+128
+00:12:31,000 --> 00:12:39,000
+This may cause actions to be performed on the website that can change session, state or operation often
+
+129
+00:12:39,000 --> 00:12:40,000
+and users account.
+
+130
+00:12:41,000 --> 00:12:48,000
+Cross sides request forgery is an attack that forces an end user to execute unwanted actions on the
+
+131
+00:12:48,000 --> 00:12:52,000
+web application in which they are currently authenticated.
+
+132
+00:12:53,000 --> 00:13:01,000
+With a little help of social engineering, such as sending an email or chat, an attacker may twigs
+
+133
+00:13:01,000 --> 00:13:08,000
+that users of a web application into executing actions of the attacker's choosing gives a victim is
+
+134
+00:13:08,000 --> 00:13:17,000
+a normal use of a successful CSR attack can force the user to perform state changing requests like transferring
+
+135
+00:13:17,000 --> 00:13:25,000
+fonts, changing the email address and so force if the victim is an administrative account.
+
+136
+00:13:25,000 --> 00:13:29,000
+See SRF can compromise in time of their application.
+
+137
+00:13:30,000 --> 00:13:37,000
+Execution after redirect execution of the rhetoric is an attack where an attacker ignores, redirects
+
+138
+00:13:38,000 --> 00:13:43,000
+and retrieves sensitive content intended for authenticated users.
+
+139
+00:13:43,000 --> 00:13:44,000
+Let me explain.
+
+140
+00:13:45,000 --> 00:13:49,000
+Consider web application that has logging functionality.
+
+141
+00:13:49,000 --> 00:13:58,000
+Users who have an account can access content features in this web application only by logging in on
+
+142
+00:13:58,000 --> 00:14:06,000
+authenticated users are redirected to the login page for them the first to log in and get an authenticated
+
+143
+00:14:06,000 --> 00:14:06,000
+session.
+
+144
+00:14:07,000 --> 00:14:15,000
+This is one of the many situations where the execute after redirect vulnerability may create, and this
+
+145
+00:14:15,000 --> 00:14:23,000
+vulnerability arises in an improper implementation of court where the developer assumes the execution
+
+146
+00:14:23,000 --> 00:14:25,000
+stops after redirect.
+
+147
+00:14:25,000 --> 00:14:34,000
+However, it is not always true the remaining port of the page or several also gets executed.
+
+148
+00:14:34,000 --> 00:14:37,000
+This is about a case when you resurrect the user.
+
+149
+00:14:38,000 --> 00:14:45,000
+You shouldn't forget the call over char massive to stop execution of the mass in order to not execute
+
+150
+00:14:45,000 --> 00:14:51,000
+any line of code that is not supposed to be executed if the user is not, log in.
+
+151
+00:14:52,000 --> 00:14:57,000
+These are the main ways that attackers will use to exploit growth and authentication.
+
+152
+00:14:58,000 --> 00:15:04,000
+Let's continue with a view of how attackers will try to exploit the application.
+
+153
+00:15:04,000 --> 00:15:07,000
+And now let's review another side of the model.
+
+154
+00:15:07,000 --> 00:15:11,000
+Let's take a look what can increase the risk of attack.
+
+155
+00:15:12,000 --> 00:15:18,000
+Let's review risk factors that we have to avoid in order to make our application more secure.
+
+156
+00:15:19,000 --> 00:15:26,000
+So among risk factors that can increase the risk of broken or syndication attacks, it is worse to mention
+
+157
+00:15:26,000 --> 00:15:30,000
+is a following once using weak and standard passwords.
+
+158
+00:15:31,000 --> 00:15:37,000
+I know that this is a very common risk factor, but it is not an exclusion for this case.
+
+159
+00:15:37,000 --> 00:15:45,000
+Is a username and password for your admin panel are at me and admin an attacker can easily guys and
+
+160
+00:15:45,000 --> 00:15:47,000
+whole system will be compromised.
+
+161
+00:15:48,000 --> 00:15:53,000
+Hackers have broken into a lot of systems in the past because of weak passwords.
+
+162
+00:15:54,000 --> 00:16:01,000
+We can implement the password limitation policies to force our users to change password each month for
+
+163
+00:16:01,000 --> 00:16:02,000
+three months.
+
+164
+00:16:02,000 --> 00:16:05,000
+For example, looking to implement weak password check.
+
+165
+00:16:05,000 --> 00:16:08,000
+And so the creation of accounts was weak passwords.
+
+166
+00:16:09,000 --> 00:16:11,000
+As you can see, we have different options here.
+
+167
+00:16:12,000 --> 00:16:16,000
+Has missing or ineffective multi-factor authentication.
+
+168
+00:16:17,000 --> 00:16:22,000
+Absence of multi-factor authentication is a significant risk factor.
+
+169
+00:16:22,000 --> 00:16:29,000
+For example, each time you want to start the session with web application besides logging and passwords
+
+170
+00:16:29,000 --> 00:16:30,000
+provided.
+
+171
+00:16:30,000 --> 00:16:38,000
+User also receives a request to his or her mobile phone, for example, and only after the request is
+
+172
+00:16:38,000 --> 00:16:41,000
+confirmed, sessions start and create.
+
+173
+00:16:42,000 --> 00:16:48,000
+The request can be sent either into the native mobile app or, as this can be called, into Assamese.
+
+174
+00:16:49,000 --> 00:16:53,000
+This can be auto generated tokens at the end before signing in.
+
+175
+00:16:54,000 --> 00:17:00,000
+There are different ways how to implement this, but just remember that multi-factor authentication
+
+176
+00:17:00,000 --> 00:17:05,000
+is very efficient and proven mechanism to confirm the identity of a user.
+
+177
+00:17:06,000 --> 00:17:10,000
+And that's a risk factor is allowing brute force cracking.
+
+178
+00:17:11,000 --> 00:17:17,000
+If you change your credentials to something stronger, those credentials can still be compromised.
+
+179
+00:17:18,000 --> 00:17:23,000
+One way an attacker can gain those credentials is via brute force cracking.
+
+180
+00:17:23,000 --> 00:17:30,000
+And other words, an attacker creates an automated script that uses different combinations of usernames
+
+181
+00:17:30,000 --> 00:17:34,000
+and passwords sequentially until he finds the right combination.
+
+182
+00:17:35,000 --> 00:17:37,000
+This process can be very time consuming.
+
+183
+00:17:38,000 --> 00:17:40,000
+Days, weeks, or even months.
+
+184
+00:17:40,000 --> 00:17:47,000
+But if you don't programmed this kind of attack, it is still doable to prevent this kind of attack.
+
+185
+00:17:47,000 --> 00:17:55,000
+Implementing delays with failed attempts to lock in or block logging attempts completely after you failed
+
+186
+00:17:55,000 --> 00:17:57,000
+to log in at times in a row.
+
+187
+00:17:58,000 --> 00:18:05,000
+Using weak or ineffective credential recovery and forgot password processes such as knowledge based
+
+188
+00:18:05,000 --> 00:18:12,000
+answers which can be made safe will ready discussed in previous classes.
+
+189
+00:18:12,000 --> 00:18:18,000
+That is is not the best practice to rely on the secrets questions while restoring the password.
+
+190
+00:18:19,000 --> 00:18:26,000
+Because in the area of social networks, this relatively easy to steal information builds the user or
+
+191
+00:18:26,000 --> 00:18:30,000
+clarify through the path of the mother's maiden name.
+
+192
+00:18:31,000 --> 00:18:39,000
+So make sure that restoring password flow is also secure and uses other communication channels that
+
+193
+00:18:39,000 --> 00:18:42,000
+only user identity has.
+
+194
+00:18:42,000 --> 00:18:51,000
+For example, make sure you enable some verification of the user use of password restoring sending credentials
+
+195
+00:18:51,000 --> 00:18:53,000
+in an insecure way.
+
+196
+00:18:54,000 --> 00:19:01,000
+Even if you use a strong password and prevent brute force attacks, but send the credentials to the
+
+197
+00:19:01,000 --> 00:19:05,000
+server in plaintext, use an unencrypted connection.
+
+198
+00:19:05,000 --> 00:19:09,000
+For example, you use a CTP but not a protocol.
+
+199
+00:19:10,000 --> 00:19:16,000
+Any other user who is connected to the same network as you can eavesdrop as a traffic.
+
+200
+00:19:17,000 --> 00:19:22,000
+Once attacker has the credentials, he can log in as if he were you.
+
+201
+00:19:23,000 --> 00:19:25,000
+Improper session time.
+
+202
+00:19:26,000 --> 00:19:29,000
+It's important to set a time out for our log in session.
+
+203
+00:19:30,000 --> 00:19:37,000
+This means that after a certain period of inactivity, the user is automatically left out from the system.
+
+204
+00:19:38,000 --> 00:19:41,000
+Failing to do so may result in session hijacking.
+
+205
+00:19:43,000 --> 00:19:45,000
+Expose in session identifiers.
+
+206
+00:19:45,000 --> 00:19:52,000
+Another way in which an attacker can compromise a session is by seeing the session identifier zero.
+
+207
+00:19:53,000 --> 00:19:59,000
+During this process, anyone who has a name can enter the stolen session.
+
+208
+00:20:00,000 --> 00:20:09,000
+Failing to secure API in an API is there is usually a way to define which roles should require and syndication
+
+209
+00:20:09,000 --> 00:20:11,000
+and which should not.
+
+210
+00:20:11,000 --> 00:20:18,000
+If you fail to add an authentication requirement for a role that should contain, the functionality
+
+211
+00:20:18,000 --> 00:20:21,000
+behind this role will be available worldwide.
+
+212
+00:20:22,000 --> 00:20:29,000
+And this is not the you should keep only public resources available, as resources should be protected
+
+213
+00:20:29,000 --> 00:20:31,000
+by authentication.
+
+214
+00:20:32,000 --> 00:20:36,000
+While reviewing the slide, I mentioned multi-factor authentication.
+
+215
+00:20:37,000 --> 00:20:43,000
+The name is MFA taking implementation side of the MFA.
+
+216
+00:20:43,000 --> 00:20:50,000
+I would say that this law is beyond the scope of this lesson, but I believe that we still need to cover
+
+217
+00:20:50,000 --> 00:20:58,000
+some basic radical knowledge about MFA that will serve as a starting point for Eugene's implementation.
+
+218
+00:20:58,000 --> 00:21:01,000
+So let's recap one more time.
+
+219
+00:21:01,000 --> 00:21:03,000
+What is MFA?
+
+220
+00:21:04,000 --> 00:21:11,000
+Multi-factor authentication is an authentication massive, which requires the user to provide two or
+
+221
+00:21:11,000 --> 00:21:20,000
+more verification factors to gain access to a resource such as an application online account or a VPN.
+
+222
+00:21:21,000 --> 00:21:27,000
+MFA is a core component of a strong identity and access management policy.
+
+223
+00:21:28,000 --> 00:21:31,000
+Rather than just asking for a username and password.
+
+224
+00:21:31,000 --> 00:21:39,000
+MFA requires one or more additional verification factors which decreases the likelihood of a successful
+
+225
+00:21:39,000 --> 00:21:40,000
+cyber attack.
+
+226
+00:21:41,000 --> 00:21:49,000
+MFA works by requiring additional verification confirmation factors that usually factor is that they
+
+227
+00:21:49,000 --> 00:22:01,000
+used under the MFA zero time based one time password short message service, electronic email push notifications.
+
+228
+00:22:02,000 --> 00:22:08,000
+One of the most common MFA factors is that user encounter is one time passwords.
+
+229
+00:22:08,000 --> 00:22:10,000
+Is that the U.S. user?
+
+230
+00:22:10,000 --> 00:22:13,000
+We are CMOs or on email.
+
+231
+00:22:14,000 --> 00:22:22,000
+I'm talking about those digit codes that you often receive email esims or some sort of mobile app and
+
+232
+00:22:22,000 --> 00:22:27,000
+you code is generated each time and a syndication request is submitted.
+
+233
+00:22:28,000 --> 00:22:35,000
+The Court is generated based upon the seat value as it is assigned to Z use of one Z first register
+
+234
+00:22:35,000 --> 00:22:41,000
+and some other factor which could simply be account incremented or the time value.
+
+235
+00:22:42,000 --> 00:22:50,000
+Most MFA authentication methodology is based on one of three types of additional information since you
+
+236
+00:22:50,000 --> 00:23:01,000
+no knowledge such as password of being since you have possession such as mage of smartphone, since
+
+237
+00:23:01,000 --> 00:23:07,000
+you are the parents such as biometric like fingerprints or voice and completion.
+
+238
+00:23:09,000 --> 00:23:11,000
+We talked with you about securing the session.
+
+239
+00:23:11,000 --> 00:23:15,000
+And let me elaborate on this a little bit more.
+
+240
+00:23:15,000 --> 00:23:24,000
+The session they need must be unpredictable, random enough to prevent gas attacks where an attacker
+
+241
+00:23:24,000 --> 00:23:31,000
+is able to guess or predict the idea of a valid session through statistical analysis techniques.
+
+242
+00:23:31,000 --> 00:23:39,000
+For this purpose, a good cryptographically secure pseudo random number generator must be used as a
+
+243
+00:23:39,000 --> 00:23:48,000
+set of guidelines created not only for Java's software engineers, but also for other programmers too.
+
+244
+00:23:49,000 --> 00:23:56,000
+I would say in case you create app on Java and you use some kind of web server, for example, you shouldn't
+
+245
+00:23:56,000 --> 00:24:04,000
+be bothered about this too much because required mechanisms are already implemented inside Tomcat.
+
+246
+00:24:05,000 --> 00:24:09,000
+Tomcat generates unique string for the session identifier.
+
+247
+00:24:10,000 --> 00:24:17,000
+If you don't have such feature out of the on your web server, you should use cryptographically secure
+
+248
+00:24:17,000 --> 00:24:19,000
+pseudo random number generator.
+
+249
+00:24:20,000 --> 00:24:27,000
+The main thing is to not use predictable sequences for this session I use the session I value must provide
+
+250
+00:24:27,000 --> 00:24:30,000
+at least 64 bits of entropy.
+
+251
+00:24:31,000 --> 00:24:38,000
+If a good random number generator is used, this value is estimated to be housing length of the session.
+
+252
+00:24:40,000 --> 00:24:42,000
+Additionally, our random session I use nothing else.
+
+253
+00:24:43,000 --> 00:24:47,000
+It must also be somewhat duplicate that I use.
+
+254
+00:24:48,000 --> 00:24:53,000
+A random session must not already exist in the current session i space.
+
+255
+00:24:54,000 --> 00:24:58,000
+Following these rules will help you to secure your S.A.T..
+
+256
+00:24:59,000 --> 00:25:01,000
+Now it is time to review.
+
+257
+00:25:01,000 --> 00:25:09,000
+Examples of attacks of our supposed Lords is a sweet time to attack parties that exploit weak association
+
+258
+00:25:10,000 --> 00:25:19,000
+their credentials, tough and brute force access session hijack lets you use these parties in scope
+
+259
+00:25:19,000 --> 00:25:22,000
+of the particular scenarios one by one.
+
+260
+00:25:23,000 --> 00:25:31,000
+Scenario number one for national stuff, the use of the use of known passwords is a common attack.
+
+261
+00:25:31,000 --> 00:25:37,000
+Suppose an application doesn't implement automated threat or credential stops and protection.
+
+262
+00:25:38,000 --> 00:25:46,000
+In that case, the application can be used as a password oracle to demand user credentials invalid user
+
+263
+00:25:46,000 --> 00:25:47,000
+credentials stuff.
+
+264
+00:25:47,000 --> 00:25:54,000
+An attacker can use automated tools to test a list of rather the usernames and passwords stolen from
+
+265
+00:25:54,000 --> 00:25:58,000
+one company against the website of another company.
+
+266
+00:25:59,000 --> 00:26:06,000
+Since users frequently use the same password on multiple accounts, attackers using this massive have
+
+267
+00:26:06,000 --> 00:26:07,000
+chances to achieve a success.
+
+268
+00:26:08,000 --> 00:26:16,000
+Scenario number two most authentication tech secure due to the continued use of passwords as a sole
+
+269
+00:26:16,000 --> 00:26:17,000
+factor.
+
+270
+00:26:18,000 --> 00:26:24,000
+Once considered best practices, passwords, limitation and complexity requirements encourage users
+
+271
+00:26:24,000 --> 00:26:27,000
+to use and reuse weak passwords.
+
+272
+00:26:28,000 --> 00:26:38,000
+Organisations are recommended to stop these processes per NIST 863 and use multi-factor authentication.
+
+273
+00:26:39,000 --> 00:26:42,000
+Multi-factor authentication should prevent brute force.
+
+274
+00:26:43,000 --> 00:26:49,000
+As we discussed, brute force and passwords is technically the process of trying every different password
+
+275
+00:26:49,000 --> 00:26:51,000
+possible to use.
+
+276
+00:26:51,000 --> 00:26:52,000
+The correct one is found.
+
+277
+00:26:53,000 --> 00:26:56,000
+In practice, this isn't necessary.
+
+278
+00:26:56,000 --> 00:27:03,000
+Attackers will use a list of the most common passwords, such as parcels and one, two, three, four,
+
+279
+00:27:03,000 --> 00:27:05,000
+five, six, seven, eight, nine.
+
+280
+00:27:05,000 --> 00:27:08,000
+And try each one in turn again.
+
+281
+00:27:08,000 --> 00:27:09,000
+Use an automated scripts.
+
+282
+00:27:10,000 --> 00:27:14,000
+Was users now having to manage so many different passwords?
+
+283
+00:27:15,000 --> 00:27:23,000
+The tendency for people to use simple ones and to use the same password across multiple accounts.
+
+284
+00:27:23,000 --> 00:27:28,000
+Brute force is consequently a simple and also effective attack.
+
+285
+00:27:30,000 --> 00:27:35,000
+Scenario number three, application session timeouts are not set correctly.
+
+286
+00:27:36,000 --> 00:27:41,000
+Imagine a case that is a hotel or at the airport.
+
+287
+00:27:41,000 --> 00:27:45,000
+A user uses a public computer to access an application.
+
+288
+00:27:46,000 --> 00:27:54,000
+Instead of selecting a logout, the user simply closes the browser tab and walks away and uses the same
+
+289
+00:27:54,000 --> 00:27:59,000
+browser an hour later, and the user is to authenticate.
+
+290
+00:28:00,000 --> 00:28:06,000
+Session hijacking is the exploitation of a legitimate user's authenticated session.
+
+291
+00:28:07,000 --> 00:28:15,000
+Once login is achieved, the host system will typically assign the session as a user so that it is necessary
+
+292
+00:28:15,000 --> 00:28:17,000
+to log in for each new page.
+
+293
+00:28:17,000 --> 00:28:25,000
+Within this session, there is usually a value as a displaced cookie on the user's computer.
+
+294
+00:28:26,000 --> 00:28:30,000
+In theory, it is removed when the user logs out from the session.
+
+295
+00:28:30,000 --> 00:28:37,000
+If an attacker can, other things, especially in any possible way, is a cross-site scripting.
+
+296
+00:28:37,000 --> 00:28:45,000
+By sniffing traffic while using laptop of the user, he or she is able to hijack a legitimate user's
+
+297
+00:28:45,000 --> 00:28:45,000
+session.
+
+298
+00:28:46,000 --> 00:28:55,000
+Since that user is already authenticated that Tucker is able to perform any action allowed to that user.
+
+299
+00:28:55,000 --> 00:29:02,000
+The most common session hijack attacks, I'm guessing all predicted, is a session talking snake on
+
+300
+00:29:02,000 --> 00:29:11,000
+the talking plan side attacks like peaks, SS malicious JavaScript codes, Trojans, etc..
+
+301
+00:29:12,000 --> 00:29:16,000
+Men's and naval attacks and manuals of browser attacks.
+
+302
+00:29:17,000 --> 00:29:25,000
+We have learned a lot about identification and authentication failures, review of that samples and
+
+303
+00:29:25,000 --> 00:29:31,000
+now we are ready to summarize recommendations and rules to follow to decrease the risk of vulnerabilities
+
+304
+00:29:31,000 --> 00:29:33,000
+from this risk category.
+
+305
+00:29:34,000 --> 00:29:38,000
+Luckily, most of the mitigation techniques are simple and straightforward.
+
+306
+00:29:39,000 --> 00:29:42,000
+If you use these techniques, zero waste decreases.
+
+307
+00:29:43,000 --> 00:29:49,000
+Most of those techniques are framework agnostic and can apply to all frameworks equally.
+
+308
+00:29:50,000 --> 00:29:53,000
+Let's review user recommendations one by one.
+
+309
+00:29:54,000 --> 00:29:58,000
+Implement multi-factor authentication wherever possible.
+
+310
+00:29:58,000 --> 00:30:06,000
+MFA supposed to prevent automated credential stuffing, brute force and stolen credential reuse attacks.
+
+311
+00:30:07,000 --> 00:30:13,000
+They're not sheep or the wall was any different credentials, especially for adding users.
+
+312
+00:30:15,000 --> 00:30:19,000
+Enforce the policy to prevent users from setting the business.
+
+313
+00:30:20,000 --> 00:30:28,000
+Implement password checks such as testing new or changed passwords against the top 10,000 versus password
+
+314
+00:30:28,000 --> 00:30:29,000
+release.
+
+315
+00:30:30,000 --> 00:30:38,000
+This should eliminate cases when users are able to set keyboard sequences as passwords like 30.
+
+316
+00:30:38,000 --> 00:30:40,000
+One, two, three, four, five six.
+
+317
+00:30:41,000 --> 00:30:49,000
+Introduce a password for a patient policy change that passwords and every specific amount of weeks or
+
+318
+00:30:49,000 --> 00:30:50,000
+each three months.
+
+319
+00:30:50,000 --> 00:30:53,000
+For example, you can implement logic.
+
+320
+00:30:53,000 --> 00:31:00,000
+One user receives notification about his password being expired and that he or she needs to change the
+
+321
+00:31:00,000 --> 00:31:04,000
+password in case password is expired.
+
+322
+00:31:04,000 --> 00:31:08,000
+User only can go through a set of password flow.
+
+323
+00:31:09,000 --> 00:31:16,000
+Limit or increase delays between failed attempts, basically zero different ways.
+
+324
+00:31:16,000 --> 00:31:17,000
+How to implement this.
+
+325
+00:31:17,000 --> 00:31:21,000
+I will let you think about the implementation and implement it.
+
+326
+00:31:22,000 --> 00:31:24,000
+This will be one of your whole tasks.
+
+327
+00:31:25,000 --> 00:31:29,000
+I will share the details about the whole tasks as a separate lesson.
+
+328
+00:31:30,000 --> 00:31:34,000
+Implement notifications when attack is detected.
+
+329
+00:31:35,000 --> 00:31:43,000
+Local sailors and alert administrators from Congressional staff and force OSR attacks the Texas.
+
+330
+00:31:44,000 --> 00:31:49,000
+Limit the session duration and invalidate the session after logout.
+
+331
+00:31:50,000 --> 00:31:52,000
+Store session and security.
+
+332
+00:31:53,000 --> 00:31:55,000
+This means a number of things at a time.
+
+333
+00:31:56,000 --> 00:31:59,000
+Namely, the not cost session is the euro.
+
+334
+00:32:00,000 --> 00:32:04,000
+Also, we learned today what is session entropy.
+
+335
+00:32:05,000 --> 00:32:11,000
+So ensure that the entropy source is quite good and also it is important.
+
+336
+00:32:11,000 --> 00:32:14,000
+Course something fun with the session time when a user is logged out.
+
+337
+00:32:15,000 --> 00:32:21,000
+These measures would take you a long way and help avoid such mistakes.
+
+338
+00:32:21,000 --> 00:32:28,000
+Confirmation of the user's identity authentication and session management is critical to protect against
+
+339
+00:32:28,000 --> 00:32:30,000
+syndication related attacks.
+
+340
+00:32:31,000 --> 00:32:32,000
+That's all.
+
+341
+00:32:32,000 --> 00:32:34,000
+What I wanted to share with you today is a lesson.
+
+342
+00:32:35,000 --> 00:32:37,000
+Let's recap what we have.
+
+343
+00:32:38,000 --> 00:32:39,000
+In this lesson.
+
+344
+00:32:39,000 --> 00:32:48,000
+The current identification and authentication failure risk category from a WASP Top ten we learned about
+
+345
+00:32:48,000 --> 00:32:50,000
+common vehicle enumerations.
+
+346
+00:32:50,000 --> 00:32:57,000
+We compared of top ten 2017 versus of up ten 2021.
+
+347
+00:32:57,000 --> 00:33:06,000
+I explained to you how to cross exclude broken authentication when you have such things as session fixation
+
+348
+00:33:06,000 --> 00:33:08,000
+plus size request forgery.
+
+349
+00:33:09,000 --> 00:33:14,000
+We have different factors that can increase probability of attacks.
+
+350
+00:33:15,000 --> 00:33:18,000
+WILLIAMS Multifactor authentication.
+
+351
+00:33:18,000 --> 00:33:25,000
+Also, I explained to you what session I.D. entropy is and how we can secure our session ID.
+
+352
+00:33:25,000 --> 00:33:29,000
+I explained different examples of attacks.
+
+353
+00:33:30,000 --> 00:33:36,000
+Now you know what credentials Statham brute force and session hijacking are.
+
+354
+00:33:36,000 --> 00:33:38,000
+And that's the end of the lesson.
+
+355
+00:33:38,000 --> 00:33:45,000
+We learned how to prevent our abilities associated with ID and authentication failures.
+
+356
+00:33:46,000 --> 00:33:48,000
+Thank you all for your attention.
+
+357
+00:33:48,000 --> 00:33:50,000
+Have a great day and see you.
+
+358
+00:33:50,000 --> 00:33:51,000
+Next lesson.
+
diff --git a/73 - OWASP Top 10 2021/015 Software & Data Integrity Failures_en.srt b/73 - OWASP Top 10 2021/015 Software & Data Integrity Failures_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..d182fafda8276ff01dfa5915db110fd732e81893
--- /dev/null
+++ b/73 - OWASP Top 10 2021/015 Software & Data Integrity Failures_en.srt
@@ -0,0 +1,740 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello, you.
+
+2
+00:00:06,000 --> 00:00:12,000
+In this lesson, we're going to talk about software and data integrity failures, risk category from
+
+3
+00:00:12,000 --> 00:00:13,000
+a loss stop.
+
+4
+00:00:13,000 --> 00:00:20,000
+That will start from the general overview of this risk category, I'm going to explain potential impacts
+
+5
+00:00:21,000 --> 00:00:23,000
+that can be caused by vulnerabilities.
+
+6
+00:00:23,000 --> 00:00:29,000
+From this risk category, we'll reviews the most notable common weakness enumerations.
+
+7
+00:00:30,000 --> 00:00:36,000
+As always, we're going to compare of us top ten 2017 versus 2021.
+
+8
+00:00:37,000 --> 00:00:44,000
+After that, we're going to review examples of attacks and as in the of lesson will talk about how to
+
+9
+00:00:44,000 --> 00:00:49,000
+prevent vulnerabilities related to software and data integrity failures.
+
+10
+00:00:50,000 --> 00:00:51,000
+Let's start our lesson.
+
+11
+00:00:52,000 --> 00:00:56,000
+Let's start from a high level overview of this risk category.
+
+12
+00:00:56,000 --> 00:01:04,000
+Nowadays relief in times of agile roles, fast delivery error of startups and technology breakthrough.
+
+13
+00:01:05,000 --> 00:01:13,000
+It is highly competitive market in many teams, and this rash leads sometimes to negative consequences.
+
+14
+00:01:13,000 --> 00:01:15,000
+You're in the software development.
+
+15
+00:01:15,000 --> 00:01:21,000
+Modern software culture encourages rapid loses and short cycles.
+
+16
+00:01:22,000 --> 00:01:31,000
+DevOps teams and security teams have less time to check the quality of you code and identify cryptographic
+
+17
+00:01:31,000 --> 00:01:38,000
+failures, vulnerable and outdated components or identification and syndication failures built into
+
+18
+00:01:38,000 --> 00:01:39,000
+the software.
+
+19
+00:01:39,000 --> 00:01:48,000
+While security professionals always should shift that, it's apparent that there are development teams
+
+20
+00:01:48,000 --> 00:01:55,000
+out there that do not have sufficient integrity verification processes that allows them to analyze,
+
+21
+00:01:55,000 --> 00:02:00,000
+work and protect users against malicious code.
+
+22
+00:02:00,000 --> 00:02:04,000
+All this leads to software and data integrity failures.
+
+23
+00:02:05,000 --> 00:02:06,000
+In few worlds.
+
+24
+00:02:06,000 --> 00:02:16,000
+This category is about the assumptions linked with critical CI pipeline data handling and software integrity
+
+25
+00:02:16,000 --> 00:02:17,000
+failures.
+
+26
+00:02:17,000 --> 00:02:25,000
+Let's now discuss what potential impact can be caused by software and data integrity failures and recap
+
+27
+00:02:25,000 --> 00:02:33,000
+one more time how they may cure the complexity of architectures in more than data release cycles.
+
+28
+00:02:33,000 --> 00:02:41,000
+Often forces developers to use plugins, modules and libraries from public repositories, untrusted
+
+29
+00:02:41,000 --> 00:02:44,000
+sources and content delivery networks.
+
+30
+00:02:45,000 --> 00:02:53,000
+Due to such complexities, software and data integrity failures categorized as design flaws accuracy.
+
+31
+00:02:53,000 --> 00:03:00,000
+When critical data and software updates are added to the delivery pipeline without work finds integrity
+
+32
+00:03:00,000 --> 00:03:08,000
+in the absence of adequate validation, software and data integrity failures make applications susceptible
+
+33
+00:03:08,000 --> 00:03:15,000
+to unauthorized information, disclosure, system, compromise or insertion of malicious code.
+
+34
+00:03:16,000 --> 00:03:24,000
+Modern software delivery pipelines include auto update functionality streamlines the life cycles by
+
+35
+00:03:24,000 --> 00:03:28,000
+downloading updates and applying them without inherent permissions.
+
+36
+00:03:29,000 --> 00:03:36,000
+Threat actors can exploit such functionalities, but performance and imminent attack to inject malicious
+
+37
+00:03:36,000 --> 00:03:39,000
+code into the pipeline to update causes.
+
+38
+00:03:40,000 --> 00:03:47,000
+This results in corrupted payloads being deployed and executed outright on application installations.
+
+39
+00:03:48,000 --> 00:03:52,000
+As always, let's review notable common vehicles enumerations.
+
+40
+00:03:53,000 --> 00:03:55,000
+Let's use them one by one.
+
+41
+00:03:56,000 --> 00:04:05,000
+we4 hundred 94 download of Code Without Integrity Chat and that topic can execute malicious code by
+
+42
+00:04:05,000 --> 00:04:13,000
+compromising the host server, performing DNS spoofing or modifying zip code in transit.
+
+43
+00:04:13,000 --> 00:04:21,000
+Attacks or accidental corruption can introduce invalid files into Conti's repository and verifying file
+
+44
+00:04:21,000 --> 00:04:23,000
+integrity can identify them.
+
+45
+00:04:24,000 --> 00:04:33,000
+In this process, the security teams can pat files digital signature or hashed content with no values.
+
+46
+00:04:33,000 --> 00:04:37,000
+Be sure the files are not altered or corrupted.
+
+47
+00:04:37,000 --> 00:04:46,000
+Some manual processes and automated checks, some validation might not detect changes in a file so corruption
+
+48
+00:04:46,000 --> 00:04:50,000
+can be used as surface content.
+
+49
+00:04:50,000 --> 00:04:57,000
+Security teams can validate a digital signature or use a cryptographic checksum in which they run the
+
+50
+00:04:57,000 --> 00:05:02,000
+hash algorithm against the file to verify file integrity.
+
+51
+00:05:02,000 --> 00:05:11,000
+Validation enables teams to find any changes to the file itself, such as file the nation and its movements
+
+52
+00:05:11,000 --> 00:05:13,000
+or unauthorized access.
+
+53
+00:05:14,000 --> 00:05:22,000
+These changes can reveal a prior intrusion from start to finish or reveal a larger attack that is under
+
+54
+00:05:22,000 --> 00:05:25,000
+way or that the team is investigating.
+
+55
+00:05:26,000 --> 00:05:29,000
+See WP 502.
+
+56
+00:05:29,000 --> 00:05:34,000
+This realisation of untrusted data cause your from zero.
+
+57
+00:05:34,000 --> 00:05:42,000
+The first job in the section about input and output streams will rejoin Watson zation and this civilization
+
+58
+00:05:42,000 --> 00:05:44,000
+is to learn more.
+
+59
+00:05:44,000 --> 00:05:47,000
+Please refer to this section of the course.
+
+60
+00:05:48,000 --> 00:05:56,000
+Ensure in Java, civilization is a process of converting an object into a stream of bytes to store the
+
+61
+00:05:56,000 --> 00:06:01,000
+object or transmit it to memory and database or the file.
+
+62
+00:06:01,000 --> 00:06:04,000
+Disorganization is a reverse process.
+
+63
+00:06:05,000 --> 00:06:10,000
+But centralization is not what can be done only in Java and was three bytes.
+
+64
+00:06:11,000 --> 00:06:13,000
+Serialization accuracy.
+
+65
+00:06:13,000 --> 00:06:21,000
+When an application converts data structures and objects into a different form, such as binary or structured
+
+66
+00:06:21,000 --> 00:06:27,000
+tax, x amount and JSON so that it is suitable for other purposes.
+
+67
+00:06:28,000 --> 00:06:34,000
+Neutralization is when an application reverts as a serialized output into its original form.
+
+68
+00:06:35,000 --> 00:06:42,000
+It is often convenient to serialize objects for communication or to see them for later use.
+
+69
+00:06:42,000 --> 00:06:51,000
+However, these serialized data or code can often be modified without using the provided access of functions
+
+70
+00:06:52,000 --> 00:06:56,000
+if it doesn't use cryptographic to protect itself.
+
+71
+00:06:57,000 --> 00:06:59,000
+CW 849.
+
+72
+00:07:00,000 --> 00:07:08,000
+Inclusion of functionality from untrusted control sphere when including such partisanship analogy such
+
+73
+00:07:08,000 --> 00:07:16,000
+as map, widget, library or a source of functionality, this software must effectively trust that functionality
+
+74
+00:07:17,000 --> 00:07:20,000
+without sufficient protection mechanisms.
+
+75
+00:07:20,000 --> 00:07:27,000
+The functionality could be malicious in nature user by common someone untrusted source being spoofed
+
+76
+00:07:27,000 --> 00:07:31,000
+or being modified in transit from a trusted source.
+
+77
+00:07:31,000 --> 00:07:39,000
+The functionality might also contain its own weakness or grant access to additional functionality and
+
+78
+00:07:39,000 --> 00:07:42,000
+state information that should be kept private.
+
+79
+00:07:42,000 --> 00:07:51,000
+Based system such as system state information, sensitive application data, or the DOM of that application.
+
+80
+00:07:52,000 --> 00:07:59,000
+This might lead to many different consequences dependent on the included functionality, but some examples
+
+81
+00:07:59,000 --> 00:08:07,000
+include injection of malware information exposure by granting excessive privileges or permissions to
+
+82
+00:08:07,000 --> 00:08:11,000
+trust, which are now done based accessible.
+
+83
+00:08:11,000 --> 00:08:16,000
+In our view, it is still users who use or open redirect to malware.
+
+84
+00:08:17,000 --> 00:08:24,000
+Now let's compare Avast Top ten 2017 versus Avast the top ten 2021.
+
+85
+00:08:25,000 --> 00:08:30,000
+This is a new category that was absent in Avast Top ten 2017.
+
+86
+00:08:30,000 --> 00:08:35,000
+This category also includes a category from across the top ten 2017.
+
+87
+00:08:36,000 --> 00:08:38,000
+I'm talking about insecure.
+
+88
+00:08:38,000 --> 00:08:46,000
+Decentralization is a vulnerability here is that a serialized object can be manipulated if malicious
+
+89
+00:08:46,000 --> 00:08:47,000
+code or data was.
+
+90
+00:08:48,000 --> 00:08:50,000
+We use it as a serialized data.
+
+91
+00:08:51,000 --> 00:08:56,000
+It was later executed during the disorganization with the rights of the application.
+
+92
+00:08:56,000 --> 00:09:04,000
+This can happen if the integrity check for this data and objects is not harder against attacks.
+
+93
+00:09:05,000 --> 00:09:13,000
+Software and data integrity failures related to code and infrastructure doesn't protect against integrity
+
+94
+00:09:13,000 --> 00:09:14,000
+violations.
+
+95
+00:09:14,000 --> 00:09:22,000
+An example of this is that an application relies upon plugins, libraries or modules from untrusted
+
+96
+00:09:22,000 --> 00:09:26,000
+sources, repositories and quantum networks.
+
+97
+00:09:26,000 --> 00:09:36,000
+CDs and insecure ICG pipelines can introduce a potential for unauthorized access, malicious code or
+
+98
+00:09:36,000 --> 00:09:38,000
+system compromise.
+
+99
+00:09:39,000 --> 00:09:47,000
+Nowadays, many applications include automatic functionality that updates are downloaded without sufficient
+
+100
+00:09:47,000 --> 00:09:52,000
+integrity, verification and applied across a trusted application.
+
+101
+00:09:52,000 --> 00:09:59,000
+Attackers potentially uploads these to be distributed and run on all installations.
+
+102
+00:10:00,000 --> 00:10:04,000
+Let's review one of the most popular examples from real life.
+
+103
+00:10:05,000 --> 00:10:10,000
+It is always better to use experience of others rather than past.
+
+104
+00:10:10,000 --> 00:10:12,000
+Was a painful experience by yourself.
+
+105
+00:10:13,000 --> 00:10:20,000
+The most famous example of a failure in software and data integrity checks is the SolarWinds Aurion
+
+106
+00:10:20,000 --> 00:10:29,000
+attack, with the now infamous attack centring around compromised update mechanisms after hacking into
+
+107
+00:10:29,000 --> 00:10:35,000
+the SolarWinds backend passwords frame or some other form of brute force attack.
+
+108
+00:10:36,000 --> 00:10:43,000
+The suspected nation state attackers said that the malicious code is the SolarWinds SII pipeline.
+
+109
+00:10:44,000 --> 00:10:51,000
+Some of the components were introduced into the SolarWinds update pipeline and signed off as a service
+
+110
+00:10:51,000 --> 00:10:56,000
+approved software update with legitimate digital signatures.
+
+111
+00:10:56,000 --> 00:11:04,000
+This compromise, the software supply chain, meant that the update was legitimate as far as SolarWinds
+
+112
+00:11:05,000 --> 00:11:07,000
+customers were concerned.
+
+113
+00:11:08,000 --> 00:11:15,000
+Of course, this is only one example of monitoring failures that have left the system compromised and
+
+114
+00:11:15,000 --> 00:11:18,000
+critical data being exposed to it internet.
+
+115
+00:11:18,000 --> 00:11:23,000
+But so we have better processes for monitoring its own updates.
+
+116
+00:11:24,000 --> 00:11:26,000
+This would not have happened.
+
+117
+00:11:27,000 --> 00:11:34,000
+The SolarWinds or an attack in which highly targeted, malicious updates were distributed to more than
+
+118
+00:11:34,000 --> 00:11:40,000
+80,000 organizations is one of the most significant breaches of this nature.
+
+119
+00:11:41,000 --> 00:11:45,000
+Now let's review all the potential attacks and errors.
+
+120
+00:11:46,000 --> 00:11:56,000
+Scenario number one, we'll talk today about potential impact made by all of the adverse highlights
+
+121
+00:11:56,000 --> 00:12:05,000
+potential visited by update without signing many home routers, set top boxes, device firmware and
+
+122
+00:12:05,000 --> 00:12:07,000
+orders do not verify updates.
+
+123
+00:12:07,000 --> 00:12:09,000
+We are signed firmware.
+
+124
+00:12:10,000 --> 00:12:16,000
+Unassigned firmware is a growing target for attackers and is expected to only get worse.
+
+125
+00:12:17,000 --> 00:12:18,000
+This is a major concern.
+
+126
+00:12:18,000 --> 00:12:26,000
+As many times there is no mechanism to remedy other than to fix in the future version and wait for previous
+
+127
+00:12:26,000 --> 00:12:27,000
+versions to age out.
+
+128
+00:12:28,000 --> 00:12:30,000
+Samarra number two.
+
+129
+00:12:31,000 --> 00:12:37,000
+We also talked about insecurity zation one of the reviewed common vehicles enumerations.
+
+130
+00:12:38,000 --> 00:12:43,000
+Let me share with you one more example related to insecure dissociation.
+
+131
+00:12:44,000 --> 00:12:51,000
+Iraq application cause a set of microservices being functional programmers.
+
+132
+00:12:51,000 --> 00:12:55,000
+Developers strive to ensure that their code is immutable.
+
+133
+00:12:56,000 --> 00:13:03,000
+The solution they came up with is to license a user state and the person that back and forth with each
+
+134
+00:13:03,000 --> 00:13:04,000
+request.
+
+135
+00:13:04,000 --> 00:13:07,000
+An attacker notices a Java object signature.
+
+136
+00:13:08,000 --> 00:13:16,000
+They understood that serialization is used and the content used is a jealous zero killer tool to gain
+
+137
+00:13:16,000 --> 00:13:19,000
+remote code execution on the application server.
+
+138
+00:13:20,000 --> 00:13:28,000
+Scenario number three is a full blown Samarra, an attack that exploits an insecure CIC pipeline and
+
+139
+00:13:28,000 --> 00:13:34,000
+installs malicious code to be distributed through the view and deployed process.
+
+140
+00:13:34,000 --> 00:13:42,000
+The attacker identifies an organization's insecure CIC pipeline and installs malicious code that is
+
+141
+00:13:42,000 --> 00:13:44,000
+pushed into production.
+
+142
+00:13:45,000 --> 00:13:51,000
+Customers unknowingly download the malicious quotes from the organization's update servers.
+
+143
+00:13:51,000 --> 00:13:55,000
+The malicious update is installed easy customers environment.
+
+144
+00:13:56,000 --> 00:14:01,000
+The attacker uses the malicious code to gain access to the customer's network.
+
+145
+00:14:02,000 --> 00:14:09,000
+That's now come to conclusion and understand how we can prevent software and data integrity failures.
+
+146
+00:14:09,000 --> 00:14:13,000
+The number of things that we can do to prevent abilities.
+
+147
+00:14:14,000 --> 00:14:22,000
+Use digital signatures or similar mechanisms to verify the software or data is from a suspected source
+
+148
+00:14:22,000 --> 00:14:24,000
+and has not been altered.
+
+149
+00:14:24,000 --> 00:14:27,000
+A digital signature is an electronics.
+
+150
+00:14:28,000 --> 00:14:28,000
+It is.
+
+151
+00:14:28,000 --> 00:14:37,000
+The event defines a region of the digital message or file z signatures from use public key infrastructure
+
+152
+00:14:37,000 --> 00:14:43,000
+partners to ensure data exchanged between parties stays private.
+
+153
+00:14:44,000 --> 00:14:53,000
+All teams should adopt digital signage solutions that automate the code signing encryption and authentication
+
+154
+00:14:53,000 --> 00:14:55,000
+across ICD pipelines.
+
+155
+00:14:56,000 --> 00:15:01,000
+Ensure libraries and dependencies such as NPM or maven.
+
+156
+00:15:01,000 --> 00:15:03,000
+Consume trusted repositories.
+
+157
+00:15:04,000 --> 00:15:09,000
+Verify that components do not contain known vulnerabilities.
+
+158
+00:15:09,000 --> 00:15:15,000
+Use such things as a trusted dependency check like we reviewed in our previous last.
+
+159
+00:15:16,000 --> 00:15:24,000
+Ensure that Zoey's interview crosses protocols and configuration changes to minimize the chance of malicious
+
+160
+00:15:24,000 --> 00:15:29,000
+code or configuration could be introduced into your software pipeline.
+
+161
+00:15:30,000 --> 00:15:33,000
+Ensures its UCI city pipeline.
+
+162
+00:15:33,000 --> 00:15:41,000
+This proper segregation configuration and access control in choosing legacy Xcode loans to build and
+
+163
+00:15:41,000 --> 00:15:42,000
+deploy processes.
+
+164
+00:15:43,000 --> 00:15:52,000
+Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some form
+
+165
+00:15:52,000 --> 00:15:53,000
+of integrity.
+
+166
+00:15:53,000 --> 00:15:57,000
+Check for digital signature to detect tampering.
+
+167
+00:15:57,000 --> 00:15:59,000
+Autoplay of the Serialized Data.
+
+168
+00:16:00,000 --> 00:16:08,000
+Even though this ability is capable of causing damage beyond once imagination, measures like continual
+
+169
+00:16:08,000 --> 00:16:15,000
+one time adoption of authentication verification practices can bring great relief.
+
+170
+00:16:16,000 --> 00:16:23,000
+In the event an application server then loads the source code and executes without validating the zip
+
+171
+00:16:23,000 --> 00:16:25,000
+code for its integrity and the region.
+
+172
+00:16:26,000 --> 00:16:32,000
+Caucus can receives the application to download the malicious code from untrusted sites.
+
+173
+00:16:32,000 --> 00:16:40,000
+Such attacks can also the execution of malicious commands, resulting in steal and sensitive information
+
+174
+00:16:41,000 --> 00:16:43,000
+or compromising backend servers.
+
+175
+00:16:44,000 --> 00:16:47,000
+That's all what I wanted to cover with you in this lesson.
+
+176
+00:16:48,000 --> 00:16:51,000
+Let's recap what we learned today.
+
+177
+00:16:51,000 --> 00:16:55,000
+Then we learned what software and integrity failures are.
+
+178
+00:16:56,000 --> 00:17:03,000
+We learned potential impact that may be caused by vulnerabilities associated with this risk category.
+
+179
+00:17:03,000 --> 00:17:06,000
+Also, we have common weakness enumerations.
+
+180
+00:17:07,000 --> 00:17:12,000
+As always, we compared avast the top ten, 2017 and 2021.
+
+181
+00:17:13,000 --> 00:17:18,000
+We discussed different examples of attacks and examples in AC.
+
+182
+00:17:18,000 --> 00:17:23,000
+We talked about how to prevent vulnerabilities from this category.
+
+183
+00:17:24,000 --> 00:17:25,000
+That's it.
+
+184
+00:17:25,000 --> 00:17:27,000
+Thank you for your attention.
+
+185
+00:17:27,000 --> 00:17:30,000
+Have a great day and see in the next lesson.
+
diff --git a/73 - OWASP Top 10 2021/016 Computer-Security-Incident-Handling-Guide.url b/73 - OWASP Top 10 2021/016 Computer-Security-Incident-Handling-Guide.url
new file mode 100644
index 0000000000000000000000000000000000000000..204cd0971bed6ff43d3364012e9aa96cd9a3f76a
--- /dev/null
+++ b/73 - OWASP Top 10 2021/016 Computer-Security-Incident-Handling-Guide.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
\ No newline at end of file
diff --git a/73 - OWASP Top 10 2021/016 Security Logging & Monitoring Failures_en.srt b/73 - OWASP Top 10 2021/016 Security Logging & Monitoring Failures_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..1b17256429810bb81da421dcdf64428d8e4902e4
--- /dev/null
+++ b/73 - OWASP Top 10 2021/016 Security Logging & Monitoring Failures_en.srt
@@ -0,0 +1,1016 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello, tim.
+
+2
+00:00:06,000 --> 00:00:13,000
+In this video we're going to run security volume and monitoring failures from avast that we're going
+
+3
+00:00:13,000 --> 00:00:17,000
+to study nicely from understanding what logging and logs are.
+
+4
+00:00:18,000 --> 00:00:24,000
+After that, I'm going to explain what security, logging and monitoring failures risk category is about.
+
+5
+00:00:25,000 --> 00:00:31,000
+Will understand the potential impacts that can be caused by vulnerabilities that are associated with
+
+6
+00:00:31,000 --> 00:00:33,000
+this risk category.
+
+7
+00:00:33,000 --> 00:00:40,000
+I will review with the risk factors that should be eliminated, and we'll review the key challenges
+
+8
+00:00:40,000 --> 00:00:42,000
+that you can face with on practice.
+
+9
+00:00:43,000 --> 00:00:49,000
+Also in this lesson, I'm going to hold an overview of wealth management tools and libraries for logging
+
+10
+00:00:49,000 --> 00:00:50,000
+in Java.
+
+11
+00:00:50,000 --> 00:00:57,000
+As always, we'll talk about the most notable common weakness and limitations from this risk category
+
+12
+00:00:57,000 --> 00:01:03,000
+will compare of up top ten 2017 versus last time.
+
+13
+00:01:03,000 --> 00:01:09,000
+2021 also will review attack examples and designs of the last.
+
+14
+00:01:09,000 --> 00:01:16,000
+And we're going to know how to prevent negative consequences that may be caused by security, logging
+
+15
+00:01:16,000 --> 00:01:17,000
+and monitoring failures.
+
+16
+00:01:18,000 --> 00:01:20,000
+Let's start our lesson.
+
+17
+00:01:21,000 --> 00:01:26,000
+The first questions that we have to address is the definition of log in and logs.
+
+18
+00:01:27,000 --> 00:01:27,000
+In computing.
+
+19
+00:01:27,000 --> 00:01:35,000
+A log file is a file that records user events to any operating system or application.
+
+20
+00:01:36,000 --> 00:01:40,000
+Log in is an act of keeping the law in the simplest case.
+
+21
+00:01:41,000 --> 00:01:50,000
+Messages Reason for a single file a log in the computing context is it automatically produced and timestamp
+
+22
+00:01:50,000 --> 00:01:56,000
+documentation of events relevant to a particular system or application.
+
+23
+00:01:57,000 --> 00:02:01,000
+Most of software applications and systems produce log files.
+
+24
+00:02:02,000 --> 00:02:10,000
+These are also separate libraries for logging and applications that helps to gather, analyze and navigate
+
+25
+00:02:10,000 --> 00:02:10,000
+the logs.
+
+26
+00:02:11,000 --> 00:02:15,000
+They're called log management applications.
+
+27
+00:02:15,000 --> 00:02:18,000
+There are really a lot of them for different languages.
+
+28
+00:02:19,000 --> 00:02:25,000
+In this lesson we're going to review library some tools that are most popular while working with Java
+
+29
+00:02:25,000 --> 00:02:26,000
+applications.
+
+30
+00:02:27,000 --> 00:02:34,000
+Now when we have learned what logs are, let's proceed with a high level overview of this risk category.
+
+31
+00:02:35,000 --> 00:02:39,000
+To help you understand what this category is about, let me ask you a question.
+
+32
+00:02:40,000 --> 00:02:47,000
+Have you ever had a case when your app was not as expected or you have to investigate some incidents
+
+33
+00:02:47,000 --> 00:02:56,000
+that happened and you can track since because of missing logs, logging and monitoring go hand in hand.
+
+34
+00:02:57,000 --> 00:03:03,000
+There is little point in having adequate logs, is there not adequate monitoring?
+
+35
+00:03:03,000 --> 00:03:12,000
+It is a problem of insufficient logging and monitoring covers type of structure and not just anything
+
+36
+00:03:12,000 --> 00:03:14,000
+that's facing that application.
+
+37
+00:03:15,000 --> 00:03:23,000
+Failure to sufficiently a law monitor or report security events such as logging items makes suspicious
+
+38
+00:03:23,000 --> 00:03:30,000
+behavior difficult to detect and significantly raises the likelihood that an attacker can successfully
+
+39
+00:03:30,000 --> 00:03:32,000
+exploit your application.
+
+40
+00:03:33,000 --> 00:03:40,000
+For example, an attacker may probe your application or software components following the abilities
+
+41
+00:03:40,000 --> 00:03:44,000
+of a permit, allowing such probes to continue.
+
+42
+00:03:44,000 --> 00:03:51,000
+And the tactic increases the likelihood that that target ultimately finds it will be with you and successfully
+
+43
+00:03:51,000 --> 00:03:59,000
+exploits a flaw in sufficient logging, monitoring or reporting makes your application susceptible to
+
+44
+00:03:59,000 --> 00:04:04,000
+attacks that target any part of the application stack.
+
+45
+00:04:04,000 --> 00:04:10,000
+Probably you can be wondering what impact can be caused by absent logging.
+
+46
+00:04:11,000 --> 00:04:18,000
+And this is a great question because it is hard to understand how absence of logging may impact security
+
+47
+00:04:18,000 --> 00:04:26,000
+of our application, while insufficient logging and monitoring is to observe to be a direct attack vector,
+
+48
+00:04:26,000 --> 00:04:31,000
+it affects the detection and response to every single breach.
+
+49
+00:04:32,000 --> 00:04:40,000
+If web application and server incidents are improperly monitored, suspicious activity can easily be
+
+50
+00:04:40,000 --> 00:04:40,000
+missed.
+
+51
+00:04:41,000 --> 00:04:49,000
+If security risks are not correct, the law or the logs are badly stored or hard to access, then these
+
+52
+00:04:49,000 --> 00:04:57,000
+flaws will go unaddressed as a result of direct vulnerabilities that can arise due to these issues.
+
+53
+00:04:57,000 --> 00:05:05,000
+But in general, logging and monitoring are quite critical and the absence of failures in directly impact
+
+54
+00:05:05,000 --> 00:05:09,000
+the visibility, incident, technology and forensics.
+
+55
+00:05:10,000 --> 00:05:17,000
+Thus, it's quite important to have a functioning logging and monitoring system to collect logs and
+
+56
+00:05:17,000 --> 00:05:21,000
+also give alerts if any malfunctions or errors happen.
+
+57
+00:05:22,000 --> 00:05:28,000
+Else use can go unnoticed for a long time and cause a lot more damage.
+
+58
+00:05:29,000 --> 00:05:33,000
+Let's review some risk factors that can lead us to negative consequences.
+
+59
+00:05:34,000 --> 00:05:40,000
+The elimination of this risk factors is it that listed on the slide will help us to decrease risks of
+
+60
+00:05:40,000 --> 00:05:49,000
+vulnerability to significantly log in and failed attempts not being locked locks on this cert locally
+
+61
+00:05:49,000 --> 00:05:50,000
+and not back.
+
+62
+00:05:50,000 --> 00:05:57,000
+Top warnings and errors are generated with an adequate or unpeel log messages.
+
+63
+00:05:58,000 --> 00:06:00,000
+It is not enough just to log an event.
+
+64
+00:06:00,000 --> 00:06:05,000
+It is also important to be able to understand it later.
+
+65
+00:06:06,000 --> 00:06:12,000
+Logs of applications and apps are not monitored for suspicious activity.
+
+66
+00:06:12,000 --> 00:06:21,000
+Penetration testing and scans by dynamic application security testing tools such as the do not trigger
+
+67
+00:06:21,000 --> 00:06:30,000
+alerts monitoring systems not able to detect suspicious activity or not able to raise alerts in real
+
+68
+00:06:30,000 --> 00:06:31,000
+time.
+
+69
+00:06:32,000 --> 00:06:38,000
+Missing monitoring and alert systems locks not protected for integrity.
+
+70
+00:06:39,000 --> 00:06:41,000
+This will allow log forgery.
+
+71
+00:06:42,000 --> 00:06:49,000
+Let's understand now the challenges that you may face weeks after implementing logging and eliminating
+
+72
+00:06:49,000 --> 00:06:51,000
+all the risk factors.
+
+73
+00:06:52,000 --> 00:06:56,000
+Very often there is a challenge that there are really a lot of loss.
+
+74
+00:06:57,000 --> 00:07:00,000
+You have multiple services then distributed.
+
+75
+00:07:00,000 --> 00:07:03,000
+Each service logs its own messages.
+
+76
+00:07:04,000 --> 00:07:06,000
+Log management can become a problem.
+
+77
+00:07:07,000 --> 00:07:13,000
+Moreover, if you are talking about monitoring, it is close to impossible to monitor such amount of
+
+78
+00:07:13,000 --> 00:07:14,000
+logs manually.
+
+79
+00:07:15,000 --> 00:07:17,000
+What would be a solution to this challenge?
+
+80
+00:07:18,000 --> 00:07:20,000
+There are some points to consider.
+
+81
+00:07:21,000 --> 00:07:25,000
+Never forget to set the proper log level for each log message.
+
+82
+00:07:25,000 --> 00:07:31,000
+We're going to have a separate lesson about logging in Java, but in case you are already familiar with
+
+83
+00:07:31,000 --> 00:07:39,000
+some logging in the programming languages, you'll know that each log message is logged on different
+
+84
+00:07:39,000 --> 00:07:47,000
+levels and it is important to agree on the criteria of each log level and set proper level to each log
+
+85
+00:07:47,000 --> 00:07:48,000
+message.
+
+86
+00:07:48,000 --> 00:07:49,000
+Why?
+
+87
+00:07:49,000 --> 00:07:51,000
+Because it is a future one.
+
+88
+00:07:51,000 --> 00:07:53,000
+We are glad to work with these logs.
+
+89
+00:07:53,000 --> 00:07:57,000
+We can apply the rules for different log levels.
+
+90
+00:07:57,000 --> 00:08:03,000
+We can filter logs on different levels and the work was logs in a more efficient way.
+
+91
+00:08:04,000 --> 00:08:11,000
+Introduce Automation, NZ lock management process, implement monitoring roles across the system.
+
+92
+00:08:11,000 --> 00:08:14,000
+For example, limit the number of sales.
+
+93
+00:08:14,000 --> 00:08:16,000
+Log in items.
+
+94
+00:08:16,000 --> 00:08:19,000
+Increase delay between failed walk ins.
+
+95
+00:08:20,000 --> 00:08:27,000
+Create IP Blacklist block IP addresses that sense suspiciously huge amounts of requests.
+
+96
+00:08:28,000 --> 00:08:31,000
+Automate alerting on some critical events.
+
+97
+00:08:31,000 --> 00:08:32,000
+Let's see.
+
+98
+00:08:32,000 --> 00:08:39,000
+In this case, security team used to monitor alarms manually and having all necessary logs.
+
+99
+00:08:39,000 --> 00:08:42,000
+Security can track down what actually happened.
+
+100
+00:08:43,000 --> 00:08:45,000
+React and allow alerts.
+
+101
+00:08:45,000 --> 00:08:52,000
+Already makes life easier rather than monitoring all possible logs in the system manually.
+
+102
+00:08:53,000 --> 00:08:54,000
+Introduce logging tools.
+
+103
+00:08:55,000 --> 00:08:57,000
+We're going to use some of them in a few seconds.
+
+104
+00:08:58,000 --> 00:09:06,000
+Let's review log management applications, the most popular ones that can help to make your life easier.
+
+105
+00:09:07,000 --> 00:09:13,000
+I want to highlight significantly more tools that I will give you on this slide.
+
+106
+00:09:13,000 --> 00:09:20,000
+So in case you are looking for something really specific, give it a try to review all of the solutions.
+
+107
+00:09:21,000 --> 00:09:24,000
+There are six those I'd like to discuss.
+
+108
+00:09:25,000 --> 00:09:27,000
+Zia Splunk.
+
+109
+00:09:27,000 --> 00:09:31,000
+Splunk is the biggest tool in the log management space.
+
+110
+00:09:31,000 --> 00:09:36,000
+It's well-established, full featured and enterprise class.
+
+111
+00:09:37,000 --> 00:09:41,000
+It's unique in this space as an on premises tool.
+
+112
+00:09:41,000 --> 00:09:45,000
+Also, they have come out with a cloud version as well.
+
+113
+00:09:45,000 --> 00:09:56,000
+And lastly, formerly known as our OC Elasticsearch Slash Kanban, it is an open source project made
+
+114
+00:09:56,000 --> 00:09:59,000
+up of many different tools for application.
+
+115
+00:09:59,000 --> 00:10:07,000
+Data analysis and visualization looks specifically was made for the collection and management of log
+
+116
+00:10:07,000 --> 00:10:10,000
+files beyond the Law congregation.
+
+117
+00:10:10,000 --> 00:10:18,000
+It includes Elasticsearch for indexing and searches for data and Cabana for charting and visualizing
+
+118
+00:10:18,000 --> 00:10:20,000
+data to gather.
+
+119
+00:10:20,000 --> 00:10:23,000
+They form a powerful log management solution.
+
+120
+00:10:23,000 --> 00:10:25,000
+Similar logic.
+
+121
+00:10:25,000 --> 00:10:33,000
+Similar logic was founded as a software, as a service version of Splunk, going so far as to imitate
+
+122
+00:10:33,000 --> 00:10:36,000
+some logs, features and visual story.
+
+123
+00:10:36,000 --> 00:10:45,000
+All since then, some logic has developed into full fledged enterprise class management solution in
+
+124
+00:10:45,000 --> 00:10:46,000
+its own right.
+
+125
+00:10:47,000 --> 00:10:52,000
+Some of the logic is a lost enterprise focus of the cloud native analyzers.
+
+126
+00:10:54,000 --> 00:10:54,000
+Love.
+
+127
+00:10:54,000 --> 00:10:55,000
+We love.
+
+128
+00:10:55,000 --> 00:11:04,000
+We used a robust analyzer focusing on simplicity and ease of use is targeted for developers and DevOps,
+
+129
+00:11:05,000 --> 00:11:07,000
+making it less enterprise focused.
+
+130
+00:11:08,000 --> 00:11:09,000
+Paper Trail.
+
+131
+00:11:10,000 --> 00:11:18,000
+Paper trail is a simple way to loop and search through logs from multiple machines in one consolidated
+
+132
+00:11:18,000 --> 00:11:19,000
+easy to use interface.
+
+133
+00:11:20,000 --> 00:11:27,000
+It is software as a service too designed to enhance the logs you already collect or generate.
+
+134
+00:11:28,000 --> 00:11:28,000
+Gridlock.
+
+135
+00:11:29,000 --> 00:11:37,000
+Gridlock is an open source look and noise are backed by MongoDB as well as Elasticsearch, similar to
+
+136
+00:11:37,000 --> 00:11:41,000
+Lock Stash for storing and searching for errors.
+
+137
+00:11:42,000 --> 00:11:50,000
+It's mainly focused on helping developers detect and fix errors in their apps, but they have also released
+
+138
+00:11:50,000 --> 00:11:53,000
+an official enterprise ready platform.
+
+139
+00:11:54,000 --> 00:11:56,000
+Let's sum it up and make conclusions.
+
+140
+00:11:57,000 --> 00:12:04,000
+Splunk is the best out of the box tool for enterprise companies, where money is less of a concern.
+
+141
+00:12:05,000 --> 00:12:12,000
+Elastic is a strongest open source project with complex set top and maintenance vs downside.
+
+142
+00:12:13,000 --> 00:12:21,000
+Similar logic is basically the software as a service version of Splunk, but is less expensive and has
+
+143
+00:12:21,000 --> 00:12:23,000
+less extensive features at least.
+
+144
+00:12:24,000 --> 00:12:32,000
+Locally is a solid solution for smaller that and above Steve's focusing on monitoring and troubleshooting.
+
+145
+00:12:33,000 --> 00:12:39,000
+Paper Trail is a simple and affordable tool for viewing log files from multiple machines.
+
+146
+00:12:39,000 --> 00:12:41,000
+In a single view is a cloud.
+
+147
+00:12:42,000 --> 00:12:48,000
+Grain law is a solid alternative to logs stash within the elastic stack framework.
+
+148
+00:12:48,000 --> 00:12:51,000
+Let's continue as a set.
+
+149
+00:12:51,000 --> 00:12:54,000
+We're going to have a separate lesson about log in.
+
+150
+00:12:54,000 --> 00:13:02,000
+In Java, we're going to have this class in scope of my course Java from zero to first job and details
+
+151
+00:13:02,000 --> 00:13:06,000
+of using log libraries also lies beyond this class.
+
+152
+00:13:07,000 --> 00:13:15,000
+But still, just for your awareness, I'd like to list here log in libraries you can use while working
+
+153
+00:13:15,000 --> 00:13:19,000
+this Java applications general log in framework.
+
+154
+00:13:19,000 --> 00:13:27,000
+Java has its own log in framework that is built in and does adjudicate honestly the Java Logan framework
+
+155
+00:13:27,000 --> 00:13:29,000
+not very popular nowadays.
+
+156
+00:13:30,000 --> 00:13:35,000
+Unfortunately, that didn't include logging in its original release.
+
+157
+00:13:36,000 --> 00:13:44,000
+So by the time the Java logging API was added, several other Logan's frameworks had become widely used.
+
+158
+00:13:45,000 --> 00:13:54,000
+Look, 4G VoLTE 4G is a general organ framework that supports the log in to files, output streams and
+
+159
+00:13:54,000 --> 00:13:58,000
+other targets and allows the configuration via config files.
+
+160
+00:13:59,000 --> 00:14:00,000
+Log back.
+
+161
+00:14:00,000 --> 00:14:05,000
+Log back is intended to be the successor of Log for G.
+
+162
+00:14:05,000 --> 00:14:11,000
+It was developed with the original log for G developer and features a lightweight architecture.
+
+163
+00:14:13,000 --> 00:14:21,000
+So for G itself, four G is a framework that acts as a simple interface for various other logging libraries,
+
+164
+00:14:21,000 --> 00:14:27,000
+allowing developers to log in the desired implementation and deployment time.
+
+165
+00:14:28,000 --> 00:14:37,000
+So basically rides it could rely on the interface provided by so for G and then decide which log you
+
+166
+00:14:37,000 --> 00:14:45,000
+want to use because A so for G supports really a lot of different factors, including connectors for
+
+167
+00:14:45,000 --> 00:14:46,000
+4G.
+
+168
+00:14:46,000 --> 00:14:54,000
+And log back, let's review multiple common considerations that are associated with this risk category.
+
+169
+00:14:55,000 --> 00:15:02,000
+There isn't much common vulnerability on the exposures data for this category, but the tactic in responding
+
+170
+00:15:02,000 --> 00:15:04,000
+to breaches is critical.
+
+171
+00:15:04,000 --> 00:15:13,000
+Still, it can be very impactful for comfortability, visibility, incident, alerting and forensics.
+
+172
+00:15:13,000 --> 00:15:24,000
+Among the most notable common victims memory that is worth the mention of the fallen S.W.A.T. 778 insufficient
+
+173
+00:15:24,000 --> 00:15:31,000
+log in when security critical events are not logged properly, such as failed log in item.
+
+174
+00:15:31,000 --> 00:15:39,000
+This can make malicious behavior more difficult to detect and may complicate analysis after an attack
+
+175
+00:15:39,000 --> 00:15:40,000
+succeeds.
+
+176
+00:15:40,000 --> 00:15:47,000
+CW E 117 Improper output neutralization for locks.
+
+177
+00:15:47,000 --> 00:15:54,000
+This can allow an attacker to forge entries or inject malicious calls into the logs.
+
+178
+00:15:54,000 --> 00:15:56,000
+Lock Forging Vulnerabilities.
+
+179
+00:15:56,000 --> 00:16:05,000
+Akua When data enters an application from an and trusted source, the data is written to an application
+
+180
+00:16:05,000 --> 00:16:06,000
+or system log file.
+
+181
+00:16:07,000 --> 00:16:13,000
+CW 223 Completion of security relevant information.
+
+182
+00:16:14,000 --> 00:16:21,000
+In this case, the application doesn't record or display information that would be important for identifying
+
+183
+00:16:21,000 --> 00:16:27,000
+the source or nature of an attack for determining if an action is safe.
+
+184
+00:16:28,000 --> 00:16:34,000
+cwe5 hundred 32 insertion of sensitive information in the log file.
+
+185
+00:16:36,000 --> 00:16:36,000
+While log in.
+
+186
+00:16:36,000 --> 00:16:39,000
+All information may be helpful.
+
+187
+00:16:39,000 --> 00:16:46,000
+Under development stages, it is important that Logan levels be set appropriately before a product ships
+
+188
+00:16:46,000 --> 00:16:54,000
+so that sensitive user data and system information are not accidentally exposed to potential attackers.
+
+189
+00:16:55,000 --> 00:17:00,000
+Let's compare WASP Top ten 2017 versus US Top ten 2021.
+
+190
+00:17:01,000 --> 00:17:03,000
+Previously we had categories.
+
+191
+00:17:03,000 --> 00:17:11,000
+It was called patient log and monitoring, and the WASP space is a 2021.
+
+192
+00:17:11,000 --> 00:17:14,000
+It was promoted to the position number nine.
+
+193
+00:17:14,000 --> 00:17:18,000
+The scope of this category has been revised.
+
+194
+00:17:18,000 --> 00:17:24,000
+TSA's name also was changed to security of volume and monitoring failures.
+
+195
+00:17:25,000 --> 00:17:29,000
+And now it is time to review examples of attacks.
+
+196
+00:17:30,000 --> 00:17:32,000
+Let's review two scenarios.
+
+197
+00:17:32,000 --> 00:17:41,000
+Scenario number one A Children's Health Plan Providers website operator who then detected breach due
+
+198
+00:17:41,000 --> 00:17:43,000
+to a lack of monitoring and log?
+
+199
+00:17:44,000 --> 00:17:54,000
+An external party informed is a health plan provider that had access and modified thousands of sensitive
+
+200
+00:17:54,000 --> 00:18:00,000
+health records of more than 3.5 million children at cost incidents.
+
+201
+00:18:00,000 --> 00:18:08,000
+Review found that the website developers had not addressed significant vulnerabilities as there was
+
+202
+00:18:08,000 --> 00:18:10,000
+no log or monitoring system.
+
+203
+00:18:11,000 --> 00:18:18,000
+The data breach could have been in progress since 2017 at periods of more than seven years.
+
+204
+00:18:19,000 --> 00:18:24,000
+An attacker gained access to an organisation's internal network.
+
+205
+00:18:25,000 --> 00:18:32,000
+The attack in Iran is coming to locate internal systems with no vulnerabilities and obtains sensitive
+
+206
+00:18:32,000 --> 00:18:39,000
+data since the organization doesn't follow adequate log and monitoring practices.
+
+207
+00:18:39,000 --> 00:18:47,000
+They are unable to attack active attacks as a data breach continuous undetected for a long period of
+
+208
+00:18:47,000 --> 00:18:48,000
+time.
+
+209
+00:18:50,000 --> 00:18:57,000
+A major Indian airline had a data breach involving more than ten years worth of personal data of millions
+
+210
+00:18:57,000 --> 00:19:02,000
+of passengers, including passport and credit card data.
+
+211
+00:19:03,000 --> 00:19:11,000
+The data breach accuracy at a search party cloud hosting provider who notified the airline of the breach
+
+212
+00:19:11,000 --> 00:19:12,000
+after some time.
+
+213
+00:19:13,000 --> 00:19:18,000
+Because of insufficient logging, not on time monitoring and alerting.
+
+214
+00:19:18,000 --> 00:19:24,000
+It was almost impossible to prevent data breaches simply once it was discovered.
+
+215
+00:19:24,000 --> 00:19:26,000
+And analyses that use that.
+
+216
+00:19:28,000 --> 00:19:33,000
+And major European airlines suffered reportable breach.
+
+217
+00:19:33,000 --> 00:19:42,000
+The breach was reportedly caused by a payment application security vulnerabilities exploited by attackers
+
+218
+00:19:42,000 --> 00:19:47,000
+who gather with more than 400,000 customer payments records.
+
+219
+00:19:48,000 --> 00:19:54,000
+The airline was fined £20 million as a result by the privacy regulator.
+
+220
+00:19:55,000 --> 00:20:01,000
+And finally, let's talk about how to prevent vulnerabilities related to security.
+
+221
+00:20:01,000 --> 00:20:03,000
+Log in and monitoring servers.
+
+222
+00:20:03,000 --> 00:20:10,000
+It is recommended that developers implement some or all of the following controls, depending on the
+
+223
+00:20:10,000 --> 00:20:12,000
+risk of the application.
+
+224
+00:20:13,000 --> 00:20:20,000
+Ensure all login access control and server side input validation failures can do logged with sufficient
+
+225
+00:20:20,000 --> 00:20:30,000
+user context to identify suspicious or malicious accounts and have enough time to allow delayed forensic
+
+226
+00:20:30,000 --> 00:20:30,000
+analysis.
+
+227
+00:20:31,000 --> 00:20:39,000
+Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems.
+
+228
+00:20:40,000 --> 00:20:43,000
+This should help avoid forgery.
+
+229
+00:20:44,000 --> 00:20:51,000
+Devsecops teams should establish effective monitoring and alerting, such as a suspicious activities
+
+230
+00:20:51,000 --> 00:20:54,000
+are detected and responded to quickly.
+
+231
+00:20:55,000 --> 00:21:02,000
+Establish or adopt an incident response and recovery plan, such as National Institute of Standards
+
+232
+00:21:02,000 --> 00:21:12,000
+and Technology 861 revision to oh eight that I'm going to leave a reference to this document attachments
+
+233
+00:21:12,000 --> 00:21:12,000
+to the last.
+
+234
+00:21:14,000 --> 00:21:22,000
+Ensure that logs contain all the relevant data and are well formatted to be consumed by other tools.
+
+235
+00:21:22,000 --> 00:21:24,000
+Lock Management Solutions.
+
+236
+00:21:25,000 --> 00:21:33,000
+Test If your monitoring systems can identify suspicious activity and ensure that dirty is done in near
+
+237
+00:21:34,000 --> 00:21:34,000
+real time.
+
+238
+00:21:35,000 --> 00:21:43,000
+Introduce some log management to at least one of those that we have discussed in this lesson or similar
+
+239
+00:21:43,000 --> 00:21:43,000
+one.
+
+240
+00:21:44,000 --> 00:21:47,000
+That's all what I wanted to discuss with you today.
+
+241
+00:21:48,000 --> 00:21:51,000
+Let's recap what we have learned in this lesson.
+
+242
+00:21:52,000 --> 00:21:58,000
+We learned what logging and logs are well on security, logging and monitoring.
+
+243
+00:21:58,000 --> 00:21:59,000
+Taylor Swift Category.
+
+244
+00:22:00,000 --> 00:22:07,000
+I explains potential impact, which may be caused by vulnerabilities associated with this risk category.
+
+245
+00:22:08,000 --> 00:22:12,000
+What discussed risk factors that should be eliminated?
+
+246
+00:22:13,000 --> 00:22:18,000
+I hold an overview of management tools and libraries for logging in Java.
+
+247
+00:22:19,000 --> 00:22:22,000
+We reviewed multiple common weaknesses enumerations.
+
+248
+00:22:23,000 --> 00:22:30,000
+Also, we did a comparison of of us top ten 2017 versus avast top ten 2021.
+
+249
+00:22:31,000 --> 00:22:39,000
+We reviewed different examples of attacks and examples of the lessons we learned how to prevent negative
+
+250
+00:22:39,000 --> 00:22:43,000
+consequences caused by security, volume and monitoring failures.
+
+251
+00:22:44,000 --> 00:22:46,000
+That's it for this lesson.
+
+252
+00:22:46,000 --> 00:22:48,000
+Thank you all for your attention.
+
+253
+00:22:48,000 --> 00:22:50,000
+Have a great day and see you.
+
+254
+00:22:50,000 --> 00:22:51,000
+Next lesson.
+
diff --git a/73 - OWASP Top 10 2021/017 Server-Side Request Forgery (SSRF)_en.srt b/73 - OWASP Top 10 2021/017 Server-Side Request Forgery (SSRF)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..7bb1e351a343aa406993c669f44dbc1957538b38
--- /dev/null
+++ b/73 - OWASP Top 10 2021/017 Server-Side Request Forgery (SSRF)_en.srt
@@ -0,0 +1,1036 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello Tim.
+
+2
+00:00:06,000 --> 00:00:12,000
+Today we are going to learn server side request forgery risk category from Avast Top ten.
+
+3
+00:00:12,000 --> 00:00:17,000
+We are going to start the lesson from the general overview of the risk category.
+
+4
+00:00:17,000 --> 00:00:22,000
+I will tell you what is called trust relationships in the web applications.
+
+5
+00:00:22,000 --> 00:00:25,000
+We are going to review different risk factors.
+
+6
+00:00:25,000 --> 00:00:28,000
+This is recommended to eliminate.
+
+7
+00:00:28,000 --> 00:00:35,000
+I will explain why server side regrets forgery is dangerous and what potential impacts are.
+
+8
+00:00:35,000 --> 00:00:40,000
+We are going to review different types of server side request forgery.
+
+9
+00:00:41,000 --> 00:00:49,000
+As always, we are going to compare Avast Top ten 2017 versus Avast Top ten 2021.
+
+10
+00:00:49,000 --> 00:00:56,000
+During the lesson we are going to review different attack examples, including Capital One incident,
+
+11
+00:00:56,000 --> 00:01:01,000
+some basic Java example and other examples of attacks.
+
+12
+00:01:01,000 --> 00:01:07,000
+And at the end of the lesson, we are going to make a summary of what we have to do in order to prevent
+
+13
+00:01:07,000 --> 00:01:10,000
+server side request forgery.
+
+14
+00:01:10,000 --> 00:01:12,000
+Let's start our lesson.
+
+15
+00:01:12,000 --> 00:01:16,000
+Let's start from the high level overview of this risk category.
+
+16
+00:01:16,000 --> 00:01:19,000
+Let's understand what it is.
+
+17
+00:01:19,000 --> 00:01:28,000
+If an attacker can make this server sends a request, usually we mean HTTP requests on its behalf.
+
+18
+00:01:28,000 --> 00:01:31,000
+Then that is server side request forgery.
+
+19
+00:01:32,000 --> 00:01:40,000
+That means that attacker get access to the internal services located on the server and can send data
+
+20
+00:01:40,000 --> 00:01:42,000
+from that server.
+
+21
+00:01:42,000 --> 00:01:47,000
+It is dangerous because in case requests are sent from the server.
+
+22
+00:01:47,000 --> 00:01:55,000
+Attackers can get access to the information on the server that is secure to be accessed outside of the
+
+23
+00:01:55,000 --> 00:01:56,000
+server.
+
+24
+00:01:56,000 --> 00:02:04,000
+For example, attackers can send information about internal resources, perform port scanning on the
+
+25
+00:02:04,000 --> 00:02:10,000
+internal network, send confidential information like credentials, etc..
+
+26
+00:02:10,000 --> 00:02:18,000
+Server side request forgery allows an attacker to force the server side application into making arbitrary
+
+27
+00:02:18,000 --> 00:02:22,000
+web requests to an unintended domain.
+
+28
+00:02:23,000 --> 00:02:31,000
+This can result in the server making connections to internal only services or arbitrary external systems.
+
+29
+00:02:32,000 --> 00:02:40,000
+A successful server side request forgery attack can result in unauthorized actions or access to data
+
+30
+00:02:40,000 --> 00:02:48,000
+within the organization, either in the vulnerable application itself or on other backend systems that
+
+31
+00:02:48,000 --> 00:02:51,000
+the application can communicate with.
+
+32
+00:02:51,000 --> 00:02:59,000
+This vulnerability usually occurs in applications that take your rails from the user and then make a
+
+33
+00:02:59,000 --> 00:03:09,000
+HTTP request to the supplied URL without proper euro validation, excluding internal IPS, for instance.
+
+34
+00:03:09,000 --> 00:03:17,000
+As modern web applications provide end users with convenient features, fetching a URL becomes a common
+
+35
+00:03:17,000 --> 00:03:18,000
+scenario.
+
+36
+00:03:19,000 --> 00:03:25,000
+As a result, the incidence of server side request forgery is increasing.
+
+37
+00:03:25,000 --> 00:03:32,000
+Also, the severity of server side request forgery is becoming high due to the cloud services and the
+
+38
+00:03:32,000 --> 00:03:35,000
+complexity of architectures.
+
+39
+00:03:36,000 --> 00:03:45,000
+Why service such request forgery is also dangerous is because trust relationships of the application
+
+40
+00:03:45,000 --> 00:03:46,000
+is under attack.
+
+41
+00:03:46,000 --> 00:03:48,000
+Now what are trust?
+
+42
+00:03:48,000 --> 00:03:57,000
+Relationships of application is the trust relationship occurs when an application server interacts with
+
+43
+00:03:57,000 --> 00:04:02,000
+private banking systems not intended for access by users.
+
+44
+00:04:03,000 --> 00:04:12,000
+Is accessible systems most likely use non-removable private IP addresses or are restricted to specific
+
+45
+00:04:12,000 --> 00:04:18,000
+costs, which assumes that the network topology protects them.
+
+46
+00:04:18,000 --> 00:04:25,000
+Lack of internal security controls opens the application to in server sites.
+
+47
+00:04:25,000 --> 00:04:26,000
+Request forgery.
+
+48
+00:04:26,000 --> 00:04:31,000
+Vulnerability is the main things that we all have to remember.
+
+49
+00:04:31,000 --> 00:04:34,000
+Never assume anything when it comes to code.
+
+50
+00:04:34,000 --> 00:04:44,000
+Security trust relationships exist because an engineer doesn't implement proper security controls because
+
+51
+00:04:44,000 --> 00:04:50,000
+they incorrectly assume attackers can attack from an already trusted location.
+
+52
+00:04:51,000 --> 00:04:56,000
+Let's review environment that can increase the risk of service sites.
+
+53
+00:04:56,000 --> 00:04:58,000
+Request Forgery Attack.
+
+54
+00:04:58,000 --> 00:05:01,000
+Let's talk about risk factors now.
+
+55
+00:05:01,000 --> 00:05:09,000
+The vulnerable application will often have functionality for publishing, reading or in-person data
+
+56
+00:05:09,000 --> 00:05:12,000
+using a URL that a user can modify.
+
+57
+00:05:13,000 --> 00:05:21,000
+The attacker takes advantage of this functionality by manipulating the euro or providing an entirely
+
+58
+00:05:21,000 --> 00:05:22,000
+new euro.
+
+59
+00:05:23,000 --> 00:05:30,000
+The court on the server will then read or submit the euro, allowing the attacker to read server data,
+
+60
+00:05:30,000 --> 00:05:37,000
+connect in internal services, or send post requests to private internal services.
+
+61
+00:05:37,000 --> 00:05:39,000
+In general server side requests.
+
+62
+00:05:39,000 --> 00:05:46,000
+Forgery attacks are made possible by a lack of user input validation in the web application.
+
+63
+00:05:47,000 --> 00:05:54,000
+Without strict validation, the attacker can alter parameters that control what gets executed.
+
+64
+00:05:54,000 --> 00:06:02,000
+Server side for example, potentially malicious commands or establish an HTTP connections to arbitrary
+
+65
+00:06:02,000 --> 00:06:03,000
+systems.
+
+66
+00:06:04,000 --> 00:06:11,000
+Vulnerabilities will arise when the web application is unable to identify and validate requests from
+
+67
+00:06:11,000 --> 00:06:21,000
+trusted applications, or when the web application can send requests to any external IP address or domain.
+
+68
+00:06:21,000 --> 00:06:29,000
+Let's review now potential impact that may be caused by server sites, request forgery and believes
+
+69
+00:06:29,000 --> 00:06:36,000
+that you ready made gas potential impact that may be caused by this vulnerability but lets some attack
+
+70
+00:06:37,000 --> 00:06:45,000
+server sites request forgery attacks present a range of risks from potentially stealing sensitive information
+
+71
+00:06:45,000 --> 00:06:50,000
+from the application to bring an entire web application down.
+
+72
+00:06:51,000 --> 00:06:59,000
+These attacks target systems that are located behind firewalls and restrict access from non trusted
+
+73
+00:06:59,000 --> 00:07:00,000
+networks.
+
+74
+00:07:01,000 --> 00:07:06,000
+Protecting your application from such attacks is vitally important.
+
+75
+00:07:07,000 --> 00:07:15,000
+The damage extent is hard to predict as outcomes depend on the system configuration, API security practices
+
+76
+00:07:15,000 --> 00:07:19,000
+adopted and the severity of the attack.
+
+77
+00:07:19,000 --> 00:07:27,000
+In some situations, the server side requests for vulnerability may even allow an attacker to perform
+
+78
+00:07:27,000 --> 00:07:29,000
+arbitrary command execution.
+
+79
+00:07:30,000 --> 00:07:39,000
+This can result in exposure and theft of data that may include sensitive, personal or corporate information.
+
+80
+00:07:39,000 --> 00:07:47,000
+If successful server side requests, forgery, vulnerability grants, hackers admin access to the data
+
+81
+00:07:47,000 --> 00:07:50,000
+stored on the server and its backend system.
+
+82
+00:07:51,000 --> 00:08:00,000
+That negative consequences can be one of the following denial of service attack, remote code execution,
+
+83
+00:08:01,000 --> 00:08:09,000
+hijack of a vulnerable system to use its trust relationship with other systems to launch further attacks
+
+84
+00:08:10,000 --> 00:08:13,000
+or cause or cross-site port attack.
+
+85
+00:08:14,000 --> 00:08:23,000
+It is not necessary that any service request for a related attack will have to bring the response data
+
+86
+00:08:23,000 --> 00:08:27,000
+to the heart to avoid missing any response.
+
+87
+00:08:27,000 --> 00:08:33,000
+An attack that can take the help of an open port using an open port.
+
+88
+00:08:33,000 --> 00:08:39,000
+It is easy to carry out a quick network scan of the application server.
+
+89
+00:08:39,000 --> 00:08:43,000
+This is known as cross-site port attack.
+
+90
+00:08:43,000 --> 00:08:50,000
+There are different types of service sites request forgery and to prevent them, we need to know these
+
+91
+00:08:50,000 --> 00:08:51,000
+types.
+
+92
+00:08:51,000 --> 00:08:56,000
+Let's learn them for any service site ecosystem.
+
+93
+00:08:56,000 --> 00:09:06,000
+There are two sites the server and its internal components, and this server was a backend system based
+
+94
+00:09:06,000 --> 00:09:09,000
+on the site impacted by this vulnerability.
+
+95
+00:09:09,000 --> 00:09:12,000
+It has two classifications.
+
+96
+00:09:12,000 --> 00:09:15,000
+Attacks against the server.
+
+97
+00:09:15,000 --> 00:09:24,000
+This is also known as basic server side request forgery and refers to the direct display of the outcome
+
+98
+00:09:24,000 --> 00:09:28,000
+of the attack to the hacker to make this happen.
+
+99
+00:09:28,000 --> 00:09:37,000
+The server accesses the attacker, fetched URL, gathers the information data response and shares it
+
+100
+00:09:37,000 --> 00:09:38,000
+with the hacker.
+
+101
+00:09:39,000 --> 00:09:49,000
+This tab describes a case when data from the malicious forced backhand request is reflected in the application
+
+102
+00:09:49,000 --> 00:09:49,000
+frontend.
+
+103
+00:09:50,000 --> 00:10:00,000
+Mostly the hacker swaps the actual URL with localhost or IP 120 7001.
+
+104
+00:10:01,000 --> 00:10:08,000
+Doing so will help the hardware to find out the path that will directly lead to crucial data.
+
+105
+00:10:09,000 --> 00:10:16,000
+This type of server side request forgery attack is common and can lead to heart.
+
+106
+00:10:16,000 --> 00:10:21,000
+Identification is the right kind of investigation is carried out.
+
+107
+00:10:21,000 --> 00:10:26,000
+And the second type attacks against banking systems.
+
+108
+00:10:27,000 --> 00:10:33,000
+Here, the threat actor doesn't directly reach the server or communicate with it.
+
+109
+00:10:33,000 --> 00:10:41,000
+It involves taking any server backend system under control and using it to access severe responses or
+
+110
+00:10:41,000 --> 00:10:42,000
+information.
+
+111
+00:10:43,000 --> 00:10:48,000
+So it is known as blind service site request forgery.
+
+112
+00:10:49,000 --> 00:10:57,000
+As the name describes with this type of server site request forgery attack, the application is forced
+
+113
+00:10:57,000 --> 00:11:02,000
+to make a back end HTTP request to a malicious domain.
+
+114
+00:11:03,000 --> 00:11:06,000
+In this type of server side request forgery.
+
+115
+00:11:06,000 --> 00:11:10,000
+The attacker doesn't get data back from the server directly.
+
+116
+00:11:11,000 --> 00:11:18,000
+The response from the backend request triggers an action on the target without getting reflected in
+
+117
+00:11:18,000 --> 00:11:19,000
+the application frontend.
+
+118
+00:11:20,000 --> 00:11:27,000
+Hacker sees this type of server side request forgery when they want to make some changes using the victim's
+
+119
+00:11:27,000 --> 00:11:28,000
+server.
+
+120
+00:11:29,000 --> 00:11:36,000
+Let's compare a WASP Top ten, 2017 versus a WASP Top ten 2021.
+
+121
+00:11:37,000 --> 00:11:39,000
+This is a new category.
+
+122
+00:11:39,000 --> 00:11:42,000
+It is added from the top ten community survey.
+
+123
+00:11:43,000 --> 00:11:51,000
+The data shows a relatively low incidence rate with above average testing coverage and above average
+
+124
+00:11:51,000 --> 00:11:54,000
+exploit and impact potential ratings.
+
+125
+00:11:55,000 --> 00:12:02,000
+From the very first list released to the newest one, service site request forgery has always been defined
+
+126
+00:12:02,000 --> 00:12:05,000
+as a potential security threat.
+
+127
+00:12:05,000 --> 00:12:10,000
+However, it got its separate category this time only.
+
+128
+00:12:11,000 --> 00:12:19,000
+Dependent upon the total common vulnerabilities and exposures reported server size request forgery secured
+
+129
+00:12:19,000 --> 00:12:22,000
+10th place in the avast least.
+
+130
+00:12:23,000 --> 00:12:25,000
+Let's start with giving examples.
+
+131
+00:12:26,000 --> 00:12:28,000
+Talking about server side requests forgery.
+
+132
+00:12:29,000 --> 00:12:33,000
+It is not possible to ignore a case that happened with Capital One.
+
+133
+00:12:34,000 --> 00:12:35,000
+What is it?
+
+134
+00:12:35,000 --> 00:12:43,000
+Capital One financial corporation is an American bank holding company specializing in credit cards,
+
+135
+00:12:43,000 --> 00:12:47,000
+auto loans, banking and savings accounts.
+
+136
+00:12:48,000 --> 00:12:58,000
+The most famous service request forgery attack happened in July of 2019 against Capital One server site
+
+137
+00:12:58,000 --> 00:13:01,000
+request forgery was used to retrieve a W.
+
+138
+00:13:01,000 --> 00:13:10,000
+S credentials that attackers used to steal over 100 million Capital One customer's personal information
+
+139
+00:13:11,000 --> 00:13:15,000
+hiding behind the VPN and Tor browser.
+
+140
+00:13:15,000 --> 00:13:23,000
+The attacker executed and server side request forgery query that the server relayed to the bank and
+
+141
+00:13:23,000 --> 00:13:28,000
+a w s server because of misconfigured web application firewall.
+
+142
+00:13:29,000 --> 00:13:38,000
+The attackers then retrieved a temporary credential from the ec2 metadata service and run the LRS Terminal
+
+143
+00:13:38,000 --> 00:13:42,000
+Command to retrieve the list of 8ws.
+
+144
+00:13:42,000 --> 00:13:46,000
+S three buckets of compromised Capital one accounts.
+
+145
+00:13:47,000 --> 00:13:48,000
+What was the result?
+
+146
+00:13:49,000 --> 00:13:57,000
+The malicious actors copied nearly 30 gigabytes of Capital One credit application data.
+
+147
+00:13:58,000 --> 00:14:01,000
+To help you understand this risk category better.
+
+148
+00:14:02,000 --> 00:14:05,000
+Let me show you one example with Java source code.
+
+149
+00:14:06,000 --> 00:14:11,000
+It is relatively simple, but it will help you to understand the challenge.
+
+150
+00:14:12,000 --> 00:14:19,000
+The code on this slide represents one of the possible masses to fetch remote resources from a Java web
+
+151
+00:14:19,000 --> 00:14:20,000
+application.
+
+152
+00:14:21,000 --> 00:14:22,000
+Zahra.
+
+153
+00:14:22,000 --> 00:14:24,000
+At least two issues with this code.
+
+154
+00:14:25,000 --> 00:14:34,000
+The first one, a java dot net euro object can represent many more schemes that just HTP.
+
+155
+00:14:34,000 --> 00:14:41,000
+For example, it can be used to fetch the local file by employing the file protocol.
+
+156
+00:14:42,000 --> 00:14:50,000
+And the second issue, no restriction whatsoever is enforced to include or exclude the means.
+
+157
+00:14:50,000 --> 00:14:59,000
+This could be exploited to fetch in general resources, for example, those that reside in local force
+
+158
+00:14:59,000 --> 00:15:01,000
+or in the internal network.
+
+159
+00:15:02,000 --> 00:15:07,000
+And we can see that there is no invalidation of location, massive parameter.
+
+160
+00:15:07,000 --> 00:15:17,000
+So technically speaking, any string can be passed to our message and resource will be read and returned
+
+161
+00:15:17,000 --> 00:15:19,000
+from the method as a string.
+
+162
+00:15:19,000 --> 00:15:22,000
+How to avoid potential liability.
+
+163
+00:15:22,000 --> 00:15:25,000
+Let me show it to you on another slide.
+
+164
+00:15:26,000 --> 00:15:31,000
+On this slide, we are going to release a solution to the challenge shown on the previous slide.
+
+165
+00:15:32,000 --> 00:15:40,000
+Fetching a user provided euro is quite a sensitive operation, especially if a user will be able to
+
+166
+00:15:40,000 --> 00:15:42,000
+read the response.
+
+167
+00:15:42,000 --> 00:15:47,000
+In such cases and allow least approach is advisable.
+
+168
+00:15:47,000 --> 00:15:55,000
+For example, on the certain protocols, the means, POS, etc. are allowed to be requested.
+
+169
+00:15:56,000 --> 00:15:59,000
+All other cases are to be rejected.
+
+170
+00:15:59,000 --> 00:16:08,000
+The court from the previous slide can be hardened by only allowing HTTP or https with sources coming
+
+171
+00:16:08,000 --> 00:16:10,000
+from specific subdomains.
+
+172
+00:16:11,000 --> 00:16:12,000
+Just look at this example.
+
+173
+00:16:13,000 --> 00:16:19,000
+You can see that they added if statement to verify location, massive parameter.
+
+174
+00:16:20,000 --> 00:16:24,000
+And as I already said, this is just an example.
+
+175
+00:16:24,000 --> 00:16:31,000
+In real life, you can come up with your own security requirements and create your custom condition
+
+176
+00:16:31,000 --> 00:16:36,000
+to validate the URL before sending request from the application.
+
+177
+00:16:36,000 --> 00:16:44,000
+I hope that with this example it is clear how server side request forgery can impact your application.
+
+178
+00:16:44,000 --> 00:16:51,000
+And we also reviewed one of the simplest workarounds how to avoid server side request forgery.
+
+179
+00:16:52,000 --> 00:16:55,000
+Let's review other examples of attack.
+
+180
+00:16:55,000 --> 00:16:59,000
+Scenario number one, ports come in channel service.
+
+181
+00:17:00,000 --> 00:17:08,000
+If the network architecture is segmented, attackers can map out internal networks and determine if
+
+182
+00:17:08,000 --> 00:17:14,000
+ports are open or closed on a channel service from connection results.
+
+183
+00:17:14,000 --> 00:17:19,000
+The defined ports can be used for further attacks.
+
+184
+00:17:20,000 --> 00:17:28,000
+Segment of network architecture is an opportunity for attackers as they can use them to figure out whether
+
+185
+00:17:28,000 --> 00:17:31,000
+or not the internal server ports are open.
+
+186
+00:17:31,000 --> 00:17:37,000
+If ports are open, they can easily carry and service sites request for connection.
+
+187
+00:17:38,000 --> 00:17:43,000
+Understand what a segmented network architecture is.
+
+188
+00:17:43,000 --> 00:17:46,000
+Let me explain what network segmentation is.
+
+189
+00:17:47,000 --> 00:17:56,000
+Network segmentation is an architectural approach that divides a network into multiple segments of subnets,
+
+190
+00:17:56,000 --> 00:17:59,000
+each acting as its own small network.
+
+191
+00:18:00,000 --> 00:18:08,000
+This allows network administrators to control the flow of traffic between subnets based on granular
+
+192
+00:18:08,000 --> 00:18:09,000
+policies.
+
+193
+00:18:09,000 --> 00:18:17,000
+Organizations use segmentation to improve monitoring, boost performance, localized technical issues,
+
+194
+00:18:17,000 --> 00:18:21,000
+and, most importantly, enhanced security.
+
+195
+00:18:22,000 --> 00:18:27,000
+Scenario number two, attacks against the local host.
+
+196
+00:18:28,000 --> 00:18:36,000
+If the local machine doesn't validate requests from the local host or execute them with elevated privilege,
+
+197
+00:18:36,000 --> 00:18:39,000
+the server becomes an attack target.
+
+198
+00:18:40,000 --> 00:18:49,000
+The TOCA convinces the application to make an HDP request back to the hosting server via its loopback
+
+199
+00:18:49,000 --> 00:18:50,000
+network interface.
+
+200
+00:18:51,000 --> 00:19:02,000
+Frequently, this involves the attacker supplying a euro with the host name like 120 7001 or just localhost.
+
+201
+00:19:03,000 --> 00:19:11,000
+And just like that, that takes advantage of the trust relationship the system has with its internal
+
+202
+00:19:11,000 --> 00:19:11,000
+requests.
+
+203
+00:19:12,000 --> 00:19:20,000
+Scenario number three, attacks against other banking systems similar to the attack against the server
+
+204
+00:19:20,000 --> 00:19:21,000
+itself.
+
+205
+00:19:21,000 --> 00:19:29,000
+When developers assume that network topologies protect an internal systems, we often see weak server
+
+206
+00:19:29,000 --> 00:19:34,000
+security controls configurations for interactions on the local network.
+
+207
+00:19:35,000 --> 00:19:43,000
+Attackers take advantage of backend systems that contain sensitive functionality and lock authentication
+
+208
+00:19:43,000 --> 00:19:48,000
+mechanisms for anyone accessing ZAP from the local network.
+
+209
+00:19:49,000 --> 00:19:56,000
+We already discussed today trustful relationships between BEC and service of the application itself.
+
+210
+00:19:56,000 --> 00:20:00,000
+It can be a risk factor for such kind of vulnerability.
+
+211
+00:20:01,000 --> 00:20:02,000
+Samarra.
+
+212
+00:20:02,000 --> 00:20:06,000
+Number four, attacks against third party systems.
+
+213
+00:20:07,000 --> 00:20:15,000
+When a company doesn't adequately protect its systems, an attacker can hijack them to launch attacks
+
+214
+00:20:15,000 --> 00:20:17,000
+against the third party.
+
+215
+00:20:17,000 --> 00:20:26,000
+This attack uses a trust relationship between the vulnerable company and the customer or vendor to access
+
+216
+00:20:26,000 --> 00:20:34,000
+private resources, and that can also launch attacks using the vulnerable server as a pivot point,
+
+217
+00:20:34,000 --> 00:20:39,000
+making the victim company appear to be the source of the attack.
+
+218
+00:20:39,000 --> 00:20:47,000
+Now I suggest to summarize all what we have learned and gather rules and guidelines to follow in order
+
+219
+00:20:47,000 --> 00:20:49,000
+to avoid server side requests.
+
+220
+00:20:49,000 --> 00:20:50,000
+Forgery.
+
+221
+00:20:50,000 --> 00:20:58,000
+It is recommended to implement security controls on different levels, namely on the network layer and
+
+222
+00:20:58,000 --> 00:21:00,000
+on the application layer.
+
+223
+00:21:01,000 --> 00:21:09,000
+On the network layer segment remote resource access functionality in separate networks to reduce the
+
+224
+00:21:09,000 --> 00:21:12,000
+impact of the server side request forgery.
+
+225
+00:21:13,000 --> 00:21:19,000
+We already talked today about network segmentation, so I will not stop on this.
+
+226
+00:21:20,000 --> 00:21:29,000
+Enforce denied by default firewall policies or network access control rules to block all but essential
+
+227
+00:21:29,000 --> 00:21:30,000
+internet traffic.
+
+228
+00:21:31,000 --> 00:21:38,000
+On the application layer, sanitise and validate all client supplied input data.
+
+229
+00:21:38,000 --> 00:21:46,000
+In some previous lessons, we already discussed correctness of using block list and allow list, maintain
+
+230
+00:21:46,000 --> 00:21:54,000
+and allow list or deny list of both of your rails that you would make or denies a request to respectively
+
+231
+00:21:55,000 --> 00:22:02,000
+develop a safe list of the allowed, the means, resources and protocols for fetching resources and
+
+232
+00:22:02,000 --> 00:22:04,000
+enforce its use.
+
+233
+00:22:04,000 --> 00:22:11,000
+Next perform safe list input validation on all inputs whenever possible.
+
+234
+00:22:11,000 --> 00:22:19,000
+Do not accept user input in functions that control where the web server can fetch resources if your
+
+235
+00:22:19,000 --> 00:22:24,000
+application must accept such user inputs validate.
+
+236
+00:22:25,000 --> 00:22:28,000
+Do not send raw responses to clients.
+
+237
+00:22:29,000 --> 00:22:36,000
+Removing trust relationships will reduce your potential server site request forgery attack surface use
+
+238
+00:22:36,000 --> 00:22:43,000
+parameterization properly and implement a zero trust architecture which requires the various parts of
+
+239
+00:22:43,000 --> 00:22:51,000
+the application environment to always revalidate one another in the previous lessons, namely when we
+
+240
+00:22:51,000 --> 00:22:57,000
+learn security misconfiguration we already talked about zero trust security model.
+
+241
+00:22:58,000 --> 00:23:02,000
+Please refer to the lesson if you want to refresh your knowledge.
+
+242
+00:23:03,000 --> 00:23:12,000
+20/21 is a service site request for its first year on the WASP lease, and security professionals should
+
+243
+00:23:12,000 --> 00:23:17,000
+expect to encounter this read more and more in the coming years.
+
+244
+00:23:17,000 --> 00:23:24,000
+But if you are effectively testing your applications and remediating issues quickly and correctly,
+
+245
+00:23:24,000 --> 00:23:32,000
+you'll be prepared to support and resolve server side requests, forgery vulnerabilities before an attacker
+
+246
+00:23:32,000 --> 00:23:33,000
+exploits them.
+
+247
+00:23:34,000 --> 00:23:37,000
+That's all what I wanted to share with you today.
+
+248
+00:23:37,000 --> 00:23:40,000
+Let's recap what we have learned.
+
+249
+00:23:40,000 --> 00:23:44,000
+We learned today what seven sites request forgery is.
+
+250
+00:23:45,000 --> 00:23:47,000
+We learned risk factors.
+
+251
+00:23:47,000 --> 00:23:50,000
+I explained potential impacts.
+
+252
+00:23:50,000 --> 00:23:55,000
+We discussed different types of server side request forgery.
+
+253
+00:23:55,000 --> 00:24:04,000
+As usual, we compared Avast Top ten 2017 versus Avast Top ten 2021.
+
+254
+00:24:04,000 --> 00:24:13,000
+And we reviewed a lot of different examples of attacks, including Capital One incident, Java example
+
+255
+00:24:13,000 --> 00:24:15,000
+and other attack examples.
+
+256
+00:24:16,000 --> 00:24:21,000
+And at the end of the lesson, we discussed how to prevent server side request forgery.
+
+257
+00:24:22,000 --> 00:24:24,000
+That's all for today.
+
+258
+00:24:24,000 --> 00:24:26,000
+Thank you for your attention.
+
+259
+00:24:26,000 --> 00:24:29,000
+Have a great day and see you in the next lesson.
+
diff --git a/73 - OWASP Top 10 2021/external-links.txt b/73 - OWASP Top 10 2021/external-links.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b59cef0718549dbe09ac6e65d5c5b88d2daab1c0
--- /dev/null
+++ b/73 - OWASP Top 10 2021/external-links.txt
@@ -0,0 +1,42 @@
+
+001 Common-Weakness-Enumeration-CWE-official-website
+https://cwe.mitre.org/index.html
+
+002 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/bac
+
+004 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/cf
+
+005 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/cf
+
+006 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/i/problem
+
+007 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/i/problem
+
+008 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/i/problem
+
+011 NIST-800-123-Guide-to-General-Server-Security
+https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-123.pdf
+
+011 NIST-800-207-Zero-Trust-Architecture
+https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
+
+012 NIST-800-123-Guide-to-General-Server-Security
+https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-123.pdf
+
+012 NIST-800-207-Zero-Trust-Architecture
+https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
+
+013 pom.xml-from-the-lesson-with-OWASP-plugin
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/blob/master/pom.xml
+
+013 Dependency-check-plugin
+https://mvnrepository.com/artifact/org.owasp/dependency-check-maven/7.1.0
+
+016 Computer-Security-Incident-Handling-Guide
+https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
diff --git a/74 - OWASP API Security Top 10 2023/001 OWASP API Security Project & OWASP API Security Top 10 2023.html b/74 - OWASP API Security Top 10 2023/001 OWASP API Security Project & OWASP API Security Top 10 2023.html
new file mode 100644
index 0000000000000000000000000000000000000000..afc6d39ba664d43b3e8e0fd73d189367cda43e47
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/001 OWASP API Security Project & OWASP API Security Top 10 2023.html
@@ -0,0 +1,69 @@
+
+
+
+
+
+ OWASP API Security Project & OWASP API Security Top 10 2023
+
+
+
+
+
+
+
OWASP API Security Project & OWASP API Security Top 10 2023
+
Introduction to OWASP API Security Top 10 2023
Why Learn the OWASP API Security Top 10 2023?
In today's digital landscape, APIs (Application Programming Interfaces) are integral to the functionality and interconnectivity of web applications, mobile applications, and IoT devices. They allow different systems to communicate and share data seamlessly. However, with this increased reliance on APIs comes an elevated risk of security vulnerabilities. Learning the OWASP API Security Top 10 2023 is crucial because:
API Proliferation: APIs are becoming more prevalent, making them attractive targets for attackers.
Unique Vulnerabilities: APIs have unique security challenges that differ from traditional web applications, requiring specialized knowledge to mitigate.
Data Sensitivity: APIs often handle sensitive data, and breaches can lead to severe data leaks and privacy violations.
Business Impact: Security flaws in APIs can lead to significant business disruptions, financial loss, and damage to reputation.
Introduction to API Security - Importance of API Security in Today's Digital Landscape
APIs (Application Programming Interfaces) have become integral to modern software applications, facilitating seamless communication and interaction between different systems and services. However, the increased reliance on APIs also exposes organizations to new security risks. Ensuring API security is crucial because:
Data Exposure: APIs often handle sensitive data such as user information, financial records, and business transactions. Insecure APIs can lead to data breaches, compromising confidentiality and privacy.
Business Continuity: API disruptions or compromises can disrupt operations, leading to financial losses and reputational damage.
Regulatory Compliance: Many industries are subject to strict regulations (e.g., GDPR, HIPAA) that mandate the protection of user data. Non-compliance can result in significant penalties.
Key Differences Between OWASP Top 10 2021 and OWASP API Security Top 10 2023
OWASP API Security Project: focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs). Includes the most recent list API Security Top 10 2023.
The OWASP API Security Top 10 focuses specifically on the unique vulnerabilities and security risks associated with Application Programming Interfaces (APIs), whereas the OWASP Top 10 2021 addresses the most critical web application security risks in general.
Key Differences
Scope:
OWASP API Security Top 10: Focuses solely on API-specific security risks.
OWASP Top 10: Covers a broader range of web application security risks.
Focus on Implementation Details:
The API Security list often dives deeper into issues that are particularly relevant to the nature of API implementations, such as asset management, rate limiting, and object/function level authorization.
New Additions in General List:
The general list introduces newer categories like SSRF, insecure design, and software/data integrity failures, which are not specifically addressed in the API list.
What is in Common between OWASP API Security Top 10 2023 and the OWASP Top 10 2021?
The OWASP API Security Top 10 2023 shares several commonalities with the OWASP Top 10 2021, reflecting enduring security challenges that affect both APIs and web applications. Here's a closer look at the similarities:
Security Misconfiguration: This risk remains a critical concern in both lists. Security misconfigurations occur when security settings are not defined, implemented, or maintained correctly, leading to vulnerabilities. Both APIs and web applications suffer from this issue due to complex configurations and the potential for human error.
Server-Side Request Forgery (SSRF): This risk appears in both lists, highlighting the importance of protecting servers from unauthorized internal requests that can lead to data leaks or manipulation.
Renamed and Reframed Categories
Some risks have been renamed or reframed in the API Security list to better reflect their specific context within APIs:
Broken Access Control in the 2021 list is now split into Broken Object Level Authorization and Broken Function Level Authorization in the API list, emphasizing different aspects of access control failures. Both lists address issues related to access control. In the API Security list, this is split into Broken Object Level Authorization and Broken Function Level Authorization, focusing on the granularity of access controls at the object and function levels, respectively. In the OWASP Top 10 2021, Broken Access Control covers a broader range of access control failures.
Identification and Authentication Failures from the 2021 list is now Broken Authentication in the API list, focusing on the critical aspects of user authentication.
Vulnerable and Outdated Components has been reframed as Improper Inventory Management in the API list, reflecting the importance of managing API components and dependencies properly.
Removed and New Additions
The OWASP Top 10 2021 includes categories that are not explicitly listed in the API Security Top 10 2023, such as:
Cryptographic Failures
Injection
Insecure Design
Software and Data Integrity Failures
Security Logging and Monitoring Failures
Conversely, the API Security Top 10 introduces categories specifically relevant to APIs, such as:
Broken Object Property Level Authorization
Unrestricted Resource Consumption
Broken Function Level Authorization
Unrestricted Access to Sensitive Business Flows
Unsage Consumption of APIs
And we are going to learn all the details in the course.
Do We Need to Learn the OWASP Top 10 2021 First?
Understanding the OWASP Top 10 2021 provides a solid foundation for web application security. This knowledge is beneficial when transitioning to the more specialized OWASP API Security Top 10 2023. The commonalities and renamed categories underscore the evolving nature of security threats while maintaining a focus on core security principles. By mastering both lists, you can better protect both general web applications and the APIs that power modern digital ecosystems.
While it's not strictly necessary to learn the OWASP Top 10 2021 before delving into the OWASP API Security Top 10 2023, it is highly beneficial. Understanding the broader context of web application security will provide a strong foundation and enhance your comprehension of API-specific vulnerabilities. The OWASP Top 10 2021 covers fundamental security concepts that are also relevant to APIs, such as access control, injection flaws, and security misconfigurations.
Additional Information
Evolving Threat Landscape: As the threat landscape evolves, staying updated with the latest security practices and vulnerabilities is essential. The OWASP API Security Top 10 2023 reflects the latest insights and research in API security.
Complementary Knowledge: Combining knowledge from both the OWASP Top 10 2021 and the OWASP API Security Top 10 2023 ensures a comprehensive understanding of web security, allowing you to safeguard both web applications and APIs effectively.
Practical Applications: Learning these security principles is not just theoretical but highly practical. Implementing these best practices can prevent many common and potentially devastating security breaches.
By understanding and applying the principles from both OWASP Top 10 lists, you can build more secure applications and contribute to a safer digital ecosystem.
+
+
+
+
diff --git a/74 - OWASP API Security Top 10 2023/002 API12023 Broken Object Level Authorization - Part 1_en.srt b/74 - OWASP API Security Top 10 2023/002 API12023 Broken Object Level Authorization - Part 1_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..1f14780fb0e80764ba627c4907a12d0dab851f4a
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/002 API12023 Broken Object Level Authorization - Part 1_en.srt
@@ -0,0 +1,720 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:13,000
+Today we start review of the first vulnerability from the OWASp API Security Top ten 2023 list.
+
+3
+00:00:13,000 --> 00:00:17,000
+In this lesson, we are going to learn broken object level authorization.
+
+4
+00:00:18,000 --> 00:00:20,000
+So here's what we'll be covering today.
+
+5
+00:00:20,000 --> 00:00:26,000
+First I will define object level authorization and explain its importance in modern applications.
+
+6
+00:00:27,000 --> 00:00:32,000
+Following that we'll delve into broken object level authorization vulnerabilities, discussing their
+
+7
+00:00:32,000 --> 00:00:40,000
+prevalence in APIs and how they relate to the OWASp top ten list, specifically under Broken Access
+
+8
+00:00:40,000 --> 00:00:41,000
+Control.
+
+9
+00:00:41,000 --> 00:00:48,000
+Next, we'll examine some real world examples of data breaches caused by broken object level authorization
+
+10
+00:00:48,000 --> 00:00:56,000
+and discuss the severe consequences these breaches have for both organisations, and users will then
+
+11
+00:00:56,000 --> 00:01:02,000
+explore insecure coding practices that lead to broken object level authorization vulnerabilities.
+
+12
+00:01:03,000 --> 00:01:08,000
+To make it practical, I will demonstrate with the code example from an online shop highlighting the
+
+13
+00:01:08,000 --> 00:01:11,000
+problem and providing a solution.
+
+14
+00:01:11,000 --> 00:01:18,000
+After this, we'll look into how to enforce robust authorization mechanisms and the importance of continuous
+
+15
+00:01:18,000 --> 00:01:21,000
+testing and validation of authorization logic.
+
+16
+00:01:21,000 --> 00:01:28,000
+We'll also cover the use of random, universally unique identifiers, discussing implementation considerations
+
+17
+00:01:28,000 --> 00:01:32,000
+when integrating Uuids into API ecosystems.
+
+18
+00:01:32,000 --> 00:01:38,000
+Additionally, we'll discuss securing the business logic layer to ensure comprehensive protection.
+
+19
+00:01:38,000 --> 00:01:44,000
+Finally, we'll explore the zero trust security model and how its principles can effectively mitigate
+
+20
+00:01:44,000 --> 00:01:47,000
+broken object level authorization vulnerabilities.
+
+21
+00:01:48,000 --> 00:01:50,000
+So let's start our lesson.
+
+22
+00:01:51,000 --> 00:01:53,000
+Let's start from understanding the general concept.
+
+23
+00:01:54,000 --> 00:01:59,000
+Let's define object level authorization and answer the question why it is important.
+
+24
+00:02:00,000 --> 00:02:05,000
+Object level authorization refers to the practice of controlling access to individual data.
+
+25
+00:02:05,000 --> 00:02:09,000
+objects based on the permissions granted to users or roles.
+
+26
+00:02:09,000 --> 00:02:18,000
+It ensures that users can only perform actions, for example, view, edit, delete on data objects
+
+27
+00:02:18,000 --> 00:02:20,000
+they are authorized to access.
+
+28
+00:02:20,000 --> 00:02:23,000
+The importance of object level authorization includes.
+
+29
+00:02:23,000 --> 00:02:31,000
+Granular control allows organizations to enforce fine grained access controls, limiting exposure and
+
+30
+00:02:31,000 --> 00:02:33,000
+reducing the impact of potential breaches.
+
+31
+00:02:34,000 --> 00:02:42,000
+Compliance helps organizations meet regulatory requirements by ensuring data access is restricted to
+
+32
+00:02:42,000 --> 00:02:43,000
+authorized personnel only.
+
+33
+00:02:44,000 --> 00:02:51,000
+Broken object level authorization vulnerabilities specifically relates to weaknesses in how APIs enforce
+
+34
+00:02:51,000 --> 00:02:55,000
+access controls at the level of individual data objects.
+
+35
+00:02:55,000 --> 00:02:59,000
+For example, records, files, resources.
+
+36
+00:02:59,000 --> 00:03:07,000
+These vulnerabilities arise when APIs fail to adequately verify whether a user has the necessary permissions
+
+37
+00:03:07,000 --> 00:03:10,000
+to access or manipulate specific data objects.
+
+38
+00:03:11,000 --> 00:03:17,000
+APIs may grant broader access rights than necessary, allowing users to perform actions they shouldn't
+
+39
+00:03:17,000 --> 00:03:18,000
+be authorized to do.
+
+40
+00:03:19,000 --> 00:03:27,000
+Broken object level authorization vulnerabilities occur due to flaws in how APIs implement object level
+
+41
+00:03:27,000 --> 00:03:28,000
+authorization.
+
+42
+00:03:28,000 --> 00:03:30,000
+Common scenarios include.
+
+43
+00:03:31,000 --> 00:03:33,000
+Direct object references.
+
+44
+00:03:33,000 --> 00:03:40,000
+APIs expose internal object references, for example, database IDs without proper validation, allowing
+
+45
+00:03:40,000 --> 00:03:44,000
+attackers to manipulate these references to access unauthorized data.
+
+46
+00:03:45,000 --> 00:03:53,000
+Predictable Object Identifiers APIs use predictable patterns or sequential identifiers for objects,
+
+47
+00:03:53,000 --> 00:04:00,000
+making it easier for attackers to guess or iterate through IDs to access unauthorized resources.
+
+48
+00:04:01,000 --> 00:04:08,000
+Inadequate scope validation APIs may lack checks to ensure that users are restricted to accessing only
+
+49
+00:04:08,000 --> 00:04:13,000
+their own data or data they are explicitly authorized to access.
+
+50
+00:04:14,000 --> 00:04:20,000
+Broken object level authorization vulnerabilities are prevalent in APIs across various industries and
+
+51
+00:04:20,000 --> 00:04:23,000
+have been exploited in high profile data breaches.
+
+52
+00:04:24,000 --> 00:04:30,000
+Understanding these vulnerabilities is crucial for implementing effective security measures and protecting
+
+53
+00:04:30,000 --> 00:04:33,000
+sensitive data within API ecosystems.
+
+54
+00:04:34,000 --> 00:04:40,000
+If you are a student of my OWASp top ten course, I believe you remember that I had a lesson with you
+
+55
+00:04:40,000 --> 00:04:43,000
+about such categories as broken Access Control.
+
+56
+00:04:43,000 --> 00:04:48,000
+By the way, I recommend to make sure you watch that lesson before you continue with this one.
+
+57
+00:04:49,000 --> 00:04:55,000
+Let's understand how broken access control is connected with broken object level authorization.
+
+58
+00:04:56,000 --> 00:05:04,000
+The OWASp top ten is a widely recognized list of the top ten most critical security risks to web applications.
+
+59
+00:05:05,000 --> 00:05:12,000
+Broken Access Control ranks prominently on this list due to its significant impact on data confidentiality,
+
+60
+00:05:12,000 --> 00:05:14,000
+integrity, and availability.
+
+61
+00:05:14,000 --> 00:05:20,000
+Key points from the OWASp top ten 2021 regarding Broken Access Control include.
+
+62
+00:05:21,000 --> 00:05:28,000
+Broken access control refers to vulnerabilities that occur when restrictions on what authenticated users
+
+63
+00:05:28,000 --> 00:05:31,000
+are allowed to do are not properly enforced.
+
+64
+00:05:32,000 --> 00:05:37,000
+This includes both vertical and horizontal access control issues.
+
+65
+00:05:38,000 --> 00:05:45,000
+Exploitation of broken access control can lead to unauthorized data access, modification or deletion,
+
+66
+00:05:45,000 --> 00:05:52,000
+allowing attackers to bypass authorization mechanisms and perform actions outside their intended scope.
+
+67
+00:05:53,000 --> 00:05:59,000
+Issues typically arise due to improper configuration, insufficient validation of user permissions,
+
+68
+00:05:59,000 --> 00:06:03,000
+or weaknesses in how access control rules are implemented and enforced.
+
+69
+00:06:04,000 --> 00:06:11,000
+Broken object level authorization is closely related to broken access control, and can be seen as a
+
+70
+00:06:11,000 --> 00:06:16,000
+specific instance or subset of this broader vulnerability category.
+
+71
+00:06:16,000 --> 00:06:24,000
+Here's how broken object level authorization relates to and overlaps with broken access control.
+
+72
+00:06:25,000 --> 00:06:32,000
+Broken access control includes a wide range of access control issues, including both overarching authorization
+
+73
+00:06:32,000 --> 00:06:36,000
+floors and more granular object level authorization.
+
+74
+00:06:36,000 --> 00:06:36,000
+Weaknesses.
+
+75
+00:06:37,000 --> 00:06:44,000
+Broken object level authorization specifically focuses on vulnerabilities where APIs fail to enforce
+
+76
+00:06:44,000 --> 00:06:50,000
+proper access controls at the level of individual data objects, for example records files.
+
+77
+00:06:50,000 --> 00:06:51,000
+Resource.
+
+78
+00:06:52,000 --> 00:06:58,000
+This often involves scenarios where direct object references or predictable identifiers are exposed
+
+79
+00:06:58,000 --> 00:07:02,000
+without adequate validation or authorization checks.
+
+80
+00:07:02,000 --> 00:07:10,000
+While broken access control addresses systemic access control failures across an application, broken
+
+81
+00:07:10,000 --> 00:07:17,000
+object level authorization vulnerabilities typically manifest in specific instances where object level
+
+82
+00:07:17,000 --> 00:07:19,000
+permissions are not correctly implemented.
+
+83
+00:07:20,000 --> 00:07:27,000
+These vulnerabilities can lead to unauthorized access to sensitive data objects, which is a critical
+
+84
+00:07:27,000 --> 00:07:29,000
+subset of the broader access control issues.
+
+85
+00:07:30,000 --> 00:07:38,000
+Broken access control and broken object level authorization both address critical aspects of application
+
+86
+00:07:38,000 --> 00:07:44,000
+security, but focus on different scopes and vulnerabilities within the application stack.
+
+87
+00:07:45,000 --> 00:07:51,000
+While broken access control tackles broader access control issues across various application interfaces,
+
+88
+00:07:52,000 --> 00:07:59,000
+broken object level authorization hones in on specific vulnerabilities within API endpoints where object
+
+89
+00:07:59,000 --> 00:08:04,000
+level permissions are manipulated or inadequately enforced.
+
+90
+00:08:04,000 --> 00:08:11,000
+Organizations must implement tailored security measures to mitigate both types of vulnerabilities effectively
+
+91
+00:08:11,000 --> 00:08:16,000
+and safeguard the applications against unauthorized access and data breaches.
+
+92
+00:08:17,000 --> 00:08:24,000
+Let's review some real world examples of data breaches due to broken object level authorization.
+
+93
+00:08:24,000 --> 00:08:29,000
+I believe these examples will motivate you to learn this lesson more thoroughly.
+
+94
+00:08:30,000 --> 00:08:31,000
+Broken object level.
+
+95
+00:08:31,000 --> 00:08:38,000
+authorization vulnerabilities have been implicated in several high profile data breaches, underscoring
+
+96
+00:08:38,000 --> 00:08:41,000
+their significance in compromising data security.
+
+97
+00:08:41,000 --> 00:08:43,000
+Here are some real world examples.
+
+98
+00:08:44,000 --> 00:08:46,000
+USPS data breach.
+
+99
+00:08:46,000 --> 00:08:53,000
+In 2014, the United States Postal Service suffered a significant data breach attributed to broken object
+
+100
+00:08:53,000 --> 00:08:56,000
+level authorization vulnerabilities.
+
+101
+00:08:56,000 --> 00:09:05,000
+Attackers exploited weaknesses in Usps's API endpoints, allowing them to manipulate object IDs to access
+
+102
+00:09:05,000 --> 00:09:08,000
+sensitive information belonging to millions of users.
+
+103
+00:09:09,000 --> 00:09:15,000
+The breach exposed personal data, including addresses, tracking information, and other confidential
+
+104
+00:09:15,000 --> 00:09:19,000
+details affecting a vast number of USPS customers.
+
+105
+00:09:20,000 --> 00:09:22,000
+Facebook data breach.
+
+106
+00:09:23,000 --> 00:09:29,000
+Facebook experienced a broken object level authorization related data breach in 2018.
+
+107
+00:09:29,000 --> 00:09:36,000
+Attackers exploited a flaw in Facebook's API that allowed them to access users private photos without
+
+108
+00:09:36,000 --> 00:09:38,000
+proper authorization.
+
+109
+00:09:39,000 --> 00:09:45,000
+Millions of users private photos were exposed, leading to privacy concerns and reputational damage
+
+110
+00:09:45,000 --> 00:09:46,000
+for Facebook.
+
+111
+00:09:47,000 --> 00:09:49,000
+Equifax data breach.
+
+112
+00:09:50,000 --> 00:09:57,000
+In 2017, Equifax, one of the largest credit reporting agencies in the US, suffered a massive data
+
+113
+00:09:57,000 --> 00:09:58,000
+breach.
+
+114
+00:09:58,000 --> 00:10:05,000
+The breach was due to a combination of factors, including broken object level authorization, vulnerabilities
+
+115
+00:10:05,000 --> 00:10:14,000
+in their web application, Personal and financial information of approximately 147 million consumers
+
+116
+00:10:14,000 --> 00:10:19,000
+was compromised, leading to widespread identity theft and financial fraud.
+
+117
+00:10:20,000 --> 00:10:26,000
+As you may already understand, violation of security rules and not following best practices that will
+
+118
+00:10:26,000 --> 00:10:32,000
+help to prevent broken object level authorization may cause different negative consequences.
+
+119
+00:10:33,000 --> 00:10:35,000
+Let's review some of them.
+
+120
+00:10:35,000 --> 00:10:37,000
+Financial losses.
+
+121
+00:10:37,000 --> 00:10:44,000
+Data breaches resulting from broken object level authorization vulnerabilities can lead to significant
+
+122
+00:10:44,000 --> 00:10:47,000
+financial consequences for organizations.
+
+123
+00:10:48,000 --> 00:10:56,000
+This includes costs associated with incident response, regulatory fines, for example, GDPR, CcpA,
+
+124
+00:10:56,000 --> 00:11:00,000
+and legal fees stemming from lawsuits filed by affected users.
+
+125
+00:11:01,000 --> 00:11:03,000
+Reputational damage.
+
+126
+00:11:03,000 --> 00:11:08,000
+Organizations may suffer long term damage to their reputation and trustworthiness.
+
+127
+00:11:09,000 --> 00:11:15,000
+Customers may lose confidence in the organization's ability to protect their data, leading to churn
+
+128
+00:11:15,000 --> 00:11:18,000
+and difficulty acquiring new customers.
+
+129
+00:11:19,000 --> 00:11:21,000
+Legal and regulatory consequences.
+
+130
+00:11:22,000 --> 00:11:28,000
+Organizations found negligent in protecting user data can face severe penalties under data protection
+
+131
+00:11:28,000 --> 00:11:29,000
+laws.
+
+132
+00:11:30,000 --> 00:11:36,000
+Compliance failures can result in fines, sanctions, and mandated corrective actions.
+
+133
+00:11:37,000 --> 00:11:39,000
+Impact on users.
+
+134
+00:11:39,000 --> 00:11:43,000
+For individuals, the consequences of data breaches can be profound.
+
+135
+00:11:44,000 --> 00:11:50,000
+They may experience identity theft, financial fraud, or personal embarrassment if sensitive information
+
+136
+00:11:50,000 --> 00:11:51,000
+is exposed.
+
+137
+00:11:52,000 --> 00:11:58,000
+Restoring one's identity and financial security can be a lengthy and stressful process.
+
+138
+00:11:59,000 --> 00:12:06,000
+Operational disruption remediation efforts following a data breach can disrupt normal business operations.
+
+139
+00:12:06,000 --> 00:12:13,000
+This includes dedicating resources to investigate the breach, implement security fixes, and communicate
+
+140
+00:12:13,000 --> 00:12:14,000
+with affected users.
+
+141
+00:12:15,000 --> 00:12:21,000
+Let's now review the most common insecure coding practices that leads to broken object level authorization.
+
+142
+00:12:21,000 --> 00:12:24,000
+You need to know them in order to avoid them.
+
+143
+00:12:25,000 --> 00:12:27,000
+Insufficient input validation.
+
+144
+00:12:27,000 --> 00:12:35,000
+Failure to properly validate and sanitize input parameters such as object IDs or parameters in API requests.
+
+145
+00:12:36,000 --> 00:12:42,000
+Attackers can manipulate these inputs to access unauthorized data objects or perform actions beyond
+
+146
+00:12:42,000 --> 00:12:44,000
+the authorized scope.
+
+147
+00:12:45,000 --> 00:12:47,000
+Predictable object identifiers.
+
+148
+00:12:47,000 --> 00:12:51,000
+Using predictable or sequential identifiers, for example.
+
+149
+00:12:51,000 --> 00:12:54,000
+Incremental IDs for data objects.
+
+150
+00:12:55,000 --> 00:13:02,000
+Attackers can guess or enumerate object IDs to access sensitive data or resources that should be restricted.
+
+151
+00:13:03,000 --> 00:13:05,000
+Lack of proper access controls.
+
+152
+00:13:06,000 --> 00:13:10,000
+Failure to implement and enforce adequate access controls at the object level.
+
+153
+00:13:11,000 --> 00:13:17,000
+Users may be able to perform operations on data objects they should not have access to, leading to
+
+154
+00:13:17,000 --> 00:13:20,000
+data breaches or unauthorized modifications.
+
+155
+00:13:21,000 --> 00:13:23,000
+Improper use of permissions and roles.
+
+156
+00:13:24,000 --> 00:13:29,000
+Incorrectly assigning or checking permissions and roles for accessing data objects.
+
+157
+00:13:29,000 --> 00:13:36,000
+Users may exploit these misconfigurations to escalate privileges or access data they are not authorised
+
+158
+00:13:36,000 --> 00:13:37,000
+to see or modify.
+
+159
+00:13:39,000 --> 00:13:45,000
+Let's also review common flaws in authorization controls that are often root causes of broken object
+
+160
+00:13:45,000 --> 00:13:47,000
+level authorization vulnerabilities.
+
+161
+00:13:48,000 --> 00:13:55,000
+Overly permissive access policies defining access policies that are too broad or permissive, granting
+
+162
+00:13:55,000 --> 00:14:03,000
+users more access than necessary increases the risk of unauthorized access and potential data breaches.
+
+163
+00:14:03,000 --> 00:14:07,000
+As users can perform actions they should not be able to.
+
+164
+00:14:08,000 --> 00:14:11,000
+Failure to enforce principle of least privilege.
+
+165
+00:14:12,000 --> 00:14:18,000
+Allowing users or processes to access resources with more privileges than needed to perform their tasks,
+
+166
+00:14:19,000 --> 00:14:27,000
+increases the attack surface and potential impact of security incidents, as attackers can exploit these
+
+167
+00:14:27,000 --> 00:14:28,000
+elevated privileges.
+
+168
+00:14:29,000 --> 00:14:32,000
+Inadequate validation of user sessions and tokens.
+
+169
+00:14:33,000 --> 00:14:36,000
+Failing to validate user sessions or tokens properly.
+
+170
+00:14:36,000 --> 00:14:41,000
+Allowing attackers to forge or manipulate tokens to gain unauthorized access.
+
+171
+00:14:42,000 --> 00:14:49,000
+Users may access data or perform actions they are not authorized for compromising data integrity and
+
+172
+00:14:49,000 --> 00:14:50,000
+confidentiality.
+
+173
+00:14:51,000 --> 00:14:55,000
+Weak authentication and authorization mechanisms.
+
+174
+00:14:56,000 --> 00:15:03,000
+Using weak or outdated authentication and authorization methods that are susceptible to exploitation,
+
+175
+00:15:03,000 --> 00:15:11,000
+allows attackers to bypass security measures and gain unauthorized access to sensitive data or resources.
+
+176
+00:15:12,000 --> 00:15:18,000
+Addressing the root causes of broken object level authorization vulnerabilities requires implementing
+
+177
+00:15:18,000 --> 00:15:24,000
+robust coding practices through input validation and stringent access control mechanisms.
+
+178
+00:15:24,000 --> 00:15:30,000
+By adopting secure coding principles and continuously auditing and updating authorization controls,
+
+179
+00:15:30,000 --> 00:15:37,000
+organizations can significantly reduce the risk of broken object level authorization vulnerabilities
+
+180
+00:15:37,000 --> 00:15:43,000
+and enhance the overall security posture of their applications and APIs.
+
diff --git a/74 - OWASP API Security Top 10 2023/003 API12023 Broken Object Level Authorization - Part 2 (Practice)_en.srt b/74 - OWASP API Security Top 10 2023/003 API12023 Broken Object Level Authorization - Part 2 (Practice)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..dbfe84bfedcba8d95b0b8a1560bf07dbf0925a82
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/003 API12023 Broken Object Level Authorization - Part 2 (Practice)_en.srt
@@ -0,0 +1,652 @@
+1
+00:00:02,000 --> 00:00:08,000
+Specially for this lesson, I prepared a demo of broken object level authorization vulnerability.
+
+2
+00:00:09,000 --> 00:00:11,000
+Together we will learn how we can fix it.
+
+3
+00:00:12,000 --> 00:00:17,000
+So let me start screen sharing all source code examples that you will see in the lesson.
+
+4
+00:00:17,000 --> 00:00:20,000
+You can find in attachments to the video.
+
+5
+00:00:20,000 --> 00:00:26,000
+And just a reminder in case you will have any questions related to the lesson, don't wait.
+
+6
+00:00:26,000 --> 00:00:30,000
+Post your questions below the video and I will be happy to answer.
+
+7
+00:00:31,000 --> 00:00:34,000
+So we are going to review the problem statement.
+
+8
+00:00:34,000 --> 00:00:40,000
+First I will show you vulnerable example first and then we will review solution and you will learn how
+
+9
+00:00:40,000 --> 00:00:43,000
+to avoid broken object level authorization vulnerability.
+
+10
+00:00:44,000 --> 00:00:49,000
+If you are a student of my course Java from zero to first job, then you are already aware that during
+
+11
+00:00:49,000 --> 00:00:51,000
+the course we develop online.
+
+12
+00:00:51,000 --> 00:00:53,000
+Shop from scratch.
+
+13
+00:00:53,000 --> 00:00:57,000
+But don't worry, I will give you a context before this example.
+
+14
+00:00:57,000 --> 00:01:04,000
+So imagine that you develop e-commerce application online shop and you are in progress of implementation
+
+15
+00:01:04,000 --> 00:01:06,000
+of API for your product entity.
+
+16
+00:01:07,000 --> 00:01:14,000
+For example, you need to introduce this API for another service or another app to manage your products
+
+17
+00:01:14,000 --> 00:01:15,000
+via API.
+
+18
+00:01:16,000 --> 00:01:19,000
+Let's review example of the servlet line by line.
+
+19
+00:01:19,000 --> 00:01:26,000
+The annotation at the top of the servlet class designates it as a servlet, and maps it to a specific
+
+20
+00:01:26,000 --> 00:01:27,000
+URL pattern.
+
+21
+00:01:28,000 --> 00:01:34,000
+This means that any request to this URL pattern will be handled by the servlet class.
+
+22
+00:01:35,000 --> 00:01:42,000
+The class itself extends HTTP servlet, which is a base class for handling HTTP requests in Java.
+
+23
+00:01:43,000 --> 00:01:48,000
+By extending this class, it can override methods like Doget to handle get requests.
+
+24
+00:01:49,000 --> 00:01:55,000
+Inside the class, there is an instance variable of type product facade which is used to interact with
+
+25
+00:01:55,000 --> 00:01:56,000
+the product data.
+
+26
+00:01:57,000 --> 00:02:01,000
+You can check details of product facade later and ask me if you have any questions.
+
+27
+00:02:01,000 --> 00:02:08,000
+But in general, this is just an implementation of facade pattern that simplify our interaction with
+
+28
+00:02:08,000 --> 00:02:09,000
+product entity.
+
+29
+00:02:10,000 --> 00:02:17,000
+This variable is initialized to an instance of default product facade through a method that implements
+
+30
+00:02:17,000 --> 00:02:19,000
+the singleton pattern.
+
+31
+00:02:19,000 --> 00:02:26,000
+We don't have any inversion of control container in this example, so I implemented singleton pattern
+
+32
+00:02:26,000 --> 00:02:27,000
+for some entities.
+
+33
+00:02:27,000 --> 00:02:32,000
+The Doget method is overridden to handle http get requests.
+
+34
+00:02:32,000 --> 00:02:38,000
+It takes two parameters, one representing the request and one representing the response.
+
+35
+00:02:39,000 --> 00:02:46,000
+Inside this method, the product ID is extracted from the request parameters and converted from a string
+
+36
+00:02:46,000 --> 00:02:47,000
+to an integer.
+
+37
+00:02:48,000 --> 00:02:53,000
+The product facade is then used to fetch a product based on the product id.
+
+38
+00:02:54,000 --> 00:02:58,000
+Here is the first alarm I extract product by ID.
+
+39
+00:02:58,000 --> 00:03:01,000
+This is not string, this is integer id.
+
+40
+00:03:02,000 --> 00:03:06,000
+Most likely all IDs goes in the sequential order one after another.
+
+41
+00:03:07,000 --> 00:03:12,000
+That is the first thing that hackers think when they see this API interface.
+
+42
+00:03:13,000 --> 00:03:19,000
+If you are a student of Udemy platform and if you will be very attentive, even Udemy used sequential
+
+43
+00:03:19,000 --> 00:03:21,000
+IDs for different resources.
+
+44
+00:03:21,000 --> 00:03:26,000
+I hope that by moment when you watch this video, they will fix this.
+
+45
+00:03:26,000 --> 00:03:30,000
+But still, it is a potential security vulnerability.
+
+46
+00:03:30,000 --> 00:03:37,000
+Just a reminder that all attempts of hacking are illegal, so please don't even try to do some attempts.
+
+47
+00:03:38,000 --> 00:03:43,000
+We are learning all this information just to learn by example how to avoid potential vulnerabilities.
+
+48
+00:03:44,000 --> 00:03:49,000
+And now you learned that having sequential IDs for resources is not the best practice.
+
+49
+00:03:50,000 --> 00:03:52,000
+So what do we have next?
+
+50
+00:03:52,000 --> 00:03:57,000
+If a product is found, it writes the product's information to the response.
+
+51
+00:03:58,000 --> 00:04:06,000
+If no product is found, it sends a 404 error response indicating that the product was not found.
+
+52
+00:04:06,000 --> 00:04:08,000
+Seems like okay for you?
+
+53
+00:04:08,000 --> 00:04:09,000
+Not at all.
+
+54
+00:04:10,000 --> 00:04:15,000
+What if during a malicious attack, somebody would read all product details, including products that
+
+55
+00:04:15,000 --> 00:04:17,000
+are not published?
+
+56
+00:04:17,000 --> 00:04:21,000
+Or even worse, what if this wouldn't be just read operation?
+
+57
+00:04:22,000 --> 00:04:28,000
+What if this would be delete operation and hacker can get opportunity to delete all products in your
+
+58
+00:04:28,000 --> 00:04:31,000
+shop simply by sending multiple requests.
+
+59
+00:04:31,000 --> 00:04:32,000
+Just change an ID.
+
+60
+00:04:33,000 --> 00:04:38,000
+Let me show you in the browser how easily you can get access to product resource.
+
+61
+00:04:39,000 --> 00:04:42,000
+So this application is deployed on my localhost.
+
+62
+00:04:43,000 --> 00:04:45,000
+Imagine I found out the resource name.
+
+63
+00:04:45,000 --> 00:04:52,000
+It can be relatively simple either by using the web resource and just by being attentive, navigating
+
+64
+00:04:52,000 --> 00:04:59,000
+between pages, or exploring network tab in Google Chrome DevTools details to learn which requests are
+
+65
+00:04:59,000 --> 00:05:01,000
+sent and different other methods.
+
+66
+00:05:02,000 --> 00:05:09,000
+This is more related to API testing, and I had a separate section about API testing in my course Java
+
+67
+00:05:09,000 --> 00:05:10,000
+from zero to first job.
+
+68
+00:05:10,000 --> 00:05:14,000
+Let's stick to agenda of the lesson and continue.
+
+69
+00:05:14,000 --> 00:05:20,000
+So I just sent a request to a resource with request parameter product ID equal to one.
+
+70
+00:05:21,000 --> 00:05:23,000
+And here is product information.
+
+71
+00:05:24,000 --> 00:05:29,000
+What if I would change a year just to the next ID that pops up in my mind?
+
+72
+00:05:29,000 --> 00:05:32,000
+Let me change ID to two.
+
+73
+00:05:33,000 --> 00:05:36,000
+What if I would send requests to resource with product ID three?
+
+74
+00:05:37,000 --> 00:05:39,000
+That is jackpot.
+
+75
+00:05:39,000 --> 00:05:46,000
+The only thing that is left for me in such case is to create a program that will send requests for all
+
+76
+00:05:46,000 --> 00:05:47,000
+integers.
+
+77
+00:05:47,000 --> 00:05:49,000
+Parse response.
+
+78
+00:05:49,000 --> 00:05:50,000
+And that's it.
+
+79
+00:05:50,000 --> 00:05:52,000
+Information is stolen.
+
+80
+00:05:53,000 --> 00:05:59,000
+Another problem with this code that during the access to resource, we don't check user's authorization
+
+81
+00:05:59,000 --> 00:06:01,000
+to access this resource.
+
+82
+00:06:01,000 --> 00:06:04,000
+In Java, this can be done very simply.
+
+83
+00:06:04,000 --> 00:06:11,000
+There is a robust and efficient spring security framework that can allow you to configure authorization
+
+84
+00:06:11,000 --> 00:06:13,000
+rules for different resources.
+
+85
+00:06:13,000 --> 00:06:19,000
+In this case, you can see that in code no authorization checks present.
+
+86
+00:06:19,000 --> 00:06:25,000
+Let me now open another file and I will show you how you can avoid broken object level authorization
+
+87
+00:06:25,000 --> 00:06:26,000
+vulnerabilities.
+
+88
+00:06:27,000 --> 00:06:29,000
+The file is called secure product servlet.
+
+89
+00:06:30,000 --> 00:06:31,000
+It is also servlet.
+
+90
+00:06:31,000 --> 00:06:34,000
+We are going to use product facade in this example too.
+
+91
+00:06:34,000 --> 00:06:37,000
+So we need to initialize it here too.
+
+92
+00:06:38,000 --> 00:06:41,000
+But do get method is written in a little bit different way.
+
+93
+00:06:42,000 --> 00:06:45,000
+First of all I changed request parameter name.
+
+94
+00:06:45,000 --> 00:06:51,000
+This time it will not be product ID it will be product global unique identifier.
+
+95
+00:06:51,000 --> 00:06:55,000
+Another difference I want to extract logged in user from the session.
+
+96
+00:06:56,000 --> 00:07:02,000
+Basically, when the user will log in into our application, I will put user object into the session.
+
+97
+00:07:02,000 --> 00:07:06,000
+There are different authentication and authorization mechanisms.
+
+98
+00:07:07,000 --> 00:07:12,000
+This is just one of the possible ways to implement this in the simplified and transparent manner.
+
+99
+00:07:12,000 --> 00:07:15,000
+That is the best for online lesson.
+
+100
+00:07:16,000 --> 00:07:22,000
+Of course, there are dozens of more complicated ways to implement authorization and authentication.
+
+101
+00:07:22,000 --> 00:07:28,000
+So if you know other way or you use different programming language or other frameworks, feel free to
+
+102
+00:07:28,000 --> 00:07:29,000
+proceed with those.
+
+103
+00:07:29,000 --> 00:07:31,000
+That is totally fine.
+
+104
+00:07:31,000 --> 00:07:33,000
+So I extracted logged in user.
+
+105
+00:07:33,000 --> 00:07:35,000
+We will use it later.
+
+106
+00:07:35,000 --> 00:07:37,000
+Let's see what is going next.
+
+107
+00:07:38,000 --> 00:07:48,000
+I extract product using not ID but global unique identifier that is long string value 32 character hexadecimal
+
+108
+00:07:48,000 --> 00:07:48,000
+string.
+
+109
+00:07:49,000 --> 00:07:55,000
+So it will take some time of hacker to guess it and it will not be super fun.
+
+110
+00:07:55,000 --> 00:08:02,000
+Hacker would require super computer to hack all the database of products you will see soon how it looks
+
+111
+00:08:02,000 --> 00:08:02,000
+like.
+
+112
+00:08:03,000 --> 00:08:09,000
+Then I check that product is not null and that product name is not null.
+
+113
+00:08:09,000 --> 00:08:16,000
+That is related with the specifics of implementation, because I try to avoid returned null values to
+
+114
+00:08:16,000 --> 00:08:18,000
+avoid null pointer exception.
+
+115
+00:08:19,000 --> 00:08:25,000
+I also try to avoid of using optional API in Java because it has its own drawbacks.
+
+116
+00:08:25,000 --> 00:08:28,000
+But anyway, this is a topic for a separate lesson.
+
+117
+00:08:29,000 --> 00:08:33,000
+What I prefer to do time to time is to return empty objects.
+
+118
+00:08:34,000 --> 00:08:38,000
+That's why I need these checks to check if object is empty or not.
+
+119
+00:08:39,000 --> 00:08:43,000
+So if there is no object, we just send error.
+
+120
+00:08:43,000 --> 00:08:45,000
+That product is not found.
+
+121
+00:08:46,000 --> 00:08:50,000
+If we found this product then I check which row has logged in.
+
+122
+00:08:50,000 --> 00:08:51,000
+User.
+
+123
+00:08:51,000 --> 00:08:58,000
+In this particular example, I allow only to users with admin role to get access to product details
+
+124
+00:08:58,000 --> 00:08:59,000
+via API.
+
+125
+00:09:00,000 --> 00:09:07,000
+And in case logged in user has admin role only, in this case it can see the product details.
+
+126
+00:09:07,000 --> 00:09:09,000
+Otherwise I return 403.
+
+127
+00:09:09,000 --> 00:09:11,000
+Error code access is forbidden.
+
+128
+00:09:11,000 --> 00:09:15,000
+The client is not permitted access to the resource and that's it.
+
+129
+00:09:16,000 --> 00:09:22,000
+So in this particular case, I used just few techniques to avoid broken object level authorization.
+
+130
+00:09:22,000 --> 00:09:30,000
+I used non predictable unique identifiers and I added zero authorization check before granting access
+
+131
+00:09:30,000 --> 00:09:31,000
+to a resource.
+
+132
+00:09:32,000 --> 00:09:37,000
+In this lesson, we'll learn even more ways how to avoid broken object level authorization.
+
+133
+00:09:37,000 --> 00:09:41,000
+But in this particular example, I applied this tool.
+
+134
+00:09:41,000 --> 00:09:44,000
+It is time to demo you how it works.
+
+135
+00:09:44,000 --> 00:09:46,000
+Let me open browser now.
+
+136
+00:09:47,000 --> 00:09:49,000
+So let's start from easy case.
+
+137
+00:09:49,000 --> 00:09:52,000
+Let's imagine I learned resource URL.
+
+138
+00:09:52,000 --> 00:09:58,000
+I try to send request with the value of product Guid request parameter equal to one.
+
+139
+00:09:59,000 --> 00:10:02,000
+So I receive 404 error code.
+
+140
+00:10:02,000 --> 00:10:04,000
+Resource is not found.
+
+141
+00:10:05,000 --> 00:10:06,000
+Cool.
+
+142
+00:10:06,000 --> 00:10:09,000
+It is already less predictable than in previous case.
+
+143
+00:10:09,000 --> 00:10:10,000
+Don't you think so?
+
+144
+00:10:10,000 --> 00:10:13,000
+Let's imagine that I managed to hack all products.
+
+145
+00:10:13,000 --> 00:10:15,000
+Unique identifiers.
+
+146
+00:10:15,000 --> 00:10:17,000
+Okay, good for me.
+
+147
+00:10:17,000 --> 00:10:21,000
+Let's try to send requests using different request parameter value.
+
+148
+00:10:21,000 --> 00:10:23,000
+Can you see this value?
+
+149
+00:10:24,000 --> 00:10:30,000
+This is 32 character hexadecimal strings that I generate for each product during its creation.
+
+150
+00:10:30,000 --> 00:10:35,000
+What I will receive now of course access is forbidden status code.
+
+151
+00:10:36,000 --> 00:10:41,000
+Product is found, but I can't access it because I don't have enough authorization rights.
+
+152
+00:10:42,000 --> 00:10:49,000
+So what I need to do to be able to read this product, I need login with admin user credentials because
+
+153
+00:10:49,000 --> 00:10:55,000
+as you remember, according to our logic, only users with admin role can get access to this resource.
+
+154
+00:10:56,000 --> 00:11:00,000
+So let me navigate to the login page of my application.
+
+155
+00:11:00,000 --> 00:11:04,000
+Here I need to enter credentials of admin user.
+
+156
+00:11:04,000 --> 00:11:06,000
+It will take few seconds.
+
+157
+00:11:07,000 --> 00:11:10,000
+Admin at Test.com and password.
+
+158
+00:11:11,000 --> 00:11:14,000
+Okay, now I'm logged in as an admin user.
+
+159
+00:11:15,000 --> 00:11:15,000
+Cool.
+
+160
+00:11:16,000 --> 00:11:19,000
+Let's check access to the same resource one more time.
+
+161
+00:11:20,000 --> 00:11:21,000
+And here we go.
+
+162
+00:11:21,000 --> 00:11:24,000
+Now we finally can access it.
+
+163
+00:11:24,000 --> 00:11:30,000
+So that's how you can avoid broken object level authorization vulnerabilities in your code.
+
diff --git a/74 - OWASP API Security Top 10 2023/003 Source-code-examples-from-the-lesson.url b/74 - OWASP API Security Top 10 2023/003 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..a693db7baec4ea05cc82099fa96b0257ce810938
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/003 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/commit/6f7f9cce32e4a535ac0b21deab0a4ccaa8d87bc4
\ No newline at end of file
diff --git a/74 - OWASP API Security Top 10 2023/004 API12023 Broken Object Level Authorization - Part 3 (Zero-Trust, UUIDs)_en.srt b/74 - OWASP API Security Top 10 2023/004 API12023 Broken Object Level Authorization - Part 3 (Zero-Trust, UUIDs)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..facd1346e228debafd8e9dfbd1bfbb468e6ed7aa
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/004 API12023 Broken Object Level Authorization - Part 3 (Zero-Trust, UUIDs)_en.srt
@@ -0,0 +1,964 @@
+1
+00:00:02,000 --> 00:00:04,000
+But that's not all for today.
+
+2
+00:00:05,000 --> 00:00:11,000
+Let me summarize prevention mechanisms that I used in this example, and also share with you some more
+
+3
+00:00:11,000 --> 00:00:16,000
+advanced techniques of how you can prevent broken object level authorization.
+
+4
+00:00:17,000 --> 00:00:21,000
+Let's talk about the importance of well controlled authorization policies.
+
+5
+00:00:22,000 --> 00:00:28,000
+You saw how I implemented authorization check during the access to resource in code.
+
+6
+00:00:28,000 --> 00:00:30,000
+But let's review this in details.
+
+7
+00:00:31,000 --> 00:00:36,000
+To begin with, enforcing the principle of least privilege is paramount.
+
+8
+00:00:36,000 --> 00:00:43,000
+This principle dictates that users and systems should only have the minimum level of access necessary
+
+9
+00:00:43,000 --> 00:00:44,000
+to perform their tasks.
+
+10
+00:00:45,000 --> 00:00:51,000
+By implementing this principle, we significantly reduce the attack surface, limiting the potential
+
+11
+00:00:51,000 --> 00:00:55,000
+damage that can occur if a user account is compromised.
+
+12
+00:00:56,000 --> 00:01:02,000
+When we grant only the necessary permissions, we minimize the risk of unauthorized access to sensitive
+
+13
+00:01:02,000 --> 00:01:04,000
+data and functions.
+
+14
+00:01:04,000 --> 00:01:11,000
+In addition to ensuring minimal access, well controlled authorization policies are vital in preventing
+
+15
+00:01:11,000 --> 00:01:12,000
+unauthorized access.
+
+16
+00:01:13,000 --> 00:01:21,000
+Such policies ensure that users can only access data and resources they are explicitly allowed to.
+
+17
+00:01:21,000 --> 00:01:28,000
+This is crucial for maintaining data confidentiality and integrity, as it prevents unauthorized users
+
+18
+00:01:28,000 --> 00:01:33,000
+from viewing, modifying, or deleting data that does not belong to them.
+
+19
+00:01:33,000 --> 00:01:40,000
+Moreover, many industries are subject to strict regulations and standards that require robust access
+
+20
+00:01:40,000 --> 00:01:45,000
+control measures such as GDPR, HIPAA and PCI.
+
+21
+00:01:45,000 --> 00:01:46,000
+DSS.
+
+22
+00:01:47,000 --> 00:01:53,000
+Well controlled authorization policies help organizations meet these compliance requirements.
+
+23
+00:01:53,000 --> 00:01:58,000
+Avoiding legal penalties and enhancing their reputation for security and reliability.
+
+24
+00:01:59,000 --> 00:02:05,000
+Lastly, effective authorization policies play a significant role in minimizing security risks.
+
+25
+00:02:06,000 --> 00:02:12,000
+They help mitigate various security threats, including insider threats, privilege escalation, and
+
+26
+00:02:12,000 --> 00:02:14,000
+unauthorized data access.
+
+27
+00:02:15,000 --> 00:02:21,000
+By enforcing robust authorization controls, we can reduce the likelihood of security incidents and
+
+28
+00:02:21,000 --> 00:02:24,000
+minimize their potential impact.
+
+29
+00:02:24,000 --> 00:02:27,000
+Now, let's move on to the next crucial aspect.
+
+30
+00:02:27,000 --> 00:02:31,000
+Continuous testing and validation of authorization logic.
+
+31
+00:02:32,000 --> 00:02:36,000
+Regular audits and reviews of authorization logic are essential.
+
+32
+00:02:36,000 --> 00:02:44,000
+By regularly auditing and reviewing, we can identify and address potential vulnerabilities or misconfigurations.
+
+33
+00:02:44,000 --> 00:02:51,000
+Continuous audits ensure that authorization policies remain effective and aligned with the organization's
+
+34
+00:02:51,000 --> 00:02:53,000
+security requirements and business needs.
+
+35
+00:02:54,000 --> 00:02:57,000
+Furthermore, implementing automated testing tools is crucial.
+
+36
+00:02:58,000 --> 00:03:05,000
+Automated testing helps regularly evaluate authorization logic to detect flaws and inconsistencies that
+
+37
+00:03:05,000 --> 00:03:07,000
+could be exploited by attackers.
+
+38
+00:03:07,000 --> 00:03:13,000
+This approach provides consistent and thorough validation of authorization mechanisms, reducing the
+
+39
+00:03:13,000 --> 00:03:18,000
+likelihood of human error and ensuring comprehensive coverage.
+
+40
+00:03:19,000 --> 00:03:22,000
+Additionally, dynamic testing in real time is important.
+
+41
+00:03:22,000 --> 00:03:27,000
+This involves evaluating authorization logic during the application's runtime.
+
+42
+00:03:27,000 --> 00:03:30,000
+Simulating real world scenarios and attack vectors.
+
+43
+00:03:31,000 --> 00:03:38,000
+Real time testing helps identify vulnerabilities that may not be apparent during static code analysis,
+
+44
+00:03:38,000 --> 00:03:42,000
+providing a more accurate assessment of the system's security posture.
+
+45
+00:03:43,000 --> 00:03:49,000
+Moreover, conducting regular penetration testing by security experts is invaluable.
+
+46
+00:03:49,000 --> 00:03:55,000
+Penetration testing can uncover complex vulnerabilities that automated tools may miss.
+
+47
+00:03:55,000 --> 00:04:02,000
+This deeper understanding of potential security weaknesses allows organizations to address them proactively,
+
+48
+00:04:03,000 --> 00:04:09,000
+incorporating authorization testing into continuous integration and continuous deployment pipelines
+
+49
+00:04:09,000 --> 00:04:11,000
+is also a best practice.
+
+50
+00:04:11,000 --> 00:04:17,000
+This integration ensures that security checks are performed automatically with every code change.
+
+51
+00:04:18,000 --> 00:04:24,000
+The continuous validation process helps catch and fix authorization issues early in the development
+
+52
+00:04:24,000 --> 00:04:27,000
+cycle, preventing them from reaching production.
+
+53
+00:04:28,000 --> 00:04:34,000
+Finally, encouraging user feedback and monitoring access Access patterns can help identify unusual
+
+54
+00:04:34,000 --> 00:04:37,000
+behavior that may indicate authorization flaws.
+
+55
+00:04:38,000 --> 00:04:43,000
+Proactive monitoring and user feedback allow organizations to respond quickly to potential security
+
+56
+00:04:43,000 --> 00:04:47,000
+incidents and refine authorization policies as needed.
+
+57
+00:04:48,000 --> 00:04:54,000
+By implementing well controlled authorization policies and continuously testing and validating authorization
+
+58
+00:04:54,000 --> 00:05:02,000
+logic, Organizations can minimize the risk of broken object level authorization vulnerabilities and
+
+59
+00:05:02,000 --> 00:05:05,000
+enhance their overall security posture.
+
+60
+00:05:06,000 --> 00:05:12,000
+This proactive approach helps safeguard user data, maintain compliance with regulations, and build
+
+61
+00:05:12,000 --> 00:05:16,000
+trust with customers and stakeholders.
+
+62
+00:05:17,000 --> 00:05:23,000
+Next, let's explore the concept of using random universally unique identifiers, or Uuids.
+
+63
+00:05:24,000 --> 00:05:31,000
+We'll discuss the advantages of Uuids over auto incrementing IDs and the key considerations for implementing
+
+64
+00:05:31,000 --> 00:05:33,000
+Uuids in API ecosystems.
+
+65
+00:05:34,000 --> 00:05:40,000
+Firstly, let's understand the advantages of Uuids over auto incrementing IDs.
+
+66
+00:05:41,000 --> 00:05:46,000
+One of the primary advantages of using Uuids is the unpredictability.
+
+67
+00:05:46,000 --> 00:05:54,000
+Unlike auto incrementing IDs, which follow a predictable sequence, uuids are designed to be random
+
+68
+00:05:54,000 --> 00:05:55,000
+and unique.
+
+69
+00:05:55,000 --> 00:06:02,000
+This randomness makes it exceedingly difficult for malicious actors to guess or predict ID values,
+
+70
+00:06:02,000 --> 00:06:05,000
+significantly enhancing security.
+
+71
+00:06:05,000 --> 00:06:14,000
+Moreover, uuids reduce the risk of enumeration attacks in systems using auto incrementing IDs.
+
+72
+00:06:14,000 --> 00:06:19,000
+Attackers can easily iterate through ID values to access unauthorized resources.
+
+73
+00:06:20,000 --> 00:06:28,000
+However, with IDs, the random nature of the IDs makes such enumeration virtually impossible, thereby
+
+74
+00:06:28,000 --> 00:06:31,000
+protecting sensitive data from unauthorized access.
+
+75
+00:06:31,000 --> 00:06:37,000
+Another significant advantage is the global uniqueness of uuids.
+
+76
+00:06:37,000 --> 00:06:44,000
+Since uuids are generated in a way that ensures they are unique across different systems and databases,
+
+77
+00:06:44,000 --> 00:06:48,000
+they are particularly useful in distributed systems.
+
+78
+00:06:48,000 --> 00:06:54,000
+This global uniqueness allows for seamless integration and data synchronization across various components
+
+79
+00:06:54,000 --> 00:06:59,000
+of an API ecosystem, without the risk of ID collisions.
+
+80
+00:06:59,000 --> 00:07:08,000
+Additionally, Uuids simplified data merging and replication in scenarios where data from multiple sources
+
+81
+00:07:08,000 --> 00:07:15,000
+or databases needs to be merged using auto incrementing ads can lead to conflicts and duplication.
+
+82
+00:07:15,000 --> 00:07:22,000
+Uuids, on the other hand, eliminate these issues by ensuring that each identifier is unique regardless
+
+83
+00:07:22,000 --> 00:07:24,000
+of its origin.
+
+84
+00:07:25,000 --> 00:07:32,000
+Now let's delve into the implementation considerations when integrating Uuids into API ecosystems.
+
+85
+00:07:33,000 --> 00:07:38,000
+Firstly, it's essential to understand the impact on database performance.
+
+86
+00:07:38,000 --> 00:07:46,000
+Uuids are typically longer and more complex than auto incrementing IDs, which can affect indexing and
+
+87
+00:07:46,000 --> 00:07:47,000
+storage efficiency.
+
+88
+00:07:48,000 --> 00:07:55,000
+Therefore, it's crucial to optimize database schemas and indexing strategies to accommodate uuids without
+
+89
+00:07:55,000 --> 00:07:57,000
+compromising performance.
+
+90
+00:07:57,000 --> 00:08:01,000
+Secondly, generating uuids correctly is vital.
+
+91
+00:08:01,000 --> 00:08:06,000
+There are various versions of Uuids, each with different generation algorithms.
+
+92
+00:08:06,000 --> 00:08:11,000
+It's important to choose the appropriate version based on your specific use case.
+
+93
+00:08:11,000 --> 00:08:19,000
+For instance, Uuid version four, which is based on random or pseudo random numbers, is commonly used
+
+94
+00:08:19,000 --> 00:08:22,000
+for ensuring high randomness and uniqueness.
+
+95
+00:08:22,000 --> 00:08:27,000
+Moreover, consider the format and representation of uuids.
+
+96
+00:08:27,000 --> 00:08:34,000
+While the standard format includes hyphens and can be quite long, you may opt to use a more compact
+
+97
+00:08:34,000 --> 00:08:40,000
+representation, such as base64 encoding, to reduce storage requirements and improve readability.
+
+98
+00:08:41,000 --> 00:08:48,000
+However, ensures that any transformations do not compromise the uniqueness and integrity of the uuids.
+
+99
+00:08:49,000 --> 00:08:56,000
+Another critical aspect is ensuring backward compatibility when transitioning from auto incrementing
+
+100
+00:08:56,000 --> 00:08:57,000
+IDs to Uuids.
+
+101
+00:08:58,000 --> 00:09:05,000
+It's important to implement mechanisms that support both types of identifiers during the migration phase.
+
+102
+00:09:06,000 --> 00:09:13,000
+This approach helps prevent disruptions and maintains compatibility with existing systems and processes.
+
+103
+00:09:13,000 --> 00:09:21,000
+Additionally, robust error handling and validation are essential since uuids are typically generated
+
+104
+00:09:21,000 --> 00:09:27,000
+on the client side or by external systems, it's crucial to implement validation checks to ensure that
+
+105
+00:09:27,000 --> 00:09:32,000
+only valid and correctly formatted Uuids are accepted by the API.
+
+106
+00:09:33,000 --> 00:09:40,000
+This step helps prevent potential security issues arising from malformed or tampered uuids.
+
+107
+00:09:41,000 --> 00:09:49,000
+Lastly, consider the implications for logging and debugging uuids being more complex than simple integers,
+
+108
+00:09:49,000 --> 00:09:52,000
+can make logs and debug information harder to read.
+
+109
+00:09:53,000 --> 00:10:00,000
+Implementing tools and practices to handle and interpret Uuids effectively and logs can streamline troubleshooting
+
+110
+00:10:00,000 --> 00:10:02,000
+and enhance operational efficiency.
+
+111
+00:10:02,000 --> 00:10:09,000
+So using random, universally unique identifiers offers significant security and scalability advantages
+
+112
+00:10:09,000 --> 00:10:17,000
+over auto incrementing IDs By understanding and addressing the implementation considerations, organizations
+
+113
+00:10:17,000 --> 00:10:25,000
+can effectively integrate Uuids into their API ecosystems, enhancing security, ensuring global uniqueness,
+
+114
+00:10:25,000 --> 00:10:28,000
+and facilitating seamless data integration.
+
+115
+00:10:28,000 --> 00:10:35,000
+This approach not only protects sensitive data, but also supports the efficient operation of distributed
+
+116
+00:10:35,000 --> 00:10:37,000
+and scalable systems.
+
+117
+00:10:38,000 --> 00:10:44,000
+Let's shift our focus to securing the business logic layer of your applications and APIs.
+
+118
+00:10:44,000 --> 00:10:51,000
+We'll discuss how to identify and mitigate vulnerabilities in this critical layer, and emphasize the
+
+119
+00:10:51,000 --> 00:10:57,000
+importance of rigorous testing beyond what traditional vulnerability scanners can offer.
+
+120
+00:10:58,000 --> 00:11:04,000
+Firstly, let's explore the process of identifying and mitigating vulnerabilities in the business logic
+
+121
+00:11:04,000 --> 00:11:04,000
+layer.
+
+122
+00:11:05,000 --> 00:11:10,000
+The business logic layer is where the core functionalities of your application reside.
+
+123
+00:11:11,000 --> 00:11:18,000
+It encompasses the rules and processes that dictate how data is created, manipulated and managed.
+
+124
+00:11:19,000 --> 00:11:25,000
+This layer is crucial because it directly handles the operations that fulfill business requirements,
+
+125
+00:11:26,000 --> 00:11:31,000
+making it a prime target for attackers looking to exploit logical flaws.
+
+126
+00:11:32,000 --> 00:11:38,000
+Identifying vulnerabilities in the business logic layer requires a thorough understanding of the applications,
+
+127
+00:11:38,000 --> 00:11:41,000
+workflows, and data flows.
+
+128
+00:11:42,000 --> 00:11:48,000
+One effective method is to perform threat modeling by systematically analyzing the application from
+
+129
+00:11:48,000 --> 00:11:55,000
+an attacker's perspective, you can identify potential weaknesses and entry points that could be exploited.
+
+130
+00:11:55,000 --> 00:12:02,000
+This proactive approach helps in uncovering logical flaws that might not be apparent through standard
+
+131
+00:12:02,000 --> 00:12:03,000
+testing methods.
+
+132
+00:12:04,000 --> 00:12:08,000
+Another essential step is to conduct manual code reviews.
+
+133
+00:12:08,000 --> 00:12:15,000
+Automated tools are excellent for identifying common vulnerabilities, but they often miss complex logic
+
+134
+00:12:15,000 --> 00:12:16,000
+issues.
+
+135
+00:12:17,000 --> 00:12:23,000
+Experienced developers and security professionals can scrutinize the business logic to spot flaws that
+
+136
+00:12:23,000 --> 00:12:26,000
+could lead to unauthorized actions or data breaches.
+
+137
+00:12:27,000 --> 00:12:34,000
+Pairing code reviews with pair programming or peer reviews can further enhance the detection of subtle
+
+138
+00:12:34,000 --> 00:12:35,000
+vulnerabilities.
+
+139
+00:12:35,000 --> 00:12:42,000
+Mitigation strategies for business logic vulnerabilities often involve redesigning the affected processes
+
+140
+00:12:42,000 --> 00:12:44,000
+to eliminate the flaws.
+
+141
+00:12:45,000 --> 00:12:49,000
+Implementing robust validation and verification mechanisms is crucial.
+
+142
+00:12:50,000 --> 00:12:57,000
+For example, enforcing strict input validation and output encoding can prevent unauthorized data manipulation
+
+143
+00:12:57,000 --> 00:12:59,000
+and injection attacks.
+
+144
+00:12:59,000 --> 00:13:05,000
+Furthermore, incorporating checks and balances such as multifactor authentication and authorization
+
+145
+00:13:05,000 --> 00:13:10,000
+checks at every step can fortify the business logic layer.
+
+146
+00:13:10,000 --> 00:13:17,000
+Securing the business logic layer is vital for protecting the core functionalities and data of your
+
+147
+00:13:17,000 --> 00:13:24,000
+application by identifying and mitigating vulnerabilities through threat modeling, code reviews, and
+
+148
+00:13:24,000 --> 00:13:31,000
+dynamic testing, and by emphasizing rigorous testing beyond traditional vulnerability scanners.
+
+149
+00:13:31,000 --> 00:13:34,000
+Organizations can ensure robust security.
+
+150
+00:13:34,000 --> 00:13:41,000
+This comprehensive approach not only safeguards the business logic, but also fortifies the entire application
+
+151
+00:13:41,000 --> 00:13:47,000
+against sophisticated attacks, thereby enhancing overall security and resilience.
+
+152
+00:13:48,000 --> 00:13:56,000
+Now let's delve into the Zero Trust security model, an advanced approach to security that can significantly
+
+153
+00:13:56,000 --> 00:14:00,000
+mitigate broken object level authorization vulnerabilities.
+
+154
+00:14:00,000 --> 00:14:07,000
+We'll start with an overview of the Zero Trust security model, and then explore how its principles
+
+155
+00:14:07,000 --> 00:14:12,000
+directly address and mitigate broken object level authorization vulnerabilities.
+
+156
+00:14:13,000 --> 00:14:17,000
+First, let's understand the zero trust security model.
+
+157
+00:14:18,000 --> 00:14:24,000
+The zero trust security model is a strategic approach to cybersecurity that eliminates the concept of
+
+158
+00:14:24,000 --> 00:14:29,000
+trusted internal networks versus untrusted external networks.
+
+159
+00:14:30,000 --> 00:14:38,000
+In a zero trust environment, no entity, whether inside or outside the network, is trusted by default.
+
+160
+00:14:38,000 --> 00:14:45,000
+Instead, every access request must be verified and validated before granting access, regardless of
+
+161
+00:14:45,000 --> 00:14:46,000
+its origin.
+
+162
+00:14:47,000 --> 00:14:51,000
+At the core of zero trust is the principle of never trust, always verify.
+
+163
+00:14:52,000 --> 00:14:59,000
+This means that every access request is subject to strict identity verification, access control, and
+
+164
+00:14:59,000 --> 00:15:00,000
+continuous monitoring.
+
+165
+00:15:01,000 --> 00:15:08,000
+The model is built on several key components, including robust authentication mechanisms, strict authorization
+
+166
+00:15:08,000 --> 00:15:12,000
+policies, and comprehensive logging and monitoring systems.
+
+167
+00:15:13,000 --> 00:15:20,000
+Zero trust architectures typically involve microsegmentation, which divides the network into smaller,
+
+168
+00:15:20,000 --> 00:15:21,000
+isolated segments.
+
+169
+00:15:22,000 --> 00:15:29,000
+Each segment is protected with granular access controls, ensuring that even if one segment is compromised,
+
+170
+00:15:29,000 --> 00:15:33,000
+the attacker cannot easily move laterally within the network.
+
+171
+00:15:34,000 --> 00:15:41,000
+Next, let's explore how zero trust principles mitigate broken object level authorization vulnerabilities.
+
+172
+00:15:42,000 --> 00:15:48,000
+Vulnerabilities occur when unauthorized users gain access to objects they shouldn't be able to access
+
+173
+00:15:48,000 --> 00:15:52,000
+due to improper or insufficient authorization checks.
+
+174
+00:15:53,000 --> 00:15:59,000
+The Zero Trust Security model addresses these vulnerabilities through its rigorous verification and
+
+175
+00:15:59,000 --> 00:16:00,000
+validation processes.
+
+176
+00:16:01,000 --> 00:16:04,000
+Strong authentication and authorization.
+
+177
+00:16:04,000 --> 00:16:12,000
+In a zero trust model, strong authentication mechanisms such as multifactor authentication are enforced
+
+178
+00:16:12,000 --> 00:16:14,000
+for all access requests.
+
+179
+00:16:15,000 --> 00:16:19,000
+This ensures that only legitimate users can access the system.
+
+180
+00:16:19,000 --> 00:16:21,000
+Beyond authentication.
+
+181
+00:16:21,000 --> 00:16:24,000
+Zero trust emphasizes continuous authorization.
+
+182
+00:16:24,000 --> 00:16:31,000
+Each access request is evaluated against the user's role and permissions, ensuring they only access
+
+183
+00:16:31,000 --> 00:16:34,000
+the resources they are authorized to interact with.
+
+184
+00:16:35,000 --> 00:16:37,000
+Least privilege principle.
+
+185
+00:16:37,000 --> 00:16:45,000
+Zero trust strictly enforces the principle of least privilege, granting users the minimum access necessary
+
+186
+00:16:45,000 --> 00:16:46,000
+to perform their tasks.
+
+187
+00:16:47,000 --> 00:16:53,000
+This minimizes the risk of unauthorized access to sensitive objects by implementing role based access
+
+188
+00:16:53,000 --> 00:16:56,000
+control and attribute based access control.
+
+189
+00:16:56,000 --> 00:17:05,000
+Organizations can ensure that users only access objects they are explicitly allowed to, thereby mitigating
+
+190
+00:17:05,000 --> 00:17:08,000
+broken object level authorization vulnerabilities.
+
+191
+00:17:09,000 --> 00:17:11,000
+Continuous monitoring and analytics.
+
+192
+00:17:12,000 --> 00:17:19,000
+Zero trust architectures involve continuous monitoring and analytics to detect and respond to suspicious
+
+193
+00:17:19,000 --> 00:17:21,000
+activities in real time.
+
+194
+00:17:21,000 --> 00:17:28,000
+This constant vigilance ensures that any anomalies, such as unauthorized attempts to access objects,
+
+195
+00:17:29,000 --> 00:17:31,000
+are promptly identified and addressed.
+
+196
+00:17:32,000 --> 00:17:39,000
+Monitoring tools analyze user behavior, flagging any deviations from normal patterns that could indicate
+
+197
+00:17:39,000 --> 00:17:43,000
+a potential broken object level authorization exploit.
+
+198
+00:17:43,000 --> 00:17:45,000
+Micro-segmentation.
+
+199
+00:17:46,000 --> 00:17:53,000
+Micro-segmentation, a key component of zero trust, enhances security by isolating different segments
+
+200
+00:17:53,000 --> 00:17:54,000
+of the network.
+
+201
+00:17:54,000 --> 00:18:01,000
+Each segment has its own access controls, reducing the attack surface and preventing lateral movement.
+
+202
+00:18:02,000 --> 00:18:09,000
+If an attacker compromises one segment, they cannot easily access other segments, limiting the impact
+
+203
+00:18:09,000 --> 00:18:13,000
+of any potential broken object level authorization vulnerability.
+
+204
+00:18:14,000 --> 00:18:19,000
+Explicit verification of access requests in a zero trust environment.
+
+205
+00:18:19,000 --> 00:18:25,000
+Every access request is explicitly verified regardless of where it originates.
+
+206
+00:18:25,000 --> 00:18:32,000
+This means that even internal requests are subjected to the same stringent checks as external ones.
+
+207
+00:18:32,000 --> 00:18:40,000
+By enforcing explicit verification, zero trust ensures that unauthorized access attempts are blocked.
+
+208
+00:18:40,000 --> 00:18:45,000
+Addressing one of the primary causes of broken object level authorization vulnerabilities.
+
+209
+00:18:46,000 --> 00:18:48,000
+Dynamic policy enforcement.
+
+210
+00:18:48,000 --> 00:18:56,000
+Zero trust employs dynamic policy enforcement, adapting access controls based on real time context
+
+211
+00:18:56,000 --> 00:18:57,000
+and risk assessment.
+
+212
+00:18:58,000 --> 00:19:05,000
+Policies are continuously evaluated and updated based on the current threat landscape, user behavior,
+
+213
+00:19:05,000 --> 00:19:07,000
+and other contextual factors.
+
+214
+00:19:08,000 --> 00:19:15,000
+This dynamic approach ensures that access controls remain effective against evolving threats, including
+
+215
+00:19:15,000 --> 00:19:17,000
+broken object level authorization.
+
+216
+00:19:18,000 --> 00:19:25,000
+Implementing the Zero Trust Security model offers a comprehensive and effective way to mitigate broken
+
+217
+00:19:25,000 --> 00:19:31,000
+object level authorization vulnerabilities by enforcing strong authentication and authorization.
+
+218
+00:19:31,000 --> 00:19:34,000
+Adhering to the principle of least privilege.
+
+219
+00:19:34,000 --> 00:19:37,000
+Continuously monitoring for anomalies.
+
+220
+00:19:37,000 --> 00:19:45,000
+Leveraging micro-segmentation and dynamically enforcing access policies, organizations can significantly
+
+221
+00:19:45,000 --> 00:19:47,000
+enhance their security posture.
+
+222
+00:19:47,000 --> 00:19:54,000
+This proactive approach not only addresses broken object level authorization vulnerabilities, but also
+
+223
+00:19:54,000 --> 00:20:01,000
+fortifies the entire security framework, making it resilient against a wide range of cyber threats.
+
+224
+00:20:02,000 --> 00:20:06,000
+That's all what I wanted to explain to you in scope of this lesson.
+
+225
+00:20:06,000 --> 00:20:11,000
+Let's recap what we've learned about broken object level authorization.
+
+226
+00:20:12,000 --> 00:20:16,000
+We explored the definition and importance of object level authorization.
+
+227
+00:20:17,000 --> 00:20:24,000
+You learned about broken object level authorization vulnerabilities, their prevalence in APIs, and
+
+228
+00:20:24,000 --> 00:20:29,000
+their connection to the OWASp top ten and the Broken access control.
+
+229
+00:20:30,000 --> 00:20:37,000
+We discussed real world examples of data breaches caused by broken object level authorization, and
+
+230
+00:20:37,000 --> 00:20:39,000
+the consequences for organizations and users.
+
+231
+00:20:40,000 --> 00:20:47,000
+Together, we examined insecure coding practices leading to broken object level authorization and reviewed
+
+232
+00:20:47,000 --> 00:20:52,000
+code examples with problems and solutions, including an online shop example.
+
+233
+00:20:53,000 --> 00:20:59,000
+I demonstrated how to enforce robust authorization mechanisms and the importance of continuous testing
+
+234
+00:20:59,000 --> 00:21:02,000
+and validation of authorization logic.
+
+235
+00:21:03,000 --> 00:21:09,000
+We covered the implementation of random universally unique identifiers in API ecosystems and securing
+
+236
+00:21:09,000 --> 00:21:11,000
+the business logic layer.
+
+237
+00:21:12,000 --> 00:21:20,000
+Finally, we reviewed the zero Trust security model and how its principles mitigate broken object level
+
+238
+00:21:20,000 --> 00:21:22,000
+authorization vulnerabilities.
+
+239
+00:21:22,000 --> 00:21:24,000
+That's all for this lesson.
+
+240
+00:21:25,000 --> 00:21:27,000
+Thanks a lot for your attention.
+
+241
+00:21:27,000 --> 00:21:30,000
+Have a great day and see you in the next lesson.
+
diff --git a/74 - OWASP API Security Top 10 2023/005 API22023 Broken Authentication - Part 1 (Basics, Impact, Types of Attacks)_en.srt b/74 - OWASP API Security Top 10 2023/005 API22023 Broken Authentication - Part 1 (Basics, Impact, Types of Attacks)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..0d00c1398f72a1e0d2e2751ef828198130e70e6e
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/005 API22023 Broken Authentication - Part 1 (Basics, Impact, Types of Attacks)_en.srt
@@ -0,0 +1,800 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:14,000
+In this lesson we will learn the next vulnerabilities that is listed in OWASp API Security Top ten 2023
+
+3
+00:00:15,000 --> 00:00:17,000
+Broken Authentication.
+
+4
+00:00:17,000 --> 00:00:19,000
+So here's what we'll be covering today.
+
+5
+00:00:20,000 --> 00:00:26,000
+We'll start with an understanding of broken authentication, including its definition and the common
+
+6
+00:00:26,000 --> 00:00:29,000
+misconceptions surrounding API authentication.
+
+7
+00:00:29,000 --> 00:00:35,000
+I'll guide you through various authentication mechanisms, highlighting their vulnerabilities and explaining
+
+8
+00:00:35,000 --> 00:00:39,000
+how easily these issues can be detected with current methodologies.
+
+9
+00:00:40,000 --> 00:00:47,000
+Next, we'll connect these concepts with the OWASp top ten focusing on Broken access control.
+
+10
+00:00:47,000 --> 00:00:54,000
+We'll clarify the distinction between authentication and access control and discuss how issues in authentication
+
+11
+00:00:54,000 --> 00:00:56,000
+can lead to broken access control.
+
+12
+00:00:57,000 --> 00:01:03,000
+I will present examples of interconnected vulnerabilities and exploits to illustrate these points.
+
+13
+00:01:03,000 --> 00:01:09,000
+We'll dive into the causes of broken authentication, examining the different types of attacks and the
+
+14
+00:01:09,000 --> 00:01:12,000
+technical factors that contribute to these vulnerabilities.
+
+15
+00:01:13,000 --> 00:01:20,000
+We'll discuss automated attacks, poor standards and practices, and the lack of protection mechanisms
+
+16
+00:01:20,000 --> 00:01:23,000
+that can lead to weak authentication.
+
+17
+00:01:23,000 --> 00:01:29,000
+Following that, we'll review several case studies to see real world examples of broken authentication.
+
+18
+00:01:29,000 --> 00:01:36,000
+We'll explore the lessons learned from these cases and discuss the impact and consequences of such vulnerabilities
+
+19
+00:01:36,000 --> 00:01:38,000
+on systems and data.
+
+20
+00:01:38,000 --> 00:01:44,000
+To wrap things up, we'll cover best practices for mitigating broken authentication vulnerabilities.
+
+21
+00:01:45,000 --> 00:01:51,000
+We'll compare our auth and OpenID to understand their roles and differences in securing authentication
+
+22
+00:01:51,000 --> 00:01:52,000
+processes.
+
+23
+00:01:52,000 --> 00:01:58,000
+Finally, we'll dive into a real life code example, demonstrating both the problems associated with
+
+24
+00:01:58,000 --> 00:02:02,000
+poor authentication practices and the solutions to address them.
+
+25
+00:02:03,000 --> 00:02:10,000
+We'll also discuss timing attacks and how to avoid them, ensuring you have a comprehensive understanding
+
+26
+00:02:10,000 --> 00:02:13,000
+of how to protect your systems against these threats.
+
+27
+00:02:14,000 --> 00:02:16,000
+Let's get started with today's lesson.
+
+28
+00:02:17,000 --> 00:02:24,000
+Today we'll delve into the concept of broken authentication, a crucial topic in the realm of API security.
+
+29
+00:02:24,000 --> 00:02:29,000
+To start, it's essential to define what we mean by broken authentication.
+
+30
+00:02:30,000 --> 00:02:37,000
+Essentially broken authentication refers to vulnerabilities in the authentication mechanisms that can
+
+31
+00:02:37,000 --> 00:02:41,000
+lead to unauthorized access to an application's resources.
+
+32
+00:02:42,000 --> 00:02:49,000
+This issue allows attackers to exploit flaws in the authentication process to gain access to user accounts,
+
+33
+00:02:49,000 --> 00:02:54,000
+sensitive data, or perform actions that they are not authorized to undertake.
+
+34
+00:02:55,000 --> 00:03:02,000
+To better understand this, let's first address some common misconceptions about API authentication.
+
+35
+00:03:02,000 --> 00:03:08,000
+One prevalent misunderstanding is that authentication is merely about verifying user credentials at
+
+36
+00:03:08,000 --> 00:03:09,000
+login.
+
+37
+00:03:10,000 --> 00:03:13,000
+In reality, authentication encompasses much more.
+
+38
+00:03:13,000 --> 00:03:20,000
+It involves managing session tokens, handling authorization, and ensuring that tokens are securely
+
+39
+00:03:20,000 --> 00:03:22,000
+stored and transmitted.
+
+40
+00:03:22,000 --> 00:03:29,000
+This broader scope is crucial because focusing only on the login process without addressing these other
+
+41
+00:03:29,000 --> 00:03:32,000
+aspects can leave significant security gaps.
+
+42
+00:03:32,000 --> 00:03:38,000
+Another misconception is the belief that API keys alone can provide sufficient security.
+
+43
+00:03:38,000 --> 00:03:44,000
+While API keys are commonly used, they are often inadequate on their own.
+
+44
+00:03:44,000 --> 00:03:51,000
+API keys are typically not very secure, as they can be easily exposed or misused without additional
+
+45
+00:03:51,000 --> 00:03:52,000
+security layers.
+
+46
+00:03:53,000 --> 00:03:59,000
+For robust protection, it is essential to incorporate other mechanisms such as OAuth or JWT.
+
+47
+00:04:00,000 --> 00:04:05,000
+Furthermore, some may assume that authentication is only relevant for user accounts.
+
+48
+00:04:05,000 --> 00:04:07,000
+However, this is not the case.
+
+49
+00:04:08,000 --> 00:04:15,000
+Authentication is equally important for machine to machine interactions and service to service communications.
+
+50
+00:04:16,000 --> 00:04:22,000
+For instance, in a microservices architecture, ensuring that services can securely authenticate and
+
+51
+00:04:22,000 --> 00:04:26,000
+authorize each other is crucial to maintaining overall system security.
+
+52
+00:04:27,000 --> 00:04:33,000
+Now let's explore the different authentication mechanisms and their associated vulnerabilities.
+
+53
+00:04:33,000 --> 00:04:41,000
+We start with basic authentication, which involves transmitting credentials as a base 64 encoded string.
+
+54
+00:04:41,000 --> 00:04:49,000
+While simple, this method is vulnerable if not used with Https, as credentials can be exposed in plain
+
+55
+00:04:49,000 --> 00:04:50,000
+text.
+
+56
+00:04:50,000 --> 00:04:58,000
+Next, we have API keys, which are straightforward tokens used to authenticate requests Despite their
+
+57
+00:04:58,000 --> 00:05:03,000
+simplicity, API keys are often insecure and can be easily leaked.
+
+58
+00:05:04,000 --> 00:05:10,000
+Session cookies are another common mechanism storing session data in cookies after a user logs in.
+
+59
+00:05:10,000 --> 00:05:17,000
+However, they are susceptible to session hijacking and cross-site request forgery attacks if not handled
+
+60
+00:05:17,000 --> 00:05:18,000
+properly.
+
+61
+00:05:19,000 --> 00:05:26,000
+In contrast, JSON web tokens, we will call them JWT, offer a more sophisticated approach by encoding
+
+62
+00:05:26,000 --> 00:05:29,000
+user identity and claims in a signed token.
+
+63
+00:05:30,000 --> 00:05:37,000
+Despite these advantages, JWT are vulnerable to risks such as weak signing algorithms and improper
+
+64
+00:05:37,000 --> 00:05:38,000
+token validation.
+
+65
+00:05:39,000 --> 00:05:45,000
+AWS is a widely used framework for authorization that allow secure access delegation.
+
+66
+00:05:45,000 --> 00:05:52,000
+Nonetheless, if misconfigured or poorly implemented, it can lead to significant authorization flaws.
+
+67
+00:05:53,000 --> 00:06:00,000
+With these mechanisms in mind, it's important to recognize common vulnerabilities associated with them.
+
+68
+00:06:01,000 --> 00:06:06,000
+Weak password policies can allow attackers to set easily guessable passwords.
+
+69
+00:06:06,000 --> 00:06:14,000
+Token exposure, such as sending tokens in URLs or storing them in securely, presents another risk.
+
+70
+00:06:15,000 --> 00:06:21,000
+Additionally, improper token management, including issues with token expiration, renewal, and revocation,
+
+71
+00:06:21,000 --> 00:06:27,000
+can further compromise security in secure storage and handling of authentication.
+
+72
+00:06:27,000 --> 00:06:32,000
+Data, such as using weak encryption algorithms, are also significant concerns.
+
+73
+00:06:33,000 --> 00:06:39,000
+To detect authentication issues effectively, we must consider both traditional and modern methodologies.
+
+74
+00:06:40,000 --> 00:06:47,000
+Traditional methods include static and dynamic analysis, which involves scanning code and testing applications
+
+75
+00:06:47,000 --> 00:06:48,000
+during execution.
+
+76
+00:06:48,000 --> 00:06:54,000
+Penetration testing, though valuable, can be time consuming and may only cover a limited scope.
+
+77
+00:06:55,000 --> 00:06:59,000
+On the other hand, modern methodologies offer more dynamic approaches.
+
+78
+00:07:00,000 --> 00:07:07,000
+Behavioral analysis, for instance, monitors API traffic to identify abnormal patterns such as excessive
+
+79
+00:07:07,000 --> 00:07:08,000
+failed login attempts.
+
+80
+00:07:09,000 --> 00:07:16,000
+Runtime protection solutions provide real time defenses against advanced attacks by detecting and blocking
+
+81
+00:07:16,000 --> 00:07:17,000
+suspicious activities.
+
+82
+00:07:18,000 --> 00:07:25,000
+Automated security tools continuously scan for vulnerabilities, helping identify issues like insecure
+
+83
+00:07:25,000 --> 00:07:26,000
+token storage.
+
+84
+00:07:26,000 --> 00:07:33,000
+Comprehensive testing frameworks ensure that authentication mechanisms are thoroughly examined across
+
+85
+00:07:33,000 --> 00:07:34,000
+various scenarios.
+
+86
+00:07:34,000 --> 00:07:42,000
+We will review more tools when we will get to the section about how to avoid broken authentication vulnerabilities.
+
+87
+00:07:42,000 --> 00:07:46,000
+Despite these advancements, challenges remain.
+
+88
+00:07:46,000 --> 00:07:53,000
+Traditional tools may generate false positives or negatives, and the increasing complexity of modern
+
+89
+00:07:53,000 --> 00:07:57,000
+systems can make it difficult to ensure comprehensive coverage.
+
+90
+00:07:57,000 --> 00:08:03,000
+To address these challenges, regular security audits, adherence to established security standards,
+
+91
+00:08:03,000 --> 00:08:07,000
+and robust monitoring and logging practices are essential.
+
+92
+00:08:08,000 --> 00:08:14,000
+Today, we will explore the crucial relationship between broken authentication and broken access control
+
+93
+00:08:14,000 --> 00:08:22,000
+from OWASp top ten 2021, focusing on how these concepts are interconnected and how one can influence
+
+94
+00:08:22,000 --> 00:08:23,000
+the other.
+
+95
+00:08:24,000 --> 00:08:29,000
+If you are a student of my course Secure Coding, then you already saw the lesson about broken access
+
+96
+00:08:29,000 --> 00:08:30,000
+control.
+
+97
+00:08:30,000 --> 00:08:37,000
+If no, then I recommend you to watch it because information from that lesson will help you better understand
+
+98
+00:08:37,000 --> 00:08:40,000
+the concepts that I'm going to describe in this lesson.
+
+99
+00:08:41,000 --> 00:08:43,000
+But do not force you to change the lesson right now.
+
+100
+00:08:44,000 --> 00:08:51,000
+Let me remind you, in short, what broken Access Control from OWASp top ten 2021 is about.
+
+101
+00:08:51,000 --> 00:08:59,000
+This category addresses vulnerabilities where users are able to gain unauthorized access to resources
+
+102
+00:08:59,000 --> 00:09:02,000
+or perform actions that they are not supposed to.
+
+103
+00:09:02,000 --> 00:09:09,000
+In essence, broken access control pertains to the failure of a system to enforce proper authorization
+
+104
+00:09:09,000 --> 00:09:16,000
+checks, allowing users to bypass restrictions and access sensitive information or functionalities.
+
+105
+00:09:17,000 --> 00:09:23,000
+While broken authentication and broken access control are related, they represent different aspects
+
+106
+00:09:23,000 --> 00:09:24,000
+of security.
+
+107
+00:09:25,000 --> 00:09:30,000
+Authentication is the process of verifying the identity of a user or system.
+
+108
+00:09:31,000 --> 00:09:36,000
+It ensures that the entity interacting with the system is who they claim to be.
+
+109
+00:09:37,000 --> 00:09:42,000
+Common authentication methods include passwords, API keys, and tokens.
+
+110
+00:09:42,000 --> 00:09:48,000
+On the other hand, access control is about ensuring that once an entity is authenticated, it is only
+
+111
+00:09:48,000 --> 00:09:53,000
+allowed to access resources or perform actions that it is authorized to.
+
+112
+00:09:53,000 --> 00:09:59,000
+This is where access control policies and mechanisms come into play, defining what each authenticated
+
+113
+00:09:59,000 --> 00:10:01,000
+user can and cannot do.
+
+114
+00:10:02,000 --> 00:10:06,000
+To illustrate this distinction, consider a bank's online platform.
+
+115
+00:10:06,000 --> 00:10:12,000
+Authentication ensures that a user is indeed the owner of a bank account when they log in.
+
+116
+00:10:12,000 --> 00:10:19,000
+However, access control determines whether this authenticated user can view account details, transfer
+
+117
+00:10:19,000 --> 00:10:22,000
+funds, or access administrative functions.
+
+118
+00:10:23,000 --> 00:10:28,000
+The link between broken authentication and broken access control is significant.
+
+119
+00:10:28,000 --> 00:10:35,000
+If authentication mechanisms are compromised or inadequately implemented, it can directly lead to issues
+
+120
+00:10:35,000 --> 00:10:37,000
+with access control.
+
+121
+00:10:37,000 --> 00:10:44,000
+For example, if an attacker is able to bypass authentication, they can gain unauthorized access to
+
+122
+00:10:44,000 --> 00:10:45,000
+the system.
+
+123
+00:10:46,000 --> 00:10:52,000
+Conversely, if authentication is weak, even properly implemented access controls may fail to prevent
+
+124
+00:10:52,000 --> 00:10:54,000
+unauthorized actions.
+
+125
+00:10:54,000 --> 00:10:56,000
+Here's a concrete example.
+
+126
+00:10:57,000 --> 00:11:04,000
+Suppose a web application uses a simple API key for authentication, and this key is embedded in a URL.
+
+127
+00:11:05,000 --> 00:11:12,000
+If an attacker discovers this URL, they can use the API key to authenticate themselves.
+
+128
+00:11:13,000 --> 00:11:19,000
+Once authenticated, if the application does not enforce proper access controls, the attacker could
+
+129
+00:11:19,000 --> 00:11:24,000
+potentially access or manipulate resources they should not have access to.
+
+130
+00:11:25,000 --> 00:11:31,000
+Let's consider a few scenarios where broken authentication can lead to broken access control.
+
+131
+00:11:31,000 --> 00:11:34,000
+Insecure password management.
+
+132
+00:11:34,000 --> 00:11:41,000
+Suppose an application allows users to reset passwords without proper rate limiting or email verification.
+
+133
+00:11:42,000 --> 00:11:47,000
+An attacker could exploit this to reset a user's password and gain unauthorized access.
+
+134
+00:11:48,000 --> 00:11:54,000
+If access control is not enforced correctly, the attacker could then access sensitive user data or
+
+135
+00:11:54,000 --> 00:11:56,000
+perform privileged actions.
+
+136
+00:11:57,000 --> 00:12:00,000
+JWT Misconfigurations.
+
+137
+00:12:00,000 --> 00:12:07,000
+Imagine a scenario where JWT are used for authentication, but the tokens are configured with weak signing
+
+138
+00:12:07,000 --> 00:12:10,000
+algorithms or inadequate expiration policies.
+
+139
+00:12:11,000 --> 00:12:18,000
+An attacker who can forge or intercept these tokens may gain unauthorized access if the system's access
+
+140
+00:12:18,000 --> 00:12:21,000
+control mechanisms are not robust.
+
+141
+00:12:21,000 --> 00:12:27,000
+The attacker might exploit this access to view or modify restricted resources.
+
+142
+00:12:28,000 --> 00:12:36,000
+Misconfigured roles in a web application with role based access control if the roles are not properly
+
+143
+00:12:36,000 --> 00:12:38,000
+configured or enforced.
+
+144
+00:12:38,000 --> 00:12:45,000
+An attacker who manages to authenticate with a compromised account could escalate their privileges and
+
+145
+00:12:45,000 --> 00:12:48,000
+access resources meant for higher privilege levels.
+
+146
+00:12:49,000 --> 00:12:56,000
+To fully grasp the concept of broken authentication, we need to explore the various causes and contributing
+
+147
+00:12:56,000 --> 00:12:58,000
+factors systematically.
+
+148
+00:12:58,000 --> 00:13:04,000
+Understanding these aspects will provide a comprehensive picture of why authentication systems might
+
+149
+00:13:04,000 --> 00:13:07,000
+fail and how they can be exploited.
+
+150
+00:13:07,000 --> 00:13:11,000
+And this will help you to understand how you can avoid them.
+
+151
+00:13:12,000 --> 00:13:18,000
+First, let's consider the types of attacks that commonly target authentication systems.
+
+152
+00:13:19,000 --> 00:13:24,000
+These attacks are crucial for understanding the vulnerabilities that can be exploited.
+
+153
+00:13:24,000 --> 00:13:31,000
+Brute force attacks are one of the most straightforward methods where attackers systematically attempt
+
+154
+00:13:31,000 --> 00:13:36,000
+every possible password combination until they find the correct one.
+
+155
+00:13:36,000 --> 00:13:42,000
+This is especially problematic if the system uses weak or outdated hashing algorithms.
+
+156
+00:13:43,000 --> 00:13:50,000
+Credential stuffing involves attackers using previously stolen credentials from other breaches to gain
+
+157
+00:13:50,000 --> 00:13:51,000
+unauthorized access.
+
+158
+00:13:52,000 --> 00:13:59,000
+Since many users tend to reuse passwords across different sites, this attack can be highly effective.
+
+159
+00:14:00,000 --> 00:14:05,000
+Password spraying, on the other hand, targets multiple accounts with a few common passwords, rather
+
+160
+00:14:05,000 --> 00:14:08,000
+than trying many passwords on a single account.
+
+161
+00:14:09,000 --> 00:14:15,000
+This approach minimizes the risk of triggering account lockouts and is effective against weak or commonly
+
+162
+00:14:15,000 --> 00:14:17,000
+used passwords.
+
+163
+00:14:18,000 --> 00:14:24,000
+Understanding the technical factors that contribute to these vulnerabilities helps us see how these
+
+164
+00:14:24,000 --> 00:14:25,000
+attacks succeed.
+
+165
+00:14:25,000 --> 00:14:33,000
+For instance, if a system employs weak password hashing algorithms such as MD5, it becomes easier
+
+166
+00:14:33,000 --> 00:14:37,000
+for attackers to crack passwords using techniques like rainbow tables.
+
+167
+00:14:38,000 --> 00:14:44,000
+Rainbow tables are precomputed tables used to reverse cryptographic hash functions, making it easier
+
+168
+00:14:44,000 --> 00:14:49,000
+for attackers to crack hashed passwords by looking up hashes in a pre-built database.
+
+169
+00:14:50,000 --> 00:14:54,000
+Similarly, inadequate token security can lead to vulnerabilities.
+
+170
+00:14:54,000 --> 00:15:01,000
+Tokens that have low entropy or are encrypted with weak algorithms can be easily guessed or decrypted.
+
+171
+00:15:01,000 --> 00:15:08,000
+Low entropy refers to the predictability of a password or token, meaning it has less randomness and
+
+172
+00:15:08,000 --> 00:15:10,000
+is easier to guess or crack.
+
+173
+00:15:10,000 --> 00:15:17,000
+Additionally, issues like improper session management, where sessions are not effectively invalidated
+
+174
+00:15:17,000 --> 00:15:22,000
+or cookies are not securely configured, can further compromise security.
+
+175
+00:15:23,000 --> 00:15:31,000
+Automated attacks driven by sophisticated tools and scripts exploit these technical weaknesses, for
+
+176
+00:15:31,000 --> 00:15:37,000
+example, brute force attacks can overwhelm a system with thousands or millions of password attempts.
+
+177
+00:15:37,000 --> 00:15:45,000
+If the system does not have adequate protections such as rate limiting, credential stuffing and password
+
+178
+00:15:45,000 --> 00:15:47,000
+spraying also benefit from automation.
+
+179
+00:15:47,000 --> 00:15:54,000
+Attackers use automated tools to execute these attacks at scale, exploiting the reuse of credentials
+
+180
+00:15:54,000 --> 00:15:57,000
+and weak password choices without manual intervention.
+
+181
+00:15:59,000 --> 00:16:04,000
+Another significant cause of broken authentication is poor standards and practices.
+
+182
+00:16:04,000 --> 00:16:10,000
+This includes custom codes that fails to adhere to established security best practices.
+
+183
+00:16:10,000 --> 00:16:17,000
+Developing custom authentication mechanisms without proper security considerations can introduce severe
+
+184
+00:16:17,000 --> 00:16:18,000
+vulnerabilities.
+
+185
+00:16:19,000 --> 00:16:26,000
+Furthermore, the improper use of libraries can also be problematic if authentication libraries are
+
+186
+00:16:26,000 --> 00:16:28,000
+outdated or misconfigured.
+
+187
+00:16:28,000 --> 00:16:32,000
+They can expose systems to known vulnerabilities.
+
+188
+00:16:32,000 --> 00:16:38,000
+Ensuring that libraries are up to date and correctly configured is essential for maintaining security.
+
+189
+00:16:39,000 --> 00:16:44,000
+Function level enforcement is another area where poor practices can lead to issues.
+
+190
+00:16:44,000 --> 00:16:50,000
+Inadequate enforcement of security measures at the function level, such as not properly securing sensitive
+
+191
+00:16:50,000 --> 00:16:56,000
+endpoints, can lead to unauthorized access and compromise overall system security.
+
+192
+00:16:57,000 --> 00:17:03,000
+A major factor contributing to broken authentication is the lack of adequate protection mechanisms.
+
+193
+00:17:03,000 --> 00:17:11,000
+For example, the absence of multi-factor authentication MFA means that the security of user accounts
+
+194
+00:17:11,000 --> 00:17:17,000
+depends solely on passwords, which are often the weakest link.
+
+195
+00:17:17,000 --> 00:17:24,000
+Similarly, weak password policies can worsen the problem if an application does not enforce strong
+
+196
+00:17:24,000 --> 00:17:26,000
+password requirements.
+
+197
+00:17:26,000 --> 00:17:33,000
+Users may choose easily guessable passwords, making it easier for attackers to gain unauthorized access.
+
+198
+00:17:34,000 --> 00:17:41,000
+Finally, the mis implementation of authentication mechanisms can significantly undermine security.
+
+199
+00:17:41,000 --> 00:17:48,000
+This includes issues like improper token configuration, such as using weak algorithms or incorrect
+
+200
+00:17:48,000 --> 00:17:55,000
+expiration settings for JSON web tokens, which can make them vulnerable to attacks.
+
diff --git a/74 - OWASP API Security Top 10 2023/006 API22023 Broken Authentication - Part 2 (Case Studies, OAuth, OpenID)_en.srt b/74 - OWASP API Security Top 10 2023/006 API22023 Broken Authentication - Part 2 (Case Studies, OAuth, OpenID)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..f33d9f37f0531e8875a11a46cc6e7741ac011666
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/006 API22023 Broken Authentication - Part 2 (Case Studies, OAuth, OpenID)_en.srt
@@ -0,0 +1,936 @@
+1
+00:00:03,000 --> 00:00:10,000
+To truly grasp the impact of broken authentication, examining real world incidents provides valuable
+
+2
+00:00:10,000 --> 00:00:11,000
+insights.
+
+3
+00:00:11,000 --> 00:00:18,000
+One such case is the Parler data breach, which highlights several critical lessons about authentication
+
+4
+00:00:18,000 --> 00:00:20,000
+practices and their failures.
+
+5
+00:00:21,000 --> 00:00:30,000
+In early 2021, the social media platform Parler experienced a significant security incident where attackers
+
+6
+00:00:30,000 --> 00:00:33,000
+were able to access and extract massive amounts of data.
+
+7
+00:00:34,000 --> 00:00:41,000
+This breach was particularly notable because it exposed various vulnerabilities related to broken authentication
+
+8
+00:00:41,000 --> 00:00:42,000
+mechanisms.
+
+9
+00:00:43,000 --> 00:00:49,000
+The primary issue in the Parler breach was the lack of proper authentication for some of its API endpoints.
+
+10
+00:00:50,000 --> 00:00:55,000
+Attackers exploited these weaknesses by accessing APIs that should have been protected.
+
+11
+00:00:55,000 --> 00:01:03,000
+Specifically, Parler's API had endpoints that allowed unauthenticated access to user profiles and content,
+
+12
+00:01:03,000 --> 00:01:06,000
+including sensitive data like posts, images, and videos.
+
+13
+00:01:07,000 --> 00:01:12,000
+This oversight allowed attackers to scrape vast amounts of data with minimal effort.
+
+14
+00:01:13,000 --> 00:01:19,000
+Additionally, it was reported that there were issues with multi-factor authentication and other security
+
+15
+00:01:19,000 --> 00:01:20,000
+configurations.
+
+16
+00:01:21,000 --> 00:01:27,000
+For instance, some reports suggested that MFA was improperly configured, which might have allowed
+
+17
+00:01:27,000 --> 00:01:31,000
+attackers to bypass this additional security layer.
+
+18
+00:01:31,000 --> 00:01:38,000
+While there was debate about the exact cause, the general consensus points to poor implementation of
+
+19
+00:01:38,000 --> 00:01:41,000
+authentication controls as a significant factor.
+
+20
+00:01:42,000 --> 00:01:44,000
+Lessons learned from the incident.
+
+21
+00:01:45,000 --> 00:01:49,000
+Importance of proper authentication for all endpoints.
+
+22
+00:01:50,000 --> 00:01:57,000
+The Pearl incident underscores the necessity of implementing robust authentication checks for every
+
+23
+00:01:57,000 --> 00:02:01,000
+API endpoint, not just those involving sensitive actions.
+
+24
+00:02:02,000 --> 00:02:09,000
+APIs that handle user data or perform critical functions must enforce strict authentication to prevent
+
+25
+00:02:09,000 --> 00:02:10,000
+unauthorized access.
+
+26
+00:02:11,000 --> 00:02:14,000
+Configuration of multifactor authentication.
+
+27
+00:02:15,000 --> 00:02:21,000
+Properly configuring MFA is essential to secure an accounts, especially for administrative functions.
+
+28
+00:02:21,000 --> 00:02:28,000
+The breach highlighted the need for correct MFA set up to prevent unauthorized access, even if credentials
+
+29
+00:02:28,000 --> 00:02:29,000
+are compromised.
+
+30
+00:02:30,000 --> 00:02:32,000
+Continuous security audits.
+
+31
+00:02:33,000 --> 00:02:39,000
+Regular security audits and penetration testing can identify vulnerabilities before attackers do.
+
+32
+00:02:39,000 --> 00:02:47,000
+The parallel breach reveals how lapses in routine security practices can lead to severe data exposure.
+
+33
+00:02:48,000 --> 00:02:50,000
+Granular access controls.
+
+34
+00:02:50,000 --> 00:02:57,000
+Employing fine grained access controls helps ensure that only authorized users can access specific data
+
+35
+00:02:57,000 --> 00:02:59,000
+or perform particular actions.
+
+36
+00:02:59,000 --> 00:03:06,000
+This practice can mitigate the risk of exposing sensitive information due to broken authentication.
+
+37
+00:03:07,000 --> 00:03:14,000
+Another illustrative example is the 2020 Twitter attack, where attackers exploited vulnerabilities
+
+38
+00:03:14,000 --> 00:03:19,000
+in Twitter's internal tools to take over high profile accounts.
+
+39
+00:03:19,000 --> 00:03:27,000
+This breach was a result of inadequate internal access controls and insufficiently protected API endpoints.
+
+40
+00:03:28,000 --> 00:03:34,000
+In this case, attackers used social engineering to gain access to internal systems, which allowed
+
+41
+00:03:34,000 --> 00:03:40,000
+them to bypass authentication mechanisms that were not robust enough to handle such threats.
+
+42
+00:03:41,000 --> 00:03:45,000
+The lessons here include securing internal tools and APIs.
+
+43
+00:03:46,000 --> 00:03:52,000
+Internal tools must have the same level of security scrutiny as external facing APIs.
+
+44
+00:03:52,000 --> 00:03:57,000
+Inadequate protection for internal systems can lead to significant breaches.
+
+45
+00:03:58,000 --> 00:04:00,000
+Role based access controls.
+
+46
+00:04:01,000 --> 00:04:08,000
+Implementing Rbac ensures that users have access only to the resources they need, reducing the risk
+
+47
+00:04:08,000 --> 00:04:11,000
+of unauthorised data access.
+
+48
+00:04:12,000 --> 00:04:17,000
+Let's make a summary now based on these two cases and summarise lessons learned.
+
+49
+00:04:18,000 --> 00:04:20,000
+Comprehensive security measures.
+
+50
+00:04:20,000 --> 00:04:26,000
+Both cases illustrate the importance of implementing comprehensive security measures that cover all
+
+51
+00:04:26,000 --> 00:04:32,000
+aspects of authentication and access control, from internal systems to public APIs.
+
+52
+00:04:33,000 --> 00:04:35,000
+Regular updates and patch management.
+
+53
+00:04:36,000 --> 00:04:42,000
+Keeping systems and authentication mechanisms up to date and patched against known vulnerabilities is
+
+54
+00:04:42,000 --> 00:04:44,000
+crucial for maintaining security.
+
+55
+00:04:45,000 --> 00:04:47,000
+User awareness and training.
+
+56
+00:04:48,000 --> 00:04:54,000
+Training staff to recognize social engineering attacks and other security threats can prevent breaches
+
+57
+00:04:54,000 --> 00:04:56,000
+that exploit human factors.
+
+58
+00:04:57,000 --> 00:05:04,000
+By analyzing these real world incidents, we can understand the practical implications of broken authentication
+
+59
+00:05:04,000 --> 00:05:10,000
+and develop more effective strategies to mitigate such vulnerabilities in our own systems.
+
+60
+00:05:11,000 --> 00:05:18,000
+Understanding the potential impact of broken authentication vulnerabilities is crucial for grasping
+
+61
+00:05:18,000 --> 00:05:24,000
+the significance of robust authentication mechanisms in safeguarding digital systems.
+
+62
+00:05:24,000 --> 00:05:31,000
+Let's explore the various consequences of broken authentication and how they can affect both organizations
+
+63
+00:05:31,000 --> 00:05:32,000
+and individuals.
+
+64
+00:05:33,000 --> 00:05:38,000
+Broken authentication can have far reaching consequences, affecting not only the immediate security
+
+65
+00:05:38,000 --> 00:05:45,000
+of an application, but also the broader integrity of an organization's operations and reputation.
+
+66
+00:05:46,000 --> 00:05:52,000
+When authentication mechanisms fail, attackers can exploit these weaknesses to gain unauthorized access,
+
+67
+00:05:52,000 --> 00:05:56,000
+leading to a cascade of negative outcomes.
+
+68
+00:05:57,000 --> 00:06:00,000
+Let's delve into the specific impacts.
+
+69
+00:06:00,000 --> 00:06:06,000
+One of the most direct and severe consequences of broken authentication is account takeover.
+
+70
+00:06:06,000 --> 00:06:13,000
+In such cases, attackers can gain control of user accounts by exploiting weaknesses in the authentication
+
+71
+00:06:13,000 --> 00:06:14,000
+process.
+
+72
+00:06:14,000 --> 00:06:21,000
+For instance, if a system is vulnerable to credential stuffing or brute force attacks, attackers can
+
+73
+00:06:21,000 --> 00:06:26,000
+potentially gain access to user accounts by guessing or acquiring credentials.
+
+74
+00:06:27,000 --> 00:06:32,000
+Once attackers have taken over an account, they can perform actions as if they were the a legitimate
+
+75
+00:06:32,000 --> 00:06:33,000
+user.
+
+76
+00:06:33,000 --> 00:06:40,000
+This could involve changing account settings, accessing sensitive personal information, or manipulating
+
+77
+00:06:40,000 --> 00:06:41,000
+account preferences.
+
+78
+00:06:42,000 --> 00:06:49,000
+For organizations, this not only jeopardizes user privacy, but also risks unauthorized access to critical
+
+79
+00:06:49,000 --> 00:06:53,000
+systems and data, potentially leading to broader security breaches.
+
+80
+00:06:55,000 --> 00:07:01,000
+Broken authentication vulnerabilities can also result in unauthorized access to sensitive data.
+
+81
+00:07:02,000 --> 00:07:08,000
+When authentication mechanisms are compromised, attackers may be able to access data that they are
+
+82
+00:07:08,000 --> 00:07:09,000
+not permitted to see.
+
+83
+00:07:10,000 --> 00:07:17,000
+For example, if an API endpoint that handles user data does not properly authenticate requests, an
+
+84
+00:07:17,000 --> 00:07:22,000
+attacker could retrieve or manipulate user information without authorization.
+
+85
+00:07:23,000 --> 00:07:29,000
+This unauthorized access can lead to data breaches where sensitive personal or financial information
+
+86
+00:07:29,000 --> 00:07:30,000
+is exposed.
+
+87
+00:07:31,000 --> 00:07:38,000
+Such breaches can have severe implications, including identity theft, financial loss, and damage
+
+88
+00:07:38,000 --> 00:07:40,000
+to an organization's reputation.
+
+89
+00:07:40,000 --> 00:07:46,000
+Additionally, regulatory consequences may arise if the exposed data includes protected information
+
+90
+00:07:46,000 --> 00:07:51,000
+subject to compliance requirements such as GDPR or HIPAA.
+
+91
+00:07:52,000 --> 00:07:58,000
+Beyond accessing data, broken authentication can enable attackers to perform unauthorized transactions
+
+92
+00:07:58,000 --> 00:07:59,000
+or actions.
+
+93
+00:07:59,000 --> 00:08:06,000
+For example, in an online banking or e-commerce application, viscose integration could allow attackers
+
+94
+00:08:06,000 --> 00:08:12,000
+to initiate financial transactions or modify order details without proper authorization.
+
+95
+00:08:13,000 --> 00:08:19,000
+Such unauthorized actions can have direct financial consequences, including fraudulent transactions
+
+96
+00:08:19,000 --> 00:08:24,000
+or erroneous modifications that affect business operations and customer trust.
+
+97
+00:08:25,000 --> 00:08:32,000
+For organizations, this may also lead to financial losses, legal liabilities, and reputational damage.
+
+98
+00:08:32,000 --> 00:08:38,000
+Ensuring robust authentication is crucial to preventing such unauthorized activities and maintaining
+
+99
+00:08:38,000 --> 00:08:46,000
+the integrity of transactional processes to effectively mitigate broken authentication vulnerabilities.
+
+100
+00:08:46,000 --> 00:08:50,000
+It is essential to adopt a comprehensive set of best practices.
+
+101
+00:08:50,000 --> 00:08:58,000
+These practices encompass both technical implementations and strategic policies that ensure robust authentication
+
+102
+00:08:58,000 --> 00:09:00,000
+mechanisms are in place.
+
+103
+00:09:01,000 --> 00:09:03,000
+Use standard authentication methods.
+
+104
+00:09:04,000 --> 00:09:12,000
+Begin by leveraging established and standardized authentication methods such as OAuth and OpenID connect.
+
+105
+00:09:12,000 --> 00:09:19,000
+These standards are widely recognized and supported, offering robust security features that have been
+
+106
+00:09:19,000 --> 00:09:21,000
+rigorously tested and validated.
+
+107
+00:09:22,000 --> 00:09:28,000
+By using these standard methods, you avoid the pitfalls of custom authentication code, which can be
+
+108
+00:09:28,000 --> 00:09:30,000
+prone to errors and vulnerabilities.
+
+109
+00:09:31,000 --> 00:09:38,000
+These protocols are fundamental in managing how users and applications interact securely in the digital
+
+110
+00:09:38,000 --> 00:09:39,000
+world.
+
+111
+00:09:39,000 --> 00:09:44,000
+That's why I believe it is important to discuss them in scope of this lesson.
+
+112
+00:09:44,000 --> 00:09:51,000
+Firstly, let's talk about AWS, which stands for Open Authorization, or AWS is an open standard for
+
+113
+00:09:51,000 --> 00:09:53,000
+access delegation.
+
+114
+00:09:53,000 --> 00:10:00,000
+Its primary purpose is to allow an application to access a user's resources on another service, without
+
+115
+00:10:00,000 --> 00:10:02,000
+exposing the user's credentials.
+
+116
+00:10:02,000 --> 00:10:09,000
+This is particularly useful when you want to enable third party applications to interact with your data
+
+117
+00:10:09,000 --> 00:10:15,000
+on services like Google, Facebook or Twitter without sharing your username and password.
+
+118
+00:10:15,000 --> 00:10:19,000
+The OAuth flow involves several key components.
+
+119
+00:10:19,000 --> 00:10:23,000
+The client which is the application requesting access.
+
+120
+00:10:23,000 --> 00:10:26,000
+The resource owner which is the user.
+
+121
+00:10:26,000 --> 00:10:29,000
+The authorization server and the resource server.
+
+122
+00:10:29,000 --> 00:10:32,000
+Here's how the process typically works.
+
+123
+00:10:32,000 --> 00:10:34,000
+Authorization grant types.
+
+124
+00:10:35,000 --> 00:10:38,000
+OAuth supports different types of authorization grants.
+
+125
+00:10:39,000 --> 00:10:44,000
+The authorization code grant is most commonly used by server side applications.
+
+126
+00:10:44,000 --> 00:10:51,000
+In this flow, the user is redirected to the authorization server to log in and consent to the access
+
+127
+00:10:51,000 --> 00:10:52,000
+request.
+
+128
+00:10:53,000 --> 00:11:00,000
+The server then issues an authorization code to the client, which is exchanged for an access token.
+
+129
+00:11:01,000 --> 00:11:07,000
+The implicit grant is suitable for single page applications where the access token is returned directly.
+
+130
+00:11:08,000 --> 00:11:15,000
+Resource owner password credentials grant involves the user providing their credentials directly to
+
+131
+00:11:15,000 --> 00:11:20,000
+the client, which is suitable only for highly trusted applications.
+
+132
+00:11:20,000 --> 00:11:28,000
+This flow is designed for situations where other or AWS 2.0 flows are not feasible or practical.
+
+133
+00:11:29,000 --> 00:11:30,000
+Client credentials.
+
+134
+00:11:30,000 --> 00:11:37,000
+Grant is used for machine to machine communication, where the client directly accesses the resources
+
+135
+00:11:37,000 --> 00:11:39,000
+without user involvement.
+
+136
+00:11:40,000 --> 00:11:42,000
+Flow of AWS.
+
+137
+00:11:43,000 --> 00:11:47,000
+The client requests authorization from the resource owner.
+
+138
+00:11:47,000 --> 00:11:54,000
+The resource owner provides authorization granting an authorization code or token to the client.
+
+139
+00:11:55,000 --> 00:12:02,000
+The client uses this authorization to request an access token from the authorization server with the
+
+140
+00:12:02,000 --> 00:12:03,000
+access token.
+
+141
+00:12:03,000 --> 00:12:07,000
+The client can access the resource server on behalf of the user.
+
+142
+00:12:08,000 --> 00:12:15,000
+While OAuth effectively handles authorization, it does not provide a standard way to authenticate users.
+
+143
+00:12:15,000 --> 00:12:18,000
+This is where OpenID connect comes into play.
+
+144
+00:12:19,000 --> 00:12:27,000
+OpenID connect is an identity layer built on top of OAuth 2.0, designed to authenticate users and provide
+
+145
+00:12:27,000 --> 00:12:29,000
+basic profile information.
+
+146
+00:12:30,000 --> 00:12:38,000
+OpenID connect extends OAuth by introducing an identity token known as the ID token, which is a JSON
+
+147
+00:12:38,000 --> 00:12:41,000
+web token containing user authentication data.
+
+148
+00:12:41,000 --> 00:12:43,000
+Here's how OpenID connect works.
+
+149
+00:12:44,000 --> 00:12:46,000
+Authentication and identity information.
+
+150
+00:12:47,000 --> 00:12:52,000
+Oidc allows clients to authenticate users and obtain profile information.
+
+151
+00:12:53,000 --> 00:13:00,000
+The ID token contains claims about the user, such as their unique identifier, name, and email.
+
+152
+00:13:01,000 --> 00:13:05,000
+Similar to AWS, the client requests authorization.
+
+153
+00:13:05,000 --> 00:13:09,000
+The user logs in and consents to the requested access.
+
+154
+00:13:10,000 --> 00:13:13,000
+The authorization server issues an authorization code.
+
+155
+00:13:13,000 --> 00:13:19,000
+The client exchanges this code for both an access token and an ID token.
+
+156
+00:13:20,000 --> 00:13:24,000
+The ID token is then used by the client to verify the user's identity.
+
+157
+00:13:26,000 --> 00:13:29,000
+How OpenID is different from all auth.
+
+158
+00:13:29,000 --> 00:13:37,000
+In this case, the difference between OAuth 2.0 and OpenID connect lies in their primary purposes and
+
+159
+00:13:37,000 --> 00:13:39,000
+functionalities.
+
+160
+00:13:39,000 --> 00:13:47,000
+OAuth 2.0 is an authorization framework that enables third party applications to obtain limited access
+
+161
+00:13:47,000 --> 00:13:51,000
+to a user's resources without exposing their credentials.
+
+162
+00:13:51,000 --> 00:14:00,000
+In contrast, OpenID connect is an identity layer built on top of OAuth 2.0 that adds authentication,
+
+163
+00:14:00,000 --> 00:14:06,000
+allowing clients to verify the identity of the end user based on the authentication performed by an
+
+164
+00:14:06,000 --> 00:14:13,000
+authorization server, and to obtain basic profile information about the user in an interoperable and
+
+165
+00:14:13,000 --> 00:14:15,000
+Rest like manner.
+
+166
+00:14:15,000 --> 00:14:25,000
+Essentially, OAuth 2.0 deals with authorization granting access, while OpenID connect handles authentication.
+
+167
+00:14:25,000 --> 00:14:27,000
+Verifying identity.
+
+168
+00:14:28,000 --> 00:14:33,000
+Let's continue now review other best practices for mitigating broken authentication.
+
+169
+00:14:34,000 --> 00:14:37,000
+Understand and correctly implement standards.
+
+170
+00:14:37,000 --> 00:14:42,000
+It is not enough to simply use standard authentication mechanisms.
+
+171
+00:14:42,000 --> 00:14:46,000
+Understanding and correctly implementing them is crucial.
+
+172
+00:14:46,000 --> 00:14:52,000
+This involves ensuring that the configurations and flows defined by standards like OAuth and OpenID
+
+173
+00:14:52,000 --> 00:14:59,000
+connect are correctly followed, which helps in preventing common implementation mistakes that could
+
+174
+00:14:59,000 --> 00:15:01,000
+lead to vulnerabilities.
+
+175
+00:15:02,000 --> 00:15:05,000
+Implement API client secrets.
+
+176
+00:15:05,000 --> 00:15:09,000
+Ensures that API client secrets are securely stored and managed.
+
+177
+00:15:10,000 --> 00:15:17,000
+API client secrets should never be hard coded into source code or stored in publicly accessible locations.
+
+178
+00:15:18,000 --> 00:15:25,000
+Use secure storage solutions to keep these secrets safe, preventing unauthorized access to your APIs.
+
+179
+00:15:26,000 --> 00:15:28,000
+Enforce strong password policies.
+
+180
+00:15:29,000 --> 00:15:34,000
+Strong password policies are fundamental to securing authentication mechanisms.
+
+181
+00:15:35,000 --> 00:15:41,000
+Encourage users to create complex passwords that include a mix of symbols, capital letters, and numbers.
+
+182
+00:15:42,000 --> 00:15:49,000
+Additionally, enforce regular password changes and prevent the reuse of old passwords to minimize the
+
+183
+00:15:49,000 --> 00:15:51,000
+risk of credential compromise.
+
+184
+00:15:51,000 --> 00:15:58,000
+If you are a student of my Java from zero to first job course, then you already saw how we implemented
+
+185
+00:15:58,000 --> 00:16:05,000
+password validation on the front end and on the back end, forcing our new customers to create safe
+
+186
+00:16:05,000 --> 00:16:07,000
+and strong passwords.
+
+187
+00:16:08,000 --> 00:16:10,000
+Use multifactor authentication.
+
+188
+00:16:11,000 --> 00:16:15,000
+Implement multi-factor authentication to add an extra layer of security.
+
+189
+00:16:16,000 --> 00:16:24,000
+Multi-factor authentication requires users to provide two or more verification factors, making it significantly
+
+190
+00:16:24,000 --> 00:16:30,000
+more challenging for attackers to gain unauthorized access even if they have obtained the user's password.
+
+191
+00:16:32,000 --> 00:16:33,000
+Stricter rate limits.
+
+192
+00:16:33,000 --> 00:16:38,000
+This is very important rules that API developers often forget.
+
+193
+00:16:38,000 --> 00:16:44,000
+Apply strict rate limits to authentication endpoints to mitigate the risk of brute force attacks.
+
+194
+00:16:45,000 --> 00:16:51,000
+Rate limiting helps to detect and block suspicious activity, such as repeated login attempts from the
+
+195
+00:16:51,000 --> 00:16:57,000
+same IP address, thereby protecting against automated attacks like credential stuffing and password
+
+196
+00:16:57,000 --> 00:16:58,000
+spraying.
+
+197
+00:16:59,000 --> 00:17:06,000
+Avoid account lockouts while it is important to implement rate limits, avoid overly aggressive account
+
+198
+00:17:06,000 --> 00:17:07,000
+lockouts.
+
+199
+00:17:07,000 --> 00:17:15,000
+Locking out real users can lead to frustration and hinder their ability to perform essential tasks such
+
+200
+00:17:15,000 --> 00:17:16,000
+as password resets.
+
+201
+00:17:16,000 --> 00:17:24,000
+Instead, use mechanisms like temporary suspensions or captchas to slow down potential attackers without
+
+202
+00:17:24,000 --> 00:17:27,000
+permanently locking out legitimate users.
+
+203
+00:17:28,000 --> 00:17:31,000
+Password confirmation for sensitive actions.
+
+204
+00:17:31,000 --> 00:17:34,000
+I am sure that you are already familiar with this practice.
+
+205
+00:17:34,000 --> 00:17:41,000
+If you use banking apps or other application with the best programming practices, require password
+
+206
+00:17:41,000 --> 00:17:47,000
+confirmation for critical actions, especially for administrative accounts or sensitive operations such
+
+207
+00:17:47,000 --> 00:17:51,000
+as changing account settings or performing high value transactions.
+
+208
+00:17:52,000 --> 00:17:59,000
+This additional layer of security ensures that even if an attacker gains access to an account, they
+
+209
+00:17:59,000 --> 00:18:03,000
+cannot easily perform sensitive actions without real authenticating.
+
+210
+00:18:04,000 --> 00:18:09,000
+Protection of password recovery and reset endpoints.
+
+211
+00:18:09,000 --> 00:18:17,000
+Secure your password recovery and reset endpoints by implementing rate limiting CAPTCHAs and additional
+
+212
+00:18:17,000 --> 00:18:18,000
+verification steps.
+
+213
+00:18:18,000 --> 00:18:26,000
+These endpoints are often targeted by attackers, so it is crucial to protect them to prevent unauthorized
+
+214
+00:18:26,000 --> 00:18:27,000
+password resets.
+
+215
+00:18:28,000 --> 00:18:31,000
+Use runtime protection and testing.
+
+216
+00:18:31,000 --> 00:18:37,000
+Utilize runtime protection solutions that can detect and block API attacks in real time.
+
+217
+00:18:38,000 --> 00:18:44,000
+Additionally perform several testing for API vulnerabilities during the development life cycle.
+
+218
+00:18:44,000 --> 00:18:52,000
+Use both static application security testing and dynamic application security testing tools to identify
+
+219
+00:18:52,000 --> 00:18:56,000
+and address potential security flaws before deployment.
+
+220
+00:18:57,000 --> 00:19:03,000
+API gateways play a critical role in enforcing authentication and access control policies.
+
+221
+00:19:03,000 --> 00:19:11,000
+They act as a centralized point for managing and securing API traffic, ensuring that only authenticated
+
+222
+00:19:11,000 --> 00:19:13,000
+and authorized requests are processed.
+
+223
+00:19:14,000 --> 00:19:22,000
+Properly configured, API gateways can help mitigate many authentication related vulnerabilities, preventing
+
+224
+00:19:22,000 --> 00:19:23,000
+user enumeration.
+
+225
+00:19:23,000 --> 00:19:30,000
+Ensures that your application returns consistent error messages for both existing and non-existing users
+
+226
+00:19:30,000 --> 00:19:32,000
+during authentication attempts.
+
+227
+00:19:32,000 --> 00:19:39,000
+This prevents attackers from enumerating valid usernames and email addresses, which is often a precursor
+
+228
+00:19:39,000 --> 00:19:41,000
+to further attacks.
+
+229
+00:19:41,000 --> 00:19:46,000
+Probably you saw such message as username or password is incorrect.
+
+230
+00:19:46,000 --> 00:19:52,000
+This is considered as a good practice because reading message like this hacker can't understand if the
+
+231
+00:19:52,000 --> 00:19:56,000
+username is correct or no, or the problem is just in the password.
+
+232
+00:19:58,000 --> 00:20:04,000
+Perform regular security assessments and manual code reviews to identify and address potential vulnerabilities.
+
+233
+00:20:05,000 --> 00:20:10,000
+Automated tools are essential, but they should be complemented with manual reviews to catch complex
+
+234
+00:20:10,000 --> 00:20:13,000
+issues that automated scanners might miss.
+
diff --git a/74 - OWASP API Security Top 10 2023/007 API22023 Broken Authentication - P.3 - (Practice, JWT Tokens, Timing Attacks)_en.srt b/74 - OWASP API Security Top 10 2023/007 API22023 Broken Authentication - P.3 - (Practice, JWT Tokens, Timing Attacks)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..1e238aca7967c2bf9bb2823ad2c771dafa08654c
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/007 API22023 Broken Authentication - P.3 - (Practice, JWT Tokens, Timing Attacks)_en.srt
@@ -0,0 +1,1348 @@
+1
+00:00:04,000 --> 00:00:10,000
+I believe that we learned as much as we can about broken authentication, vulnerability and its prevention.
+
+2
+00:00:11,000 --> 00:00:14,000
+Now it is time to review real life code.
+
+3
+00:00:14,000 --> 00:00:14,000
+Example.
+
+4
+00:00:15,000 --> 00:00:21,000
+If you are a student of my Java from zero to first job course, then you are aware that during the course
+
+5
+00:00:21,000 --> 00:00:27,000
+we build online, shop from scratch and all examples we learn with this application.
+
+6
+00:00:27,000 --> 00:00:34,000
+So today you may hear e-commerce naming and terminology because usually it is super easy to understand
+
+7
+00:00:34,000 --> 00:00:38,000
+new concepts on the example of online shop.
+
+8
+00:00:38,000 --> 00:00:41,000
+Let's start from the review of the problem statement.
+
+9
+00:00:42,000 --> 00:00:47,000
+As always, you will be able to find all source code examples in attachments to the video.
+
+10
+00:00:48,000 --> 00:00:55,000
+And as always, if something is not clear for you, please just post your question below the video and
+
+11
+00:00:55,000 --> 00:00:56,000
+I will be happy to answer.
+
+12
+00:00:57,000 --> 00:01:02,000
+Let's start by examining the structure and functionality of this servlet.
+
+13
+00:01:02,000 --> 00:01:11,000
+The class Insecure Authentication servlet extends HTTP servlet, indicating that it handles HTTP requests
+
+14
+00:01:12,000 --> 00:01:16,000
+near the annotation of web servlet specified mapping.
+
+15
+00:01:16,000 --> 00:01:20,000
+This servlet is mapped to insecure out servlet.
+
+16
+00:01:20,000 --> 00:01:24,000
+You can see that only the post method is overridden in the servlet.
+
+17
+00:01:24,000 --> 00:01:29,000
+So that means that it handles only Post requests within the class.
+
+18
+00:01:29,000 --> 00:01:35,000
+We first declare a user facade instance, which is obtained through a singleton pattern.
+
+19
+00:01:36,000 --> 00:01:42,000
+This facade provides a simplified interface for interacting with the underlying user data store.
+
+20
+00:01:42,000 --> 00:01:47,000
+We implemented it in other lessons of my course Java from zero to first job.
+
+21
+00:01:47,000 --> 00:01:49,000
+You can check the source code.
+
+22
+00:01:49,000 --> 00:01:50,000
+It is pretty straightforward.
+
+23
+00:01:51,000 --> 00:01:57,000
+It is not directly related to the agenda of today's lesson, but if you have any questions, please
+
+24
+00:01:57,000 --> 00:01:59,000
+let me know about them.
+
+25
+00:02:00,000 --> 00:02:07,000
+The core of the servlets functionality resides in the Dopost method, which processes incoming Post
+
+26
+00:02:07,000 --> 00:02:07,000
+requests.
+
+27
+00:02:08,000 --> 00:02:14,000
+Upon receiving a request, the servlet extracts the email and password parameters from the request body.
+
+28
+00:02:15,000 --> 00:02:21,000
+These parameters are then used to fetch the corresponding user object from the user database via the
+
+29
+00:02:21,000 --> 00:02:22,000
+user facade.
+
+30
+00:02:23,000 --> 00:02:30,000
+Next, the code checks if the user exists and if the provided password matches the stored password.
+
+31
+00:02:31,000 --> 00:02:35,000
+Here we encounter our first security issue.
+
+32
+00:02:36,000 --> 00:02:39,000
+The password comparison is performed using the equals method.
+
+33
+00:02:40,000 --> 00:02:46,000
+This method is vulnerable to timing attacks as it may reveal information about the password based on
+
+34
+00:02:46,000 --> 00:02:49,000
+the time taken to compare the strings.
+
+35
+00:02:49,000 --> 00:02:53,000
+By the way, this is also an interesting topic to talk about.
+
+36
+00:02:53,000 --> 00:02:56,000
+Let me explain you about timing attacks.
+
+37
+00:02:57,000 --> 00:03:04,000
+When discussing the security of password comparison, it's crucial to consider protection against timing
+
+38
+00:03:04,000 --> 00:03:04,000
+attacks.
+
+39
+00:03:05,000 --> 00:03:11,000
+A timing attack is a form of side channel attack, where an attacker attempts to compromise a system
+
+40
+00:03:11,000 --> 00:03:15,000
+by analyzing the time taken to execute cryptographic algorithms.
+
+41
+00:03:17,000 --> 00:03:21,000
+To understand why the equals method for password comparison can be problematic.
+
+42
+00:03:21,000 --> 00:03:25,000
+Let's break down its operation step by step.
+
+43
+00:03:26,000 --> 00:03:31,000
+Firstly, consider how the equals method in Java compares two strings.
+
+44
+00:03:31,000 --> 00:03:34,000
+It does so character by character.
+
+45
+00:03:34,000 --> 00:03:38,000
+If the method finds a mismatch, it immediately returns false.
+
+46
+00:03:39,000 --> 00:03:45,000
+This means that if the first character of the password doesn't match, the message stops immediately
+
+47
+00:03:45,000 --> 00:03:52,000
+and returns false if the first character matches but the second does not, the message stops after comparing
+
+48
+00:03:52,000 --> 00:03:54,000
+the second character, and so on.
+
+49
+00:03:55,000 --> 00:04:00,000
+This brings us to our next point, the variable time taken for comparisons.
+
+50
+00:04:01,000 --> 00:04:07,000
+Because the equals method stops at the first mismatch, the time it takes to compare two strings depends
+
+51
+00:04:07,000 --> 00:04:09,000
+on how much of the strings match.
+
+52
+00:04:10,000 --> 00:04:17,000
+For instance, comparing password one with password two will take longer than comparing password one
+
+53
+00:04:17,000 --> 00:04:20,000
+with password zero arg2.
+
+54
+00:04:20,000 --> 00:04:23,000
+If the mismatch is further along the string.
+
+55
+00:04:24,000 --> 00:04:28,000
+This behavior opens up the system to a timing attack.
+
+56
+00:04:28,000 --> 00:04:34,000
+An attacker can exploit this by sending different passwords and measuring the time taken to receive
+
+57
+00:04:34,000 --> 00:04:35,000
+a response.
+
+58
+00:04:35,000 --> 00:04:42,000
+By analyzing these response times, the attacker can deduce how many characters of the guest password
+
+59
+00:04:42,000 --> 00:04:43,000
+were correct.
+
+60
+00:04:43,000 --> 00:04:48,000
+Through multiple attempts, the attacker can eventually determine the entire password.
+
+61
+00:04:49,000 --> 00:04:56,000
+To illustrate this with an example, suppose the stored password is secret 123.
+
+62
+00:04:57,000 --> 00:04:59,000
+The attacker first tries s.
+
+63
+00:04:59,000 --> 00:05:05,000
+If the response time is very short, the attacker knows that the first character is correct.
+
+64
+00:05:05,000 --> 00:05:10,000
+Next, the attacker tries C, then C, C, and so on.
+
+65
+00:05:10,000 --> 00:05:16,000
+By measuring and analyzing the time taken for each attempt, the attacker can determine each subsequent
+
+66
+00:05:16,000 --> 00:05:17,000
+character.
+
+67
+00:05:18,000 --> 00:05:22,000
+To mitigate this risk, we use a constant time comparison function.
+
+68
+00:05:23,000 --> 00:05:29,000
+A constant time comparison function takes the same amount of time to compare two strings, regardless
+
+69
+00:05:29,000 --> 00:05:30,000
+of their content.
+
+70
+00:05:31,000 --> 00:05:38,000
+This ensures that an attacker cannot gain useful information based on the time taken to compare passwords.
+
+71
+00:05:38,000 --> 00:05:44,000
+During review of the solution, I will show you how to avoid risk of timing attack in Java.
+
+72
+00:05:45,000 --> 00:05:47,000
+At the meantime, let's continue.
+
+73
+00:05:48,000 --> 00:05:55,000
+If the authentication is successful, the servlet generates a token using the generate weak token method.
+
+74
+00:05:56,000 --> 00:06:03,000
+This method is just an example, just one of possible ways that can become another source of vulnerability.
+
+75
+00:06:03,000 --> 00:06:08,000
+It creates a token by simply appending the email to a string prefix.
+
+76
+00:06:08,000 --> 00:06:08,000
+Token.
+
+77
+00:06:08,000 --> 00:06:09,000
+Underscore.
+
+78
+00:06:10,000 --> 00:06:14,000
+And again, this is just an example of weak and vulnerable token.
+
+79
+00:06:14,000 --> 00:06:18,000
+There can be different variations that may cause vulnerability.
+
+80
+00:06:18,000 --> 00:06:21,000
+Basically any predictable sequence of characters.
+
+81
+00:06:21,000 --> 00:06:28,000
+This approach results in weak tokens that are predictable and easily guessable, lacking any form of
+
+82
+00:06:28,000 --> 00:06:30,000
+encryption or expiration policy.
+
+83
+00:06:31,000 --> 00:06:36,000
+The generated token is then returned to the client as a JSON response.
+
+84
+00:06:36,000 --> 00:06:44,000
+The content type of the response is set to application JSON, and the HTTP status code is set to 200
+
+85
+00:06:44,000 --> 00:06:44,000
+okay.
+
+86
+00:06:45,000 --> 00:06:52,000
+Conversely, if authentication fails, the servlet responds with a 401 unauthorized status code.
+
+87
+00:06:53,000 --> 00:06:57,000
+In summary, this example illustrates several critical vulnerabilities.
+
+88
+00:06:57,000 --> 00:07:05,000
+Weak password comparison using the equals method for password comparison can lead to timing attacks.
+
+89
+00:07:06,000 --> 00:07:08,000
+Weak token generation.
+
+90
+00:07:08,000 --> 00:07:15,000
+Tokens generated in this manner are predictable and lack security features such as encryption and expiration.
+
+91
+00:07:16,000 --> 00:07:18,000
+Absence of rate limits.
+
+92
+00:07:18,000 --> 00:07:25,000
+If hacker wants, they can send multiple requests with the help of automated scripts without any blockers.
+
+93
+00:07:25,000 --> 00:07:29,000
+This is also can be treated as vulnerability.
+
+94
+00:07:30,000 --> 00:07:32,000
+Lack of token expiration.
+
+95
+00:07:32,000 --> 00:07:39,000
+The generated tokens do not expire, which can lead to long term security risks if a token is compromised.
+
+96
+00:07:40,000 --> 00:07:47,000
+Insecure authentication logic, the overall approach to authentication is simplistic and does not follow
+
+97
+00:07:47,000 --> 00:07:50,000
+best practices for secure authentication.
+
+98
+00:07:52,000 --> 00:07:54,000
+Let's review another insecure servlet.
+
+99
+00:07:55,000 --> 00:08:02,000
+This servlets primary function is to fetch and return user data based on an authentication token provided
+
+100
+00:08:02,000 --> 00:08:03,000
+in the request.
+
+101
+00:08:03,000 --> 00:08:09,000
+In this class, I have user facade to fetch user from database by email.
+
+102
+00:08:09,000 --> 00:08:13,000
+Have JSON object to convert object to JSON when sending it to the client.
+
+103
+00:08:14,000 --> 00:08:21,000
+I hope you already know based on your experience, that JSON is library that works with JSON and knows
+
+104
+00:08:21,000 --> 00:08:24,000
+how to convert objects to JSON and vice versa.
+
+105
+00:08:25,000 --> 00:08:26,000
+We need it for this example.
+
+106
+00:08:27,000 --> 00:08:32,000
+The do get method is overridden to handle get requests made to this servlet.
+
+107
+00:08:32,000 --> 00:08:36,000
+The servlet begins by extracting the authorization header from the request.
+
+108
+00:08:36,000 --> 00:08:40,000
+It checks if the header is present and begins with bearer.
+
+109
+00:08:40,000 --> 00:08:43,000
+If so, it extracts the token part of the header.
+
+110
+00:08:43,000 --> 00:08:49,000
+This token is then passed to the validate week token method to determine its validity.
+
+111
+00:08:50,000 --> 00:08:56,000
+In the Validate week token method, the token is checked to see if it starts with token underscore.
+
+112
+00:08:56,000 --> 00:09:04,000
+If it does, the method extracts and returns the portion of the token that follows token underscore.
+
+113
+00:09:04,000 --> 00:09:08,000
+This approach is just an example of weak token validation.
+
+114
+00:09:09,000 --> 00:09:16,000
+If the email extracted from the token is not null, the servlet retrieves user data associated with
+
+115
+00:09:16,000 --> 00:09:18,000
+that email from the user facade.
+
+116
+00:09:19,000 --> 00:09:25,000
+The response is then prepared in JSON format and sent back with an HTTP status of 200.
+
+117
+00:09:25,000 --> 00:09:30,000
+Okay, if the token validation fails, that is, email is null.
+
+118
+00:09:31,000 --> 00:09:36,000
+The servlet response was 401 unauthorized status code.
+
+119
+00:09:37,000 --> 00:09:39,000
+So what's wrong with this servlet?
+
+120
+00:09:39,000 --> 00:09:45,000
+The major security flaw in this survey lies in its token validation method.
+
+121
+00:09:46,000 --> 00:09:52,000
+The validate weak token method performs only a basic check for the token prefix, and extracts the email
+
+122
+00:09:52,000 --> 00:09:55,000
+without validating the tokens authenticity.
+
+123
+00:09:56,000 --> 00:10:03,000
+This approach makes the servlet vulnerable to several attacks, including token forgery.
+
+124
+00:10:03,000 --> 00:10:09,000
+Attackers could craft tokens starting with token underscore to gain unauthorized access.
+
+125
+00:10:10,000 --> 00:10:17,000
+Lack of token integrity checks without verifying the tokens signature or expiration, the server cannot
+
+126
+00:10:17,000 --> 00:10:19,000
+ensure that the token is legitimate.
+
+127
+00:10:20,000 --> 00:10:23,000
+Let me show you this API with postman.
+
+128
+00:10:24,000 --> 00:10:29,000
+I believe that you are familiar with postman tool and use it for API testing tool.
+
+129
+00:10:29,000 --> 00:10:35,000
+If no, then feel free to ask me questions below the video and I will be happy to answer you.
+
+130
+00:10:36,000 --> 00:10:43,000
+Also in my course Java from zero to first job, you will learn how to use tools for API testing in details.
+
+131
+00:10:44,000 --> 00:10:52,000
+And right now let's focus on API testing itself so that you can understand why the API from example
+
+132
+00:10:52,000 --> 00:10:53,000
+is vulnerable.
+
+133
+00:10:53,000 --> 00:10:59,000
+So hacker can implement script that with brute force will send millions of requests.
+
+134
+00:10:59,000 --> 00:11:03,000
+And finally credentials will be guessed.
+
+135
+00:11:03,000 --> 00:11:10,000
+Or if pattern of authorization token is predictable and based on their own credentials, hackers can
+
+136
+00:11:10,000 --> 00:11:13,000
+analyze how token is formed.
+
+137
+00:11:13,000 --> 00:11:15,000
+Then our code is vulnerable.
+
+138
+00:11:15,000 --> 00:11:21,000
+In this particular case, hacker can just guess that we add prefix before the email to generate token,
+
+139
+00:11:22,000 --> 00:11:28,000
+even if there will be more complex token, but algorithm of its generation will be predictable and deterministic.
+
+140
+00:11:28,000 --> 00:11:30,000
+Then we are in trouble.
+
+141
+00:11:30,000 --> 00:11:35,000
+That's why it is recommended to use secret key to generate authorization token.
+
+142
+00:11:36,000 --> 00:11:38,000
+When we will get to the solution review, I will show you.
+
+143
+00:11:39,000 --> 00:11:46,000
+So regarding this endpoint you can see that in the request body I send credentials and receive token.
+
+144
+00:11:47,000 --> 00:11:53,000
+Now I can copy this token and use another endpoint to send requests.
+
+145
+00:11:53,000 --> 00:11:57,000
+For this endpoint I need to click on the tab authorization.
+
+146
+00:11:57,000 --> 00:12:02,000
+For the authorization type, I select auth 2.0.
+
+147
+00:12:02,000 --> 00:12:05,000
+In the token text field, I insert generated token.
+
+148
+00:12:06,000 --> 00:12:12,000
+For header prefix I leave a default value and I send requests like this.
+
+149
+00:12:12,000 --> 00:12:15,000
+I receive user details in response.
+
+150
+00:12:15,000 --> 00:12:22,000
+Of course, if I would adjust token and send request one more time, of course I will not receive user
+
+151
+00:12:22,000 --> 00:12:30,000
+details because there is no user with such email and it seems like API works as expected.
+
+152
+00:12:30,000 --> 00:12:34,000
+But no, that's definitely not how we want to build our API.
+
+153
+00:12:34,000 --> 00:12:38,000
+It has a lot of vulnerabilities that we already talked about.
+
+154
+00:12:39,000 --> 00:12:44,000
+Let me show you the solution and I will point out the things where we did some improvements.
+
+155
+00:12:45,000 --> 00:12:48,000
+I'm going to start review from the G2 class.
+
+156
+00:12:48,000 --> 00:12:51,000
+You already know what a GPG token is.
+
+157
+00:12:51,000 --> 00:12:56,000
+So I decided to put all the logic of work with JWT tokens in this class.
+
+158
+00:12:56,000 --> 00:13:02,000
+This class provides essential functions such as generating and validating tweets.
+
+159
+00:13:03,000 --> 00:13:08,000
+Let's walk through the code and understand its components and functionality in detail.
+
+160
+00:13:08,000 --> 00:13:13,000
+First and foremost, observe the use of a secret key within this class.
+
+161
+00:13:13,000 --> 00:13:17,000
+It's crucial to note the comments emphasizing the best practice.
+
+162
+00:13:17,000 --> 00:13:20,000
+Never store secret keys in the source code.
+
+163
+00:13:20,000 --> 00:13:22,000
+Use secret key vaults.
+
+164
+00:13:23,000 --> 00:13:25,000
+This is an important security consideration.
+
+165
+00:13:25,000 --> 00:13:31,000
+Storing secret keys directly in your source code can expose your application to significant security
+
+166
+00:13:31,000 --> 00:13:32,000
+risks.
+
+167
+00:13:33,000 --> 00:13:39,000
+Instead, these keys should be managed securely using a secrets management system or key vault.
+
+168
+00:13:39,000 --> 00:13:44,000
+But to not complicate this example, and for the sake of the demo, I will keep it here.
+
+169
+00:13:44,000 --> 00:13:50,000
+The secret key in this example is represented as a base 64 encoded string.
+
+170
+00:13:50,000 --> 00:13:57,000
+This string is decoded and used to create a secret key instance, which is essential for signing and
+
+171
+00:13:57,000 --> 00:13:59,000
+verifying the JWT keys.
+
+172
+00:13:59,000 --> 00:14:05,000
+Moving on to the functionality of this class, we begin with the Generate token method.
+
+173
+00:14:05,000 --> 00:14:10,000
+This method is responsible for creating a JWT for a given user email.
+
+174
+00:14:10,000 --> 00:14:16,000
+It sets the subject of the token to the provided user email, and includes an issue that date and an
+
+175
+00:14:16,000 --> 00:14:20,000
+expiration date set to ten days from the current time.
+
+176
+00:14:21,000 --> 00:14:27,000
+So that means that even in some edge cases, token will be compromised anyway.
+
+177
+00:14:27,000 --> 00:14:29,000
+Client need to generate a new token.
+
+178
+00:14:29,000 --> 00:14:35,000
+Notice the signed with method which uses the secret key to sign the token.
+
+179
+00:14:35,000 --> 00:14:41,000
+This ensures the integrity and authenticity of the token, meaning that any tampering will render the
+
+180
+00:14:41,000 --> 00:14:42,000
+token invalid.
+
+181
+00:14:43,000 --> 00:14:48,000
+Pay attention that in this case I use library that is called JSON Web token.
+
+182
+00:14:48,000 --> 00:14:54,000
+I added dependency in the pom qml file on the latest version of this library.
+
+183
+00:14:54,000 --> 00:14:58,000
+You will be able to find it in the source code from attachments two.
+
+184
+00:14:59,000 --> 00:15:02,000
+Next we have the is token valid method.
+
+185
+00:15:02,000 --> 00:15:07,000
+This method validates a given JWT to ensure its integrity and validity.
+
+186
+00:15:08,000 --> 00:15:13,000
+Here a JWT parser is created with a secret key.
+
+187
+00:15:14,000 --> 00:15:17,000
+The parser method attempts to parse the token.
+
+188
+00:15:17,000 --> 00:15:25,000
+If the token is valid, the method returns true if any exception occurs, indicating that the token
+
+189
+00:15:25,000 --> 00:15:27,000
+is invalid or tampered with.
+
+190
+00:15:27,000 --> 00:15:30,000
+The method catches the exception and returns false.
+
+191
+00:15:31,000 --> 00:15:37,000
+Finally, the parse token method is used to extract claims from a given JWT.
+
+192
+00:15:38,000 --> 00:15:42,000
+What are claims in the context of JSON web tokens?
+
+193
+00:15:42,000 --> 00:15:46,000
+Claims are pieces of information that are encoded into the token.
+
+194
+00:15:47,000 --> 00:15:54,000
+They are integral to JWT as they provide the necessary context and data for authentication and authorization.
+
+195
+00:15:55,000 --> 00:16:02,000
+This method, similar to this token valid, uses the Dupli parser, but returns the parsed claims if
+
+196
+00:16:02,000 --> 00:16:03,000
+the token is valid.
+
+197
+00:16:04,000 --> 00:16:10,000
+These claims can contain various pieces of information about the token subject, such as the user email
+
+198
+00:16:10,000 --> 00:16:11,000
+in our case.
+
+199
+00:16:12,000 --> 00:16:14,000
+Let's review the next class.
+
+200
+00:16:14,000 --> 00:16:17,000
+It is called Secure Authentication Servlet.
+
+201
+00:16:18,000 --> 00:16:24,000
+We are going to use this class to generate secure token for further authorization in the applications
+
+202
+00:16:24,000 --> 00:16:24,000
+API.
+
+203
+00:16:25,000 --> 00:16:32,000
+This class incorporates several critical mechanisms to prevent broken authentication vulnerabilities,
+
+204
+00:16:32,000 --> 00:16:37,000
+ensuring a robust approach to managing user credentials and access tokens.
+
+205
+00:16:38,000 --> 00:16:45,000
+The Secure Authentication Servlet class extends HTTP servlet and provides a secure implementation for
+
+206
+00:16:45,000 --> 00:16:49,000
+user authentication via an HTTP post request.
+
+207
+00:16:50,000 --> 00:16:57,000
+It interacts with a user facade to retrieve user details and validates login attempts while implementing
+
+208
+00:16:57,000 --> 00:17:00,000
+security measures to mitigate common vulnerabilities.
+
+209
+00:17:01,000 --> 00:17:04,000
+Let me highlight key components of the class.
+
+210
+00:17:05,000 --> 00:17:07,000
+Rate limiting.
+
+211
+00:17:07,000 --> 00:17:14,000
+One of the primary security features of this server is rate limiting, which is crucial for preventing
+
+212
+00:17:14,000 --> 00:17:16,000
+abuse such as brute force attacks.
+
+213
+00:17:17,000 --> 00:17:23,000
+The class uses a concurrent hash map to track the number of requests made by each client IP address.
+
+214
+00:17:24,000 --> 00:17:25,000
+Here's how it works.
+
+215
+00:17:26,000 --> 00:17:33,000
+Request tracking the request data in a class holds the request count and the timestamp of the first
+
+216
+00:17:33,000 --> 00:17:35,000
+request within a time window.
+
+217
+00:17:36,000 --> 00:17:43,000
+This allows a servlet to keep track of how many requests a specific IP has made, and when the window
+
+218
+00:17:43,000 --> 00:17:44,000
+started.
+
+219
+00:17:45,000 --> 00:17:48,000
+Rate limiting logic is a is allowed.
+
+220
+00:17:48,000 --> 00:17:53,000
+Method checks if the client IP has exceeded the allowed number of requests per minute.
+
+221
+00:17:54,000 --> 00:18:03,000
+If the number of requests is too high, the server responds with a 429 status code indicating too many
+
+222
+00:18:03,000 --> 00:18:04,000
+requests.
+
+223
+00:18:04,000 --> 00:18:10,000
+This helps to prevent an attacker from overwhelming the server with excessive logging attempts.
+
+224
+00:18:11,000 --> 00:18:18,000
+The Isallowed method now includes logic to reset the request count if more than one minute has passed
+
+225
+00:18:18,000 --> 00:18:20,000
+since the last request.
+
+226
+00:18:21,000 --> 00:18:27,000
+This ensures that the request count is reset periodically, allowing the client to make new requests
+
+227
+00:18:27,000 --> 00:18:30,000
+after the time limit has expired.
+
+228
+00:18:30,000 --> 00:18:37,000
+You can adjust the rate limit on the time period easily by changing the max underscore requests underscore
+
+229
+00:18:37,000 --> 00:18:42,000
+per underscore minute and the time comparison logic in is allowed.
+
+230
+00:18:43,000 --> 00:18:45,000
+Password handling.
+
+231
+00:18:46,000 --> 00:18:52,000
+The servlet illustrates a method of comparing passwords using message digest dot is equal.
+
+232
+00:18:53,000 --> 00:18:59,000
+This approach is an improvement over using string equals, which is susceptible to timing attacks.
+
+233
+00:19:00,000 --> 00:19:07,000
+Message digest is equal is designed to compare byte arrays in constant time, meaning that the time
+
+234
+00:19:07,000 --> 00:19:13,000
+it takes to perform the comparison does not vary based on the content of the inputs.
+
+235
+00:19:13,000 --> 00:19:19,000
+This feature helps prevent timing attacks which exploit differences in comparison.
+
+236
+00:19:19,000 --> 00:19:22,000
+Time to infer information about the password.
+
+237
+00:19:23,000 --> 00:19:28,000
+As you can see, the code compares the stored password with the provided password.
+
+238
+00:19:28,000 --> 00:19:35,000
+However, it's important to note that in a production environment, passwords should be hashed and salted,
+
+239
+00:19:35,000 --> 00:19:37,000
+not stored in plain text.
+
+240
+00:19:38,000 --> 00:19:39,000
+Token generation.
+
+241
+00:19:40,000 --> 00:19:46,000
+Upon successful authentication, the server generates a JWT token using the JRT utils generate token
+
+242
+00:19:46,000 --> 00:19:47,000
+method.
+
+243
+00:19:47,000 --> 00:19:51,000
+This token is then sent to the client as a JSON response.
+
+244
+00:19:52,000 --> 00:19:59,000
+The token acts as a credential that the client can use for subsequent requests to authenticate itself.
+
+245
+00:19:59,000 --> 00:20:09,000
+If the user credentials are incorrect or missing, the servlet responds with a 401 status code unauthorized,
+
+246
+00:20:09,000 --> 00:20:14,000
+ensuring Ensuring that only authenticated users can access the protected resource.
+
+247
+00:20:15,000 --> 00:20:19,000
+And let's finally review the third class of my solution.
+
+248
+00:20:19,000 --> 00:20:24,000
+The primary function of this survey is to provide user data in a secure manner.
+
+249
+00:20:25,000 --> 00:20:32,000
+To begin with, the survey relies on a user facade implementation, specifically the default user facade,
+
+250
+00:20:32,000 --> 00:20:35,000
+which is used to interact with the user data layer.
+
+251
+00:20:36,000 --> 00:20:41,000
+This instance of user facade is initialized when the servlet is created.
+
+252
+00:20:42,000 --> 00:20:48,000
+Additionally, the class includes a JSON object, which is a library used for converting Java objects
+
+253
+00:20:48,000 --> 00:20:52,000
+into the JSON representation, and vice versa.
+
+254
+00:20:53,000 --> 00:20:59,000
+When a Get request is received, the service do get method is invoked.
+
+255
+00:20:59,000 --> 00:21:06,000
+The first task within this method is to check for the presence of an authorization header in the request.
+
+256
+00:21:06,000 --> 00:21:15,000
+This header is expected to contain a JSON web token, which is a standard way to securely transmit information
+
+257
+00:21:15,000 --> 00:21:16,000
+between parties.
+
+258
+00:21:17,000 --> 00:21:25,000
+The code verifies that the authorization header starts with the prefix bearer If this prefix is present,
+
+259
+00:21:25,000 --> 00:21:27,000
+the token is extracted from the header.
+
+260
+00:21:28,000 --> 00:21:34,000
+The next step is to validate this token using the JWT utils is token valid method.
+
+261
+00:21:35,000 --> 00:21:40,000
+This method checks whether the token is legitimate and has not expired.
+
+262
+00:21:41,000 --> 00:21:48,000
+Assuming the token is valid, the servlet proceeds to parse the token to extract the user's email address
+
+263
+00:21:48,000 --> 00:21:49,000
+from the tokens payload.
+
+264
+00:21:50,000 --> 00:21:57,000
+This email address is then used to fetch the corresponding user data from the user data layer, using
+
+265
+00:21:57,000 --> 00:21:58,000
+the user facade.
+
+266
+00:21:58,000 --> 00:22:00,000
+Getuser by email method.
+
+267
+00:22:01,000 --> 00:22:07,000
+Once the user data is retrieved, the servlet prepares a JSON response containing the user information.
+
+268
+00:22:08,000 --> 00:22:12,000
+It sends the response content type to application JSON.
+
+269
+00:22:13,000 --> 00:22:21,000
+Writes the user data as a JSON string into the response body, and sets the HTTP status code to 200
+
+270
+00:22:21,000 --> 00:22:25,000
+okay, indicating that the request was successful.
+
+271
+00:22:26,000 --> 00:22:32,000
+In case of any errors during token validation or user data retrieval, or if the token is invalid,
+
+272
+00:22:33,000 --> 00:22:39,000
+the servlet responds with an HTTP status code of 401 unauthorized.
+
+273
+00:22:40,000 --> 00:22:46,000
+This status code signifies that the request could not be fulfilled due to authentication issues.
+
+274
+00:22:47,000 --> 00:22:54,000
+In the updated solution, significant improvements have been made to address the vulnerabilities present
+
+275
+00:22:54,000 --> 00:22:55,000
+in the previous examples.
+
+276
+00:22:56,000 --> 00:23:02,000
+Here's how the new solution addresses and mitigates the weaknesses from the problem statement.
+
+277
+00:23:02,000 --> 00:23:03,000
+Source code examples.
+
+278
+00:23:05,000 --> 00:23:07,000
+Enhanced password comparison.
+
+279
+00:23:07,000 --> 00:23:12,000
+The new solution uses a constant time comparison method for password validation.
+
+280
+00:23:13,000 --> 00:23:15,000
+Improved token generation.
+
+281
+00:23:16,000 --> 00:23:21,000
+The new implementation uses JSON web tokens with a securely generated secret key.
+
+282
+00:23:22,000 --> 00:23:24,000
+Implementation of rate limiting.
+
+283
+00:23:25,000 --> 00:23:31,000
+The new solution introduces rate limiting by tracking the number of requests per minute from each client
+
+284
+00:23:31,000 --> 00:23:31,000
+IP.
+
+285
+00:23:32,000 --> 00:23:39,000
+If the number of requests exceeds a predefined threshold, further requests are blocked, thereby mitigating
+
+286
+00:23:39,000 --> 00:23:44,000
+brute force attacks and improving the robustness of the authentication system.
+
+287
+00:23:45,000 --> 00:23:47,000
+Token expiration management.
+
+288
+00:23:48,000 --> 00:23:54,000
+Proper implementation should include setting an expiration date for the token to ensure that it becomes
+
+289
+00:23:54,000 --> 00:24:01,000
+invalid after a certain period, thus reducing the risk associated with token misuse.
+
+290
+00:24:02,000 --> 00:24:04,000
+Secure authentication logic.
+
+291
+00:24:05,000 --> 00:24:10,000
+The revised solution employs more secure practices by using constant time comparisons.
+
+292
+00:24:10,000 --> 00:24:15,000
+Implementing gates for token management and enforcing rate limits.
+
+293
+00:24:16,000 --> 00:24:23,000
+And finally, let's check this API in the postman and you will see that this code is more reliable than
+
+294
+00:24:23,000 --> 00:24:24,000
+previous one.
+
+295
+00:24:24,000 --> 00:24:29,000
+The interaction will look in the similar way in the request body.
+
+296
+00:24:29,000 --> 00:24:33,000
+I send my credentials and I want to request a token.
+
+297
+00:24:34,000 --> 00:24:36,000
+And here is an authorization token.
+
+298
+00:24:37,000 --> 00:24:40,000
+I believe you can notice that it is more complex.
+
+299
+00:24:40,000 --> 00:24:42,000
+Let me copy it to the clipboard.
+
+300
+00:24:43,000 --> 00:24:48,000
+And now I want to show you one more difference of this updated API.
+
+301
+00:24:48,000 --> 00:24:54,000
+The difference is that I will not be able to request for token more than five times per one minute.
+
+302
+00:24:55,000 --> 00:25:01,000
+So if I would send few more requests, then I will see error message when I will send six requests within
+
+303
+00:25:01,000 --> 00:25:02,000
+a minute.
+
+304
+00:25:03,000 --> 00:25:07,000
+As you can see on the screen, I received error message.
+
+305
+00:25:07,000 --> 00:25:09,000
+Too many requests.
+
+306
+00:25:09,000 --> 00:25:18,000
+Now our API became more reliable and now I can request user details from the second endpoint using my
+
+307
+00:25:18,000 --> 00:25:19,000
+authorization token.
+
+308
+00:25:20,000 --> 00:25:23,000
+I just open authorization tab in postman.
+
+309
+00:25:24,000 --> 00:25:26,000
+I add authorization token here.
+
+310
+00:25:27,000 --> 00:25:31,000
+This will add authorization header to the HTTP request.
+
+311
+00:25:31,000 --> 00:25:34,000
+And now I'm ready to send the request.
+
+312
+00:25:35,000 --> 00:25:38,000
+Do you remember the source code of this endpoint.
+
+313
+00:25:39,000 --> 00:25:41,000
+In this token user email is encoded.
+
+314
+00:25:42,000 --> 00:25:50,000
+So my back end will be able to retrieve email from this token without a problem, and using user email,
+
+315
+00:25:50,000 --> 00:25:54,000
+my application will extract user details from the database.
+
+316
+00:25:55,000 --> 00:25:58,000
+Yes, that's how it works.
+
+317
+00:25:58,000 --> 00:26:04,000
+If you have any questions, please do not hesitate to post your questions below the video and I will
+
+318
+00:26:04,000 --> 00:26:06,000
+be happy to answer.
+
+319
+00:26:07,000 --> 00:26:12,000
+That's all what I wanted to discuss with you in scope of broken authentication lesson.
+
+320
+00:26:12,000 --> 00:26:15,000
+Let's recap what we have learned in this lesson.
+
+321
+00:26:16,000 --> 00:26:23,000
+We explored the concept of broken authentication, including its definition and the common misconceptions
+
+322
+00:26:23,000 --> 00:26:26,000
+associated with API authentication.
+
+323
+00:26:27,000 --> 00:26:31,000
+We examined various authentication mechanisms and their vulnerabilities.
+
+324
+00:26:32,000 --> 00:26:37,000
+Gaining insight into how these issues can be detected with current methodologies.
+
+325
+00:26:38,000 --> 00:26:44,000
+We connected these concepts to the OWASp top ten, distinguishing between authentication and access
+
+326
+00:26:44,000 --> 00:26:50,000
+control, and understanding how broken authentication can lead to broken access control.
+
+327
+00:26:51,000 --> 00:26:58,000
+Through examples of interconnected vulnerabilities and exploits, we identified the root causes of broken
+
+328
+00:26:58,000 --> 00:27:01,000
+authentication and discussed different types of attacks.
+
+329
+00:27:02,000 --> 00:27:09,000
+We reviewed technical factors contributing to vulnerabilities, including automated attacks, poor standards,
+
+330
+00:27:09,000 --> 00:27:12,000
+and mis implementation of authentication mechanisms.
+
+331
+00:27:14,000 --> 00:27:21,000
+We analyzed real life case studies, drawing lessons learned and understanding the impact on consequences
+
+332
+00:27:21,000 --> 00:27:24,000
+of broken authentication vulnerabilities.
+
+333
+00:27:25,000 --> 00:27:32,000
+We covered best practices for mitigating these vulnerabilities, compared OAuth and OpenID, and reviewed
+
+334
+00:27:32,000 --> 00:27:39,000
+a real life code example addressing both problems and solutions, including how to avoid timing attacks.
+
+335
+00:27:40,000 --> 00:27:42,000
+That's all for this lesson.
+
+336
+00:27:42,000 --> 00:27:44,000
+Thanks a lot for your attention.
+
+337
+00:27:44,000 --> 00:27:47,000
+Have a great day and see you in the next lesson.
+
diff --git a/74 - OWASP API Security Top 10 2023/007 Source-code-examples-from-the-lesson.url b/74 - OWASP API Security Top 10 2023/007 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..ee91fbadb6fd51ec8eabb4703b58aba815b8f7db
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/007 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/commit/42ee72c9ea198a0f66d42ce8cab8a501d8995600
\ No newline at end of file
diff --git a/74 - OWASP API Security Top 10 2023/008 API32023 Broken Object Property Level Authorization - Part 1_en.srt b/74 - OWASP API Security Top 10 2023/008 API32023 Broken Object Property Level Authorization - Part 1_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..f5adeea1aef3526ea030438c718af01e4f36bdfa
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/008 API32023 Broken Object Property Level Authorization - Part 1_en.srt
@@ -0,0 +1,988 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:08,000
+Happy to see you in the lesson.
+
+3
+00:00:08,000 --> 00:00:13,000
+This time we will talk about broken object property level authorization.
+
+4
+00:00:13,000 --> 00:00:19,000
+Today we will delve into broken object property level authorization and its critical role in API security.
+
+5
+00:00:20,000 --> 00:00:25,000
+We will start by defining what it is and why it's essential to secure your APIs.
+
+6
+00:00:26,000 --> 00:00:32,000
+We'll then identify potential threat agents and attack vectors, highlighting common security weaknesses
+
+7
+00:00:32,000 --> 00:00:34,000
+and their impacts.
+
+8
+00:00:34,000 --> 00:00:40,000
+We'll discuss the real world consequences of these vulnerabilities with two practical examples a fitness
+
+9
+00:00:40,000 --> 00:00:45,000
+apps, workout tracking, and an online learning platforms quiz submissions.
+
+10
+00:00:45,000 --> 00:00:51,000
+Next, we'll cover prevention measures including implementing access controls, minimizing data exposure
+
+11
+00:00:51,000 --> 00:00:56,000
+using schema based validation, and avoiding overreliance on client side filtering.
+
+12
+00:00:57,000 --> 00:01:03,000
+We'll also explore related concepts like excessive data exposure and mass assignment from the OWASp
+
+13
+00:01:03,000 --> 00:01:04,000
+API top ten.
+
+14
+00:01:05,000 --> 00:01:11,000
+Finally, we'll review practical source code examples from an online shop to see how these concepts
+
+15
+00:01:11,000 --> 00:01:13,000
+are applied in real scenarios.
+
+16
+00:01:13,000 --> 00:01:15,000
+Let's start our lesson.
+
+17
+00:01:16,000 --> 00:01:22,000
+Today we are diving into the critical concept of broken object property level authorization, one of
+
+18
+00:01:22,000 --> 00:01:24,000
+key vulnerabilities in API security.
+
+19
+00:01:25,000 --> 00:01:29,000
+Let's start from the definition of broken object property level authorization.
+
+20
+00:01:29,000 --> 00:01:31,000
+I will explain you what it is.
+
+21
+00:01:32,000 --> 00:01:39,000
+Broken object property level authorization occurs when an API allows users to access or manipulate object
+
+22
+00:01:39,000 --> 00:01:42,000
+properties without proper authorization.
+
+23
+00:01:42,000 --> 00:01:49,000
+This means that users can see or alter data they shouldn't have access to, leading to potential security
+
+24
+00:01:49,000 --> 00:01:49,000
+risks.
+
+25
+00:01:50,000 --> 00:01:52,000
+To understand its importance, consider this.
+
+26
+00:01:52,000 --> 00:01:58,000
+If an API endpoint exposes sensitive properties such as personal information or financial details to
+
+27
+00:01:58,000 --> 00:02:02,000
+unauthorized users, it can result in serious privacy breaches.
+
+28
+00:02:02,000 --> 00:02:09,000
+For example, a user might access confidential data that's meant to be restricted, thereby violating
+
+29
+00:02:09,000 --> 00:02:10,000
+the principles of data protection.
+
+30
+00:02:11,000 --> 00:02:18,000
+Similarly, if the API allows unauthorized modifications, such as altering an account balance or changing
+
+31
+00:02:18,000 --> 00:02:25,000
+a user's permissions, it compromises the integrity of the data and can lead to unauthorized privilege
+
+32
+00:02:25,000 --> 00:02:26,000
+escalation.
+
+33
+00:02:26,000 --> 00:02:32,000
+Moreover, addressing this issue is crucial for regulatory compliance.
+
+34
+00:02:32,000 --> 00:02:39,000
+Many data protection regulations, such as GDPR and HIPAA, mandate strict access controls to safeguard
+
+35
+00:02:39,000 --> 00:02:41,000
+sensitive information.
+
+36
+00:02:41,000 --> 00:02:48,000
+Failure to enforce these controls not only risks non-compliance, but also exposes the organization
+
+37
+00:02:48,000 --> 00:02:50,000
+to legal repercussions.
+
+38
+00:02:50,000 --> 00:02:56,000
+In addition to regulatory concerns, the trust and reputation of a business are at stake.
+
+39
+00:02:56,000 --> 00:03:02,000
+Security vulnerabilities can undermine user confidence and damage an organisation's reputation.
+
+40
+00:03:02,000 --> 00:03:11,000
+Thus, implementing robust authorisation controls is essential to protect both data and business integrity.
+
+41
+00:03:11,000 --> 00:03:15,000
+Finally, let's not overlook the financial impact.
+
+42
+00:03:15,000 --> 00:03:22,000
+Data breaches and unauthorised access can lead to significant costs, including legal fees, regulatory
+
+43
+00:03:22,000 --> 00:03:24,000
+fines and loss of business.
+
+44
+00:03:25,000 --> 00:03:31,000
+By addressing broken object property level authorization effectively, we not only enhance the security
+
+45
+00:03:31,000 --> 00:03:38,000
+of our APIs, but also mitigate these potential risks and ensure the stability of our systems.
+
+46
+00:03:39,000 --> 00:03:45,000
+Let's focus our attention now on threat agents, attack vectors, security weaknesses, and their real
+
+47
+00:03:45,000 --> 00:03:47,000
+world consequences.
+
+48
+00:03:47,000 --> 00:03:52,000
+Understanding these elements is essential for developing robust API security measures.
+
+49
+00:03:53,000 --> 00:03:57,000
+Firstly, let's consider threat agents and attack vectors.
+
+50
+00:03:57,000 --> 00:04:05,000
+Threat agents in this context are individuals or entities who exploit vulnerabilities within an API
+
+51
+00:04:05,000 --> 00:04:08,000
+to gain unauthorized access or manipulate data.
+
+52
+00:04:09,000 --> 00:04:14,000
+These attackers may be internal or external, and are often skilled in identifying weaknesses in API
+
+53
+00:04:14,000 --> 00:04:16,000
+design or implementation.
+
+54
+00:04:16,000 --> 00:04:19,000
+The attack vectors they use can vary widely.
+
+55
+00:04:20,000 --> 00:04:26,000
+For example, they might target API endpoints that inadvertently expose more data than necessary.
+
+56
+00:04:26,000 --> 00:04:31,000
+So these endpoints attackers can access sensitive information that should be restricted.
+
+57
+00:04:32,000 --> 00:04:36,000
+Additionally, improper access controls present another vector.
+
+58
+00:04:36,000 --> 00:04:40,000
+If an API fails to enforce stringent authorization checks.
+
+59
+00:04:40,000 --> 00:04:47,000
+Attackers can craft requests that access or modify data beyond their intended permissions.
+
+60
+00:04:48,000 --> 00:04:55,000
+Manipulated requests are another common tactic where attackers intentionally alter requests to interact
+
+61
+00:04:55,000 --> 00:04:58,000
+with object properties that should be off limits.
+
+62
+00:04:59,000 --> 00:05:02,000
+Moving on to security weaknesses and their impacts.
+
+63
+00:05:02,000 --> 00:05:10,000
+The core issue lies in the API's failure to enforce adequate authorization checks for object properties.
+
+64
+00:05:10,000 --> 00:05:19,000
+This weakness often stems from inadequate authorization mechanisms, where APIs lack the necessary controls
+
+65
+00:05:19,000 --> 00:05:24,000
+to ensure that only authorized users can access or modify specific properties.
+
+66
+00:05:25,000 --> 00:05:32,000
+Another contributing factor is data exposure, where APIs may reveal more information than intended,
+
+67
+00:05:32,000 --> 00:05:38,000
+either directly through responses or through probing tools that uncover hidden properties.
+
+68
+00:05:39,000 --> 00:05:46,000
+Insufficient input validation further exacerbates the issue, allowing attackers to manipulate data
+
+69
+00:05:46,000 --> 00:05:49,000
+in ways that were not anticipated by the application's design.
+
+70
+00:05:50,000 --> 00:05:54,000
+The impact of these security weaknesses can be profound.
+
+71
+00:05:54,000 --> 00:06:01,000
+Unauthorized access to sensitive data can lead to privacy breaches, where personal or financial information
+
+72
+00:06:01,000 --> 00:06:03,000
+is exposed to unauthorized individuals.
+
+73
+00:06:04,000 --> 00:06:09,000
+This, in turn, can result in identity theft or other privacy violations.
+
+74
+00:06:10,000 --> 00:06:13,000
+Data corruption is another serious concern.
+
+75
+00:06:13,000 --> 00:06:20,000
+Attackers might alter critical data, leading to inaccurate records and potential system failures.
+
+76
+00:06:21,000 --> 00:06:27,000
+Additionally, vulnerabilities can enable privilege escalation, allowing attackers to gain access to
+
+77
+00:06:27,000 --> 00:06:34,000
+functionalities or data beyond their authorized scope, which can further compromise system integrity.
+
+78
+00:06:35,000 --> 00:06:41,000
+To illustrate the real world consequences of these vulnerabilities, consider the financial and reputational
+
+79
+00:06:41,000 --> 00:06:43,000
+damage that can occur.
+
+80
+00:06:44,000 --> 00:06:51,000
+Data breaches involving sensitive information often lead to substantial legal and regulatory repercussions,
+
+81
+00:06:51,000 --> 00:06:53,000
+such as fines or sanctions.
+
+82
+00:06:53,000 --> 00:07:00,000
+For instance, exposure of personal health information might violate regulations like HIPAA, resulting
+
+83
+00:07:00,000 --> 00:07:02,000
+in significant penalties.
+
+84
+00:07:02,000 --> 00:07:09,000
+Financial losses can also be severe, with attackers potentially altering transaction amounts or account
+
+85
+00:07:09,000 --> 00:07:12,000
+balances, leading to fraudulent activities and revenue loss.
+
+86
+00:07:13,000 --> 00:07:19,000
+Furthermore, a security breach can tarnish an organization's reputation, diminishing user trust and
+
+87
+00:07:19,000 --> 00:07:20,000
+causing negative publicity.
+
+88
+00:07:21,000 --> 00:07:27,000
+This loss of confidence can decrease customer retention and harm the organization's overall standing
+
+89
+00:07:27,000 --> 00:07:27,000
+in the market.
+
+90
+00:07:28,000 --> 00:07:35,000
+Lastly, legal and compliance issues arise when proper protection measures are not in place, leading
+
+91
+00:07:35,000 --> 00:07:40,000
+to lawsuits or compliance violations and further financial and reputational damage.
+
+92
+00:07:41,000 --> 00:07:44,000
+Let's review some practical examples and scenarios.
+
+93
+00:07:45,000 --> 00:07:51,000
+Imagine a fitness app where users can log their workout activities and view their personal fitness stats
+
+94
+00:07:51,000 --> 00:07:52,000
+through an API.
+
+95
+00:07:53,000 --> 00:07:55,000
+Here's how the correct scenario would look.
+
+96
+00:07:55,000 --> 00:08:03,000
+Users submit their workout data using a Post request to log their activities via Post request to API.
+
+97
+00:08:03,000 --> 00:08:05,000
+Workouts report endpoint.
+
+98
+00:08:05,000 --> 00:08:07,000
+User submits.
+
+99
+00:08:07,000 --> 00:08:12,000
+User ID, workout type, duration, and calories burned.
+
+100
+00:08:12,000 --> 00:08:16,000
+The user can then retrieve their workout details using a Get request.
+
+101
+00:08:16,000 --> 00:08:21,000
+As you can see in example, in this case we just pass user ID in the pass.
+
+102
+00:08:21,000 --> 00:08:27,000
+The API response might include personal information such as array of workouts containing more than one
+
+103
+00:08:27,000 --> 00:08:33,000
+record, also containing fitness goals that can be different, and really personal ones that people
+
+104
+00:08:33,000 --> 00:08:34,000
+want to keep private.
+
+105
+00:08:34,000 --> 00:08:40,000
+So what is the problem if the API does not properly enforce access controls?
+
+106
+00:08:40,000 --> 00:08:42,000
+A user could access or modify data.
+
+107
+00:08:42,000 --> 00:08:43,000
+They shouldn't.
+
+108
+00:08:44,000 --> 00:08:47,000
+For example, unauthorized access.
+
+109
+00:08:47,000 --> 00:08:54,000
+An attacker might use a Get request to access another user's fitness goals or past performance by manipulating
+
+110
+00:08:54,000 --> 00:08:56,000
+the user ID in the request.
+
+111
+00:08:57,000 --> 00:09:05,000
+For instance, if user ID 1234 belongs to another user, the attacker could potentially see sensitive
+
+112
+00:09:05,000 --> 00:09:09,000
+data about that user's fitness goals and past performance.
+
+113
+00:09:10,000 --> 00:09:13,000
+Theoretically, hacker can get access to other data too.
+
+114
+00:09:14,000 --> 00:09:16,000
+And this is just an example, right?
+
+115
+00:09:16,000 --> 00:09:23,000
+We can't imagine to what other data hacker may also get access and what information will be in response.
+
+116
+00:09:24,000 --> 00:09:31,000
+Data manipulation Although Post requests typically create data in proper validation or authorization,
+
+117
+00:09:31,000 --> 00:09:34,000
+checks can also lead to security issues.
+
+118
+00:09:34,000 --> 00:09:41,000
+If an API allows updating data through a Post request without proper authorization checks, an attacker
+
+119
+00:09:41,000 --> 00:09:48,000
+might alter fields they shouldn't be able to change, such as updating their calories burned to unrealistically
+
+120
+00:09:48,000 --> 00:09:49,000
+high values.
+
+121
+00:09:50,000 --> 00:09:55,000
+This may break all the statistics of your application and impact users experience.
+
+122
+00:09:55,000 --> 00:09:58,000
+And we don't want that, right?
+
+123
+00:09:58,000 --> 00:10:04,000
+Just a reminder in case you have any follow up questions, you don't need to wait till the end of the
+
+124
+00:10:04,000 --> 00:10:05,000
+lesson.
+
+125
+00:10:05,000 --> 00:10:08,000
+Just post your question below the video and I will be happy to answer.
+
+126
+00:10:09,000 --> 00:10:11,000
+Let's review another example.
+
+127
+00:10:12,000 --> 00:10:18,000
+Let's consider an online learning platform where students submit quiz answers and receive their grades
+
+128
+00:10:18,000 --> 00:10:19,000
+via an API.
+
+129
+00:10:20,000 --> 00:10:25,000
+Students submit their quiz answers using a Post request to API quizzes.
+
+130
+00:10:25,000 --> 00:10:31,000
+Submit an endpoint quiz object has quiz ID, student ID and contain answers.
+
+131
+00:10:32,000 --> 00:10:37,000
+After submission, students might retrieve their quiz results using a Get request.
+
+132
+00:10:37,000 --> 00:10:44,000
+The API response could include all the information submitted, where might be a problem, and what you
+
+133
+00:10:44,000 --> 00:10:46,000
+need to test and avoid in your application.
+
+134
+00:10:47,000 --> 00:10:53,000
+If the endpoint handling quiz submissions is not properly secured, a student might exploit this by
+
+135
+00:10:53,000 --> 00:10:56,000
+altering the submitted data to change their own score.
+
+136
+00:10:57,000 --> 00:11:00,000
+For example, they might send a Post request with a score attribute.
+
+137
+00:11:00,000 --> 00:11:07,000
+This would enable them to artificially inflate the score, which undermines the gradient system's integrity.
+
+138
+00:11:08,000 --> 00:11:15,000
+Of course, this requires time and API analysis, sending multiple posts and get requests, analyzing
+
+139
+00:11:15,000 --> 00:11:18,000
+data structure, and trying different combinations of attributes.
+
+140
+00:11:19,000 --> 00:11:26,000
+But still, after spending some time making different types of requests, hackers can identify weak
+
+141
+00:11:26,000 --> 00:11:28,000
+points in your API.
+
+142
+00:11:28,000 --> 00:11:32,000
+As you can see, the process will not look like in Hollywood movies.
+
+143
+00:11:32,000 --> 00:11:36,000
+But now you can imagine how actually hacking is happening.
+
+144
+00:11:37,000 --> 00:11:40,000
+I am telling you, not you, to repeat this, but in order.
+
+145
+00:11:40,000 --> 00:11:47,000
+You could understand how hackers think and how they plan to hack API of your application.
+
+146
+00:11:47,000 --> 00:11:54,000
+So now I believe you are protected with knowledge and during the API design process, always challenge
+
+147
+00:11:54,000 --> 00:11:57,000
+yourself in a similar way.
+
+148
+00:11:57,000 --> 00:12:04,000
+Hackers may get unauthorized access to data if the API fails to enforce strict access controls.
+
+149
+00:12:04,000 --> 00:12:11,000
+A student might be able to retrieve results for other students by manipulating the student ID parameter
+
+150
+00:12:11,000 --> 00:12:12,000
+in the Get request.
+
+151
+00:12:13,000 --> 00:12:19,000
+For instance, seeing data of other students simply by submitting other students ID.
+
+152
+00:12:20,000 --> 00:12:26,000
+This request could potentially expose the quiz results of another student, leading to a breach of privacy
+
+153
+00:12:26,000 --> 00:12:28,000
+and unfair advantage.
+
+154
+00:12:29,000 --> 00:12:32,000
+So we learned examples of vulnerabilities.
+
+155
+00:12:33,000 --> 00:12:38,000
+It is just the right moment to answer what to do and how to avoid them.
+
+156
+00:12:38,000 --> 00:12:44,000
+To address vulnerabilities related to broken object property level authorization, it is crucial to
+
+157
+00:12:44,000 --> 00:12:50,000
+implement several preventive measures that ensure both security and integrity of the data.
+
+158
+00:12:51,000 --> 00:12:55,000
+The first critical step is implementing access controls.
+
+159
+00:12:55,000 --> 00:13:02,000
+Access controls are fundamental to API security because they regulate who can access what data and perform
+
+160
+00:13:02,000 --> 00:13:02,000
+what actions.
+
+161
+00:13:03,000 --> 00:13:08,000
+By defining and enforcing access policies, you can ensure that users and roles have the appropriate
+
+162
+00:13:08,000 --> 00:13:11,000
+permissions for specific data or operations.
+
+163
+00:13:11,000 --> 00:13:17,000
+This means checking that each request is authorized to access or modify the object properties and targets.
+
+164
+00:13:18,000 --> 00:13:25,000
+For instance, a user should only be able to access their own profile information and not that of others
+
+165
+00:13:25,000 --> 00:13:27,000
+based on their role and permissions.
+
+166
+00:13:28,000 --> 00:13:35,000
+For example, during the API call, code should verify that requester client is either the owner of
+
+167
+00:13:35,000 --> 00:13:37,000
+the profile or an admin.
+
+168
+00:13:38,000 --> 00:13:46,000
+If the user ID in the request URL matches the authenticated users ID, or if the user has an admin role,
+
+169
+00:13:46,000 --> 00:13:48,000
+access is granted.
+
+170
+00:13:48,000 --> 00:13:57,000
+Otherwise, the API responds with a 403 forbidden status depending on authentication mechanisms, approaches
+
+171
+00:13:57,000 --> 00:14:00,000
+may be different, but principle stays the same.
+
+172
+00:14:00,000 --> 00:14:04,000
+During the practical example, we will see specific examples in code.
+
+173
+00:14:04,000 --> 00:14:06,000
+Wait for it just a little bit.
+
+174
+00:14:07,000 --> 00:14:10,000
+We will learn concepts and then we will jump to practice.
+
+175
+00:14:11,000 --> 00:14:12,000
+Next.
+
+176
+00:14:12,000 --> 00:14:16,000
+Minimizing data exposure is essential in protecting sensitive information.
+
+177
+00:14:17,000 --> 00:14:24,000
+When designing APIs, it's important to ensure that only the necessary data is returned in API responses.
+
+178
+00:14:24,000 --> 00:14:31,000
+This involves selectively choosing which object properties are included in the response based on the
+
+179
+00:14:31,000 --> 00:14:32,000
+user's permissions.
+
+180
+00:14:33,000 --> 00:14:40,000
+By avoiding the exposure of extraneous or sensitive data, you reduce the risk of unauthorized access
+
+181
+00:14:40,000 --> 00:14:41,000
+and data leaks.
+
+182
+00:14:41,000 --> 00:14:47,000
+For example, if a user requests the account information, the API should return only the fields relevant
+
+183
+00:14:47,000 --> 00:14:51,000
+to their access level, excluding any internal or sensitive details.
+
+184
+00:14:51,000 --> 00:14:54,000
+User even not always need to know their IDs.
+
+185
+00:14:54,000 --> 00:14:58,000
+Exposing IDs can cause risk of vulnerability exposure.
+
+186
+00:14:58,000 --> 00:15:01,000
+Another important practice is using schema based validation.
+
+187
+00:15:01,000 --> 00:15:08,000
+Schema based validation provides an additional layer of security by defining and enforcing the structure
+
+188
+00:15:08,000 --> 00:15:11,000
+and constraints of data exchanged through APIs.
+
+189
+00:15:11,000 --> 00:15:18,000
+By establishing clear schemas for both requests and responses, you can ensure that data adheres to
+
+190
+00:15:18,000 --> 00:15:20,000
+expected formats and values.
+
+191
+00:15:20,000 --> 00:15:27,000
+This not only helps in preventing unauthorized data access, but also in catching anomalies or invalid
+
+192
+00:15:27,000 --> 00:15:29,000
+inputs early in the process.
+
+193
+00:15:30,000 --> 00:15:36,000
+For instance, if an API request attempts to submit a field that is not defined in the schema, it should
+
+194
+00:15:36,000 --> 00:15:37,000
+be rejected.
+
+195
+00:15:38,000 --> 00:15:42,000
+And again, depending on the programming language and framework used, the.
+
+196
+00:15:42,000 --> 00:15:45,000
+Technically this can be implemented in different ways.
+
+197
+00:15:46,000 --> 00:15:49,000
+Personally, I use it very often in my applications.
+
+198
+00:15:50,000 --> 00:15:57,000
+Finally, it is crucial to avoid relying on client side filtering relying on client side mechanisms
+
+199
+00:15:57,000 --> 00:16:04,000
+for data filtering or validation is a security risk because it assumes that the client which can be
+
+200
+00:16:04,000 --> 00:16:08,000
+manipulated will correctly enforce access restrictions.
+
+201
+00:16:09,000 --> 00:16:14,000
+Instead, all critical checks and data filtering should be handled server side.
+
+202
+00:16:15,000 --> 00:16:21,000
+This ensures that data exposure and modification are controlled centrally and not subject to tampering
+
+203
+00:16:21,000 --> 00:16:23,000
+by the client.
+
+204
+00:16:23,000 --> 00:16:30,000
+For example, even if a client side application hides certain data fields from the user interface,
+
+205
+00:16:31,000 --> 00:16:38,000
+the server should still validate and enforce access controls before processing any request that attempts
+
+206
+00:16:38,000 --> 00:16:41,000
+to access or modify those fields.
+
+207
+00:16:41,000 --> 00:16:44,000
+Very often this happens with HTML forms.
+
+208
+00:16:45,000 --> 00:16:51,000
+You can't rely just on the fact that nobody will change hidden fields that are not visible on UI.
+
+209
+00:16:52,000 --> 00:16:59,000
+Hackers exploring the source code of the front end learning API and then can imitate the request impacting
+
+210
+00:16:59,000 --> 00:17:04,000
+your application in the realm of API security.
+
+211
+00:17:04,000 --> 00:17:11,000
+Understanding related to broken object property level authorization Vulnerabilities such as excessive
+
+212
+00:17:11,000 --> 00:17:18,000
+data exposure and mass assignment, is crucial for comprehending how different security flaws can impact
+
+213
+00:17:18,000 --> 00:17:20,000
+an application.
+
+214
+00:17:20,000 --> 00:17:31,000
+Both are outlined in the OWASp top ten API security, specifically API three 2019 and API six 2019,
+
+215
+00:17:31,000 --> 00:17:32,000
+respectively.
+
+216
+00:17:33,000 --> 00:17:41,000
+Excessive data exposure, as described in OWASp API three 2019, refers to the issue where an API returns
+
+217
+00:17:41,000 --> 00:17:43,000
+more data than necessary to the client.
+
+218
+00:17:43,000 --> 00:17:48,000
+This vulnerability arises when APIs provide comprehensive object representations that include sensitive
+
+219
+00:17:48,000 --> 00:17:53,000
+or irrelevant information, which could be exploited by unauthorized users.
+
+220
+00:17:54,000 --> 00:18:00,000
+For instance, if an API endpoint returns detailed user profiles, including internal flags or private
+
+221
+00:18:00,000 --> 00:18:06,000
+informations that should be hidden, this exposes users to potential data breaches.
+
+222
+00:18:07,000 --> 00:18:13,000
+The core problem here is that the API discloses more information than the user should have access to,
+
+223
+00:18:13,000 --> 00:18:19,000
+which can be used maliciously if an attacker is able to sniff or intercept API responses.
+
+224
+00:18:20,000 --> 00:18:29,000
+Mass assignment covered under OWASp API six 2019, pertains to the issue where an API allows clients
+
+225
+00:18:29,000 --> 00:18:35,000
+to modify object properties that they should not be able to access or alter.
+
+226
+00:18:35,000 --> 00:18:43,000
+This vulnerability occurs when an API endpoint automatically binds client input to internal object properties
+
+227
+00:18:44,000 --> 00:18:46,000
+without proper validation or filtering.
+
+228
+00:18:47,000 --> 00:18:55,000
+For example, if a client can submit a payload to update a user profile and due to inadequate controls,
+
+229
+00:18:55,000 --> 00:19:01,000
+modify fields like is underscore, admin or user underscore role, which should be protected.
+
+230
+00:19:01,000 --> 00:19:06,000
+It leads to unauthorized privilege escalation or data tampering.
+
+231
+00:19:08,000 --> 00:19:13,000
+Let's understand how these three categories are connected and how they are different.
+
+232
+00:19:13,000 --> 00:19:15,000
+Key differences.
+
+233
+00:19:15,000 --> 00:19:22,000
+Broken object property level authorization focuses on controlling access to specific object properties
+
+234
+00:19:22,000 --> 00:19:24,000
+based on user roles and permissions.
+
+235
+00:19:25,000 --> 00:19:32,000
+It is about ensuring that users only interact with data and features they are authorized to access.
+
+236
+00:19:32,000 --> 00:19:39,000
+Excessive data exposure primarily deals with the problem of too much data being sent to the client.
+
+237
+00:19:39,000 --> 00:19:45,000
+It is a data retrieval issue where sensitive information is unnecessarily exposed in the API response.
+
+238
+00:19:45,000 --> 00:19:51,000
+Mass assignment, on the other hand, deals with the problem of unauthorized modification of data.
+
+239
+00:19:52,000 --> 00:19:57,000
+It is a data submission issue where clients can alter object properties beyond their permitted scope.
+
+240
+00:19:58,000 --> 00:20:02,000
+Let's now check what these three categories have in common.
+
+241
+00:20:02,000 --> 00:20:08,000
+All three vulnerabilities can lead to unauthorized access or modification of data.
+
+242
+00:20:08,000 --> 00:20:15,000
+For instance, an API suffering from both broken object property level authorization and excessive data
+
+243
+00:20:15,000 --> 00:20:21,000
+exposure might expose sensitive properties and allow unauthorized users to access them.
+
+244
+00:20:22,000 --> 00:20:27,000
+Each vulnerability highlights the importance of thorough validation and access controls.
+
+245
+00:20:28,000 --> 00:20:34,000
+Broken object property level authorization requires careful permission checks for each property.
+
+246
+00:20:35,000 --> 00:20:40,000
+Excessive data exposure requires filtering of data in responses and mass assignments.
+
+247
+00:20:40,000 --> 00:20:45,000
+Requires validation of input data to prevent unauthorized changes.
+
diff --git a/74 - OWASP API Security Top 10 2023/009 API32023 Broken Object Property Level Authorization - Part 2 (Practice)_en.srt b/74 - OWASP API Security Top 10 2023/009 API32023 Broken Object Property Level Authorization - Part 2 (Practice)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..0e7b88fbee819d0cc0eb0d47d187402999a9f21d
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/009 API32023 Broken Object Property Level Authorization - Part 2 (Practice)_en.srt
@@ -0,0 +1,812 @@
+1
+00:00:04,000 --> 00:00:05,000
+We learned enough theory.
+
+2
+00:00:05,000 --> 00:00:12,000
+So now it is time to take a look at practical example, understand problem on real example and learn
+
+3
+00:00:12,000 --> 00:00:14,000
+how to avoid it in the future.
+
+4
+00:00:14,000 --> 00:00:16,000
+Let me start screen sharing.
+
+5
+00:00:17,000 --> 00:00:21,000
+As always, you can find all source code examples in attachments to the video.
+
+6
+00:00:22,000 --> 00:00:29,000
+And in case something will remain unclear after my explanation, please no need to feel sad and disappointed.
+
+7
+00:00:29,000 --> 00:00:33,000
+Just post your question below the video and I will be happy to help you.
+
+8
+00:00:34,000 --> 00:00:35,000
+Let me walk you through this code.
+
+9
+00:00:35,000 --> 00:00:36,000
+Examples.
+
+10
+00:00:36,000 --> 00:00:38,000
+We will understand the problem statement.
+
+11
+00:00:38,000 --> 00:00:42,000
+First we will review some examples and then we will review solution.
+
+12
+00:00:43,000 --> 00:00:45,000
+Before we start I want to highlight one point.
+
+13
+00:00:45,000 --> 00:00:50,000
+These are basic Java examples from my course Java from zero to first job.
+
+14
+00:00:51,000 --> 00:00:58,000
+Together with my students we develop online shop from scratch because on the example of online shop,
+
+15
+00:00:58,000 --> 00:01:02,000
+there is opportunity to explain complex concepts on the simple examples.
+
+16
+00:01:03,000 --> 00:01:08,000
+That's why today we are going to use e-commerce terminology in our examples.
+
+17
+00:01:08,000 --> 00:01:14,000
+But principles that I am going to explain in the demo applicable for every web application.
+
+18
+00:01:14,000 --> 00:01:21,000
+Also example is created in Java on plain servlets to not overcomplicate example with different frameworks
+
+19
+00:01:21,000 --> 00:01:24,000
+and make explanation as transparent as it is possible.
+
+20
+00:01:24,000 --> 00:01:28,000
+So let's start review from the problem statement purchase servlet.
+
+21
+00:01:29,000 --> 00:01:33,000
+We have two fields here purchase Dao and JSON.
+
+22
+00:01:34,000 --> 00:01:41,000
+The purchase Dao is instantiated as an implementation of purchase Dao which interacts with the database.
+
+23
+00:01:42,000 --> 00:01:45,000
+Later you can check the source code of purchased Dao if you wish.
+
+24
+00:01:46,000 --> 00:01:50,000
+The given object is used for converting objects to JSON and vice versa.
+
+25
+00:01:51,000 --> 00:01:57,000
+During today's example, I will show you how data can be exposed to hackers and how data may be adjusted
+
+26
+00:01:57,000 --> 00:02:01,000
+by hackers because of broken object property level authorization.
+
+27
+00:02:02,000 --> 00:02:05,000
+That's why in the servlet we have two methods.
+
+28
+00:02:06,000 --> 00:02:13,000
+One handles read request via HTTP get method and another handles update requests via HTTP put method.
+
+29
+00:02:14,000 --> 00:02:18,000
+In the get method, purchased id is extracted from the request path.
+
+30
+00:02:18,000 --> 00:02:25,000
+The substring one call removes the leading slash from the URL path, and you can see the mapping of
+
+31
+00:02:25,000 --> 00:02:27,000
+this servlet here on top of the file.
+
+32
+00:02:28,000 --> 00:02:34,000
+The purchase Dao gets purchased by ID Idcol fetches the purchase detail from the database.
+
+33
+00:02:35,000 --> 00:02:41,000
+If you are a student of my Java from zero to first job or software architecture course, then you are
+
+34
+00:02:41,000 --> 00:02:46,000
+already familiar with the concept of DTO that stands for Data Transfer Object.
+
+35
+00:02:46,000 --> 00:02:52,000
+In our particular example, this DTO includes all fields from the database which may contain sensitive
+
+36
+00:02:52,000 --> 00:02:55,000
+information such as customer details or payment information.
+
+37
+00:02:56,000 --> 00:03:02,000
+That's why usually on this level, it is better to operate not with DTO but with business level objects.
+
+38
+00:03:03,000 --> 00:03:06,000
+Later we will get to this point and I will explain you more.
+
+39
+00:03:07,000 --> 00:03:11,000
+The purchase DTO is converted to JSON and sent back to the client.
+
+40
+00:03:12,000 --> 00:03:18,000
+This exposes all the data fields, potentially including sensitive information if the access controls
+
+41
+00:03:18,000 --> 00:03:20,000
+are not correctly enforced.
+
+42
+00:03:20,000 --> 00:03:23,000
+I will show this problem via postman in a minute.
+
+43
+00:03:23,000 --> 00:03:26,000
+Let's check another method that we have here.
+
+44
+00:03:27,000 --> 00:03:30,000
+Do put method handles requests for updates.
+
+45
+00:03:30,000 --> 00:03:37,000
+Imagine use case when we need to expose API to the client in order to provide interface of order update.
+
+46
+00:03:38,000 --> 00:03:45,000
+Let's imagine that order is in review and user want to change amount of products or to add additional
+
+47
+00:03:45,000 --> 00:03:46,000
+products.
+
+48
+00:03:46,000 --> 00:03:51,000
+This endpoint supposed to help to execute this type of operation.
+
+49
+00:03:51,000 --> 00:03:57,000
+Applying different techniques, hackers can identify this endpoint and try to hack it.
+
+50
+00:03:57,000 --> 00:03:58,000
+Let's take a look.
+
+51
+00:03:58,000 --> 00:03:59,000
+What do we have here?
+
+52
+00:04:00,000 --> 00:04:04,000
+The purchase ID is again extracted from the request path.
+
+53
+00:04:05,000 --> 00:04:12,000
+The Bufferedreader reads the request body which is then converted from JSON into a purchase DTO object
+
+54
+00:04:12,000 --> 00:04:14,000
+using JSON.
+
+55
+00:04:14,000 --> 00:04:18,000
+This object directly reflects the incoming data.
+
+56
+00:04:18,000 --> 00:04:24,000
+The existing purchase details, the original ones, are fetched from the database and then updated with
+
+57
+00:04:24,000 --> 00:04:26,000
+the values from the request.
+
+58
+00:04:27,000 --> 00:04:30,000
+This is where the issue of mass assignment becomes critical.
+
+59
+00:04:31,000 --> 00:04:38,000
+The copy properties method transfers all fields from the incoming purchased DTO to the existing one,
+
+60
+00:04:38,000 --> 00:04:45,000
+which may inadvertently expose or alter sensitive data if not carefully managed.
+
+61
+00:04:45,000 --> 00:04:53,000
+The updated purchase is saved back to the database, and the updated purchase detail is sent back to
+
+62
+00:04:53,000 --> 00:04:54,000
+the client.
+
+63
+00:04:54,000 --> 00:05:01,000
+This exposes all fields of the purchased DTO, including potentially sensitive information without proper
+
+64
+00:05:01,000 --> 00:05:02,000
+authorization checks.
+
+65
+00:05:04,000 --> 00:05:10,000
+The code does not currently implement authorization checks to ensure that only authorized users can
+
+66
+00:05:10,000 --> 00:05:13,000
+access or modify specific purchases.
+
+67
+00:05:14,000 --> 00:05:21,000
+This means any authenticated user with access to the purchase endpoint can potentially view or modify
+
+68
+00:05:21,000 --> 00:05:24,000
+purchase data that they should not have access to.
+
+69
+00:05:25,000 --> 00:05:33,000
+The copy properties method directly assigns fields from the incoming purchase data to the existing purchase
+
+70
+00:05:33,000 --> 00:05:33,000
+object.
+
+71
+00:05:34,000 --> 00:05:39,000
+This is a risk because it allows unauthorized fields to be updated if not properly validated.
+
+72
+00:05:40,000 --> 00:05:46,000
+For instance, a malicious user could attempt to modify fields that should be protected or not exposed
+
+73
+00:05:46,000 --> 00:05:48,000
+through the API.
+
+74
+00:05:48,000 --> 00:05:51,000
+I believe that you understand the context of our example.
+
+75
+00:05:51,000 --> 00:05:56,000
+If you are interested in the specific details of implementation, please investigate the source code
+
+76
+00:05:56,000 --> 00:06:03,000
+from the attachments to this lesson or post your question below the video and I will be happy to answer.
+
+77
+00:06:03,000 --> 00:06:07,000
+Let's now review this API in action via postman.
+
+78
+00:06:07,000 --> 00:06:11,000
+We will start from the dog get method overview.
+
+79
+00:06:11,000 --> 00:06:16,000
+I took random purchase from the database was add 45.
+
+80
+00:06:17,000 --> 00:06:21,000
+Let's make an API call via postman to this endpoint.
+
+81
+00:06:22,000 --> 00:06:24,000
+And what do we see here?
+
+82
+00:06:25,000 --> 00:06:32,000
+We see all the information about user the user who placed this order, who made this purchase.
+
+83
+00:06:32,000 --> 00:06:34,000
+This is not good.
+
+84
+00:06:34,000 --> 00:06:41,000
+Definitely when client requests information about purchase, it is better to clean the whole information
+
+85
+00:06:41,000 --> 00:06:48,000
+about the user, especially with so many personal information like first name, last name, email,
+
+86
+00:06:48,000 --> 00:06:51,000
+credit card number, etc..
+
+87
+00:06:52,000 --> 00:06:59,000
+Then goes array of products, which is probably okay, but I would also filter out greed, image name
+
+88
+00:06:59,000 --> 00:07:02,000
+and other not important attribute for the client.
+
+89
+00:07:02,000 --> 00:07:05,000
+And at the bottom we have purchased status.
+
+90
+00:07:05,000 --> 00:07:07,000
+Pay attention to the status.
+
+91
+00:07:07,000 --> 00:07:10,000
+Status ID is one which is receive request.
+
+92
+00:07:11,000 --> 00:07:14,000
+Now let's explore update endpoint.
+
+93
+00:07:14,000 --> 00:07:16,000
+Put request has body.
+
+94
+00:07:17,000 --> 00:07:21,000
+So I send in the body the whole order body that I received.
+
+95
+00:07:21,000 --> 00:07:28,000
+But I changed the one minor thing I changed purchased status ID in our specific example, I can change
+
+96
+00:07:28,000 --> 00:07:32,000
+any field and update order in the database with the postman.
+
+97
+00:07:33,000 --> 00:07:40,000
+Let me send this request with updated status ID and now let's perform a read operation.
+
+98
+00:07:42,000 --> 00:07:46,000
+Can you see this status is paid at the moment?
+
+99
+00:07:46,000 --> 00:07:49,000
+But we know that client didn't pay us yet.
+
+100
+00:07:49,000 --> 00:07:55,000
+That's how hackers can cause financial losses to the online shop in case some endpoints are not protected
+
+101
+00:07:55,000 --> 00:07:56,000
+well enough.
+
+102
+00:07:56,000 --> 00:08:02,000
+So the problem is that in this case, purchase status DTO may be updated by any user who can break the
+
+103
+00:08:02,000 --> 00:08:04,000
+whole order system of online shop.
+
+104
+00:08:05,000 --> 00:08:07,000
+Let's now check how to fix this.
+
+105
+00:08:08,000 --> 00:08:10,000
+I open the source code of the solution.
+
+106
+00:08:11,000 --> 00:08:15,000
+I open file that is called solution purchase servlet.
+
+107
+00:08:15,000 --> 00:08:18,000
+We initialize several key components.
+
+108
+00:08:19,000 --> 00:08:26,000
+Purchase facade and user facade are responsible for purchase and user operations respectively, while
+
+109
+00:08:26,000 --> 00:08:29,000
+JSON facilitates JSON conversion.
+
+110
+00:08:29,000 --> 00:08:37,000
+The purchase converter helps in translating between purchase DTO and purchase business objects in the
+
+111
+00:08:37,000 --> 00:08:39,000
+solution purchase servlet.
+
+112
+00:08:39,000 --> 00:08:46,000
+The purchase data to purchase converter plays a crucial role in controlling which data is used in the
+
+113
+00:08:46,000 --> 00:08:47,000
+business context.
+
+114
+00:08:48,000 --> 00:08:54,000
+This converter acts as a bridge between the data transfer object and the business layer, allowing us
+
+115
+00:08:54,000 --> 00:09:00,000
+to specify exactly which data from the DTO should be mapped into the business object.
+
+116
+00:09:01,000 --> 00:09:08,000
+This step ensures that only relevant data is passed to the business logic, while potentially sensitive
+
+117
+00:09:08,000 --> 00:09:11,000
+or unnecessary data is excluded.
+
+118
+00:09:11,000 --> 00:09:18,000
+This approach is vital in ensuring the integrity and security of the business operations by enforcing
+
+119
+00:09:18,000 --> 00:09:23,000
+clear boundaries between data representation and business functionality.
+
+120
+00:09:23,000 --> 00:09:30,000
+For a deeper dive into this topic, especially in the context of layered architecture, you can refer
+
+121
+00:09:30,000 --> 00:09:33,000
+to the lessons in my Software Architecture course.
+
+122
+00:09:34,000 --> 00:09:40,000
+These lessons provide detailed insights into how data flow is managed in a layered system.
+
+123
+00:09:41,000 --> 00:09:47,000
+Additionally, this conversion process aligns with the principles of domain driven design.
+
+124
+00:09:48,000 --> 00:09:54,000
+In TDD, business objects are designed to encapsulate both data and behavior, providing a richer representation
+
+125
+00:09:54,000 --> 00:09:56,000
+of the business domain.
+
+126
+00:09:56,000 --> 00:10:02,000
+Unlike simple data objects, which primarily carry data, business objects incorporate the logic and
+
+127
+00:10:02,000 --> 00:10:08,000
+rules of the domain, facilitating more robust and meaningful interactions within the business layer.
+
+128
+00:10:09,000 --> 00:10:15,000
+I have this converter declared in the facade in my business layer, but for the sake of the demo and
+
+129
+00:10:15,000 --> 00:10:21,000
+to simplify learning examples, I decided to place them vividly in this class so that you can see how
+
+130
+00:10:21,000 --> 00:10:22,000
+they work.
+
+131
+00:10:22,000 --> 00:10:25,000
+Let's continue review of the get method.
+
+132
+00:10:25,000 --> 00:10:30,000
+In this method, we first extract the purchase id from the request URL.
+
+133
+00:10:31,000 --> 00:10:35,000
+This ID identifies which purchase we are interested in.
+
+134
+00:10:35,000 --> 00:10:41,000
+We then use the extract user from basic auth method to authenticate the user.
+
+135
+00:10:42,000 --> 00:10:48,000
+In this particular example, we expect the user uses basic authentication with login and password.
+
+136
+00:10:48,000 --> 00:10:54,000
+Of course, you can use API key authentication or token based authentication.
+
+137
+00:10:54,000 --> 00:10:57,000
+We reviewed different approaches in my previous lessons.
+
+138
+00:10:58,000 --> 00:11:02,000
+If authentication fails, the method returns early.
+
+139
+00:11:02,000 --> 00:11:07,000
+If successful, we proceed to retrieve the purchase details using the purchase facade.
+
+140
+00:11:09,000 --> 00:11:10,000
+Authorization is next.
+
+141
+00:11:10,000 --> 00:11:17,000
+We check if the authenticated user is either the customer associated with the purchase or an administrator.
+
+142
+00:11:18,000 --> 00:11:23,000
+This ensures that unauthorized users cannot access the purchase details.
+
+143
+00:11:24,000 --> 00:11:31,000
+If the check fails, we return a forbidden status before sending the response, we sanitize the purchase
+
+144
+00:11:31,000 --> 00:11:37,000
+object by nullifying sensitive information such as credit card numbers and customer details.
+
+145
+00:11:38,000 --> 00:11:41,000
+This step ensures that sensitive data is not exposed.
+
+146
+00:11:41,000 --> 00:11:45,000
+We then convert the purchase object to JSON and send it to the client.
+
+147
+00:11:45,000 --> 00:11:50,000
+In case of errors, we handle them gracefully by returning an internal server error status.
+
+148
+00:11:51,000 --> 00:11:57,000
+Now let's examine the do post method Similar to the do get method, we start by authenticating the user.
+
+149
+00:11:58,000 --> 00:12:00,000
+If authentication fails, the process stops.
+
+150
+00:12:01,000 --> 00:12:08,000
+We extract the purchase ID from the URL and read the request body to obtain the updated purchase details.
+
+151
+00:12:08,000 --> 00:12:12,000
+We then convert this purchase detail into a purchase business object.
+
+152
+00:12:13,000 --> 00:12:17,000
+The purchase facade retrieves the existing purchase from the database.
+
+153
+00:12:18,000 --> 00:12:19,000
+The original one.
+
+154
+00:12:19,000 --> 00:12:25,000
+We then perform an authorization check to ensure that the authenticated user has permission to update
+
+155
+00:12:25,000 --> 00:12:26,000
+the purchase.
+
+156
+00:12:27,000 --> 00:12:30,000
+This step is crucial to prevent unauthorized modifications.
+
+157
+00:12:31,000 --> 00:12:37,000
+We only allow updates to the list of products, ensuring that sensitive fields remain protected.
+
+158
+00:12:37,000 --> 00:12:40,000
+Do you see the difference with previous example?
+
+159
+00:12:40,000 --> 00:12:44,000
+Client can update only list of products and that's it.
+
+160
+00:12:44,000 --> 00:12:52,000
+No other details can be adjusted and only that client who placed order and administrator may apply these
+
+161
+00:12:52,000 --> 00:12:52,000
+changes.
+
+162
+00:12:53,000 --> 00:12:55,000
+Additional validation can be performed if needed.
+
+163
+00:12:56,000 --> 00:13:02,000
+Finally, we save the updated purchase and convert it to JSON before sending it back to the client.
+
+164
+00:13:03,000 --> 00:13:10,000
+If any exceptions occur, we handle them by returning an internal server error status.
+
+165
+00:13:11,000 --> 00:13:17,000
+As you can see, this solution demonstrates a secure approach to handling HTTP requests for purchase
+
+166
+00:13:17,000 --> 00:13:24,000
+data by enforcing proper authentication and authorization checks and by sanitizing sensitive information.
+
+167
+00:13:24,000 --> 00:13:30,000
+It effectively addresses common vulnerabilities such as broken object property level authorization.
+
+168
+00:13:30,000 --> 00:13:36,000
+This ensures that both get and put operations are performed securely, protecting user data and preventing
+
+169
+00:13:36,000 --> 00:13:37,000
+unauthorized access.
+
+170
+00:13:38,000 --> 00:13:40,000
+Let's now test this API via postman.
+
+171
+00:13:41,000 --> 00:13:46,000
+I entered the URL, I clicked on authorization tab and selected basic authorization.
+
+172
+00:13:47,000 --> 00:13:49,000
+Then I inserted my login and password.
+
+173
+00:13:49,000 --> 00:13:52,000
+This is admin login and password.
+
+174
+00:13:53,000 --> 00:13:56,000
+And we received the JSON of our order.
+
+175
+00:13:56,000 --> 00:14:02,000
+Can you see that there is no user object anymore at all?
+
+176
+00:14:02,000 --> 00:14:05,000
+Also, the value of credit card number is empty.
+
+177
+00:14:06,000 --> 00:14:12,000
+I can see only products and status statuses paid after the previous example.
+
+178
+00:14:13,000 --> 00:14:21,000
+Now let me try to update this order this purchase object with update API that we implemented in the
+
+179
+00:14:21,000 --> 00:14:22,000
+solution file.
+
+180
+00:14:22,000 --> 00:14:29,000
+This time I will remove one product from products array, and I will try to change purchase status by
+
+181
+00:14:29,000 --> 00:14:35,000
+moving it to the state number six, which is supposed to be purchase completed status.
+
+182
+00:14:35,000 --> 00:14:40,000
+In this case, I also use basic authorization by login and password.
+
+183
+00:14:40,000 --> 00:14:44,000
+I sent request order is updated.
+
+184
+00:14:44,000 --> 00:14:48,000
+Let's perform, get operation and check the state of this purchase object.
+
+185
+00:14:51,000 --> 00:14:58,000
+As you can see, I have one product name in the products array, but my purchase status is the same.
+
+186
+00:14:58,000 --> 00:15:03,000
+Number three paid and it wasn't changed to complete it.
+
+187
+00:15:03,000 --> 00:15:08,000
+That proves that our new endpoint updates only products property.
+
+188
+00:15:09,000 --> 00:15:11,000
+That's how you can secure your API.
+
+189
+00:15:12,000 --> 00:15:18,000
+Now you learned how to avoid broken object property level authorization on example.
+
+190
+00:15:19,000 --> 00:15:23,000
+That's all what I wanted to explain you about this OWASp category.
+
+191
+00:15:24,000 --> 00:15:26,000
+Let's recap what we've learned in this lesson.
+
+192
+00:15:27,000 --> 00:15:33,000
+We defined the broken object property level authorization and discussed its importance in API security.
+
+193
+00:15:34,000 --> 00:15:41,000
+We examined potential threat agents and attack vectors, understanding their impact on security weaknesses.
+
+194
+00:15:41,000 --> 00:15:48,000
+We reviewed real world consequences of these vulnerabilities through two example scenarios a fitness
+
+195
+00:15:48,000 --> 00:15:52,000
+apps workout tracking, and an online learning platform squeeze submissions.
+
+196
+00:15:53,000 --> 00:15:58,000
+We covered prevention measures including implementing access controls, minimizing data exposure using
+
+197
+00:15:58,000 --> 00:16:02,000
+schema based validation, and avoiding reliance on client side filtering.
+
+198
+00:16:03,000 --> 00:16:08,000
+We explored related concepts such as excessive data exposure and mass assignments from the OWASp API
+
+199
+00:16:08,000 --> 00:16:09,000
+top ten.
+
+200
+00:16:09,000 --> 00:16:14,000
+We applied these concepts through a practical source code review of an online shop.
+
+201
+00:16:15,000 --> 00:16:17,000
+That's all for this lesson.
+
+202
+00:16:17,000 --> 00:16:19,000
+Thanks a lot for your attention.
+
+203
+00:16:19,000 --> 00:16:22,000
+Have a great day and see you in the next lesson.
+
diff --git a/74 - OWASP API Security Top 10 2023/009 Source-code-examples-from-the-lesson.url b/74 - OWASP API Security Top 10 2023/009 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..cc38c58574634605ce3abd9d44ae3cc492a7fc11
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/009 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/bopla
\ No newline at end of file
diff --git a/74 - OWASP API Security Top 10 2023/010 API42023 Unrestricted Resource Consumption - Part 1_en.srt b/74 - OWASP API Security Top 10 2023/010 API42023 Unrestricted Resource Consumption - Part 1_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..64e6bc824c2664a42e92a16ee5b4878fa7c81f1f
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/010 API42023 Unrestricted Resource Consumption - Part 1_en.srt
@@ -0,0 +1,1308 @@
+1
+00:00:05,000 --> 00:00:12,000
+Hello dear students, in this lesson we will talk about such vulnerability as unrestricted resource
+
+2
+00:00:12,000 --> 00:00:13,000
+consumption.
+
+3
+00:00:14,000 --> 00:00:21,000
+We will start by defining what this issue means, focusing on how it occurs when systems don't properly
+
+4
+00:00:21,000 --> 00:00:22,000
+limit resource use.
+
+5
+00:00:23,000 --> 00:00:28,000
+Next, we'll look at who might exploit these vulnerabilities and how they do it.
+
+6
+00:00:28,000 --> 00:00:33,000
+We'll discuss common methods attackers use to take advantage of these weaknesses.
+
+7
+00:00:33,000 --> 00:00:39,000
+After that, we'll identify common design flaws and configuration problems that lead to unrestricted
+
+8
+00:00:39,000 --> 00:00:40,000
+resource consumption.
+
+9
+00:00:41,000 --> 00:00:45,000
+Knowing these issues will help us understand where vulnerabilities typically appear.
+
+10
+00:00:46,000 --> 00:00:49,000
+Then we'll analyze the technical impact of these problems.
+
+11
+00:00:49,000 --> 00:00:55,000
+You will see how they can slow down systems, cause crashes and other performance issues.
+
+12
+00:00:55,000 --> 00:01:01,000
+We'll also look at the business impact, including the financial and operational consequences.
+
+13
+00:01:02,000 --> 00:01:07,000
+To make things clear, we'll review real world examples of unrestricted resource consumption.
+
+14
+00:01:07,000 --> 00:01:14,000
+We will cover cases like SMS abuse, leading to financial losses, increased cloud storage costs, and
+
+15
+00:01:14,000 --> 00:01:18,000
+a major DDoS attack on Poland's tax portal.
+
+16
+00:01:18,000 --> 00:01:29,000
+We'll then discuss specific weaknesses such as CW 770, CW 400, and CW 799.
+
+17
+00:01:29,000 --> 00:01:32,000
+For each, we'll explain the problem and how to fix it.
+
+18
+00:01:33,000 --> 00:01:37,000
+Finally, we'll talk about how to detect and prevent disease issues.
+
+19
+00:01:37,000 --> 00:01:41,000
+We'll cover best practices to keep your systems secure and efficient.
+
+20
+00:01:42,000 --> 00:01:48,000
+We'll end with a practical example of source code showing a common problem and its solution to bring
+
+21
+00:01:48,000 --> 00:01:49,000
+everything together.
+
+22
+00:01:49,000 --> 00:01:51,000
+Let's start our lesson.
+
+23
+00:01:52,000 --> 00:01:55,000
+And to start with, let's give an answer.
+
+24
+00:01:55,000 --> 00:01:58,000
+What is unrestricted resource consumption.
+
+25
+00:01:59,000 --> 00:02:06,000
+Unrestricted resource consumption refers to a type of vulnerability where an application or API does
+
+26
+00:02:06,000 --> 00:02:10,000
+not properly limit the amount of system resources a user can consume.
+
+27
+00:02:11,000 --> 00:02:17,000
+These resources include CPU, memory, disk space, and network bandwidth.
+
+28
+00:02:17,000 --> 00:02:24,000
+When these limitations are absent or inadequately enforced, an attacker can exploit the system by consuming
+
+29
+00:02:24,000 --> 00:02:25,000
+excessive resources.
+
+30
+00:02:26,000 --> 00:02:30,000
+This can lead to significant performance degradation or even complete system outages.
+
+31
+00:02:31,000 --> 00:02:37,000
+To illustrate, consider a scenario where an API endpoint allows users to request a password reset without
+
+32
+00:02:37,000 --> 00:02:38,000
+any constraints.
+
+33
+00:02:39,000 --> 00:02:44,000
+An attacker could flood this endpoint with requests, causing the server to exhaust its resources as
+
+34
+00:02:44,000 --> 00:02:46,000
+it processes each request.
+
+35
+00:02:48,000 --> 00:02:54,000
+There are several common ways attackers exploit unrestricted resource consumption vulnerabilities.
+
+36
+00:02:54,000 --> 00:02:59,000
+One of the primary vectors is through a lack of constraints on execution time.
+
+37
+00:02:59,000 --> 00:03:07,000
+For example, if an API endpoint allows long running operations without a timeout, an attacker could
+
+38
+00:03:07,000 --> 00:03:10,000
+initiate operations that run indefinitely.
+
+39
+00:03:10,000 --> 00:03:16,000
+Tying up server resources and potentially causing a denial of service condition.
+
+40
+00:03:17,000 --> 00:03:21,000
+Another attack vector is related to memory consumption.
+
+41
+00:03:21,000 --> 00:03:29,000
+If an application accepts inputs that are too large or if it processes large files without size limits,
+
+42
+00:03:29,000 --> 00:03:34,000
+an attacker can exploit this by submitting excessively large data.
+
+43
+00:03:34,000 --> 00:03:41,000
+This can lead to memory exhaustion, which might cause the server to crash or become unresponsive.
+
+44
+00:03:41,000 --> 00:03:49,000
+Similarly, if there are no limits on the number of file uploads or the size of these files, the system
+
+45
+00:03:49,000 --> 00:03:53,000
+could quickly run out of disk space, leading to further disruptions.
+
+46
+00:03:54,000 --> 00:03:57,000
+Network bandwidth can also be targeted.
+
+47
+00:03:58,000 --> 00:04:05,000
+An attacker might send a large volume of requests or large data payloads to overwhelm the network infrastructure.
+
+48
+00:04:06,000 --> 00:04:12,000
+This not only impacts the targeted service, but can also degrade the performance of other services
+
+49
+00:04:12,000 --> 00:04:14,000
+hosted on the same network.
+
+50
+00:04:15,000 --> 00:04:21,000
+Several design flaws and configuration issues typically contribute to unrestricted resource consumption
+
+51
+00:04:21,000 --> 00:04:22,000
+vulnerabilities.
+
+52
+00:04:23,000 --> 00:04:30,000
+A common design flaw is the failure to implement rate limiting without rate limits.
+
+53
+00:04:30,000 --> 00:04:36,000
+There are no restrictions on how frequently a user or attacker can interact with the system, which
+
+54
+00:04:36,000 --> 00:04:38,000
+opens the door to abuse.
+
+55
+00:04:39,000 --> 00:04:45,000
+Similarly, inadequate input validation, and lack of constraints on data size or processing time can
+
+56
+00:04:45,000 --> 00:04:48,000
+allow malicious actors to exploit these weaknesses.
+
+57
+00:04:49,000 --> 00:04:51,000
+Configuration issues also play a significant role.
+
+58
+00:04:51,000 --> 00:04:58,000
+For instance, default configurations that do not enforce maximum execution time or memory usage limits
+
+59
+00:04:58,000 --> 00:04:59,000
+can be exploited.
+
+60
+00:05:00,000 --> 00:05:05,000
+Furthermore, failing to set proper quotas for resource usage, such as the maximum number of operations
+
+61
+00:05:05,000 --> 00:05:10,000
+or the maximum size of uploaded files, can lead to resource exhaustion.
+
+62
+00:05:11,000 --> 00:05:16,000
+Let's hold technical impact analysis and review different types of technical impact.
+
+63
+00:05:17,000 --> 00:05:20,000
+Denial of service at a technical level.
+
+64
+00:05:20,000 --> 00:05:26,000
+Unrestricted resource consumption can directly lead to a denial of service attack.
+
+65
+00:05:26,000 --> 00:05:34,000
+When an API or application does not impose limits on resource usage, attackers can exploit this vulnerability
+
+66
+00:05:34,000 --> 00:05:37,000
+to flood the system with excessive requests or data.
+
+67
+00:05:38,000 --> 00:05:44,000
+This overwhelms the system's ability to process legitimate requests, causing it to become unresponsive
+
+68
+00:05:44,000 --> 00:05:45,000
+or entirely unavailable.
+
+69
+00:05:46,000 --> 00:05:52,000
+For example, an endpoint that lacks rate limiting might be bombarded with thousands of requests per
+
+70
+00:05:52,000 --> 00:05:58,000
+second, consuming all available processing power and bandwidth, which renders the service unusable
+
+71
+00:05:58,000 --> 00:06:00,000
+for legitimate users.
+
+72
+00:06:01,000 --> 00:06:05,000
+During the lesson, I will use interchangeably two terms dose and dose.
+
+73
+00:06:05,000 --> 00:06:09,000
+Let's learn what is the difference between these two concepts?
+
+74
+00:06:10,000 --> 00:06:16,000
+A denial of service DDoS attack aims to disrupt a system or service by overwhelming it with traffic
+
+75
+00:06:16,000 --> 00:06:21,000
+or resource demands from a single source, leading to unresponsiveness.
+
+76
+00:06:21,000 --> 00:06:28,000
+In contrast, a distributed denial of service DDoS attack amplifies this by using multiple compromised
+
+77
+00:06:28,000 --> 00:06:34,000
+systems or botnets to flood the target with massive traffic from various sources, making it harder
+
+78
+00:06:34,000 --> 00:06:37,000
+to mitigate and causing more severe disruption.
+
+79
+00:06:37,000 --> 00:06:43,000
+Essentially, while DDoS attacks come from a single origin and are limited in scale, DDoS attacks are
+
+80
+00:06:43,000 --> 00:06:48,000
+widespread, leveraging numerous devices to create a larger, more damaging effect.
+
+81
+00:06:49,000 --> 00:06:51,000
+Let's get back to technical impact analysis.
+
+82
+00:06:52,000 --> 00:06:54,000
+Performance degradation.
+
+83
+00:06:55,000 --> 00:06:59,000
+Unrestricted resource consumption can severely degrade system performance.
+
+84
+00:06:59,000 --> 00:07:05,000
+For instance, if an application allows users to submit large files without restriction, the server's
+
+85
+00:07:05,000 --> 00:07:09,000
+memory and processing resources can become overtaxed.
+
+86
+00:07:09,000 --> 00:07:17,000
+As more resources are consumed, the application's response times increase and its throughput decreases.
+
+87
+00:07:17,000 --> 00:07:24,000
+This degradation impacts user experience, as legitimate users may experience sluggish performance or
+
+88
+00:07:24,000 --> 00:07:30,000
+timeouts, which can frustrate them and lead to loss of trust in the application.
+
+89
+00:07:31,000 --> 00:07:33,000
+High operational costs.
+
+90
+00:07:33,000 --> 00:07:40,000
+Another significant technical impact is the increase in operational costs when systems are forced to
+
+91
+00:07:40,000 --> 00:07:47,000
+handle excessive loads, whether through increased CPU usage, memory consumption or data transfer.
+
+92
+00:07:47,000 --> 00:07:50,000
+The operational costs can rise dramatically.
+
+93
+00:07:51,000 --> 00:07:56,000
+For example, cloud based services often charge based on resource consumption.
+
+94
+00:07:57,000 --> 00:08:02,000
+Excessive data transfer or processing can lead to substantial financial burdens.
+
+95
+00:08:02,000 --> 00:08:08,000
+If an application experiences spikes in resource usage due to unrestricted access.
+
+96
+00:08:08,000 --> 00:08:15,000
+The associated costs can be substantial, especially if billing is based on usage metrics.
+
+97
+00:08:16,000 --> 00:08:19,000
+Let's talk about potential business impact.
+
+98
+00:08:20,000 --> 00:08:23,000
+Financial losses from a business perspective.
+
+99
+00:08:23,000 --> 00:08:28,000
+The financial implications of unrestricted resource consumption can be severe.
+
+100
+00:08:28,000 --> 00:08:34,000
+Increased operational costs, as previously mentioned, are a direct financial impact.
+
+101
+00:08:34,000 --> 00:08:40,000
+Additionally, businesses may face additional costs related to scaling infrastructure to handle the
+
+102
+00:08:40,000 --> 00:08:44,000
+excessive load or to mitigate the impact of an attack.
+
+103
+00:08:44,000 --> 00:08:50,000
+For example, if an e-commerce site is targeted with a resource intensive attack, the costs to upgrade
+
+104
+00:08:50,000 --> 00:08:55,000
+servers, expand bandwidth, or deploy additional defenses can be substantial.
+
+105
+00:08:55,000 --> 00:08:59,000
+These unplanned expenses can significantly impact the bottom line.
+
+106
+00:08:59,000 --> 00:09:01,000
+Operational disruptions.
+
+107
+00:09:01,000 --> 00:09:04,000
+Operational disruptions are another critical business impact.
+
+108
+00:09:04,000 --> 00:09:10,000
+When an application becomes slow or unresponsive due to resource exhaustion, it can disrupt business
+
+109
+00:09:10,000 --> 00:09:11,000
+operations.
+
+110
+00:09:11,000 --> 00:09:17,000
+For an e-commerce business, this means lost sales opportunities as customers are unable to complete
+
+111
+00:09:17,000 --> 00:09:18,000
+transactions.
+
+112
+00:09:19,000 --> 00:09:25,000
+Prolonged outages or degraded performance can disrupt business processes, affect productivity, and
+
+113
+00:09:25,000 --> 00:09:27,000
+lead to operational inefficiencies.
+
+114
+00:09:28,000 --> 00:09:34,000
+Moreover, frequent disruptions can require additional resources to resolve issues further escalating
+
+115
+00:09:34,000 --> 00:09:35,000
+costs.
+
+116
+00:09:36,000 --> 00:09:38,000
+Reputational damage.
+
+117
+00:09:38,000 --> 00:09:43,000
+The reputational damage resulting from such vulnerabilities can be considerable.
+
+118
+00:09:43,000 --> 00:09:47,000
+Customers expect reliable and performance services.
+
+119
+00:09:47,000 --> 00:09:54,000
+When an application is repeatedly down or slow due to resource related issues, it erodes customer trust
+
+120
+00:09:54,000 --> 00:09:57,000
+and can damage the company's reputation.
+
+121
+00:09:58,000 --> 00:10:05,000
+Negative reviews, social media backlash, and customer dissatisfaction can have long term effects on
+
+122
+00:10:05,000 --> 00:10:08,000
+brand perception and customer retention.
+
+123
+00:10:08,000 --> 00:10:16,000
+For example, a high profile e-commerce site experiencing frequent outages may lose customers to competitors,
+
+124
+00:10:16,000 --> 00:10:19,000
+impacting market share and brand loyalty.
+
+125
+00:10:20,000 --> 00:10:26,000
+To learn more how to avoid unrestricted resource consumption, let's review real world examples.
+
+126
+00:10:27,000 --> 00:10:32,000
+Knowing the history and real examples, you can become more experienced and learn how to avoid this
+
+127
+00:10:32,000 --> 00:10:35,000
+type of vulnerability during the development.
+
+128
+00:10:36,000 --> 00:10:40,000
+Scenario one SMS abuse leading to financial loss.
+
+129
+00:10:40,000 --> 00:10:42,000
+NordVPN.
+
+130
+00:10:42,000 --> 00:10:50,000
+In this scenario, we observe how an unrestricted resource consumption vulnerability can lead to significant
+
+131
+00:10:50,000 --> 00:10:52,000
+financial repercussions.
+
+132
+00:10:52,000 --> 00:10:58,000
+NordVPN, a prominent virtual private network service provider, experienced an issue where their forgot
+
+133
+00:10:58,000 --> 00:11:01,000
+password API endpoint had no rate limits.
+
+134
+00:11:01,000 --> 00:11:06,000
+This allowed an attacker to continuously initiate password reset requests, which in turn triggered
+
+135
+00:11:06,000 --> 00:11:09,000
+the sending of SMS messages to users.
+
+136
+00:11:09,000 --> 00:11:16,000
+The abuse of this endpoint resulted in a flood of SMS messages being sent, each incurring a cost without
+
+137
+00:11:16,000 --> 00:11:18,000
+proper rate limiting or quota management.
+
+138
+00:11:18,000 --> 00:11:24,000
+The attacker exploited this lack of restriction to generate a massive volume of requests.
+
+139
+00:11:24,000 --> 00:11:31,000
+The financial impact was considerable as the cost of sending SMS messages quickly accumulated.
+
+140
+00:11:31,000 --> 00:11:41,000
+For instance, if sending an SMS costs $0.0079 and an attacker sends 10,000 messages is a financial
+
+141
+00:11:41,000 --> 00:11:43,000
+outlay for the service provider.
+
+142
+00:11:43,000 --> 00:11:51,000
+Amounts to $79, not including the potential administrative and operational costs incurred from handling
+
+143
+00:11:51,000 --> 00:11:54,000
+the attack scenario.
+
+144
+00:11:54,000 --> 00:11:56,000
+Increased cloud storage costs.
+
+145
+00:11:57,000 --> 00:11:59,000
+File download service.
+
+146
+00:12:00,000 --> 00:12:06,000
+Consider a file download service where users can upload and download files without restriction.
+
+147
+00:12:07,000 --> 00:12:14,000
+In the absence of limits on file sizes or number of requests, attackers can exploit this by uploading
+
+148
+00:12:14,000 --> 00:12:18,000
+extremely large files or performing numerous downloads in a short period.
+
+149
+00:12:19,000 --> 00:12:20,000
+The result is twofold.
+
+150
+00:12:20,000 --> 00:12:27,000
+First, the immediate impact is on the server's storage resources, which can quickly become saturated.
+
+151
+00:12:28,000 --> 00:12:34,000
+Second, the increased storage usage directly translates into higher cloud storage costs.
+
+152
+00:12:34,000 --> 00:12:39,000
+Cloud providers often charge based on the amount of data stored and transferred.
+
+153
+00:12:39,000 --> 00:12:48,000
+For instance, if a cloud provider charges $0.10 per GB and an attacker's activities lead to the accumulation
+
+154
+00:12:48,000 --> 00:12:54,000
+of ten terabytes of data, the additional cost to the service provider would be $1,000.
+
+155
+00:12:55,000 --> 00:13:01,000
+This not only affects financial resources, but also requires operational intervention to manage and
+
+156
+00:13:01,000 --> 00:13:03,000
+mitigate the excessive usage.
+
+157
+00:13:04,000 --> 00:13:09,000
+The next case study is DDoS attack on Poland's tax portal.
+
+158
+00:13:10,000 --> 00:13:17,000
+In this case study, we analyze a significant DDoS distributed denial of service attack on Poland's
+
+159
+00:13:17,000 --> 00:13:23,000
+tax portal, which demonstrates the severe impact of unrestricted resource consumption vulnerabilities
+
+160
+00:13:23,000 --> 00:13:25,000
+in a high stakes environment.
+
+161
+00:13:25,000 --> 00:13:32,000
+The tax portal used by citizens for tax filings and financial management became the target of a large
+
+162
+00:13:32,000 --> 00:13:34,000
+scale DDoS attack.
+
+163
+00:13:35,000 --> 00:13:40,000
+The attackers exploited vulnerabilities in the portal's infrastructure to send a massive volume of requests,
+
+164
+00:13:40,000 --> 00:13:43,000
+overwhelming the system's resources.
+
+165
+00:13:43,000 --> 00:13:49,000
+This attack resulted in a substantial degradation of service, rendering the portal unavailable to legitimate
+
+166
+00:13:49,000 --> 00:13:50,000
+users.
+
+167
+00:13:50,000 --> 00:13:56,000
+The attack leveraged multiple compromised systems to generate a flood of traffic, consuming both network
+
+168
+00:13:56,000 --> 00:13:59,000
+bandwidth and server resources.
+
+169
+00:14:00,000 --> 00:14:01,000
+Let's analyze the impact.
+
+170
+00:14:03,000 --> 00:14:06,000
+The immediate technical impact was a complete service outage.
+
+171
+00:14:06,000 --> 00:14:12,000
+The attack overwhelmed the portal's servers, leading to system crashes and unresponsiveness.
+
+172
+00:14:13,000 --> 00:14:20,000
+The high volume of requests consumed all available CPU and memory resources, making it impossible for
+
+173
+00:14:20,000 --> 00:14:23,000
+the portal to handle legitimate user requests.
+
+174
+00:14:24,000 --> 00:14:26,000
+The business repercussions were significant.
+
+175
+00:14:27,000 --> 00:14:34,000
+The tax portal's unavailability disrupted tax filing processes, causing frustration among users and
+
+176
+00:14:34,000 --> 00:14:37,000
+potentially delaying critical tax related operations.
+
+177
+00:14:38,000 --> 00:14:45,000
+The downtime led to operational inefficiencies and necessitated extensive resources to mitigate the
+
+178
+00:14:45,000 --> 00:14:48,000
+attack and restore normal functionality.
+
+179
+00:14:48,000 --> 00:14:54,000
+Additionally, there were increased costs associated with DDoS mitigation and recovery efforts.
+
+180
+00:14:55,000 --> 00:15:01,000
+Beyond the technical and financial impacts, the incident had severe reputational consequences.
+
+181
+00:15:01,000 --> 00:15:07,000
+The inability to provide reliable service eroded public trust in the tax portal's capability to manage
+
+182
+00:15:07,000 --> 00:15:09,000
+critical functions.
+
+183
+00:15:09,000 --> 00:15:16,000
+This loss of trust can have long lasting effects on user confidence and government credibility.
+
+184
+00:15:17,000 --> 00:15:24,000
+The DDoS attack on Poland's tax portal serves as a stark reminder of the potential consequences of unrestricted
+
+185
+00:15:24,000 --> 00:15:27,000
+resource consumption vulnerabilities.
+
+186
+00:15:27,000 --> 00:15:33,000
+It underscores the importance of implementing robust rate limiting resource management and security
+
+187
+00:15:33,000 --> 00:15:36,000
+measures to protect against such attacks.
+
+188
+00:15:37,000 --> 00:15:43,000
+In scope of this lesson, I would like to remind you that during the learning of each vulnerability,
+
+189
+00:15:43,000 --> 00:15:46,000
+it is recommended to explore related keywords.
+
+190
+00:15:47,000 --> 00:15:54,000
+In previous lessons about OWASp, I already explained what CWA, but let me shortly remind you what
+
+191
+00:15:54,000 --> 00:15:54,000
+it is.
+
+192
+00:15:55,000 --> 00:15:58,000
+CWA stands for Common Weakness enumeration.
+
+193
+00:15:59,000 --> 00:16:03,000
+It is a community developed list of software and hardware weaknesses.
+
+194
+00:16:04,000 --> 00:16:09,000
+It provides a standardized classification of vulnerabilities that can help developers, security professionals,
+
+195
+00:16:09,000 --> 00:16:14,000
+and organizations understand and mitigate potential risks in their systems.
+
+196
+00:16:15,000 --> 00:16:21,000
+Each CWA entry identifies a specific type of weakness that can lead to security vulnerabilities, often
+
+197
+00:16:21,000 --> 00:16:24,000
+with associated examples, consequences, and mitigation strategies.
+
+198
+00:16:25,000 --> 00:16:31,000
+In the context of unrestricted resource consumption, several CWA queries address issues that can lead
+
+199
+00:16:31,000 --> 00:16:36,000
+to vulnerabilities related to the misuse or mismanagement of system resources.
+
+200
+00:16:37,000 --> 00:16:40,000
+Let's explore three particular quiz related to these concerns.
+
+201
+00:16:41,000 --> 00:16:49,000
+They are CWA 770, CWA 400 and CWA 799.
+
+202
+00:16:49,000 --> 00:16:51,000
+CWA 770.
+
+203
+00:16:51,000 --> 00:17:00,000
+Pertains to scenarios where a system allocates resources such as memory, CPU time, or disk space without
+
+204
+00:17:00,000 --> 00:17:02,000
+implementing adequate controls.
+
+205
+00:17:02,000 --> 00:17:09,000
+In essence, this weakness allows for unrestricted allocation, which can lead to significant system
+
+206
+00:17:09,000 --> 00:17:10,000
+issues.
+
+207
+00:17:11,000 --> 00:17:18,000
+Specifically, the absence of limitations means that an attacker could exploit this gap by consuming
+
+208
+00:17:18,000 --> 00:17:23,000
+excessive resources, thereby causing performance degradation or even system crashes.
+
+209
+00:17:24,000 --> 00:17:31,000
+To address CWA 770, it is crucial to incorporate proper resource management strategies.
+
+210
+00:17:31,000 --> 00:17:38,000
+This involves setting clear maximum thresholds for resource allocation, to ensure that no single process
+
+211
+00:17:38,000 --> 00:17:40,000
+or user can overwhelm the system.
+
+212
+00:17:41,000 --> 00:17:46,000
+Additionally, implementing throttling mechanisms can help regulate the rate of resource consumption.
+
+213
+00:17:47,000 --> 00:17:53,000
+Regular monitoring and resource usage audits are essential practices to detect any potential overuse
+
+214
+00:17:53,000 --> 00:17:55,000
+before it leads to severe issues.
+
+215
+00:17:56,000 --> 00:18:04,000
+CWA 400 refers to the uncontrolled consumption of resources, where a system lacks appropriate controls
+
+216
+00:18:04,000 --> 00:18:08,000
+to manage the amount of resources used by operations or users.
+
+217
+00:18:08,000 --> 00:18:15,000
+Without such controls, an attacker or even a high volume of legitimate requests can lead to system
+
+218
+00:18:15,000 --> 00:18:19,000
+overloads causing performance slowdowns or crashes.
+
+219
+00:18:19,000 --> 00:18:27,000
+For example, an API endpoint that allows unlimited data retrieval can be exploited to flood the system,
+
+220
+00:18:27,000 --> 00:18:30,000
+with requests leading to severe performance issues.
+
+221
+00:18:30,000 --> 00:18:36,000
+To mitigate the risks associated with CWA 400, it is essential to implement rate limiting and resource
+
+222
+00:18:36,000 --> 00:18:42,000
+quotas by setting limits on how much resource can be consumed and performing regular stress tests,
+
+223
+00:18:42,000 --> 00:18:45,000
+you can identify and address potential vulnerabilities.
+
+224
+00:18:45,000 --> 00:18:51,000
+Furthermore, integrating robust monitoring tools can help track resource usage patterns, enabling
+
+225
+00:18:51,000 --> 00:18:55,000
+timely intervention before the system experiences significant strain.
+
+226
+00:18:56,000 --> 00:19:04,000
+CWA 799 arises from improper control over the frequency of interactions with a system, such as how
+
+227
+00:19:04,000 --> 00:19:08,000
+often users can perform certain actions or make requests.
+
+228
+00:19:09,000 --> 00:19:15,000
+This lack of control can lead to excessive interaction rates, which may exhaust system resources and
+
+229
+00:19:15,000 --> 00:19:17,000
+cause performance issues.
+
+230
+00:19:17,000 --> 00:19:24,000
+For instance, if an API endpoint does not limit the number of password reset requests it could be abused
+
+231
+00:19:24,000 --> 00:19:27,000
+to generate a flood of requests, overwhelming the system.
+
+232
+00:19:28,000 --> 00:19:35,000
+To counteract Kiwi 799, it is important to enforce limits on the frequency of interactions.
+
+233
+00:19:35,000 --> 00:19:42,000
+This can be achieved by implementing rate limiting mechanisms and setting thresholds for request rates.
+
+234
+00:19:42,000 --> 00:19:49,000
+Managing quotas for how often users can perform specific actions helps in controlling interaction frequency.
+
+235
+00:19:49,000 --> 00:19:55,000
+Additionally, regularly reviewing and testing interaction patterns can aid in identifying and addressing
+
+236
+00:19:55,000 --> 00:19:58,000
+potential weaknesses in the system's controls.
+
+237
+00:20:00,000 --> 00:20:06,000
+As we delve into the realm of unrestricted resource consumption, it's crucial to understand how to
+
+238
+00:20:06,000 --> 00:20:09,000
+effectively detect and prevent this vulnerability.
+
+239
+00:20:09,000 --> 00:20:15,000
+This ensures that systems remain robust and resilient against potential attacks.
+
+240
+00:20:15,000 --> 00:20:19,000
+Let's explore each aspect of detection and prevention strategies in detail.
+
+241
+00:20:21,000 --> 00:20:23,000
+Identify an unrestricted resource.
+
+242
+00:20:23,000 --> 00:20:28,000
+Consumption vulnerabilities involves recognizing certain key indicators that suggest the system may
+
+243
+00:20:28,000 --> 00:20:29,000
+be prone to exploitation.
+
+244
+00:20:29,000 --> 00:20:36,000
+Common signs include lack of constraints, systems that do not impose limits on operations, such as
+
+245
+00:20:36,000 --> 00:20:43,000
+file uploads, database queries, or API requests are particularly vulnerable if an endpoint or service
+
+246
+00:20:43,000 --> 00:20:47,000
+allows excessive operations without any restrictions, it is a potential risk.
+
+247
+00:20:48,000 --> 00:20:50,000
+Performance degradation.
+
+248
+00:20:50,000 --> 00:20:57,000
+If you observe significant slowdowns or performance issues when certain inputs or operations are performed,
+
+249
+00:20:57,000 --> 00:21:02,000
+this may indicate that the system is struggling to manage excessive resource consumption.
+
+250
+00:21:03,000 --> 00:21:05,000
+Resource exhaustion alerts.
+
+251
+00:21:05,000 --> 00:21:13,000
+Monitoring tools that track CPU, memory, or network usage might show unexpected spikes.
+
+252
+00:21:13,000 --> 00:21:19,000
+These anomalies can signal that the system is under stress due to uncontrolled resource usage.
+
+253
+00:21:20,000 --> 00:21:22,000
+Frequent errors or crashes.
+
+254
+00:21:23,000 --> 00:21:29,000
+A pattern of system errors or crashes triggered by specific actions, such as large file uploads or
+
+255
+00:21:29,000 --> 00:21:30,000
+frequent requests.
+
+256
+00:21:30,000 --> 00:21:33,000
+Often points to a lack of resource limits.
+
+257
+00:21:34,000 --> 00:21:40,000
+By actively monitoring for these indicators, organizations can identify potential vulnerabilities early
+
+258
+00:21:40,000 --> 00:21:42,000
+and take corrective measures.
+
+259
+00:21:43,000 --> 00:21:48,000
+The multiple of prevention strategies that I'd like you to learn from this lesson.
+
+260
+00:21:48,000 --> 00:21:50,000
+Let's review them.
+
+261
+00:21:50,000 --> 00:21:55,000
+And just a reminder, in case something is not clear for you, you don't have to wait till the end of
+
+262
+00:21:55,000 --> 00:21:56,000
+the lesson.
+
+263
+00:21:56,000 --> 00:22:00,000
+Just post your question below the video and I will be happy to answer.
+
+264
+00:22:01,000 --> 00:22:08,000
+One effective way to manage resource consumption is by setting execution timeouts for operations.
+
+265
+00:22:08,000 --> 00:22:14,000
+Timeouts ensures that processes do not run indefinitely, thereby preventing them from monopolizing
+
+266
+00:22:14,000 --> 00:22:15,000
+system resources.
+
+267
+00:22:15,000 --> 00:22:21,000
+For example, you might configure your server or application to terminate operations that exceed a specified
+
+268
+00:22:21,000 --> 00:22:22,000
+duration.
+
+269
+00:22:23,000 --> 00:22:28,000
+Establishing memory limits is another crucial strategy by defining the maximum amount of memory that
+
+270
+00:22:28,000 --> 00:22:33,000
+can be allocated for a process, you can prevent excessive memory consumption.
+
+271
+00:22:33,000 --> 00:22:38,000
+This can be configured at the application level or within the server's environment.
+
+272
+00:22:38,000 --> 00:22:39,000
+Settings.
+
+273
+00:22:40,000 --> 00:22:42,000
+File size restrictions.
+
+274
+00:22:42,000 --> 00:22:49,000
+Implementing file size restrictions helps control the amount of data that can be processed in a single
+
+275
+00:22:49,000 --> 00:22:49,000
+operation.
+
+276
+00:22:50,000 --> 00:22:56,000
+By setting limits on file uploads and downloads, you can mitigate the risk of overwhelming the system
+
+277
+00:22:56,000 --> 00:22:58,000
+with excessively large files.
+
+278
+00:23:00,000 --> 00:23:06,000
+Rate limiting is a fundamental technique for controlling the number of requests that a user or IP address
+
+279
+00:23:06,000 --> 00:23:11,000
+can make to an API or service within a given time frame.
+
+280
+00:23:11,000 --> 00:23:18,000
+This prevents abuse by ensuring that no single entity can overwhelm the system or with a high volume
+
+281
+00:23:18,000 --> 00:23:19,000
+of requests.
+
+282
+00:23:20,000 --> 00:23:26,000
+In addition to rate limiting, setting request quotas allows you to define limits on the total number
+
+283
+00:23:26,000 --> 00:23:31,000
+of operations or requests that can be performed by a user over a specific period.
+
+284
+00:23:32,000 --> 00:23:39,000
+For example, a user might be allowed to make up to 100 API calls per hour, after which further requests
+
+285
+00:23:39,000 --> 00:23:41,000
+are denied until the quota is reset.
+
+286
+00:23:42,000 --> 00:23:47,000
+To ensure that rate limits and quotas are effective, it is essential to fine tune these parameters
+
+287
+00:23:47,000 --> 00:23:51,000
+based on the specific needs and usage patterns of your application.
+
+288
+00:23:52,000 --> 00:23:57,000
+This may involve analyzing traffic patterns and adjusting limits to balance performance and security.
+
+289
+00:23:59,000 --> 00:24:05,000
+Validating input parameters is crucial to ensure that requests do not exceed acceptable limits.
+
+290
+00:24:06,000 --> 00:24:13,000
+This involves checking the size, type, and content of inputs to prevent excessively large or resource
+
+291
+00:24:13,000 --> 00:24:15,000
+intensive data from being processed.
+
+292
+00:24:17,000 --> 00:24:20,000
+Throttling controls the rate at which operations are performed.
+
+293
+00:24:20,000 --> 00:24:26,000
+This can include limiting the frequency of certain actions, such as password reset requests or data
+
+294
+00:24:26,000 --> 00:24:30,000
+processing tasks, to prevent them from overloading the system.
+
+295
+00:24:31,000 --> 00:24:37,000
+Implementing validation and throttling techniques involves integrating checks and controls into your
+
+296
+00:24:37,000 --> 00:24:38,000
+application's logic.
+
+297
+00:24:38,000 --> 00:24:45,000
+For instance, validating the size of file uploads and the frequency of API requests can prevent excessive
+
+298
+00:24:45,000 --> 00:24:47,000
+resource usage.
+
+299
+00:24:48,000 --> 00:24:55,000
+Setting spending limits for third party services, such as cloud storage or SMS providers, helps prevent
+
+300
+00:24:55,000 --> 00:24:57,000
+unexpected financial impacts.
+
+301
+00:24:57,000 --> 00:25:04,000
+By defining caps on spending, you can ensure that costs do not escalate due to uncontrolled resource
+
+302
+00:25:04,000 --> 00:25:04,000
+consumption.
+
+303
+00:25:06,000 --> 00:25:11,000
+Regularly monitoring usage and costs associated with third party services is essential for detecting
+
+304
+00:25:11,000 --> 00:25:12,000
+Anomalies.
+
+305
+00:25:12,000 --> 00:25:18,000
+This can be achieved through dashboards and alerts that notify you of unusual spending patterns or exceeding
+
+306
+00:25:18,000 --> 00:25:20,000
+predefined thresholds.
+
+307
+00:25:21,000 --> 00:25:27,000
+Configuring alerts and caps for third party services involves setting up notifications to warn you when
+
+308
+00:25:27,000 --> 00:25:30,000
+spending approaches or exceeds predefined limits.
+
+309
+00:25:30,000 --> 00:25:34,000
+This allows you to take corrective action before costs become unmanageable.
+
+310
+00:25:35,000 --> 00:25:42,000
+For instance, if your application uses an SMS service for notifications, monitoring the number of
+
+311
+00:25:42,000 --> 00:25:48,000
+messages sent and setting spending alerts can help you manage costs effectively and detect potential
+
+312
+00:25:48,000 --> 00:25:49,000
+misuse.
+
+313
+00:25:50,000 --> 00:25:55,000
+And now, I would like to share with you some of the best practices to follow that will help you to
+
+314
+00:25:55,000 --> 00:25:57,000
+prevent unrestricted resource consumption.
+
+315
+00:25:59,000 --> 00:26:05,000
+Consistent monitoring of system performance and resource usage is vital for identifying potential issues
+
+316
+00:26:05,000 --> 00:26:05,000
+early.
+
+317
+00:26:05,000 --> 00:26:11,000
+Use monitoring tools to track key metrics and receive alerts for abnormal behavior.
+
+318
+00:26:12,000 --> 00:26:18,000
+Conducting threat modeling helps identify potential vulnerabilities related to resource consumption
+
+319
+00:26:18,000 --> 00:26:21,000
+by analyzing your system's design and operation.
+
+320
+00:26:21,000 --> 00:26:26,000
+You can uncover areas where resource abuse could occur and address them proactively.
+
+321
+00:26:28,000 --> 00:26:33,000
+Regular code reviews are essential for ensuring that resource management practices are correctly implemented.
+
+322
+00:26:33,000 --> 00:26:40,000
+Reviewing code helps identify weaknesses and confirm that appropriate limits and controls are in place.
+
+323
+00:26:41,000 --> 00:26:48,000
+In summary, detecting and preventing unrestricted resource consumption involves a multifaceted approach
+
+324
+00:26:49,000 --> 00:26:55,000
+by setting resource limits, implementing rate limiting, validating inputs, controlling costs, and
+
+325
+00:26:55,000 --> 00:26:57,000
+adhering to best practices.
+
+326
+00:26:57,000 --> 00:27:03,000
+Organizations can safeguard their systems against potential vulnerabilities and ensure reliable and
+
+327
+00:27:03,000 --> 00:27:05,000
+efficient operations.
+
diff --git a/74 - OWASP API Security Top 10 2023/011 API42023 Unrestricted Resource Consumption - Part 2 (Practice)_en.srt b/74 - OWASP API Security Top 10 2023/011 API42023 Unrestricted Resource Consumption - Part 2 (Practice)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..99f6812ff7ac3079eda1006cb99c229844fc216d
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/011 API42023 Unrestricted Resource Consumption - Part 2 (Practice)_en.srt
@@ -0,0 +1,488 @@
+1
+00:00:03,000 --> 00:00:05,000
+Let's review source code examples.
+
+2
+00:00:05,000 --> 00:00:10,000
+Now we will review source code of the problem and then we'll review solution.
+
+3
+00:00:10,000 --> 00:00:15,000
+As always, you can find all source code examples in attachments to the lesson.
+
+4
+00:00:15,000 --> 00:00:19,000
+In case during the explanation something will be not clear for you.
+
+5
+00:00:19,000 --> 00:00:25,000
+Or in case you have any questions regarding the example, please don't wait till the end of the lesson.
+
+6
+00:00:25,000 --> 00:00:30,000
+Just post your question below the video and I will be happy to answer.
+
+7
+00:00:30,000 --> 00:00:33,000
+So let's start review the code from the problem statement.
+
+8
+00:00:33,000 --> 00:00:39,000
+And at first let me give you some context about the example and what this class is supposed to do.
+
+9
+00:00:39,000 --> 00:00:47,000
+This servlet problem password reset servlet is designed to handle password reset requests when a user
+
+10
+00:00:47,000 --> 00:00:50,000
+submits their email address via a Post request.
+
+11
+00:00:50,000 --> 00:00:53,000
+The servlet performs the following tasks.
+
+12
+00:00:54,000 --> 00:00:58,000
+It fetches the user associated with the provided email from a user.
+
+13
+00:00:58,000 --> 00:01:05,000
+Facades service I create object of user facade for that and interact through the user facade.
+
+14
+00:01:06,000 --> 00:01:13,000
+This is the real code from my online shop applications that we develop with my students during my course.
+
+15
+00:01:13,000 --> 00:01:15,000
+Java from zero to first job.
+
+16
+00:01:16,000 --> 00:01:20,000
+The servlet retrieves the user by their email address.
+
+17
+00:01:20,000 --> 00:01:24,000
+If the email is invalid, that is, no user is found.
+
+18
+00:01:24,000 --> 00:01:28,000
+It responds with a 400 bad request status.
+
+19
+00:01:29,000 --> 00:01:33,000
+This is a standard practice to handle user input errors gracefully.
+
+20
+00:01:34,000 --> 00:01:37,000
+It generates a four digit reset code.
+
+21
+00:01:37,000 --> 00:01:41,000
+The generate reset code method creates a four digit numeric code.
+
+22
+00:01:42,000 --> 00:01:45,000
+This is a common practice in password reset functionality.
+
+23
+00:01:46,000 --> 00:01:53,000
+However, it lacks complexity, which may impact security for enhanced security.
+
+24
+00:01:53,000 --> 00:01:56,000
+A more complex code or token might be preferable.
+
+25
+00:01:57,000 --> 00:02:00,000
+The user object is updated with this reset code.
+
+26
+00:02:00,000 --> 00:02:04,000
+As you can see, I set reset code and code expiration date.
+
+27
+00:02:05,000 --> 00:02:10,000
+The code for updating the user with the reset code and sending an email is commented out.
+
+28
+00:02:10,000 --> 00:02:16,000
+Ideally, this operations should be implemented to ensure the password reset process is completed.
+
+29
+00:02:16,000 --> 00:02:19,000
+But I believe you understand the context.
+
+30
+00:02:19,000 --> 00:02:23,000
+You can also implement it as part of your homework as you wish.
+
+31
+00:02:23,000 --> 00:02:28,000
+But in scope of this lesson, we are focusing on the architecture itself, right?
+
+32
+00:02:29,000 --> 00:02:35,000
+So no matter which is your primary programming language, I want you to grasp the core idea of the problem
+
+33
+00:02:35,000 --> 00:02:36,000
+statement.
+
+34
+00:02:38,000 --> 00:02:41,000
+And finally it responds with a success message.
+
+35
+00:02:42,000 --> 00:02:47,000
+Now let's analyze and answer the question what is wrong with this code?
+
+36
+00:02:47,000 --> 00:02:50,000
+I mean, what is wrong with the approach?
+
+37
+00:02:51,000 --> 00:02:56,000
+Based on the name of the lesson, you may guess that it should be something related to unrestricted
+
+38
+00:02:56,000 --> 00:02:57,000
+resource consumption.
+
+39
+00:02:58,000 --> 00:03:03,000
+But where do you see it already after completing the theoretical part of the lesson?
+
+40
+00:03:04,000 --> 00:03:09,000
+A critical issue with this implementation is the absence of rate limiting or throttling.
+
+41
+00:03:10,000 --> 00:03:15,000
+Without these controls, the servlet is vulnerable to denial of service attacks.
+
+42
+00:03:15,000 --> 00:03:16,000
+How?
+
+43
+00:03:16,000 --> 00:03:17,000
+Let me show you.
+
+44
+00:03:17,000 --> 00:03:22,000
+An attacker could flood the endpoint with a high volume of password reset requests.
+
+45
+00:03:22,000 --> 00:03:26,000
+This could exhaust server resources and impact the availability of the service.
+
+46
+00:03:27,000 --> 00:03:30,000
+Each request triggers the creation of a reset code.
+
+47
+00:03:30,000 --> 00:03:36,000
+And while generating these codes is not resource intensive by itself, a large number of such requests
+
+48
+00:03:36,000 --> 00:03:41,000
+could lead to server overload, high computational load, or increased costs.
+
+49
+00:03:41,000 --> 00:03:47,000
+If the system is hosted on a cloud platform with pay as you go pricing.
+
+50
+00:03:47,000 --> 00:03:54,000
+If this servlet is part of a cloud based service, the excessive processing due to high request volumes
+
+51
+00:03:54,000 --> 00:03:57,000
+can lead to increased operational costs.
+
+52
+00:03:57,000 --> 00:04:04,000
+Cloud services often charge based on usage, so a flood of requests could significantly increase the
+
+53
+00:04:04,000 --> 00:04:05,000
+expense.
+
+54
+00:04:06,000 --> 00:04:10,000
+Okay, so let me open another class and we will review solution.
+
+55
+00:04:10,000 --> 00:04:18,000
+Now this revised servlet IRC solution password reset servlet improves upon the original by integrating
+
+56
+00:04:18,000 --> 00:04:23,000
+rate limiting mechanisms to control the frequency of password reset requests.
+
+57
+00:04:24,000 --> 00:04:25,000
+Here's how it works.
+
+58
+00:04:26,000 --> 00:04:30,000
+The servlet introduces a rate limiting mechanism to prevent abuse.
+
+59
+00:04:30,000 --> 00:04:35,000
+It enforces a maximum of five requests per 30 minutes.
+
+60
+00:04:36,000 --> 00:04:41,000
+This helps mitigate the risk of denial of service attacks by limiting the number of requests a user
+
+61
+00:04:41,000 --> 00:04:43,000
+can make in a given time frame.
+
+62
+00:04:44,000 --> 00:04:49,000
+Pay attention that in this class are declared max requests constant and time window in minutes.
+
+63
+00:04:49,000 --> 00:04:54,000
+Also, there is a static concurrent hash map where I will store information related to the number of
+
+64
+00:04:54,000 --> 00:04:56,000
+attempts for password reset.
+
+65
+00:04:57,000 --> 00:05:02,000
+It has a has string value as a key and rate limit info type as values.
+
+66
+00:05:03,000 --> 00:05:08,000
+As a rate limit, info class is used to track request counts and manage rate limits.
+
+67
+00:05:09,000 --> 00:05:14,000
+It stores expiry time when the current rate limit window ends.
+
+68
+00:05:14,000 --> 00:05:19,000
+Request count the number of requests made within the current window.
+
+69
+00:05:19,000 --> 00:05:23,000
+So let's now analyze the flow and go line by line.
+
+70
+00:05:24,000 --> 00:05:30,000
+The servlet retrieves the user associated with the provided email and performs the necessary operations
+
+71
+00:05:30,000 --> 00:05:33,000
+only if the rate limit has not been exceeded.
+
+72
+00:05:34,000 --> 00:05:41,000
+For this, we need to check the state of associated with the client identifier rate limit info I extract
+
+73
+00:05:41,000 --> 00:05:47,000
+the object from the map and perform rate limit check before processing a request.
+
+74
+00:05:47,000 --> 00:05:52,000
+The servlet checks whether the rate limit window has expired.
+
+75
+00:05:53,000 --> 00:05:57,000
+If expired, it resets the count and the expiry time.
+
+76
+00:05:58,000 --> 00:06:02,000
+It increments the request count if within the allowed limits.
+
+77
+00:06:02,000 --> 00:06:09,000
+If the limit is exceeded, it sends a 429 to many request status code informing the user of the rate
+
+78
+00:06:09,000 --> 00:06:10,000
+limit breach.
+
+79
+00:06:12,000 --> 00:06:17,000
+A reset code is generated and ideally would be sent to the user's email.
+
+80
+00:06:17,000 --> 00:06:22,000
+The code generation remains the same, but its impact is now controlled by rate limits.
+
+81
+00:06:23,000 --> 00:06:29,000
+If within limits, it updates the user with a reset code and sends a success response.
+
+82
+00:06:29,000 --> 00:06:37,000
+If the limit is exceeded, it responds with a 429 too many requests, status, and a message indicating
+
+83
+00:06:37,000 --> 00:06:40,000
+that the user should try again later.
+
+84
+00:06:41,000 --> 00:06:44,000
+Do you see the improvements in comparison with the previous solution?
+
+85
+00:06:44,000 --> 00:06:47,000
+How the solution fixes unrestricted resource consumption.
+
+86
+00:06:48,000 --> 00:06:51,000
+Let me elaborate on that by implementing rate limiting.
+
+87
+00:06:52,000 --> 00:06:57,000
+The servlet prevents any single user from making an excessive number of requests in a short period.
+
+88
+00:06:58,000 --> 00:07:03,000
+This ensures that system resources are not overwhelmed by a flood of requests from an individual user.
+
+89
+00:07:03,000 --> 00:07:07,000
+Addressing the unrestricted resource consumption issue directly.
+
+90
+00:07:08,000 --> 00:07:14,000
+The rate limit protects the system from DDoS attacks that exploit unrestricted request handling.
+
+91
+00:07:15,000 --> 00:07:21,000
+With a cap on request frequency, the server can handle legitimate traffic more efficiently, reducing
+
+92
+00:07:21,000 --> 00:07:24,000
+the risk of service degradation and crashes.
+
+93
+00:07:25,000 --> 00:07:31,000
+The rate limiting mechanism ensures that resource usage is controlled and predictable.
+
+94
+00:07:32,000 --> 00:07:39,000
+By limiting how many times a user can request a password reset, the server's computational resources,
+
+95
+00:07:39,000 --> 00:07:43,000
+such as processing power and memory, are used more efficiently.
+
+96
+00:07:43,000 --> 00:07:47,000
+Avoiding overuse and potential overload.
+
+97
+00:07:47,000 --> 00:07:53,000
+In addition to technical benefits, rate limiting helps maintain a stable and responsive service for
+
+98
+00:07:53,000 --> 00:07:54,000
+all users.
+
+99
+00:07:55,000 --> 00:08:00,000
+It prevents a system from being bogged down by a single user's excessive request.
+
+100
+00:08:01,000 --> 00:08:04,000
+Ensuring fair access and better service quality.
+
+101
+00:08:05,000 --> 00:08:12,000
+So we can say that this solution enhances the robustness of the password reset functionality by integrating
+
+102
+00:08:12,000 --> 00:08:14,000
+effective rate limiting.
+
+103
+00:08:14,000 --> 00:08:20,000
+It addresses the issue of unrestricted resource consumption by capping the number of requests that can
+
+104
+00:08:20,000 --> 00:08:22,000
+be made in a specific time frame.
+
+105
+00:08:23,000 --> 00:08:29,000
+This not only protects the server from potential abuse and denial of service attacks, but also ensures
+
+106
+00:08:30,000 --> 00:08:36,000
+efficient and fair usage of resources, thereby maintaining a smooth and reliable service for all users.
+
+107
+00:08:37,000 --> 00:08:40,000
+That's all what I wanted to share with you in this lesson.
+
+108
+00:08:40,000 --> 00:08:42,000
+Let's recap what we have learned.
+
+109
+00:08:43,000 --> 00:08:48,000
+We defined unrestricted resource consumption and examined how it can lead to system vulnerabilities.
+
+110
+00:08:48,000 --> 00:08:53,000
+We explored common threat agents and attack vectors that exploit these vulnerabilities.
+
+111
+00:08:54,000 --> 00:09:01,000
+We identified typical design flaws and configuration issues that contribute to resource overuse.
+
+112
+00:09:02,000 --> 00:09:08,000
+We analyzed the technical and business impacts of unrestricted resource consumption, understanding
+
+113
+00:09:08,000 --> 00:09:12,000
+both system performance and financial consequences.
+
+114
+00:09:12,000 --> 00:09:20,000
+We reviewed real world examples including SMS abuse, increased cloud storage costs, and DDoS attacks
+
+115
+00:09:20,000 --> 00:09:22,000
+to see these principles in action.
+
+116
+00:09:22,000 --> 00:09:32,000
+We examined specific cases such as Cui 770, Cui 400, and Cui 799.
+
+117
+00:09:32,000 --> 00:09:36,000
+To understand how these weaknesses manifest in different contexts.
+
+118
+00:09:37,000 --> 00:09:43,000
+We discussed detection methods and prevention strategies for mitigating these issues, and reviewed
+
+119
+00:09:43,000 --> 00:09:47,000
+best practices to ensure robust resource management.
+
+120
+00:09:48,000 --> 00:09:49,000
+That's all for the lesson.
+
+121
+00:09:49,000 --> 00:09:51,000
+Thanks a lot for your attention.
+
+122
+00:09:52,000 --> 00:09:55,000
+Have a great day and see you in the next lesson.
+
diff --git a/74 - OWASP API Security Top 10 2023/011 Source-code-examples-from-the-lesson.url b/74 - OWASP API Security Top 10 2023/011 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..fbc47799a05c2161edded1ceacff1c15535b60bf
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/011 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/urc
\ No newline at end of file
diff --git a/74 - OWASP API Security Top 10 2023/012 API52023 Broken Function Level Authorization - Part 1_en.srt b/74 - OWASP API Security Top 10 2023/012 API52023 Broken Function Level Authorization - Part 1_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..5802227c36f3dd3369907cf290823798535a0543
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/012 API52023 Broken Function Level Authorization - Part 1_en.srt
@@ -0,0 +1,860 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:13,000
+In this lesson we will learn about broken function level authorization, a critical issue in API security.
+
+3
+00:00:14,000 --> 00:00:19,000
+To start, we'll define broken function level authorization and explain its significance in the realm
+
+4
+00:00:19,000 --> 00:00:20,000
+of cyber security.
+
+5
+00:00:21,000 --> 00:00:27,000
+We'll also differentiate between broken function level authorization and a related issue called broken
+
+6
+00:00:27,000 --> 00:00:29,000
+object level authorization.
+
+7
+00:00:30,000 --> 00:00:34,000
+Next, we'll explore the root causes of broken function level authorization.
+
+8
+00:00:35,000 --> 00:00:40,000
+This will include a look at how complex access control policies, misconfigured hierarchies, and other
+
+9
+00:00:40,000 --> 00:00:43,000
+common pitfalls contribute to this vulnerability.
+
+10
+00:00:43,000 --> 00:00:46,000
+We'll then move on to real world attack scenarios.
+
+11
+00:00:47,000 --> 00:00:52,000
+I'll walk you through some illustrative examples to show how attackers might exploit broken function
+
+12
+00:00:52,000 --> 00:00:54,000
+level authorization vulnerabilities.
+
+13
+00:00:55,000 --> 00:01:00,000
+Understanding these scenarios will help you appreciate the potential consequences of broken function
+
+14
+00:01:00,000 --> 00:01:06,000
+level authorization, Realization such as data breaches, privilege escalation, and service disruptions.
+
+15
+00:01:07,000 --> 00:01:12,000
+Following this, we'll focus on how to detect broken function level authorization.
+
+16
+00:01:12,000 --> 00:01:19,000
+You'll learn about techniques for analyzing authorization mechanisms and the use of tools for API mapping
+
+17
+00:01:19,000 --> 00:01:21,000
+and vulnerability scanning.
+
+18
+00:01:22,000 --> 00:01:28,000
+To wrap things up, we'll cover prevention techniques to protect against broken function level authorization.
+
+19
+00:01:29,000 --> 00:01:35,000
+This will include best practices for implementing consistent authorization modules, applying the principle
+
+20
+00:01:35,000 --> 00:01:40,000
+of least privilege, and conducting regular API security testing.
+
+21
+00:01:40,000 --> 00:01:46,000
+Finally, we'll review a practical example through a source code review to illustrate a common broken
+
+22
+00:01:46,000 --> 00:01:50,000
+function level authorization problem and its solution.
+
+23
+00:01:50,000 --> 00:01:52,000
+Let's start our lesson.
+
+24
+00:01:53,000 --> 00:01:56,000
+Let's dive into broken function level authorization.
+
+25
+00:01:56,000 --> 00:02:04,000
+Often abbreviated as BFL, a broken function level authorization occurs when an application fails to
+
+26
+00:02:04,000 --> 00:02:11,000
+properly enforce authorization checks, thereby allowing users to access functionalities or resources
+
+27
+00:02:11,000 --> 00:02:13,000
+beyond their permitted scope.
+
+28
+00:02:14,000 --> 00:02:21,000
+In essence, broken function level authorization involves situations where users are able to interact
+
+29
+00:02:21,000 --> 00:02:27,000
+with or invoke functions within an API that they should not be authorized to access.
+
+30
+00:02:28,000 --> 00:02:33,000
+This issue is particularly significant because it can lead to unauthorized access to sensitive data
+
+31
+00:02:33,000 --> 00:02:37,000
+or critical functionality, posing serious security risks.
+
+32
+00:02:38,000 --> 00:02:42,000
+To better understand broken function level authorization, it is important to differentiate it from
+
+33
+00:02:42,000 --> 00:02:47,000
+another common security vulnerability known as broken object level authorization.
+
+34
+00:02:48,000 --> 00:02:53,000
+I also have the lesson about it in my course, so if you skipped it, I recommend you to watch it.
+
+35
+00:02:54,000 --> 00:03:01,000
+While broken function level authorization pertains to the improper authorization of specific functions
+
+36
+00:03:01,000 --> 00:03:08,000
+within an API broken Object level authorization generally deals with the access control of individual
+
+37
+00:03:08,000 --> 00:03:10,000
+objects or resources.
+
+38
+00:03:11,000 --> 00:03:17,000
+For instance, broken function level authorization might allow an unauthorized user to invoke an admin
+
+39
+00:03:17,000 --> 00:03:23,000
+level function, while broken object level authorization would typically permit unauthorized access
+
+40
+00:03:23,000 --> 00:03:26,000
+to an object like a user profile.
+
+41
+00:03:27,000 --> 00:03:32,000
+So what are root causes of broken function level authorization?
+
+42
+00:03:32,000 --> 00:03:36,000
+Let's review the key root causes to begin with.
+
+43
+00:03:36,000 --> 00:03:42,000
+Complex access control policies and misconfigured hierarchies are significant contributors to broken
+
+44
+00:03:42,000 --> 00:03:47,000
+function level authorization vulnerabilities in many applications.
+
+45
+00:03:47,000 --> 00:03:53,000
+The access control model can become quite intricate, with different levels of permissions assigned
+
+46
+00:03:53,000 --> 00:03:56,000
+based on user roles or other criteria.
+
+47
+00:03:57,000 --> 00:04:03,000
+When these policies are not meticulously implemented or configured, they can lead to security gaps.
+
+48
+00:04:04,000 --> 00:04:09,000
+For instance, if an access control hierarchy is poorly designed, or if there are inconsistencies in
+
+49
+00:04:09,000 --> 00:04:15,000
+how permissions are applied, it may result in functions being exposed to users who should not have
+
+50
+00:04:15,000 --> 00:04:15,000
+access.
+
+51
+00:04:16,000 --> 00:04:21,000
+Misconfigurations might occur when hierarchical roles are not correctly mapped to the corresponding
+
+52
+00:04:21,000 --> 00:04:26,000
+access controls, thereby creating unintended exposure of sensitive functionalities.
+
+53
+00:04:27,000 --> 00:04:28,000
+Moving on.
+
+54
+00:04:28,000 --> 00:04:34,000
+Overreliance on predictable object identifiers and lack of proper permission checks is another critical
+
+55
+00:04:34,000 --> 00:04:35,000
+factor.
+
+56
+00:04:35,000 --> 00:04:42,000
+Many applications use predictable identifiers, such as numerical IDs or easily guessable strings to
+
+57
+00:04:42,000 --> 00:04:45,000
+refer to resources or functions.
+
+58
+00:04:45,000 --> 00:04:51,000
+When these identifiers are predictable, it becomes relatively easy for an attacker to guess or enumerate
+
+59
+00:04:51,000 --> 00:04:56,000
+them, potentially gaining unauthorized access to restricted functions.
+
+60
+00:04:57,000 --> 00:05:03,000
+Furthermore, if proper permission checks are not enforced for each function, this reliance on predictable
+
+61
+00:05:03,000 --> 00:05:07,000
+identifiers can significantly Increase the risk of unauthorized access.
+
+62
+00:05:08,000 --> 00:05:16,000
+For example, if a user can access an endpoint by simply altering a URL parameter, it suggests that
+
+63
+00:05:16,000 --> 00:05:20,000
+permission checks are either absent or inadequately implemented.
+
+64
+00:05:21,000 --> 00:05:28,000
+Lastly, common development pitfalls leading to broken function level authorization often stem from
+
+65
+00:05:28,000 --> 00:05:32,000
+routine development practices that overlook security considerations.
+
+66
+00:05:32,000 --> 00:05:39,000
+These pitfalls include insufficient validation of user roles and permissions, hard coding authorization
+
+67
+00:05:39,000 --> 00:05:44,000
+checks within the application, and inadequate testing for different access scenarios.
+
+68
+00:05:45,000 --> 00:05:51,000
+Developers might assume that role based access controls are inherently secure without verifying their
+
+69
+00:05:51,000 --> 00:05:58,000
+proper implementation, or might neglect to perform comprehensive testing to cover all potential access
+
+70
+00:05:58,000 --> 00:05:59,000
+scenarios.
+
+71
+00:05:59,000 --> 00:06:06,000
+Such oversights can lead to gaps in the authorization mechanisms allowing unauthorized access to functions.
+
+72
+00:06:07,000 --> 00:06:12,000
+To get better understanding, let's review different attack scenarios and specific examples.
+
+73
+00:06:13,000 --> 00:06:19,000
+Scenario one unauthorized user sending a legitimate API call to an admin only function.
+
+74
+00:06:20,000 --> 00:06:27,000
+Consider a situation where a web application exposes a range of functions through its API, including
+
+75
+00:06:27,000 --> 00:06:30,000
+both user level and administrative functions.
+
+76
+00:06:31,000 --> 00:06:37,000
+In a typical case, administrative functions should be restricted to users with elevated privileges,
+
+77
+00:06:37,000 --> 00:06:39,000
+such as system administrators.
+
+78
+00:06:39,000 --> 00:06:44,000
+However, an unauthorized user might attempt to exploit a broken function level authorization by crafting
+
+79
+00:06:44,000 --> 00:06:48,000
+a legitimate API request that targets an admin only function.
+
+80
+00:06:49,000 --> 00:06:55,000
+For example, if the application allows a user to query data via an endpoint such as slash API slash
+
+81
+00:06:55,000 --> 00:07:01,000
+data slash view, an attacker might manipulate the request to access admin specific data by using a
+
+82
+00:07:01,000 --> 00:07:04,000
+different endpoint like slash API.
+
+83
+00:07:04,000 --> 00:07:07,000
+Slash admin slash data slash view.
+
+84
+00:07:07,000 --> 00:07:15,000
+If the API lacks proper authorization checks and the function is not securely protected, the unauthorized
+
+85
+00:07:15,000 --> 00:07:22,000
+user may gain access to sensitive information or perform administrative actions they should not be able
+
+86
+00:07:22,000 --> 00:07:23,000
+to execute.
+
+87
+00:07:24,000 --> 00:07:30,000
+Scenario two manipulating HTTP methods to access restricted endpoints.
+
+88
+00:07:30,000 --> 00:07:36,000
+In another scenario, an attacker might leverage HTTP methods to bypass authorization mechanisms.
+
+89
+00:07:37,000 --> 00:07:45,000
+Many APIs use different HTTP methods such as get, post, put, and delete to interact with resources.
+
+90
+00:07:46,000 --> 00:07:53,000
+If an API endpoint is designed to be accessible via a certain HTTP methods for authorized users, an
+
+91
+00:07:53,000 --> 00:07:59,000
+attacker might attempt to exploit this by changing the HTTP method to access restricted endpoints.
+
+92
+00:07:59,000 --> 00:08:07,000
+For example, if an endpoint slash API slash resource is intended to be accessed with a Post request
+
+93
+00:08:07,000 --> 00:08:11,000
+for creating resources but does not properly validate permissions.
+
+94
+00:08:11,000 --> 00:08:18,000
+An attacker might use a get or delete request on the same endpoint to manipulate or retrieve data.
+
+95
+00:08:18,000 --> 00:08:20,000
+They are not authorized to access.
+
+96
+00:08:21,000 --> 00:08:28,000
+This manipulation exploits weaknesses in how the API enforces authorization across different HTTP methods.
+
+97
+00:08:29,000 --> 00:08:36,000
+Scenario three example from New Relic synthetics privilege escalation through API manipulation.
+
+98
+00:08:37,000 --> 00:08:44,000
+In 2018, a notable case of broken function level authorization was reported involving New Relic synthetics.
+
+99
+00:08:45,000 --> 00:08:52,000
+In this incident, the application suffered from privilege escalation due to flaws in its API design.
+
+100
+00:08:53,000 --> 00:09:00,000
+Specifically, attackers were able to manipulate API calls to elevate their privileges from standard
+
+101
+00:09:00,000 --> 00:09:01,000
+users to administrative roles.
+
+102
+00:09:02,000 --> 00:09:08,000
+This was possible because the API did not properly validate user permissions before allowing access
+
+103
+00:09:08,000 --> 00:09:14,000
+to certain administrative functions by crafting specific API requests and exploiting the lack of adequate
+
+104
+00:09:14,000 --> 00:09:15,000
+permission checks.
+
+105
+00:09:15,000 --> 00:09:22,000
+Attackers could gain unauthorized access to sensitive functionalities, such as altering application
+
+106
+00:09:22,000 --> 00:09:26,000
+configurations or accessing detailed metrics and logs.
+
+107
+00:09:27,000 --> 00:09:34,000
+This example underscores how inadequate authorization checks can lead to significant security vulnerabilities,
+
+108
+00:09:34,000 --> 00:09:40,000
+allowing attackers to escalate their privileges and compromise the integrity of the application.
+
+109
+00:09:41,000 --> 00:09:48,000
+So these examples that we reviewed demonstrate various ways in which broken function level authorization
+
+110
+00:09:48,000 --> 00:09:50,000
+can be exploited.
+
+111
+00:09:50,000 --> 00:09:58,000
+Unauthorized users might access admin functions through legitimate API calls, manipulate HTTP methods
+
+112
+00:09:58,000 --> 00:10:05,000
+to gain access to restricted endpoints, or exploit API design flaws to escalate their privileges.
+
+113
+00:10:05,000 --> 00:10:11,000
+Understanding these scenarios helps highlight the importance of robust authorisation mechanisms and
+
+114
+00:10:11,000 --> 00:10:16,000
+comprehensive security practices to protect applications from such vulnerabilities.
+
+115
+00:10:18,000 --> 00:10:22,000
+What are the potential consequences of broken function level authorization?
+
+116
+00:10:23,000 --> 00:10:29,000
+Understanding of negative consequences will help you to understand the importance of its prevention.
+
+117
+00:10:30,000 --> 00:10:37,000
+One of the most significant risks associated with broken function level authorization is the potential
+
+118
+00:10:37,000 --> 00:10:38,000
+for data breaches.
+
+119
+00:10:39,000 --> 00:10:45,000
+When an attacker exploits authorization flaws to access functions or data that are not supposed to.
+
+120
+00:10:45,000 --> 00:10:48,000
+Sensitive information can be exposed.
+
+121
+00:10:48,000 --> 00:10:54,000
+For instance, if an unauthorized user gains access to an endpoint that retrieves confidential user
+
+122
+00:10:54,000 --> 00:11:00,000
+data or proprietary business information, this can lead to unauthorized disclosure of sensitive data
+
+123
+00:11:01,000 --> 00:11:04,000
+as a breach of personal identifiable information.
+
+124
+00:11:04,000 --> 00:11:11,000
+Financial records or intellectual property can have severe repercussions for both individuals and organizations,
+
+125
+00:11:11,000 --> 00:11:16,000
+including legal consequences, financial losses, and damage to reputation.
+
+126
+00:11:17,000 --> 00:11:23,000
+Privilege escalation is another critical consequence of broken function level authorization.
+
+127
+00:11:23,000 --> 00:11:31,000
+This occurs when a user initially granted minimal access rights, is able to exploit flaws in the system
+
+128
+00:11:31,000 --> 00:11:36,000
+to elevate their privileges to those of an administrator or another privileged role.
+
+129
+00:11:36,000 --> 00:11:43,000
+For example, an attacker might exploit broken function level authorization to gain access to administrative
+
+130
+00:11:43,000 --> 00:11:48,000
+functions that should be restricted to system administrators only.
+
+131
+00:11:49,000 --> 00:11:55,000
+Such unauthorized access can allow them to modify configurations, access or manipulate sensitive data,
+
+132
+00:11:55,000 --> 00:11:59,000
+or even controls the application's entire system.
+
+133
+00:12:00,000 --> 00:12:07,000
+Privilege escalation not only increases the risk of further unauthorized actions, but also can compromise
+
+134
+00:12:07,000 --> 00:12:10,000
+the integrity and security of the application as a whole.
+
+135
+00:12:12,000 --> 00:12:18,000
+Broken function level authorization can also lead to service disruption, which affects the availability
+
+136
+00:12:18,000 --> 00:12:21,000
+and functionality of the application.
+
+137
+00:12:21,000 --> 00:12:28,000
+When unauthorized users gain access to administrative functions or critical endpoints, they might perform
+
+138
+00:12:28,000 --> 00:12:31,000
+actions that disrupt normal operations.
+
+139
+00:12:31,000 --> 00:12:38,000
+This could include deleting essential data, modifying system settings, or causing conflicts within
+
+140
+00:12:38,000 --> 00:12:40,000
+the application's workflow.
+
+141
+00:12:40,000 --> 00:12:48,000
+Such disruptions can lead to downtime, degraded service quality, or even complete system outages.
+
+142
+00:12:49,000 --> 00:12:55,000
+For businesses, this translates into operational interruptions, loss of customer trust, and potentially
+
+143
+00:12:55,000 --> 00:13:00,000
+significant financial impacts due to service unavailability.
+
+144
+00:13:01,000 --> 00:13:08,000
+So let me give you some hints about how you can detect broken function level authorization to effectively
+
+145
+00:13:08,000 --> 00:13:15,000
+detect broken function level authorization, we must first engage in a deep analysis of authorization
+
+146
+00:13:15,000 --> 00:13:16,000
+mechanisms.
+
+147
+00:13:17,000 --> 00:13:23,000
+This process involves a thorough examination of how authorization is handled within the application.
+
+148
+00:13:23,000 --> 00:13:29,000
+Begin by reviewing the application's architecture and identifying where and how access controls are
+
+149
+00:13:29,000 --> 00:13:30,000
+implemented.
+
+150
+00:13:31,000 --> 00:13:37,000
+Specifically, assess the function level authorization policies to ensure that they are correctly applied
+
+151
+00:13:37,000 --> 00:13:38,000
+and enforced.
+
+152
+00:13:39,000 --> 00:13:44,000
+Start by analyzing the authorization logic for each function or endpoint.
+
+153
+00:13:44,000 --> 00:13:50,000
+This entails verifying that each function has proper access controls in place, and that these controls
+
+154
+00:13:50,000 --> 00:13:51,000
+are strictly enforced.
+
+155
+00:13:52,000 --> 00:13:57,000
+For instance, you should check that administrative functions are only accessible to users with appropriate
+
+156
+00:13:57,000 --> 00:14:04,000
+roles or permissions, and that there are no loopholes that might allow unauthorized users to bypass
+
+157
+00:14:04,000 --> 00:14:05,000
+these controls.
+
+158
+00:14:06,000 --> 00:14:12,000
+Pay particular attention to scenarios where access controls might be inconsistently applied, or where
+
+159
+00:14:12,000 --> 00:14:18,000
+functions might be inadvertently exposed due to misconfigurations or oversights.
+
+160
+00:14:18,000 --> 00:14:25,000
+In addition to manual analysis, use of tools for API mapping and vulnerability scanning plays a critical
+
+161
+00:14:25,000 --> 00:14:31,000
+role in identifying broken function level authorization vulnerabilities.
+
+162
+00:14:32,000 --> 00:14:39,000
+API mapping tools can help you systematically discover and document all API endpoints and their associated
+
+163
+00:14:39,000 --> 00:14:40,000
+functions.
+
+164
+00:14:41,000 --> 00:14:48,000
+These tools can provide a comprehensive view of the API surface, helping to identify endpoints that
+
+165
+00:14:48,000 --> 00:14:51,000
+may require closer scrutiny for authorization issues.
+
+166
+00:14:52,000 --> 00:14:58,000
+Next, employee vulnerability scanning tools designed specifically for APIs.
+
+167
+00:14:58,000 --> 00:15:04,000
+These tools can automate the process of testing API endpoints for common vulnerabilities, including
+
+168
+00:15:04,000 --> 00:15:10,000
+broken function level authorization by simulating various attack vectors.
+
+169
+00:15:10,000 --> 00:15:16,000
+These tools can help uncover authorization weaknesses that might not be immediately apparent through
+
+170
+00:15:16,000 --> 00:15:17,000
+manual testing.
+
+171
+00:15:18,000 --> 00:15:25,000
+They can also check for improper access controls and highlight areas where authorization mechanisms
+
+172
+00:15:25,000 --> 00:15:26,000
+may be insufficient.
+
+173
+00:15:27,000 --> 00:15:33,000
+By combining deep manual analysis with automated tools, you can achieve a more comprehensive detection
+
+174
+00:15:33,000 --> 00:15:37,000
+of broken function level authorization vulnerabilities.
+
+175
+00:15:37,000 --> 00:15:44,000
+This dual approach allows you to ensure that authorization mechanisms are robust and that potential
+
+176
+00:15:44,000 --> 00:15:48,000
+security gaps are identified and addressed effectively.
+
+177
+00:15:49,000 --> 00:15:55,000
+And finally, it is time to learn how you can prevent broken function level authorization.
+
+178
+00:15:55,000 --> 00:15:58,000
+Let's learn some techniques that will help you.
+
+179
+00:15:59,000 --> 00:16:06,000
+One of the fundamental steps in preventing broken function level authorization is to ensure that authorization
+
+180
+00:16:06,000 --> 00:16:12,000
+modules are consistently applied across all business functions within your application.
+
+181
+00:16:12,000 --> 00:16:18,000
+This means integrating robust authorization checks into every function or endpoint where access control
+
+182
+00:16:18,000 --> 00:16:19,000
+is required.
+
+183
+00:16:19,000 --> 00:16:25,000
+By doing so, you maintain uniformity in access control policies, reducing the likelihood of overlooked
+
+184
+00:16:25,000 --> 00:16:27,000
+or inconsistent authorization checks.
+
+185
+00:16:28,000 --> 00:16:34,000
+This consistency ensures that each function adheres to the same security standards, thus mitigating
+
+186
+00:16:34,000 --> 00:16:39,000
+the risk of unauthorized access due to gaps or variations in implementation.
+
+187
+00:16:40,000 --> 00:16:46,000
+The principle of least privilege and role based access control are essential concepts in preventing
+
+188
+00:16:46,000 --> 00:16:49,000
+broken function level authorization.
+
+189
+00:16:50,000 --> 00:16:56,000
+The principle of least privilege dictates that users should be granted the minimum level of access necessary
+
+190
+00:16:56,000 --> 00:16:58,000
+to perform their job functions.
+
+191
+00:16:59,000 --> 00:17:05,000
+This minimizes the risk of unauthorized actions by limiting the scope of what users can do.
+
+192
+00:17:06,000 --> 00:17:13,000
+Role based access control complements this by assigning permissions based on user roles rather than
+
+193
+00:17:13,000 --> 00:17:20,000
+individual users by defining roles with specific access rights and ensuring that users are only assigned
+
+194
+00:17:20,000 --> 00:17:27,000
+to roles appropriate to their responsibilities, you can effectively manage and restrict access, reducing
+
+195
+00:17:27,000 --> 00:17:31,000
+the risk of privilege escalation and unauthorized function access.
+
+196
+00:17:33,000 --> 00:17:39,000
+Effective session management and input validation are critical in preventing broken function level authorization.
+
+197
+00:17:40,000 --> 00:17:46,000
+Proper session management ensures that user sessions are securely maintained, and that session tokens
+
+198
+00:17:46,000 --> 00:17:49,000
+or credentials are not exposed or misused.
+
+199
+00:17:50,000 --> 00:17:56,000
+This includes practices such as session expiration, secure token handling, and invalidation of sessions
+
+200
+00:17:56,000 --> 00:17:58,000
+upon logout or inactivity.
+
+201
+00:17:59,000 --> 00:18:04,000
+Input validation, on the other hand, involves scrutinizing and sanitizing user inputs to prevent malicious
+
+202
+00:18:04,000 --> 00:18:06,000
+data from being processed.
+
+203
+00:18:06,000 --> 00:18:11,000
+By validating and sanitizing inputs, you can mitigate the risk of attackers exploiting authorization
+
+204
+00:18:11,000 --> 00:18:14,000
+flaws through crafted requests or payloads.
+
+205
+00:18:14,000 --> 00:18:18,000
+Thus securing your endpoints from unauthorized access.
+
+206
+00:18:19,000 --> 00:18:27,000
+Lastly, regular API security testing, both automated and manual, is crucial for identifying and addressing
+
+207
+00:18:27,000 --> 00:18:30,000
+broken function level authorization vulnerabilities.
+
+208
+00:18:31,000 --> 00:18:37,000
+Automated tools can quickly scan APIs for common security issues and vulnerabilities, providing a broad
+
+209
+00:18:37,000 --> 00:18:39,000
+coverage of potential weaknesses.
+
+210
+00:18:40,000 --> 00:18:47,000
+However, automated tools may not catch all nuances of broken function level authorization, so complementing
+
+211
+00:18:47,000 --> 00:18:50,000
+them with manual testing is important.
+
+212
+00:18:51,000 --> 00:18:58,000
+Manual testing involves experienced security professionals manually assessing APIs and business logic
+
+213
+00:18:58,000 --> 00:19:03,000
+for complex authorization issues that automated tools might miss.
+
+214
+00:19:04,000 --> 00:19:09,000
+By conducting these regular security assessments, you can proactively discover and remediate broken
+
+215
+00:19:09,000 --> 00:19:14,000
+function level authorization vulnerabilities before they are exploited
+
diff --git a/74 - OWASP API Security Top 10 2023/013 API52023 Broken Function Level Authorization - Part 2 (Practice)_en.srt b/74 - OWASP API Security Top 10 2023/013 API52023 Broken Function Level Authorization - Part 2 (Practice)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..5ece303d65bd330808bfd9c1cd20b1bfb228be11
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/013 API52023 Broken Function Level Authorization - Part 2 (Practice)_en.srt
@@ -0,0 +1,404 @@
+1
+00:00:03,000 --> 00:00:05,000
+Let's review source code examples.
+
+2
+00:00:05,000 --> 00:00:11,000
+Now we'll review source code of the problem and then we will review solution.
+
+3
+00:00:11,000 --> 00:00:16,000
+As always you can find all source code examples in attachments to the lesson.
+
+4
+00:00:16,000 --> 00:00:20,000
+In case during the explanation something will be not clear for you.
+
+5
+00:00:20,000 --> 00:00:26,000
+Or in case you have any questions regarding the example, please don't wait till the end of the lesson.
+
+6
+00:00:26,000 --> 00:00:31,000
+Just post your question below the video and I will be happy to answer.
+
+7
+00:00:32,000 --> 00:00:35,000
+So let's start review the code from the problem statement.
+
+8
+00:00:35,000 --> 00:00:40,000
+And at first let me give you some context about the example and what this class is supposed to do.
+
+9
+00:00:41,000 --> 00:00:48,000
+In this example, we have a servlet that handles HTTP post requests to update user profiles.
+
+10
+00:00:48,000 --> 00:00:55,000
+The class is intended to facilitate users making changes to their own profiles via an HTML form.
+
+11
+00:00:55,000 --> 00:00:59,000
+However, this code has a critical security issue.
+
+12
+00:00:59,000 --> 00:01:02,000
+Related to broken function level authorization.
+
+13
+00:01:03,000 --> 00:01:09,000
+An instance of user facade is created, which will be used to interact with the user data.
+
+14
+00:01:09,000 --> 00:01:13,000
+This class provides methods to retrieve and update user information.
+
+15
+00:01:14,000 --> 00:01:16,000
+The Dopost method handles Post requests.
+
+16
+00:01:17,000 --> 00:01:20,000
+It is invoked when the form submits data to the servlet.
+
+17
+00:01:21,000 --> 00:01:25,000
+The method retrieves the action type and user ID from the request parameters.
+
+18
+00:01:26,000 --> 00:01:29,000
+The user ID is taken from the form input and converted to an integer.
+
+19
+00:01:30,000 --> 00:01:35,000
+The user facade is used to fetch the user object from the database, based on the user ID provided in
+
+20
+00:01:35,000 --> 00:01:36,000
+the request.
+
+21
+00:01:37,000 --> 00:01:45,000
+If the action specified is update profile, the servlet updates the user object with new credit card
+
+22
+00:01:45,000 --> 00:01:48,000
+and email information obtained from the request parameters.
+
+23
+00:01:48,000 --> 00:01:55,000
+The updated user object is saved back to the database and the client is redirected to their profile
+
+24
+00:01:55,000 --> 00:01:55,000
+page.
+
+25
+00:01:56,000 --> 00:02:04,000
+If the action is not update profile, an error message is written to the response So do you see here
+
+26
+00:02:04,000 --> 00:02:07,000
+broken function level authorization or not yet?
+
+27
+00:02:08,000 --> 00:02:11,000
+Let me elaborate on the problems of this code.
+
+28
+00:02:12,000 --> 00:02:18,000
+This code does not perform any checks to ensure that the user ID provided in the request matches the
+
+29
+00:02:18,000 --> 00:02:21,000
+ID of the currently logged in user.
+
+30
+00:02:22,000 --> 00:02:29,000
+This omission means that any user could potentially submit a Post request with another user's ID and
+
+31
+00:02:29,000 --> 00:02:32,000
+modify someone else's profile.
+
+32
+00:02:32,000 --> 00:02:39,000
+You shouldn't forget that your code will not work only with the HTML forms that you developed and where
+
+33
+00:02:39,000 --> 00:02:41,000
+you control which ID you pass.
+
+34
+00:02:41,000 --> 00:02:43,000
+Never forget about this.
+
+35
+00:02:44,000 --> 00:02:50,000
+In a real world scenario, if an attacker uses a tool like postman or manipulates HTTP requests, they
+
+36
+00:02:50,000 --> 00:02:53,000
+can exploit this vulnerability.
+
+37
+00:02:53,000 --> 00:03:01,000
+They could craft a request to update another user's profile information, leading to unauthorized changes.
+
+38
+00:03:01,000 --> 00:03:05,000
+Imagine a malicious user knows another user's ID.
+
+39
+00:03:05,000 --> 00:03:12,000
+They can craft a request to update the credit card and email address of that user, affecting the integrity
+
+40
+00:03:12,000 --> 00:03:18,000
+of the user data and potentially leading to further security issues such as fraud or identity theft.
+
+41
+00:03:19,000 --> 00:03:24,000
+And after updating emails, they can reset password and perform other actions.
+
+42
+00:03:24,000 --> 00:03:30,000
+So you can see a classic example of broken function level authorization by failing to validate that
+
+43
+00:03:30,000 --> 00:03:33,000
+the user performing the action is authorized to do so.
+
+44
+00:03:33,000 --> 00:03:36,000
+The survey opens the door to potential misuse.
+
+45
+00:03:36,000 --> 00:03:43,000
+Addressing this issue involves implementing proper authorization checks to ensure that users can only
+
+46
+00:03:43,000 --> 00:03:51,000
+modify their own profiles, or, in specific cases, only perform actions they are permitted to perform.
+
+47
+00:03:52,000 --> 00:03:59,000
+Let's review a solution now, and let's learn how to avoid broken function level authorization.
+
+48
+00:04:00,000 --> 00:04:06,000
+In this revised survey, we have made significant improvements to address the broken function level
+
+49
+00:04:06,000 --> 00:04:10,000
+authorization issues seen in the previous example.
+
+50
+00:04:10,000 --> 00:04:17,000
+Let's walk through this code line by line, highlighting the changes and explaining how they address
+
+51
+00:04:17,000 --> 00:04:21,000
+the broken function level authorization vulnerability.
+
+52
+00:04:22,000 --> 00:04:26,000
+We retain the use of user facade to interact with user data.
+
+53
+00:04:26,000 --> 00:04:30,000
+This line remains unchanged from the previous example.
+
+54
+00:04:30,000 --> 00:04:35,000
+The method signature remains the same handling Post requests from the client.
+
+55
+00:04:36,000 --> 00:04:41,000
+We still extract the action parameter from the request to determine what operation to perform.
+
+56
+00:04:42,000 --> 00:04:48,000
+Here, we ensure that the user is logged in by retrieving the user object from the HTTP session.
+
+57
+00:04:49,000 --> 00:04:55,000
+If the user is not logged in, we send an HTTP 403 forbidden response.
+
+58
+00:04:55,000 --> 00:05:02,000
+This change addresses a significant security concern by confirming that only authenticated users can
+
+59
+00:05:02,000 --> 00:05:03,000
+perform actions.
+
+60
+00:05:04,000 --> 00:05:11,000
+The user ID parameter is still extracted from the request, but now it will be subject to further authorization
+
+61
+00:05:11,000 --> 00:05:12,000
+checks.
+
+62
+00:05:12,000 --> 00:05:14,000
+Then goes a crucial addition.
+
+63
+00:05:14,000 --> 00:05:21,000
+We now verify that the logged in user is either trying to update their own profile or is an admin.
+
+64
+00:05:22,000 --> 00:05:29,000
+This ensures that users cannot modify other users profiles, fixing the issue of unauthorized access.
+
+65
+00:05:30,000 --> 00:05:35,000
+If the action is to update the profile, we retrieve the user by user ID.
+
+66
+00:05:36,000 --> 00:05:39,000
+We also check if the user exists before proceeding.
+
+67
+00:05:40,000 --> 00:05:44,000
+This addition prevents errors that might occur if a non-existent user ID is provided.
+
+68
+00:05:45,000 --> 00:05:47,000
+The profile is updated with new information.
+
+69
+00:05:47,000 --> 00:05:52,000
+If the action is valid and the user is redirected to their profile page.
+
+70
+00:05:52,000 --> 00:05:55,000
+Invalid actions are handled by providing an error message.
+
+71
+00:05:55,000 --> 00:06:01,000
+This solution helps us to prevent broken function level authorization by retrieving the user from the
+
+72
+00:06:01,000 --> 00:06:08,000
+session and ensuring they are logged in, we prevent unauthorized users from accessing the servlet.
+
+73
+00:06:09,000 --> 00:06:15,000
+We added logic to ensure that users can only update their own profiles or perform administrative actions,
+
+74
+00:06:15,000 --> 00:06:21,000
+thereby fixing the core broken function level authorization issue from the previous code.
+
+75
+00:06:22,000 --> 00:06:30,000
+The code now properly handles scenarios where a user is not logged in or a user ID does not exist,
+
+76
+00:06:30,000 --> 00:06:34,000
+making the servlet more robust and secure.
+
+77
+00:06:34,000 --> 00:06:42,000
+So this revised code addresses the broken function level authorization issue by implementing proper
+
+78
+00:06:42,000 --> 00:06:48,000
+authentication and authorization checks, ensuring that users can only perform actions they are permitted
+
+79
+00:06:48,000 --> 00:06:49,000
+to.
+
+80
+00:06:50,000 --> 00:06:55,000
+This helps to secure the application from unauthorized modifications and potential exploits.
+
+81
+00:06:56,000 --> 00:06:59,000
+That's all what I wanted to share with you in this lesson.
+
+82
+00:06:59,000 --> 00:07:02,000
+Let's recap what we've learned.
+
+83
+00:07:02,000 --> 00:07:08,000
+We covered the definition and explanation of broken function level authorization, understanding its
+
+84
+00:07:08,000 --> 00:07:10,000
+core concepts and implications.
+
+85
+00:07:11,000 --> 00:07:17,000
+We distinguished between broken function level authorization and broken object level authorization,
+
+86
+00:07:17,000 --> 00:07:21,000
+clarifying the differences and specific vulnerabilities.
+
+87
+00:07:21,000 --> 00:07:28,000
+We explored the root causes of broken function level authorization, including complex access control
+
+88
+00:07:28,000 --> 00:07:30,000
+policies and common development pitfalls.
+
+89
+00:07:31,000 --> 00:07:37,000
+We examined various attack scenarios and examples to see how broken function level authorization can
+
+90
+00:07:37,000 --> 00:07:39,000
+be exploited in real world situations.
+
+91
+00:07:40,000 --> 00:07:46,000
+We discussed the potential consequences of broken function level authorization, including data breaches,
+
+92
+00:07:46,000 --> 00:07:49,000
+privilege escalation, and service disruptions.
+
+93
+00:07:50,000 --> 00:07:55,000
+We learned how to detect broken function level authorizations through deep analysis of authorization
+
+94
+00:07:55,000 --> 00:07:59,000
+mechanisms and the use of vulnerability scanning tools.
+
+95
+00:08:00,000 --> 00:08:06,000
+We reviewed effective prevention techniques for broken function level authorization, including implementing
+
+96
+00:08:06,000 --> 00:08:11,000
+proper authorization checks and applying the principle of least privilege.
+
+97
+00:08:12,000 --> 00:08:18,000
+And at the end of the lesson, we analyzed the practical examples through source code review, identifying
+
+98
+00:08:18,000 --> 00:08:23,000
+an address in a broken function level authorization vulnerability.
+
+99
+00:08:24,000 --> 00:08:25,000
+That's all for this lesson.
+
+100
+00:08:26,000 --> 00:08:28,000
+Thanks a lot for your attention.
+
+101
+00:08:28,000 --> 00:08:31,000
+Have a great day and see you in the next lesson.
+
diff --git a/74 - OWASP API Security Top 10 2023/013 Source-code-examples-from-the-lesson.url b/74 - OWASP API Security Top 10 2023/013 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..c26286cfb794ea9e113740d8e2e364195f230949
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/013 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/bfla
\ No newline at end of file
diff --git a/74 - OWASP API Security Top 10 2023/014 API62023 Unrestricted Access to Sensitive Business Flows - Part 1_en.srt b/74 - OWASP API Security Top 10 2023/014 API62023 Unrestricted Access to Sensitive Business Flows - Part 1_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..f427feedb75c972348d4988eccb071c28b523757
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/014 API62023 Unrestricted Access to Sensitive Business Flows - Part 1_en.srt
@@ -0,0 +1,952 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello.
+
+2
+00:00:07,000 --> 00:00:12,000
+In this lesson, we are going to learn more about unrestricted access to sensitive business flows.
+
+3
+00:00:12,000 --> 00:00:15,000
+So here's what we will be diving into today.
+
+4
+00:00:15,000 --> 00:00:21,000
+We'll start by defining what unrestricted access to sensitive business flows is, and why it's crucial
+
+5
+00:00:21,000 --> 00:00:24,000
+to understand this vulnerability.
+
+6
+00:00:24,000 --> 00:00:31,000
+Next, we'll differentiate unrestricted access to sensitive business flows from other API vulnerabilities,
+
+7
+00:00:31,000 --> 00:00:35,000
+giving you a clear picture of its unique characteristics.
+
+8
+00:00:36,000 --> 00:00:42,000
+Then we'll explore how attackers exploit unrestricted access to sensitive business flows to their advantage.
+
+9
+00:00:42,000 --> 00:00:48,000
+We'll review common scenarios and examples where this vulnerability is present, including some illustrative
+
+10
+00:00:48,000 --> 00:00:50,000
+cases of business logic abuse.
+
+11
+00:00:51,000 --> 00:00:56,000
+After understanding how unrestricted access to sensitive business flows is exploited, we'll tackle
+
+12
+00:00:56,000 --> 00:01:00,000
+the challenges involved in detecting and protecting against it.
+
+13
+00:01:00,000 --> 00:01:06,000
+We'll discuss effective ways to address these challenges, providing practical insights for mitigating
+
+14
+00:01:06,000 --> 00:01:07,000
+risks.
+
+15
+00:01:08,000 --> 00:01:14,000
+We'll also examine the potential impacts on businesses such as service disruption, resource exhaustion,
+
+16
+00:01:14,000 --> 00:01:18,000
+and unauthorized access or data breaches.
+
+17
+00:01:18,000 --> 00:01:25,000
+To make things concrete, we'll analyze a real life case study focusing on airline ticketing abuse,
+
+18
+00:01:25,000 --> 00:01:28,000
+highlighting the consequences of such attacks.
+
+19
+00:01:29,000 --> 00:01:35,000
+Moving forward, we'll cover prevention and mitigation strategies at both the business and engineering
+
+20
+00:01:35,000 --> 00:01:41,000
+layers, ensuring you know how to safeguard against these vulnerabilities effectively.
+
+21
+00:01:41,000 --> 00:01:48,000
+We'll then touch on testing methods for unrestricted access to sensitive business flows, followed by
+
+22
+00:01:48,000 --> 00:01:51,000
+best practices to ensure your API remains secure.
+
+23
+00:01:52,000 --> 00:01:58,000
+Finally, we will review a practical example by examining source code to identify a problem and discuss
+
+24
+00:01:58,000 --> 00:02:00,000
+the corresponding solution.
+
+25
+00:02:00,000 --> 00:02:07,000
+Let's dive into these topics and enhance our understanding of securing APIs against unrestricted access
+
+26
+00:02:07,000 --> 00:02:08,000
+to sensitive business flows.
+
+27
+00:02:10,000 --> 00:02:15,000
+Let's start from learning the definition of unrestricted access to sensitive business flows.
+
+28
+00:02:16,000 --> 00:02:23,000
+Unrestricted access to sensitive business flows refers to a type of vulnerability within APIs, where
+
+29
+00:02:23,000 --> 00:02:28,000
+sensitive business processes are exposed without sufficient access controls.
+
+30
+00:02:29,000 --> 00:02:35,000
+This vulnerability arises when an API endpoint provides access to critical business functions such as
+
+31
+00:02:35,000 --> 00:02:42,000
+purchasing high demand items, making reservations, or creating user generated content without properly
+
+32
+00:02:42,000 --> 00:02:45,000
+restricting how and by whom these functions can be used.
+
+33
+00:02:46,000 --> 00:02:51,000
+Essentially, it's when an API allows for excessive or unauthorized interaction with business critical
+
+34
+00:02:51,000 --> 00:02:57,000
+operations, often resulting in exploitation through automation or malicious intent.
+
+35
+00:02:57,000 --> 00:03:04,000
+For example, if an API allows users to buy unlimited quantities of a limited edition product without
+
+36
+00:03:04,000 --> 00:03:05,000
+checks or limits.
+
+37
+00:03:05,000 --> 00:03:13,000
+An attacker could exploit this by purchasing all available stock and reselling it at a higher price.
+
+38
+00:03:13,000 --> 00:03:20,000
+Similarly, if an API endpoint for reservations has no restrictions, a malicious actor could book all
+
+39
+00:03:20,000 --> 00:03:25,000
+available slots and prevent legitimate users from accessing the service.
+
+40
+00:03:25,000 --> 00:03:32,000
+This type of vulnerability highlights a lack of control over the business logic that the API is supposed
+
+41
+00:03:32,000 --> 00:03:33,000
+to manage.
+
+42
+00:03:34,000 --> 00:03:40,000
+Understanding unrestricted access to sensitive business flows is crucial for several reasons.
+
+43
+00:03:40,000 --> 00:03:47,000
+First and foremost, this vulnerability can lead to significant financial loss and operational disruption
+
+44
+00:03:48,000 --> 00:03:52,000
+when sensitive business processes are exposed without adequate restrictions.
+
+45
+00:03:52,000 --> 00:03:58,000
+It opens the door for attackers to manipulate or abuse these processes to their advantage.
+
+46
+00:03:59,000 --> 00:04:05,000
+This could mean lost revenue from scalping decreased user satisfaction due to service unavailability,
+
+47
+00:04:05,000 --> 00:04:10,000
+or even reputational damage from perceived unfair practices.
+
+48
+00:04:11,000 --> 00:04:17,000
+Furthermore, the impact of unrestricted access to sensitive business flows is not always immediately
+
+49
+00:04:17,000 --> 00:04:24,000
+obvious, as the attacks often involve legitimate looking requests that, when aggregated, result in
+
+50
+00:04:24,000 --> 00:04:26,000
+harmful outcomes.
+
+51
+00:04:27,000 --> 00:04:33,000
+Traditional security measures like web application firewalls or rate limiters, may not be sufficient
+
+52
+00:04:33,000 --> 00:04:39,000
+to detect or prevent these types of attacks, because they often rely on rules or patterns that do not
+
+53
+00:04:39,000 --> 00:04:41,000
+account for complex business logic.
+
+54
+00:04:41,000 --> 00:04:42,000
+Interactions.
+
+55
+00:04:44,000 --> 00:04:50,000
+Unrestricted access to sensitive business flows is distinct from other API vulnerabilities in several
+
+56
+00:04:50,000 --> 00:04:55,000
+key ways, each rooted in the nature of its impact and exploitation mechanisms.
+
+57
+00:04:56,000 --> 00:05:02,000
+Firstly, unlike vulnerabilities such as broken object level authorization or broken authentication,
+
+58
+00:05:02,000 --> 00:05:07,000
+which typically involve unauthorized access to resources or user accounts.
+
+59
+00:05:07,000 --> 00:05:13,000
+Unrestricted access to sensitive business flows focuses on the exploitation of business logic.
+
+60
+00:05:13,000 --> 00:05:19,000
+While broken object level authorization might allow an attacker to access or manipulate data, they
+
+61
+00:05:19,000 --> 00:05:20,000
+should not be able to.
+
+62
+00:05:20,000 --> 00:05:26,000
+Unrestricted access to sensitive business flows targets the functional aspects of the business process
+
+63
+00:05:26,000 --> 00:05:27,000
+itself.
+
+64
+00:05:28,000 --> 00:05:34,000
+This means that an API with unrestricted access to sensitive business flows issues allows an attacker
+
+65
+00:05:34,000 --> 00:05:40,000
+to misuse the business functionality, such as making unlimited reservations or purchasing restricted
+
+66
+00:05:40,000 --> 00:05:44,000
+items, often through automated scripts or bots.
+
+67
+00:05:45,000 --> 00:05:51,000
+Secondly, unrestricted access to sensitive business flows is characterized by its reliance on business
+
+68
+00:05:51,000 --> 00:05:54,000
+logic rather than technical flaws.
+
+69
+00:05:55,000 --> 00:06:03,000
+Vulnerabilities like injection or security misconfiguration often arise from errors in code or configuration
+
+70
+00:06:03,000 --> 00:06:05,000
+that can be detected and corrected through.
+
+71
+00:06:05,000 --> 00:06:07,000
+Traditional security testing methods.
+
+72
+00:06:08,000 --> 00:06:11,000
+In contrast, unrestricted access to sensitive.
+
+73
+00:06:11,000 --> 00:06:17,000
+Business flows stems from a lack of understanding or consideration of how business processes can be
+
+74
+00:06:17,000 --> 00:06:20,000
+abused, if not properly restricted.
+
+75
+00:06:21,000 --> 00:06:23,000
+This makes unrestricted access to sensitive.
+
+76
+00:06:23,000 --> 00:06:28,000
+Business flows and vulnerabilities that is more difficult to detect through conventional means, because
+
+77
+00:06:28,000 --> 00:06:35,000
+it involves analyzing the cumulative impact of API requests within the context of business operations.
+
+78
+00:06:36,000 --> 00:06:42,000
+Additionally, while vulnerabilities such as rate limiting, bypass, or excessive data exposure are
+
+79
+00:06:42,000 --> 00:06:45,000
+about how data or services are accessed.
+
+80
+00:06:45,000 --> 00:06:52,000
+Unrestricted access to sensitive business flows specifically concerns the broader implications of how
+
+81
+00:06:52,000 --> 00:06:56,000
+business critical functions are performed and controlled.
+
+82
+00:06:56,000 --> 00:07:03,000
+It requires a deeper understanding of the specific business logic and workflow behind the API, rather
+
+83
+00:07:03,000 --> 00:07:05,000
+than just examining the data or resource.
+
+84
+00:07:05,000 --> 00:07:06,000
+Access patterns.
+
+85
+00:07:07,000 --> 00:07:10,000
+Finally, unrestricted access to sensitive business flows can lead.
+
+86
+00:07:10,000 --> 00:07:14,000
+To unique types of abuse and financial loss that are not typically associated with.
+
+87
+00:07:14,000 --> 00:07:16,000
+Other vulnerabilities.
+
+88
+00:07:16,000 --> 00:07:19,000
+For instance, while an injection flow might lead to data.
+
+89
+00:07:19,000 --> 00:07:25,000
+Theft or corruption, unrestricted access to sensitive business flows can result in direct financial
+
+90
+00:07:25,000 --> 00:07:31,000
+damage through activities like scalping, high demand products, or flooding a reservation system to
+
+91
+00:07:31,000 --> 00:07:32,000
+drive down prices.
+
+92
+00:07:33,000 --> 00:07:40,000
+This means the consequences of unrestricted access to sensitive business flows are often more closely
+
+93
+00:07:40,000 --> 00:07:43,000
+tied to business operations and revenue impacts.
+
+94
+00:07:44,000 --> 00:07:50,000
+So while other API vulnerabilities focus on unauthorized access or technical flaws.
+
+95
+00:07:50,000 --> 00:07:57,000
+Unrestricted access to sensitive business flows is about how business functions can be exploited when
+
+96
+00:07:57,000 --> 00:08:04,000
+exposed without proper controls It requires a nuanced understanding of both the technical and business
+
+97
+00:08:04,000 --> 00:08:12,000
+aspects of the API to effectively mitigate and manage attackers, exploit unrestricted access to sensitive
+
+98
+00:08:12,000 --> 00:08:19,000
+business flows by leveraging a thorough understanding of the business logic behind an API to manipulate
+
+99
+00:08:19,000 --> 00:08:22,000
+its intended functionality for malicious purposes.
+
+100
+00:08:23,000 --> 00:08:29,000
+This exploitation process involves several steps, each tailored to the specific business flow exposed
+
+101
+00:08:29,000 --> 00:08:31,000
+by the API.
+
+102
+00:08:31,000 --> 00:08:38,000
+First, attackers typically begin by gaining insight into the business processes that the API supports.
+
+103
+00:08:38,000 --> 00:08:43,000
+They analyze how the API endpoints interact with the underlying business logic.
+
+104
+00:08:43,000 --> 00:08:49,000
+For example, if an API endpoint allows users to purchase items, the attacker would study how this
+
+105
+00:08:49,000 --> 00:08:54,000
+process works, including any constraints or limits that are supposed to be in place.
+
+106
+00:08:54,000 --> 00:09:00,000
+Once the attacker has a clear understanding of the business flow, they identify which aspects of this
+
+107
+00:09:00,000 --> 00:09:02,000
+flow are sensitive or valuable.
+
+108
+00:09:03,000 --> 00:09:09,000
+Sensitive business flows could include functions like purchasing high demand items, making reservations,
+
+109
+00:09:09,000 --> 00:09:12,000
+or creating user generated content.
+
+110
+00:09:12,000 --> 00:09:18,000
+The key here is to find business processes where unrestricted access could lead to significant harm
+
+111
+00:09:18,000 --> 00:09:19,000
+or gain.
+
+112
+00:09:19,000 --> 00:09:26,000
+With this knowledge, the attacker then uses automation tools or scripts to interact with the API in
+
+113
+00:09:26,000 --> 00:09:29,000
+ways that were not anticipated by the developers.
+
+114
+00:09:30,000 --> 00:09:37,000
+For instance, if an API allows for the purchase of limited edition items but does not enforce a per
+
+115
+00:09:37,000 --> 00:09:43,000
+customer limit, the attacker could write a script to automatically place numerous orders in rapid succession.
+
+116
+00:09:44,000 --> 00:09:51,000
+This automated approach allows the attacker to exploit the business process at scale, often much faster
+
+117
+00:09:51,000 --> 00:09:52,000
+than a human could.
+
+118
+00:09:52,000 --> 00:09:59,000
+In cases where the API provides functionalities such as making reservations or booking tickets, the
+
+119
+00:09:59,000 --> 00:10:03,000
+attacker might use similar techniques to reserve all available slots or tickets.
+
+120
+00:10:04,000 --> 00:10:10,000
+By doing so, they prevent legitimate users from accessing these resources, which can disrupt services
+
+121
+00:10:10,000 --> 00:10:16,000
+and force the business to deal with negative consequences, such as having to discount prices or deal
+
+122
+00:10:16,000 --> 00:10:18,000
+with customer complaints.
+
+123
+00:10:19,000 --> 00:10:25,000
+Moreover, attackers may employ sophisticated evasion techniques to mimic legitimate user behavior,
+
+124
+00:10:25,000 --> 00:10:28,000
+making it challenging to detect their activities.
+
+125
+00:10:28,000 --> 00:10:36,000
+They might use distributed networks of IP addresses, employ headless browsers that simulate human interactions,
+
+126
+00:10:36,000 --> 00:10:43,000
+or implement Captcha bypass techniques to avoid detection by security mechanisms that are designed to
+
+127
+00:10:43,000 --> 00:10:44,000
+prevent abuse.
+
+128
+00:10:45,000 --> 00:10:52,000
+When examining unrestricted access to sensitive business flows, it is essential to understand how attackers
+
+129
+00:10:52,000 --> 00:10:56,000
+exploit this vulnerability through various common scenarios.
+
+130
+00:10:56,000 --> 00:11:03,000
+These scenarios illustrate how attackers can abuse business processes Exposed via APIs to cause significant
+
+131
+00:11:03,000 --> 00:11:05,000
+disruption or gain.
+
+132
+00:11:06,000 --> 00:11:10,000
+One prevalent example of unrestricted access to sensitive business flows.
+
+133
+00:11:10,000 --> 00:11:12,000
+Exploitation is scalping.
+
+134
+00:11:12,000 --> 00:11:16,000
+In this scenario, attackers exploit APIs that facilitate.
+
+135
+00:11:16,000 --> 00:11:20,000
+The purchasing of high demand, limited availability items such as concert.
+
+136
+00:11:20,000 --> 00:11:22,000
+Tickets or collectible merchandise.
+
+137
+00:11:23,000 --> 00:11:27,000
+Consider a ticketing API that allows users to purchase tickets for a popular event.
+
+138
+00:11:27,000 --> 00:11:32,000
+If the API does not enforce limits on the number of tickets a single user can buy.
+
+139
+00:11:32,000 --> 00:11:36,000
+Attackers can automate requests to buy up large quantities of tickets quickly.
+
+140
+00:11:37,000 --> 00:11:43,000
+The attackers then resell these tickets at a higher price, capitalizing on the high demand.
+
+141
+00:11:43,000 --> 00:11:50,000
+This not only disrupts the availability for genuine customers, but also undermines the fairness of
+
+142
+00:11:50,000 --> 00:11:52,000
+the purchasing process.
+
+143
+00:11:52,000 --> 00:11:55,000
+Another common scenario is spamming.
+
+144
+00:11:55,000 --> 00:12:02,000
+In this case, attackers exploit APIs that allow user generated content such as comments or posts.
+
+145
+00:12:03,000 --> 00:12:09,000
+For example, imagine an API that permits users to submit reviews or comments on a product.
+
+146
+00:12:10,000 --> 00:12:16,000
+If there are no restrictions on the rate or volume of submissions, an attacker could automate the creation
+
+147
+00:12:16,000 --> 00:12:19,000
+of a large number of comments or posts in a short period.
+
+148
+00:12:20,000 --> 00:12:27,000
+This flooding of the system can overwhelm it, degrade performance, and potentially flood users with
+
+149
+00:12:27,000 --> 00:12:33,000
+irrelevant or harmful content, damaging the platform's integrity and user experience.
+
+150
+00:12:34,000 --> 00:12:37,000
+Reservation abuse is yet another significant concern.
+
+151
+00:12:38,000 --> 00:12:45,000
+Suppose an API is used for booking appointments or reserving resources like rental properties or conference
+
+152
+00:12:45,000 --> 00:12:45,000
+rooms.
+
+153
+00:12:46,000 --> 00:12:53,000
+If the API lacks proper controls, an attacker could exploit it to book all available slots or resources,
+
+154
+00:12:53,000 --> 00:13:01,000
+for instance by automatically reserving every available appointment slot in a healthcare system or conference
+
+155
+00:13:01,000 --> 00:13:06,000
+room booking system, an attacker can prevent legitimate users from making reservations.
+
+156
+00:13:07,000 --> 00:13:12,000
+This can lead to operational disruptions, revenue losses, and customer dissatisfaction.
+
+157
+00:13:13,000 --> 00:13:18,000
+A classic example of business logic abuse is manipulating promotional offers.
+
+158
+00:13:19,000 --> 00:13:23,000
+Consider an API that manages discount codes or promotional offers.
+
+159
+00:13:24,000 --> 00:13:31,000
+If there is no restriction on how many times a discount can be used, or if the API does not properly
+
+160
+00:13:31,000 --> 00:13:37,000
+validate the eligibility of users for such offers, an attacker could exploit this by automating the
+
+161
+00:13:37,000 --> 00:13:39,000
+use of discount codes.
+
+162
+00:13:40,000 --> 00:13:45,000
+This could result in significant financial losses for the business, as the attacker accumulates large
+
+163
+00:13:45,000 --> 00:13:48,000
+amounts of discounted products or services.
+
+164
+00:13:48,000 --> 00:13:52,000
+Another example involves exploiting free trial systems.
+
+165
+00:13:52,000 --> 00:13:57,000
+Some services offer free trials with certain limits, like a one month free trial for a subscription
+
+166
+00:13:57,000 --> 00:13:58,000
+service.
+
+167
+00:13:58,000 --> 00:14:04,000
+If the API managing these trials does not enforce proper limits or track trial usage accurately.
+
+168
+00:14:04,000 --> 00:14:11,000
+An attacker could create multiple accounts to continuously receive free trials without ever paying for
+
+169
+00:14:11,000 --> 00:14:11,000
+the service.
+
+170
+00:14:12,000 --> 00:14:18,000
+This can lead to financial losses and increased operational costs for managing numerous fraudulent accounts.
+
+171
+00:14:19,000 --> 00:14:27,000
+In each of these examples, the core issue is that the API does not adequately restrict or control how
+
+172
+00:14:27,000 --> 00:14:30,000
+its functionalities are accessed and used.
+
+173
+00:14:30,000 --> 00:14:37,000
+By failing to enforce appropriate business logic constraints, organizations expose themselves to a
+
+174
+00:14:37,000 --> 00:14:42,000
+range of abuses that can have serious financial and operational consequences.
+
+175
+00:14:43,000 --> 00:14:50,000
+To mitigate these risks, it is crucial to implement rigorous controls and continuously monitor API
+
+176
+00:14:50,000 --> 00:14:54,000
+usage patterns to detect and prevent potential abuse.
+
+177
+00:14:55,000 --> 00:15:01,000
+Detecting and protecting against unrestricted access to sensitive business flows presents a range of
+
+178
+00:15:01,000 --> 00:15:02,000
+complex challenges.
+
+179
+00:15:02,000 --> 00:15:08,000
+Due to the nature of the vulnerabilities and the sophisticated methods attackers employ.
+
+180
+00:15:09,000 --> 00:15:15,000
+Addressing these challenges requires a nuanced understanding of both the technical aspects of APIs and
+
+181
+00:15:15,000 --> 00:15:18,000
+the broader business context in which they operate.
+
+182
+00:15:20,000 --> 00:15:22,000
+Is it easy to detect this vulnerability?
+
+183
+00:15:22,000 --> 00:15:24,000
+There are some challenges.
+
+184
+00:15:24,000 --> 00:15:25,000
+Let's review them.
+
+185
+00:15:26,000 --> 00:15:32,000
+The primary challenge in detecting unrestricted access to sensitive business flows is the subtlety of
+
+186
+00:15:32,000 --> 00:15:34,000
+the attack patterns.
+
+187
+00:15:34,000 --> 00:15:41,000
+Unlike more straightforward vulnerabilities that might involve anomalous or unauthorized access attempts
+
+188
+00:15:41,000 --> 00:15:44,000
+unrestricted access to sensitive business flows.
+
+189
+00:15:44,000 --> 00:15:50,000
+Attacks often manifest through legitimate looking requests that, when aggregated, lead to malicious
+
+190
+00:15:50,000 --> 00:15:51,000
+outcomes.
+
+191
+00:15:51,000 --> 00:15:57,000
+Attackers exploit the business logic of an API, and each individual request might appear normal in
+
+192
+00:15:57,000 --> 00:15:57,000
+isolation.
+
+193
+00:15:58,000 --> 00:16:04,000
+The malicious behavior only becomes apparent when examining the a cumulative impact of many requests
+
+194
+00:16:04,000 --> 00:16:04,000
+over time.
+
+195
+00:16:05,000 --> 00:16:10,000
+For instance, an attacker might not trigger any alarms with individual reservation requests, but the
+
+196
+00:16:10,000 --> 00:16:15,000
+aggregate effect of rapidly filling all available slots becomes a significant issue.
+
+197
+00:16:15,000 --> 00:16:22,000
+Detecting such abuse requires not just monitoring individual requests, but also understanding and analyzing
+
+198
+00:16:22,000 --> 00:16:23,000
+the overall business logic.
+
+199
+00:16:23,000 --> 00:16:24,000
+Context.
+
+200
+00:16:24,000 --> 00:16:31,000
+This means correlating data across different endpoints and analyzing usage patterns in relation to business
+
+201
+00:16:31,000 --> 00:16:36,000
+rules, which is often beyond the capabilities of traditional monitoring tools.
+
+202
+00:16:36,000 --> 00:16:41,000
+Another challenge is the sophistication of modern evasion techniques.
+
+203
+00:16:41,000 --> 00:16:48,000
+Attackers frequently use methods designed to mimic legitimate user behavior to bypass detection systems.
+
+204
+00:16:49,000 --> 00:16:56,000
+They might employ techniques such as rotating IP addresses using headless browsers that simulate human
+
+205
+00:16:56,000 --> 00:16:59,000
+interactions or implementing Captcha bypasses.
+
+206
+00:17:00,000 --> 00:17:07,000
+These methods make it difficult for standard security tools, which rely on static rules and signatures
+
+207
+00:17:07,000 --> 00:17:11,000
+to differentiate between legitimate and malicious traffic.
+
+208
+00:17:12,000 --> 00:17:18,000
+When it comes to protection, one major challenge is implementing effective controls without inadvertently
+
+209
+00:17:18,000 --> 00:17:20,000
+impacting legitimate users.
+
+210
+00:17:21,000 --> 00:17:27,000
+Many anti-abuse measures, such as rate limiting or device fingerprinting, can potentially disrupt
+
+211
+00:17:27,000 --> 00:17:31,000
+genuine user activities if not carefully calibrated.
+
+212
+00:17:31,000 --> 00:17:37,000
+For instance, aggressive rate limiting might inconvenience real users trying to make legitimate purchases
+
+213
+00:17:37,000 --> 00:17:43,000
+or reservations, which could affect the overall user experience and lead to customer dissatisfaction.
+
+214
+00:17:44,000 --> 00:17:47,000
+Another challenge is the dynamic nature of business logic itself.
+
+215
+00:17:48,000 --> 00:17:53,000
+Business requirements and workflows can evolve, and APIs that were secure at one point might become
+
+216
+00:17:53,000 --> 00:17:56,000
+vulnerable as business processes change.
+
+217
+00:17:56,000 --> 00:18:02,000
+Keeping security measures in sync with the evolving business logic is crucial but can be difficult.
+
+218
+00:18:02,000 --> 00:18:08,000
+It requires continuous collaboration between development teams and security professionals to ensure
+
+219
+00:18:08,000 --> 00:18:15,000
+that any changes in business processes are adequately reflected in the API's security measures.
+
+220
+00:18:16,000 --> 00:18:23,000
+Moreover, traditional security solutions such as web application firewalls and API gateways often fall
+
+221
+00:18:23,000 --> 00:18:27,000
+short in addressing unrestricted access to sensitive business flows.
+
+222
+00:18:28,000 --> 00:18:34,000
+These tools are typically designed to protect against known attack vectors, and might not be equipped
+
+223
+00:18:34,000 --> 00:18:37,000
+to handle the nuances of business logic abuse.
+
+224
+00:18:37,000 --> 00:18:44,000
+They may not provide the context needed to understand the business flow, or detect sophisticated patterns
+
+225
+00:18:44,000 --> 00:18:51,000
+of abuse to effectively detect and protect against unrestricted access to sensitive business flows.
+
+226
+00:18:51,000 --> 00:18:55,000
+Organizations must adopt a multifaceted approach.
+
+227
+00:18:55,000 --> 00:19:03,000
+This includes leveraging advanced monitoring tools that provide deep insights into API usage patterns
+
+228
+00:19:03,000 --> 00:19:08,000
+and integrating AI driven analytics to identify deviations from normal behavior.
+
+229
+00:19:09,000 --> 00:19:15,000
+Implementing comprehensive logging and analysis of API traffic can help in understanding and detecting
+
+230
+00:19:15,000 --> 00:19:17,000
+complex abuse patterns.
+
+231
+00:19:17,000 --> 00:19:22,000
+Furthermore, security measures should be closely aligned with business logic.
+
+232
+00:19:22,000 --> 00:19:28,000
+This means conducting thorough risk assessments to identify potential abuse scenarios and implementing
+
+233
+00:19:28,000 --> 00:19:32,000
+controls that are specifically tailored to address these risks.
+
+234
+00:19:32,000 --> 00:19:37,000
+Regular reviews and updates of security policies and protections are essential to adapt to changing
+
+235
+00:19:37,000 --> 00:19:40,000
+business conditions and emerging threats.
+
+236
+00:19:40,000 --> 00:19:46,000
+Ultimately, addressing the challenges of unrestricted access to sensitive business flows requires a
+
+237
+00:19:46,000 --> 00:19:53,000
+combination of sophisticated detection techniques, thoughtful implementation of protective measures,
+
+238
+00:19:53,000 --> 00:19:59,000
+and ongoing vigilance to ensure that APIs remain secure against evolving threats
+
diff --git a/74 - OWASP API Security Top 10 2023/015 API62023 Unrestricted Access to Sensitive Business Flows - Part 2_en.srt b/74 - OWASP API Security Top 10 2023/015 API62023 Unrestricted Access to Sensitive Business Flows - Part 2_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..4ecd82e0ae7a4bcf4dab33e9c7c8a046e10a8234
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/015 API62023 Unrestricted Access to Sensitive Business Flows - Part 2_en.srt
@@ -0,0 +1,1212 @@
+1
+00:00:04,000 --> 00:00:10,000
+The potential impacts of unrestricted access to sensitive business flows on businesses are profound
+
+2
+00:00:10,000 --> 00:00:17,000
+and multifaceted, touching upon various critical aspects of operational integrity and security.
+
+3
+00:00:17,000 --> 00:00:23,000
+Understanding these impacts is crucial for developing effective strategies to mitigate the risks associated
+
+4
+00:00:23,000 --> 00:00:25,000
+with this vulnerability.
+
+5
+00:00:26,000 --> 00:00:31,000
+One of the primary concerns was unrestricted access to sensitive business flows.
+
+6
+00:00:31,000 --> 00:00:35,000
+Is the potential for significant service disruption.
+
+7
+00:00:35,000 --> 00:00:41,000
+When an attacker exploits unrestricted access to sensitive business processes, they can overwhelm the
+
+8
+00:00:41,000 --> 00:00:44,000
+system with an excessive number of requests.
+
+9
+00:00:44,000 --> 00:00:51,000
+This might occur through automated scripts or bots that flood the API, with requests each appearing
+
+10
+00:00:51,000 --> 00:00:53,000
+legitimate on its own.
+
+11
+00:00:53,000 --> 00:00:59,000
+For example, if an attacker books all available slots for a high demand service or product, Legitimate
+
+12
+00:00:59,000 --> 00:01:03,000
+users may be unable to access the system or complete transactions.
+
+13
+00:01:03,000 --> 00:01:09,000
+This type of disruption not only affects the immediate availability of the service, but can also lead
+
+14
+00:01:09,000 --> 00:01:12,000
+to longer term damage to the business's reputation.
+
+15
+00:01:13,000 --> 00:01:19,000
+Customers who are unable to use the service as intended may become frustrated, leading to lost sales
+
+16
+00:01:19,000 --> 00:01:20,000
+and diminished trust.
+
+17
+00:01:21,000 --> 00:01:27,000
+In severe cases, prolonged service disruptions can drive customers to competitors and tarnish the company's
+
+18
+00:01:27,000 --> 00:01:28,000
+reputation in the market.
+
+19
+00:01:30,000 --> 00:01:36,000
+Resource exhaustion is another critical impact associated with unrestricted access to sensitive business
+
+20
+00:01:36,000 --> 00:01:36,000
+flows.
+
+21
+00:01:37,000 --> 00:01:44,000
+Attackers can exploit the API to consume server resources such as CPU, memory, and bandwidth, leading
+
+22
+00:01:44,000 --> 00:01:48,000
+to performance degradation or even complete system failure.
+
+23
+00:01:48,000 --> 00:01:55,000
+For instance, an attacker might reserve all available inventory or place numerous orders, causing
+
+24
+00:01:55,000 --> 00:01:59,000
+the backend systems to process an unusually high volume of transactions.
+
+25
+00:02:00,000 --> 00:02:05,000
+This can strain infrastructure, resulting in slow response times or system outages.
+
+26
+00:02:06,000 --> 00:02:12,000
+In addition to immediate operational disruptions, resource exhaustion can incur substantial costs for
+
+27
+00:02:12,000 --> 00:02:18,000
+businesses as they may need to invest in scaling their infrastructure or address the technical debt
+
+28
+00:02:18,000 --> 00:02:19,000
+incurred by the attack.
+
+29
+00:02:20,000 --> 00:02:27,000
+The long term operational costs and the need for remediation can be significant, affecting the overall
+
+30
+00:02:27,000 --> 00:02:29,000
+financial health of the organization.
+
+31
+00:02:31,000 --> 00:02:37,000
+Unauthorized access and data breaches are serious consequences of unrestricted access to sensitive business
+
+32
+00:02:37,000 --> 00:02:37,000
+flows.
+
+33
+00:02:37,000 --> 00:02:38,000
+Attacks.
+
+34
+00:02:38,000 --> 00:02:45,000
+If an attacker can exploit the API to gain unauthorized access to sensitive data or user accounts,
+
+35
+00:02:45,000 --> 00:02:48,000
+the implications can be severe.
+
+36
+00:02:48,000 --> 00:02:54,000
+For instance, attackers might leverage unrestricted access to read or modify user data, leading to
+
+37
+00:02:55,000 --> 00:02:56,000
+potential data breaches.
+
+38
+00:02:56,000 --> 00:03:02,000
+This could include exposure of personal information, financial details or proprietary business information.
+
+39
+00:03:03,000 --> 00:03:07,000
+The repercussions of such breaches extend beyond immediate data loss.
+
+40
+00:03:07,000 --> 00:03:13,000
+Organisations might face regulatory fines and legal actions, especially if they are found to be non-compliant
+
+41
+00:03:13,000 --> 00:03:17,000
+with data protection regulations such as GDPR or CcpA.
+
+42
+00:03:17,000 --> 00:03:24,000
+Furthermore, data breaches can lead to significant reputational damage, eroding customer trust and
+
+43
+00:03:24,000 --> 00:03:27,000
+potentially resulting in a loss of business.
+
+44
+00:03:27,000 --> 00:03:34,000
+Restoring trust and managing the fallout from a breach requires considerable effort and resources,
+
+45
+00:03:34,000 --> 00:03:40,000
+including public relations campaigns, customer notification, and remediation of security weaknesses.
+
+46
+00:03:41,000 --> 00:03:48,000
+To deepen our understanding of unrestricted access to sensitive business flows, let us examine a real
+
+47
+00:03:48,000 --> 00:03:52,000
+life case study involving airline ticket and abuse.
+
+48
+00:03:52,000 --> 00:03:57,000
+This example will illustrate how unrestricted access to sensitive business flows.
+
+49
+00:03:57,000 --> 00:04:04,000
+Vulnerabilities are exploited, and the consequences that follow provide invaluable insights into both
+
+50
+00:04:04,000 --> 00:04:08,000
+the mechanics of such attacks and their broader implications.
+
+51
+00:04:09,000 --> 00:04:15,000
+Consider a scenario where an airline offers online ticket booking with the added benefit of no cancellation
+
+52
+00:04:15,000 --> 00:04:16,000
+fees.
+
+53
+00:04:16,000 --> 00:04:23,000
+This seemingly customer friendly policy, however, can expose the airline to significant risks if not
+
+54
+00:04:23,000 --> 00:04:24,000
+managed carefully.
+
+55
+00:04:25,000 --> 00:04:31,000
+An attacker with malicious intent could exploit this policy by targeting the airline's booking system
+
+56
+00:04:31,000 --> 00:04:32,000
+through its API.
+
+57
+00:04:33,000 --> 00:04:38,000
+In this case, the attacker's goal is to manipulate the system to gain financial advantage.
+
+58
+00:04:38,000 --> 00:04:45,000
+The attacker first identifies the API endpoint responsible for handling ticket reservations leveraging
+
+59
+00:04:45,000 --> 00:04:46,000
+automated scripts.
+
+60
+00:04:46,000 --> 00:04:52,000
+The attacker quickly reserves a substantial portion, or even all of the available seats on a high demand
+
+61
+00:04:52,000 --> 00:04:52,000
+flight.
+
+62
+00:04:53,000 --> 00:04:59,000
+By doing so, the attacker monopolizes the inventory, making it impossible for legitimate customers
+
+63
+00:04:59,000 --> 00:05:00,000
+to purchase tickets.
+
+64
+00:05:01,000 --> 00:05:08,000
+In this example, the exploitation of unrestricted access to sensitive business flows begins with the
+
+65
+00:05:08,000 --> 00:05:14,000
+attackers understanding of the business logic and the airline's booking flow.
+
+66
+00:05:14,000 --> 00:05:21,000
+The attacker recognizes that the system's API does not impose sufficient restrictions on the number
+
+67
+00:05:21,000 --> 00:05:24,000
+of reservations that can be made by a single user.
+
+68
+00:05:25,000 --> 00:05:31,000
+Armed with this knowledge, the attacker uses automation tools to bypass any rate limiting or usage
+
+69
+00:05:31,000 --> 00:05:36,000
+restrictions that might have been intended to prevent such abuse.
+
+70
+00:05:36,000 --> 00:05:42,000
+Once the attacker has booked the majority of the seats, they then cancel these reservations just before
+
+71
+00:05:42,000 --> 00:05:43,000
+the flight date.
+
+72
+00:05:44,000 --> 00:05:48,000
+Given the airline's policy of no cancellation fees.
+
+73
+00:05:48,000 --> 00:05:52,000
+The cancellation incurs no cost to the attacker.
+
+74
+00:05:52,000 --> 00:05:59,000
+As a result, the airline is forced to put the now available tickets back on sale, often at a discounted
+
+75
+00:05:59,000 --> 00:06:01,000
+rate, to fill the seats quickly.
+
+76
+00:06:02,000 --> 00:06:08,000
+The attacker, in turn, benefits from purchasing tickets at a reduced price, which they can then resell
+
+77
+00:06:08,000 --> 00:06:09,000
+at a premium.
+
+78
+00:06:10,000 --> 00:06:16,000
+To effectively prevent and mitigate unrestricted access to sensitive business flows, it is crucial
+
+79
+00:06:16,000 --> 00:06:22,000
+to adopt a two pronged approach that encompasses both the business and engineering layers.
+
+80
+00:06:23,000 --> 00:06:29,000
+Let us delve into the strategies for addressing unrestricted access to sensitive business flows at the
+
+81
+00:06:29,000 --> 00:06:36,000
+business layer, focusing on identifying sensitive business flows and assessing the risks associated
+
+82
+00:06:36,000 --> 00:06:38,000
+with these flows.
+
+83
+00:06:39,000 --> 00:06:44,000
+The first step in prevention and mitigation begins with a thorough understanding of your business operations
+
+84
+00:06:44,000 --> 00:06:46,000
+and the API endpoints that support them.
+
+85
+00:06:46,000 --> 00:06:52,000
+Some sensitive business flows are processes or transactions that, if abused, could have significant
+
+86
+00:06:52,000 --> 00:06:54,000
+adverse effects on the organization.
+
+87
+00:06:55,000 --> 00:07:01,000
+This might include high value transactions, limited inventory items, critical reservations, or any
+
+88
+00:07:01,000 --> 00:07:06,000
+process where abuse could lead to financial loss or reputational damage.
+
+89
+00:07:06,000 --> 00:07:12,000
+To identify these sensitive flows, engage in a comprehensive review of your business processes.
+
+90
+00:07:13,000 --> 00:07:19,000
+This involves mapping out the APIs and the associated business functions such as purchasing systems,
+
+91
+00:07:19,000 --> 00:07:22,000
+booking engines, or user account management.
+
+92
+00:07:23,000 --> 00:07:29,000
+During this process, consider scenarios where an API could be manipulated to gain undue advantage or
+
+93
+00:07:29,000 --> 00:07:30,000
+cause disruption.
+
+94
+00:07:31,000 --> 00:07:38,000
+For instance, if an API allows bulk buying of limited edition items without restrictions, this flow
+
+95
+00:07:38,000 --> 00:07:41,000
+is inherently sensitive and needs careful scrutiny.
+
+96
+00:07:42,000 --> 00:07:48,000
+Incorporate input from various Stakeholders within the organization, including business analysts,
+
+97
+00:07:48,000 --> 00:07:51,000
+product managers, and operations teams.
+
+98
+00:07:52,000 --> 00:07:57,000
+They can provide valuable insights into which processes are most critical and where vulnerabilities
+
+99
+00:07:57,000 --> 00:07:58,000
+might exist.
+
+100
+00:07:59,000 --> 00:08:05,000
+Additionally, reviewing historical incidents and understanding where past abuse has occurred can guide
+
+101
+00:08:06,000 --> 00:08:08,000
+the identification of sensitive flows.
+
+102
+00:08:09,000 --> 00:08:15,000
+Once sensitive business flows have been identified, the next step is to assess the risks associated
+
+103
+00:08:15,000 --> 00:08:16,000
+with them.
+
+104
+00:08:17,000 --> 00:08:23,000
+This involves analyzing how these flows could be exploited and the potential impact on the business
+
+105
+00:08:23,000 --> 00:08:25,000
+if they were to be abused.
+
+106
+00:08:25,000 --> 00:08:31,000
+Start by evaluating the potential consequences of abuse for each sensitive flow.
+
+107
+00:08:31,000 --> 00:08:38,000
+For example, if an API allows users to reserve multiple high demand tickets, consider the financial
+
+108
+00:08:38,000 --> 00:08:38,000
+impact.
+
+109
+00:08:38,000 --> 00:08:44,000
+If an attacker monopolizes these tickets and then forces the organization to sell them at a discount.
+
+110
+00:08:45,000 --> 00:08:50,000
+Similarly, assess the reputational damage that could occur if the abuse leads to customer dissatisfaction
+
+111
+00:08:50,000 --> 00:08:52,000
+or negative publicity.
+
+112
+00:08:52,000 --> 00:08:54,000
+Consider both direct and indirect risks.
+
+113
+00:08:55,000 --> 00:09:01,000
+Direct risks might include financial losses or operational disruptions, while indirect risks could
+
+114
+00:09:01,000 --> 00:09:06,000
+involve damage to customer trust and brand reputation.
+
+115
+00:09:06,000 --> 00:09:13,000
+Use risk assessment tools and methodologies to quantify these risks, such as impact analysis and probability
+
+116
+00:09:13,000 --> 00:09:14,000
+assessments.
+
+117
+00:09:14,000 --> 00:09:20,000
+This will help prioritize which risks need immediate attention and which can be addressed over time.
+
+118
+00:09:21,000 --> 00:09:27,000
+Additionally, evaluate the existing controls and safeguards related to these sensitive flows.
+
+119
+00:09:28,000 --> 00:09:34,000
+Identify any gaps in current policies or technical measures that could be exploited by malicious actors.
+
+120
+00:09:35,000 --> 00:09:41,000
+This includes reviewing rate limiting, access controls and monitoring mechanisms to ensure they are
+
+121
+00:09:41,000 --> 00:09:48,000
+robust enough to prevent abuse in addressing unrestricted access to sensitive business flows.
+
+122
+00:09:48,000 --> 00:09:55,000
+The engineering layer plays a crucial role in the implementation of robust preventative and mitigative
+
+123
+00:09:55,000 --> 00:09:56,000
+measures.
+
+124
+00:09:56,000 --> 00:10:03,000
+These measures are designed to enforce access controls, detect automated abuse, and ensure that the
+
+125
+00:10:03,000 --> 00:10:07,000
+API functions within the defined business logic constraints.
+
+126
+00:10:08,000 --> 00:10:13,000
+Let us explore the key strategies for prevention and mitigation at this engineering layer.
+
+127
+00:10:14,000 --> 00:10:16,000
+Implementing rate limiting and access controls.
+
+128
+00:10:16,000 --> 00:10:21,000
+Employing device fingerprinting and human detection, and analyzing non-human usage patterns.
+
+129
+00:10:23,000 --> 00:10:25,000
+Rate limiting is a fundamental technique to prevent abuse.
+
+130
+00:10:25,000 --> 00:10:32,000
+By restricting the number of requests a user or system can make to an API within a specified time frame.
+
+131
+00:10:32,000 --> 00:10:39,000
+By enforcing rate limits, you can effectively manage the volume of incoming requests and prevent automated
+
+132
+00:10:39,000 --> 00:10:42,000
+scripts or bots from overwhelming the system.
+
+133
+00:10:42,000 --> 00:10:49,000
+This approach ensures that the API remains available and responsive to legitimate users.
+
+134
+00:10:49,000 --> 00:10:56,000
+Access controls further reinforce security by regulating who can access specific API endpoints and under
+
+135
+00:10:56,000 --> 00:10:58,000
+what conditions.
+
+136
+00:10:58,000 --> 00:11:05,000
+This includes implementing authentication mechanisms to verify the identity of users, and authorization
+
+137
+00:11:05,000 --> 00:11:12,000
+rules to determine their permissions for sensitive business flows, such as purchasing or booking.
+
+138
+00:11:12,000 --> 00:11:18,000
+Additional restrictions may be necessary to limit the number of transactions a user can perform, or
+
+139
+00:11:18,000 --> 00:11:21,000
+the frequency with which they can access the system.
+
+140
+00:11:22,000 --> 00:11:28,000
+Rate limiting and access controls should be tailored to the nature of the API and the specific risks
+
+141
+00:11:28,000 --> 00:11:30,000
+associated with its business flows.
+
+142
+00:11:31,000 --> 00:11:37,000
+This requires a thorough understanding of the normal usage patterns and potential abuse scenarios.
+
+143
+00:11:37,000 --> 00:11:44,000
+Fine tuning these controls can help balance between usability and security, ensuring that legitimate
+
+144
+00:11:44,000 --> 00:11:49,000
+users can perform necessary actions while minimizing opportunities for exploitation.
+
+145
+00:11:50,000 --> 00:11:55,000
+Device fingerprinting involves collecting information about the client device making requests to the
+
+146
+00:11:55,000 --> 00:11:56,000
+API.
+
+147
+00:11:57,000 --> 00:12:04,000
+This technique can identify and differentiate between various devices based on attributes such as IP
+
+148
+00:12:04,000 --> 00:12:08,000
+address, browser characteristics, and hardware configurations.
+
+149
+00:12:09,000 --> 00:12:15,000
+By analyzing device fingerprints, you can detect patterns indicative of automated attacks, such as
+
+150
+00:12:15,000 --> 00:12:20,000
+multiple requests originating from a single device or from known proxy servers.
+
+151
+00:12:21,000 --> 00:12:26,000
+Human detection methods are employed to distinguish between human users and automated bots.
+
+152
+00:12:27,000 --> 00:12:32,000
+This can be achieved through various techniques, including Captcha challenges, which require users
+
+153
+00:12:32,000 --> 00:12:39,000
+to complete tasks that are difficult for bots, such as identifying objects in images or solving puzzles.
+
+154
+00:12:40,000 --> 00:12:46,000
+More advanced solutions might involve biometric approaches or behavioral analysis, which assess typing
+
+155
+00:12:46,000 --> 00:12:50,000
+patterns or mouse movements to confirm human interaction.
+
+156
+00:12:50,000 --> 00:12:57,000
+Integrating device fingerprinting and human detection into your API security strategy enhances your
+
+157
+00:12:57,000 --> 00:13:00,000
+ability to detect and mitigate malicious, automated behavior.
+
+158
+00:13:01,000 --> 00:13:07,000
+These measures provide additional layers of verification and help ensure that access to sensitive business
+
+159
+00:13:07,000 --> 00:13:10,000
+flows is restricted to genuine users.
+
+160
+00:13:12,000 --> 00:13:18,000
+To effectively combat unrestricted access to sensitive business flows, it is essential to analyze usage
+
+161
+00:13:18,000 --> 00:13:21,000
+patterns that deviate from typical human behavior.
+
+162
+00:13:22,000 --> 00:13:27,000
+Automated scripts and bots often exhibit distinct patterns compared to human users.
+
+163
+00:13:28,000 --> 00:13:33,000
+For example, bots might send requests at an abnormally high rate.
+
+164
+00:13:33,000 --> 00:13:38,000
+Execute actions in rapid succession or perform transactions with precise timing.
+
+165
+00:13:39,000 --> 00:13:44,000
+By analyzing these non-human usage patterns, you can identify and block suspicious activity.
+
+166
+00:13:45,000 --> 00:13:51,000
+Implementing monitoring tools that track and analyze API traffic can help you detect anomalies, such
+
+167
+00:13:51,000 --> 00:13:56,000
+as unusually high request rates or repetitive actions that are inconsistent with human behavior.
+
+168
+00:13:57,000 --> 00:14:03,000
+Machine learning algorithms and behavioral analytics can enhance this analysis by learning from historical
+
+169
+00:14:03,000 --> 00:14:07,000
+data and identifying patterns that indicate potential abuse.
+
+170
+00:14:08,000 --> 00:14:14,000
+Incorporating these analytical techniques allows for a more nuanced approach to detecting and mitigating
+
+171
+00:14:14,000 --> 00:14:15,000
+threats.
+
+172
+00:14:16,000 --> 00:14:22,000
+Rather than relying solely on static rules, you can dynamically adjust your defenses based on real
+
+173
+00:14:22,000 --> 00:14:25,000
+time data and evolving attack strategies.
+
+174
+00:14:27,000 --> 00:14:33,000
+Testing for unrestricted access to sensitive business flows involves a comprehensive approach to ensure
+
+175
+00:14:33,000 --> 00:14:38,000
+that APIs are resilient against misuse of sensitive business processes.
+
+176
+00:14:38,000 --> 00:14:46,000
+This process requires a methodical examination of how APIs handle business flows, focusing on identifying
+
+177
+00:14:46,000 --> 00:14:50,000
+potential vulnerabilities that could be exploited to cause harm.
+
+178
+00:14:51,000 --> 00:14:57,000
+Here, we explore effective methods for testing APIs to uncover unrestricted access to sensitive business
+
+179
+00:14:57,000 --> 00:15:01,000
+flows, vulnerabilities, and ensure robust protection.
+
+180
+00:15:01,000 --> 00:15:06,000
+Before delving into specific testing methods, it is essential to understand the objectives.
+
+181
+00:15:07,000 --> 00:15:12,000
+Testing for unrestricted access to sensitive business flows vulnerabilities aims to identify scenarios
+
+182
+00:15:12,000 --> 00:15:18,000
+where sensitive business processes can be abused due to insufficient access restrictions or inadequate
+
+183
+00:15:18,000 --> 00:15:19,000
+controls.
+
+184
+00:15:19,000 --> 00:15:26,000
+This involves assessing whether the APIs design and implementation appropriately safeguard against misuse
+
+185
+00:15:26,000 --> 00:15:27,000
+of its business logic.
+
+186
+00:15:28,000 --> 00:15:35,000
+There are manual and automated masses to test APIs for unrestricted access to sensitive business flows.
+
+187
+00:15:35,000 --> 00:15:36,000
+Let's review them.
+
+188
+00:15:37,000 --> 00:15:44,000
+Manual testing involves a hands on approach where testers simulate real world scenarios to identify
+
+189
+00:15:44,000 --> 00:15:45,000
+vulnerabilities.
+
+190
+00:15:46,000 --> 00:15:52,000
+This method is critical for understanding the context in which sensitive business flows operate and
+
+191
+00:15:52,000 --> 00:15:54,000
+how they might be exploited.
+
+192
+00:15:55,000 --> 00:16:00,000
+Begin by mapping out the sensitive business flows exposed by the API, such as purchasing mechanisms,
+
+193
+00:16:00,000 --> 00:16:03,000
+reservation systems, or content creation features.
+
+194
+00:16:04,000 --> 00:16:08,000
+Understanding these flows helps in crafting test scenarios that reflect potential abuse.
+
+195
+00:16:09,000 --> 00:16:15,000
+Create test cases that simulate various abuse scenarios such as rapid bulk purchases, excessive content
+
+196
+00:16:15,000 --> 00:16:17,000
+creation, or mass reservations.
+
+197
+00:16:17,000 --> 00:16:22,000
+These scenarios should be designed to test the limits and restrictions of the API.
+
+198
+00:16:23,000 --> 00:16:26,000
+Observe how the API responds to these scenarios.
+
+199
+00:16:27,000 --> 00:16:33,000
+Assess whether the API enforces appropriate limits and whether it detects and mitigates attempts to
+
+200
+00:16:33,000 --> 00:16:35,000
+exploit sensitive business flows.
+
+201
+00:16:36,000 --> 00:16:42,000
+Automated testing tools can streamline the process of identifying and restricted access to sensitive
+
+202
+00:16:42,000 --> 00:16:43,000
+business flows.
+
+203
+00:16:43,000 --> 00:16:44,000
+Vulnerabilities.
+
+204
+00:16:44,000 --> 00:16:49,000
+By systematically analyzing API behavior under various conditions.
+
+205
+00:16:49,000 --> 00:16:55,000
+These tools can simulate a high volume of requests and interactions to uncover weaknesses.
+
+206
+00:16:56,000 --> 00:17:02,000
+Use load testing tools to generate a large number of requests to sensitive endpoints.
+
+207
+00:17:03,000 --> 00:17:09,000
+This helps determine if the API can handle excessive load and if rate limiting mechanisms are effective
+
+208
+00:17:09,000 --> 00:17:10,000
+in preventing abuse.
+
+209
+00:17:11,000 --> 00:17:16,000
+Employ tools that analyze API behavior patterns, including request frequency and sequence.
+
+210
+00:17:16,000 --> 00:17:22,000
+These tools can help detect anomalies that may indicate abuse, such as unusually rapid or repetitive
+
+211
+00:17:22,000 --> 00:17:22,000
+actions.
+
+212
+00:17:23,000 --> 00:17:29,000
+Business logic analysis focuses on evaluating the integrity and security of the business processes implemented
+
+213
+00:17:29,000 --> 00:17:30,000
+by the API.
+
+214
+00:17:31,000 --> 00:17:38,000
+This method involves examining the APIs business rules and constraints to ensure they are enforced properly.
+
+215
+00:17:39,000 --> 00:17:46,000
+Analyze the business logic embedded in the API to ensure that it correctly enforces restrictions on
+
+216
+00:17:46,000 --> 00:17:47,000
+sensitive operations.
+
+217
+00:17:48,000 --> 00:17:55,000
+For instance, verify that limits on purchase quantities or reservation slots are accurately implemented.
+
+218
+00:17:56,000 --> 00:18:02,000
+Test the APIs adherence to business rules by attempting to bypass or override restrictions.
+
+219
+00:18:03,000 --> 00:18:09,000
+This can involve manipulating request parameters or payloads to see if the API enforces its business
+
+220
+00:18:09,000 --> 00:18:10,000
+logic consistently.
+
+221
+00:18:12,000 --> 00:18:19,000
+Penetration testing involves simulating attacks to uncover vulnerabilities that may not be apparent
+
+222
+00:18:19,000 --> 00:18:22,000
+through other testing methods.
+
+223
+00:18:22,000 --> 00:18:28,000
+This approach provides a comprehensive assessment of how well the API can withstand deliberate attempts
+
+224
+00:18:28,000 --> 00:18:30,000
+to exploit business flows.
+
+225
+00:18:32,000 --> 00:18:36,000
+Conduct tests to exploit potential vulnerabilities identified during the assessment.
+
+226
+00:18:37,000 --> 00:18:43,000
+This includes attempting to bypass access controls, floods the system with requests, or manipulate
+
+227
+00:18:43,000 --> 00:18:44,000
+business processes.
+
+228
+00:18:45,000 --> 00:18:50,000
+Assess the impact of successful exploitation on the API and associated business processes.
+
+229
+00:18:51,000 --> 00:18:56,000
+Determine if the exploited vulnerabilities could lead to significant harm, such as service disruption
+
+230
+00:18:56,000 --> 00:18:58,000
+or financial loss.
+
+231
+00:18:59,000 --> 00:19:04,000
+Ongoing monitoring and testing are crucial for identifying and mitigating new vulnerabilities as they
+
+232
+00:19:04,000 --> 00:19:04,000
+emerge.
+
+233
+00:19:05,000 --> 00:19:10,000
+Implementing continuous testing practices helps maintain API security over time.
+
+234
+00:19:11,000 --> 00:19:18,000
+Deploy monitoring tools that continuously track API usage and detect patterns indicative of abuse.
+
+235
+00:19:19,000 --> 00:19:25,000
+This allows for real time detection of potential unrestricted access to sensitive business flows.
+
+236
+00:19:25,000 --> 00:19:25,000
+Attacks.
+
+237
+00:19:26,000 --> 00:19:27,000
+Update.
+
+238
+00:19:27,000 --> 00:19:31,000
+Testing methodologies and tools to address evolving threats and business requirements.
+
+239
+00:19:32,000 --> 00:19:37,000
+Regularly revisit and test sensitive business flows to ensure ongoing protection.
+
+240
+00:19:39,000 --> 00:19:42,000
+Let's talk about best practices and recommendations now.
+
+241
+00:19:42,000 --> 00:19:45,000
+When addressing unrestricted access to sensitive.
+
+242
+00:19:45,000 --> 00:19:52,000
+Business flows, it is crucial to adopt best practices that not only secure APIs during their design
+
+243
+00:19:52,000 --> 00:19:59,000
+and implementation, but also ensure their continued safety through rigorous monitoring and testing.
+
+244
+00:20:00,000 --> 00:20:06,000
+This comprehensive approach will help safeguard sensitive business processes from exploitation and ensure
+
+245
+00:20:06,000 --> 00:20:08,000
+the integrity of your systems.
+
+246
+00:20:09,000 --> 00:20:15,000
+Implement robust access controls effective access control mechanisms are foundational to securing APIs.
+
+247
+00:20:15,000 --> 00:20:21,000
+Ensure that each API endpoint enforces appropriate access restrictions based on user roles and permissions.
+
+248
+00:20:22,000 --> 00:20:28,000
+Define and enforce granular permissions for each API endpoint, particularly those that handle sensitive
+
+249
+00:20:28,000 --> 00:20:29,000
+business flows.
+
+250
+00:20:30,000 --> 00:20:35,000
+Limit access based on user roles and responsibilities to prevent unauthorized actions.
+
+251
+00:20:36,000 --> 00:20:44,000
+Use strong authentication methods such as OAuth 2.0 or multi-factor authentication to verify the identity
+
+252
+00:20:44,000 --> 00:20:45,000
+of users.
+
+253
+00:20:46,000 --> 00:20:53,000
+Implement robust authorization mechanisms to ensure that users can only access resources and perform
+
+254
+00:20:53,000 --> 00:20:55,000
+actions they are permitted to.
+
+255
+00:20:56,000 --> 00:20:58,000
+Enforce rate limiting and throttling.
+
+256
+00:20:59,000 --> 00:21:06,000
+Rate limiting and throttling are essential to prevent abuse of API endpoints, especially those involved
+
+257
+00:21:06,000 --> 00:21:08,000
+in critical business processes.
+
+258
+00:21:09,000 --> 00:21:15,000
+Set limits on the number of requests a user or system can make within a specific time frame.
+
+259
+00:21:16,000 --> 00:21:22,000
+This helps prevent automated abuse such as rapid fire purchases or reservations.
+
+260
+00:21:23,000 --> 00:21:29,000
+Implement adaptive throttling to dynamically adjust limits based on the observed traffic patterns and
+
+261
+00:21:29,000 --> 00:21:30,000
+load.
+
+262
+00:21:31,000 --> 00:21:37,000
+This approach can help mitigate unexpected spikes in usage and protect against denial of service attacks.
+
+263
+00:21:39,000 --> 00:21:42,000
+Design business logic was abuse prevention in mind.
+
+264
+00:21:42,000 --> 00:21:48,000
+Incorporate abuse prevention strategies directly into the business logic of your APIs.
+
+265
+00:21:49,000 --> 00:21:53,000
+Implement validation rules and constraints to enforce business policies.
+
+266
+00:21:53,000 --> 00:21:59,000
+For instance, restrict the number of items a user can purchase or the number of reservations they can
+
+267
+00:21:59,000 --> 00:22:01,000
+make within a given period.
+
+268
+00:22:02,000 --> 00:22:07,000
+Ensure that error messages do not reveal sensitive information about the underlying business logic or
+
+269
+00:22:07,000 --> 00:22:08,000
+constraints.
+
+270
+00:22:08,000 --> 00:22:13,000
+This helps prevent attackers from gaining insights into how to bypass restrictions.
+
+271
+00:22:14,000 --> 00:22:21,000
+Secure sensitive data protects sensitive data handled by APIs to prevent unauthorized access and breaches.
+
+272
+00:22:22,000 --> 00:22:25,000
+Use encryption to protect data both in transit and at rest.
+
+273
+00:22:26,000 --> 00:22:32,000
+Ensures that sensitive information, such as personal details or financial data, is encrypted using
+
+274
+00:22:32,000 --> 00:22:34,000
+strong encryption standards.
+
+275
+00:22:35,000 --> 00:22:41,000
+Follows the principle of data minimization by collecting and storing only the data necessary for business
+
+276
+00:22:41,000 --> 00:22:42,000
+operations.
+
+277
+00:22:42,000 --> 00:22:46,000
+Avoid exposing sensitive data through API responses or logs.
+
+278
+00:22:48,000 --> 00:22:54,000
+Ongoing monitoring is essential for detecting and responding to potential threats in real time.
+
+279
+00:22:55,000 --> 00:22:58,000
+Implement tools to monitor API traffic patterns.
+
+280
+00:22:58,000 --> 00:23:06,000
+Continuously look for anomalies such as unusual request rates or access patterns, which may indicate
+
+281
+00:23:06,000 --> 00:23:08,000
+abusive behavior or attacks.
+
+282
+00:23:09,000 --> 00:23:16,000
+Use behavioral analytics to establish a baseline of normal API usage and detect deviations that could
+
+283
+00:23:16,000 --> 00:23:17,000
+suggest exploitation attempts.
+
+284
+00:23:18,000 --> 00:23:23,000
+This approach helps identify sophisticated attacks that may bypass traditional security measures.
+
+285
+00:23:25,000 --> 00:23:30,000
+Regular security testing helps identify and address vulnerabilities before they can be exploited.
+
+286
+00:23:31,000 --> 00:23:37,000
+Employ automated security scanners to regularly assess APIs for known vulnerabilities and misconfigurations.
+
+287
+00:23:38,000 --> 00:23:45,000
+These tools can help identify issues such as missing rate limits or inadequate access controls.
+
+288
+00:23:46,000 --> 00:23:51,000
+Conduct periodic penetration tests to simulate real world attacks on your APIs.
+
+289
+00:23:51,000 --> 00:23:58,000
+This helps uncover vulnerabilities in business logic and access controls that may not be detected through
+
+290
+00:23:58,000 --> 00:24:00,000
+automated testing alone.
+
+291
+00:24:01,000 --> 00:24:03,000
+Update and patch management.
+
+292
+00:24:04,000 --> 00:24:09,000
+Maintaining up to date software and infrastructure is crucial for protecting against emerging threats.
+
+293
+00:24:11,000 --> 00:24:17,000
+Implement a robust patch management process to ensure that all software components, including APIs
+
+294
+00:24:17,000 --> 00:24:22,000
+and their dependencies, are kept up to date with the latest security patches and updates.
+
+295
+00:24:24,000 --> 00:24:29,000
+Use version control to manage changes to API design and implementation.
+
+296
+00:24:29,000 --> 00:24:35,000
+This allows for tracking modifications and ensures that updates do not inadvertently introduce new vulnerabilities.
+
+297
+00:24:36,000 --> 00:24:42,000
+Incident response planning prepare for potential security incidents by developing and implementing an
+
+298
+00:24:42,000 --> 00:24:44,000
+incident response plan.
+
+299
+00:24:45,000 --> 00:24:51,000
+Define clear procedures for responding to API security incidents, including how to contain and mitigate
+
+300
+00:24:51,000 --> 00:24:51,000
+attacks.
+
+301
+00:24:51,000 --> 00:24:55,000
+Communicate with stakeholders and recover from breaches.
+
+302
+00:24:56,000 --> 00:25:02,000
+Conduct regular incident response drills to test the effectiveness of your response plan and ensure
+
+303
+00:25:02,000 --> 00:25:07,000
+that your team is prepared to handle security incidents efficiently.
+
diff --git a/74 - OWASP API Security Top 10 2023/016 API62023 Unrestricted Access to Sensitive Business Flows - Part 3 (Practice)_en.srt b/74 - OWASP API Security Top 10 2023/016 API62023 Unrestricted Access to Sensitive Business Flows - Part 3 (Practice)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..2d34ca77171348e9b8091fa3b3c867030d1f1ff2
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/016 API62023 Unrestricted Access to Sensitive Business Flows - Part 3 (Practice)_en.srt
@@ -0,0 +1,508 @@
+1
+00:00:03,000 --> 00:00:05,000
+Let's review source code examples.
+
+2
+00:00:05,000 --> 00:00:11,000
+Now we'll review source code of the problem and then we will review solution.
+
+3
+00:00:11,000 --> 00:00:15,000
+As always you can find all source code examples in attachments to the lesson.
+
+4
+00:00:16,000 --> 00:00:20,000
+In case during the explanation something will be not clear for you.
+
+5
+00:00:20,000 --> 00:00:26,000
+Or in case you have any questions regarding the example, please don't wait till the end of the lesson.
+
+6
+00:00:26,000 --> 00:00:31,000
+Just post your question below the video and I will be happy to answer.
+
+7
+00:00:31,000 --> 00:00:34,000
+So let's start review the code from the problem statement.
+
+8
+00:00:34,000 --> 00:00:40,000
+And at first let me give you some context about the example and what this class is supposed to do.
+
+9
+00:00:41,000 --> 00:00:43,000
+Let's dive into the problem.
+
+10
+00:00:43,000 --> 00:00:50,000
+Unrestricted purchase servlet class, which is intended to handle purchase requests in a web application.
+
+11
+00:00:50,000 --> 00:00:56,000
+Our goal is to understand how the servlet is structured, what it is supposed to do, and where it could
+
+12
+00:00:56,000 --> 00:01:03,000
+potentially introduce vulnerabilities, Particularly with respect to unrestricted access to sensitive
+
+13
+00:01:03,000 --> 00:01:04,000
+business flows.
+
+14
+00:01:05,000 --> 00:01:09,000
+As a primary goal of this survey is to process purchase requests.
+
+15
+00:01:09,000 --> 00:01:15,000
+It allows users to specify an item and a quantity they want to buy, processes the purchase, and responds
+
+16
+00:01:15,000 --> 00:01:18,000
+to the client based on whether the purchase was successful.
+
+17
+00:01:19,000 --> 00:01:22,000
+This endpoint processes HTTP post requests.
+
+18
+00:01:22,000 --> 00:01:25,000
+The Dopost method is responsible for processing the request.
+
+19
+00:01:26,000 --> 00:01:30,000
+We retrieve the item ID and quantity parameters from the HTTP request.
+
+20
+00:01:30,000 --> 00:01:38,000
+Item ID is a string representing the item being purchased, and quantity is an integer representing
+
+21
+00:01:38,000 --> 00:01:40,000
+the number of units the user wants to buy.
+
+22
+00:01:41,000 --> 00:01:47,000
+The process purchase method is called to handle the purchase logic, which returns a boolean indicating
+
+23
+00:01:47,000 --> 00:01:50,000
+whether the purchase was successful.
+
+24
+00:01:50,000 --> 00:01:56,000
+The process purchase method is a placeholder for the actual logic that would process the purchase.
+
+25
+00:01:56,000 --> 00:02:03,000
+In this simplified example, it always returns true, meaning the purchase is considered successful
+
+26
+00:02:03,000 --> 00:02:05,000
+regardless of the quantity.
+
+27
+00:02:06,000 --> 00:02:13,000
+Importantly, there is no limit enforced on the quantity of items purchased, which is a potential vulnerability
+
+28
+00:02:14,000 --> 00:02:17,000
+based on the result from process purchase.
+
+29
+00:02:17,000 --> 00:02:20,000
+The servlet sets the HTTP status code.
+
+30
+00:02:20,000 --> 00:02:25,000
+If the purchase was successful, it sets the status to 200 okay.
+
+31
+00:02:26,000 --> 00:02:33,000
+If the purchase failed, it sends an error response with a status code of 500, internal server error
+
+32
+00:02:33,000 --> 00:02:35,000
+and a failure message.
+
+33
+00:02:36,000 --> 00:02:39,000
+So where is vulnerability?
+
+34
+00:02:39,000 --> 00:02:41,000
+I believe you already see it.
+
+35
+00:02:42,000 --> 00:02:43,000
+Let me explain.
+
+36
+00:02:44,000 --> 00:02:51,000
+Let's consider the scenario where a new product, such as a highly anticipated smartphone is announced
+
+37
+00:02:51,000 --> 00:02:52,000
+and released.
+
+38
+00:02:52,000 --> 00:02:56,000
+Imagine that there is a rush to buy this product immediately upon release.
+
+39
+00:02:57,000 --> 00:03:03,000
+If our system allows a single user to purchase an unlimited number of units.
+
+40
+00:03:03,000 --> 00:03:05,000
+The following issues could arise.
+
+41
+00:03:06,000 --> 00:03:13,000
+A single user or a group of users could buy up the entire stock of the new product, leaving none available
+
+42
+00:03:13,000 --> 00:03:14,000
+for other customers.
+
+43
+00:03:15,000 --> 00:03:18,000
+This would lead to customer dissatisfaction and loss of sales.
+
+44
+00:03:19,000 --> 00:03:24,000
+The user who bought up all the stock might resell the items at a higher price, taking advantage of
+
+45
+00:03:24,000 --> 00:03:25,000
+the high demand.
+
+46
+00:03:26,000 --> 00:03:29,000
+This practice can damage the brand's reputation and fairness.
+
+47
+00:03:30,000 --> 00:03:36,000
+Such unrestricted access to sensitive business flows could result in significant financial losses and
+
+48
+00:03:36,000 --> 00:03:39,000
+operational challenges for the business.
+
+49
+00:03:39,000 --> 00:03:46,000
+The inability to control purchases means that the system is vulnerable to exploitation and abuse.
+
+50
+00:03:47,000 --> 00:03:53,000
+What if, during the launch of a new product like the iPhone, a single distributor or individual could
+
+51
+00:03:53,000 --> 00:03:57,000
+buy thousands of units due to the lack of purchase limits?
+
+52
+00:03:58,000 --> 00:04:02,000
+This kind of abuse could severely impact the business.
+
+53
+00:04:02,000 --> 00:04:09,000
+Wouldn't this create an environment where the product becomes unavailable for regular customers, damaging
+
+54
+00:04:09,000 --> 00:04:13,000
+the brand and creating a negative customer experience?
+
+55
+00:04:14,000 --> 00:04:21,000
+So I can say that this code example illustrates how the lack of restrictions on item quantity can lead
+
+56
+00:04:21,000 --> 00:04:23,000
+to potential business risks.
+
+57
+00:04:23,000 --> 00:04:29,000
+Understanding and mitigating such vulnerabilities is crucial to maintaining a fair and operationally
+
+58
+00:04:29,000 --> 00:04:30,000
+sound system.
+
+59
+00:04:31,000 --> 00:04:38,000
+So let's review a solution now and how to avoid unrestricted access to sensitive business flows.
+
+60
+00:04:38,000 --> 00:04:44,000
+This code addresses the vulnerability of unrestricted access to sensitive business flows, which was
+
+61
+00:04:44,000 --> 00:04:46,000
+an issue in our previous example.
+
+62
+00:04:47,000 --> 00:04:53,000
+Let's go through the code line by line, highlighting how it resolves the problems and enhances security.
+
+63
+00:04:53,000 --> 00:04:59,000
+The goal of this survey is to manage purchase requests while imposing restrictions on the number of
+
+64
+00:04:59,000 --> 00:05:01,000
+items a user can buy per product.
+
+65
+00:05:01,000 --> 00:05:07,000
+This helps prevent abuse such as stock depletion or scalping, ensuring that purchases are fair and
+
+66
+00:05:07,000 --> 00:05:08,000
+controlled.
+
+67
+00:05:08,000 --> 00:05:14,000
+On top of the file, we define a constant that is called max items per product, which sets a limit
+
+68
+00:05:14,000 --> 00:05:17,000
+on the number of items a user can purchase for each product.
+
+69
+00:05:18,000 --> 00:05:24,000
+This is a crucial addition compared to the previous example where no such restriction existed.
+
+70
+00:05:24,000 --> 00:05:28,000
+Then we proceed by checking if there is an active user session.
+
+71
+00:05:28,000 --> 00:05:37,000
+If the session does not exist or the user is not logged in, we respond with an HTTP 401 unauthorized
+
+72
+00:05:37,000 --> 00:05:37,000
+error.
+
+73
+00:05:38,000 --> 00:05:42,000
+This ensures that only logged in users can make purchases.
+
+74
+00:05:43,000 --> 00:05:49,000
+We retrieve the user ID from the session and the item ID and quantity from the request parameters.
+
+75
+00:05:49,000 --> 00:05:53,000
+This data is necessary to determine if the purchase can be processed.
+
+76
+00:05:54,000 --> 00:05:59,000
+We call this purchase allowed method to check if the purchase exceeds the allowed limit.
+
+77
+00:05:59,000 --> 00:06:06,000
+If the limit is exceeded, we respond with an HTTP 403 forbidden error.
+
+78
+00:06:06,000 --> 00:06:11,000
+This prevents users from buying more than the allowed number of items.
+
+79
+00:06:11,000 --> 00:06:15,000
+We attempt to process the purchase with the process purchase method.
+
+80
+00:06:15,000 --> 00:06:20,000
+If successful, we set the HTTP status to 200 okay.
+
+81
+00:06:20,000 --> 00:06:26,000
+If the purchase fails, we return an HTTP 500 internal server error.
+
+82
+00:06:26,000 --> 00:06:32,000
+This purchase allowed method checks if the total number of items a user has already purchased, combined
+
+83
+00:06:32,000 --> 00:06:35,000
+with the new quantity, does not exceed the maximum allowed.
+
+84
+00:06:35,000 --> 00:06:39,000
+This ensures that users cannot bypass the limit by making multiple purchases.
+
+85
+00:06:40,000 --> 00:06:45,000
+Process Purchase Methods handles the purchase logic and updates the database with the number of items
+
+86
+00:06:45,000 --> 00:06:46,000
+purchased.
+
+87
+00:06:47,000 --> 00:06:51,000
+This ensures that the user's purchase history is accurately tracked.
+
+88
+00:06:52,000 --> 00:06:54,000
+Get total items purchased.
+
+89
+00:06:54,000 --> 00:07:00,000
+Placeholder method would be used to retrieve the total number of items purchased by the user from the
+
+90
+00:07:00,000 --> 00:07:01,000
+database.
+
+91
+00:07:01,000 --> 00:07:08,000
+In a real application, it would involve querying the database and update total items purchased.
+
+92
+00:07:08,000 --> 00:07:13,000
+Placeholder method would update the database with the new quantity of items purchased.
+
+93
+00:07:14,000 --> 00:07:19,000
+It ensures that purchase limits are enforced by maintaining accurate records.
+
+94
+00:07:20,000 --> 00:07:26,000
+So I believe you noticed changes that removed unrestricted access to sensitive business flows.
+
+95
+00:07:26,000 --> 00:07:27,000
+Vulnerability.
+
+96
+00:07:28,000 --> 00:07:34,000
+The previous code lacked any limits on the number of items a user could purchase, allowing unrestricted
+
+97
+00:07:34,000 --> 00:07:36,000
+access to sensitive business flows.
+
+98
+00:07:38,000 --> 00:07:41,000
+The revised servlet introduces several important fixes.
+
+99
+00:07:41,000 --> 00:07:48,000
+It enforces a maximum limit on the number of items per product, preventing users from buying more than
+
+100
+00:07:48,000 --> 00:07:49,000
+allowed.
+
+101
+00:07:49,000 --> 00:07:55,000
+It checks for user authentication to ensure only logged in users can make purchases.
+
+102
+00:07:56,000 --> 00:08:03,000
+It includes logic to verify the total number of items already purchased by a user, ensuring that the
+
+103
+00:08:03,000 --> 00:08:06,000
+limit is respected across multiple transactions.
+
+104
+00:08:07,000 --> 00:08:13,000
+This solution effectively mitigates the risk of unrestricted access to sensitive business flows by implementing
+
+105
+00:08:13,000 --> 00:08:19,000
+limits and tracking purchase history, thus protecting the business from potential exploitation and
+
+106
+00:08:19,000 --> 00:08:21,000
+ensuring operational integrity.
+
+107
+00:08:21,000 --> 00:08:27,000
+I hope that this example helped you to understand better what an unrestricted access to sensitive flows
+
+108
+00:08:27,000 --> 00:08:30,000
+vulnerability is, and how to prevent it.
+
+109
+00:08:31,000 --> 00:08:33,000
+That's all what I wanted to discuss in this lesson.
+
+110
+00:08:34,000 --> 00:08:37,000
+Let's recap what we have learned from the lesson.
+
+111
+00:08:38,000 --> 00:08:45,000
+We explored the concept of unrestricted access to sensitive business flows and understood its significance
+
+112
+00:08:45,000 --> 00:08:46,000
+in API security.
+
+113
+00:08:47,000 --> 00:08:54,000
+We examined how unrestricted access to sensitive business flows differs from other API vulnerabilities,
+
+114
+00:08:54,000 --> 00:08:57,000
+and identified the masked attackers used to exploit it.
+
+115
+00:08:58,000 --> 00:09:04,000
+We reviewed common scenarios and examples of unrestricted access to sensitive business flows, including
+
+116
+00:09:04,000 --> 00:09:06,000
+business logic abuse cases.
+
+117
+00:09:06,000 --> 00:09:12,000
+We discussed the challenges associated with detecting and protecting against unrestricted access to
+
+118
+00:09:12,000 --> 00:09:17,000
+sensitive business flows, and explored strategies to address these challenges.
+
+119
+00:09:17,000 --> 00:09:23,000
+We analyzed the potential impacts of unrestricted access to sensitive business flows on businesses,
+
+120
+00:09:23,000 --> 00:09:27,000
+and reviewed a real life case study involving airline ticketing abuse.
+
+121
+00:09:28,000 --> 00:09:34,000
+We covered preventive measures and mitigation strategies, both from a business layer and engineering
+
+122
+00:09:34,000 --> 00:09:36,000
+layer perspective.
+
+123
+00:09:36,000 --> 00:09:42,000
+We conducted a practical example source code review, comparing problematic and improved implementations
+
+124
+00:09:42,000 --> 00:09:45,000
+to reinforce our understanding.
+
+125
+00:09:46,000 --> 00:09:47,000
+That's all for this lesson.
+
+126
+00:09:48,000 --> 00:09:50,000
+Thanks a lot for your attention.
+
+127
+00:09:50,000 --> 00:09:53,000
+Have a great day and see you in the next lesson.
+
diff --git a/74 - OWASP API Security Top 10 2023/016 Source-code-examples-from-the-lesson.url b/74 - OWASP API Security Top 10 2023/016 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..6718161081900bb960e0e32741de606d79dbb6db
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/016 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/uasbf
\ No newline at end of file
diff --git a/74 - OWASP API Security Top 10 2023/017 API72023 - Server Side Request Forgery.html b/74 - OWASP API Security Top 10 2023/017 API72023 - Server Side Request Forgery.html
new file mode 100644
index 0000000000000000000000000000000000000000..a7e944d7f7bc3e08deb7db701fbfad26be3ac81b
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/017 API72023 - Server Side Request Forgery.html
@@ -0,0 +1,69 @@
+
+
+
+
+
+ API72023 - Server Side Request Forgery
+
+
+
+
+
+
+
API72023 - Server Side Request Forgery
+
Please, check video lesson dedicated to SSRF from the section about OWASP Top 10 2021.
API7:2023 - Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) is a critical security vulnerability that can lead to severe consequences, especially in modern API-driven architectures and cloud-based environments. In this article, we’ll explore API7:2023 from the OWASP API Security Top 10, which highlights SSRF as one of the key risks in API development, while also comparing it to its previous iteration from OWASP Top 10 2021 (A10:2021).
Similarities Between API7:2023 and A10:2021
Both API7:2023 and A10:2021 emphasize the core nature of SSRF: it occurs when an attacker tricks a server into sending unauthorized requests to unintended destinations, either inside or outside the network. Key points of similarity include:
Exploitation of Server Functionality: In both lists, SSRF occurs when a web application or API fetches a remote resource based on untrusted user input (such as URLs) without properly validating or sanitizing the input. This can lead to unauthorized access to internal systems, port scanning, or sensitive data exposure.
Targeting Internal Systems: Both versions highlight that SSRF can be used to target internal resources that are normally protected by firewalls, VPNs, or network access controls, allowing attackers to bypass security barriers and exploit sensitive systems.
Cloud Exploitation: SSRF is especially dangerous in cloud environments, where metadata services can be targeted to access credentials or sensitive information. Both versions mention this risk, with examples such as exploiting cloud metadata storage by sending requests to addresses like http://169.254.169.254/, a common endpoint in cloud environments.
Prevention Strategies: Both API7:2023 and A10:2021 recommend similar approaches to mitigate SSRF risks, such as validating and sanitizing all user-supplied URLs, using allow lists for safe URLs, and segmenting networks to minimize the impact of a successful SSRF attack.
Differences Between API7:2023 and A10:2021
While the foundational concepts of SSRF remain consistent between the two OWASP versions, API7:2023 introduces several distinctions that reflect the evolving landscape of API security:
API-Centric Focus: The 2023 version is more focused on how SSRF vulnerabilities manifest in API-driven applications. It highlights common scenarios like APIs that use webhooks, URL previews, file fetching from external URLs, and custom SSO implementations. These API-specific features expose more opportunities for attackers to exploit SSRF.
In contrast, A10:2021 takes a broader view, focusing on SSRF in general web applications, which doesn’t necessarily dive as deep into specific API attack vectors.
Impact of Modern Infrastructure: API7:2023 underscores the heightened risk of SSRF due to modern cloud-native environments such as Kubernetes and Docker. These infrastructures often expose management interfaces over HTTP, which can be easily targeted through SSRF. Moreover, the connected nature of modern applications makes it harder to restrict outbound traffic, increasing the difficulty of fully mitigating SSRF.
The 2021 version mentions cloud exploitation but does not delve as deeply into cloud-native technologies or their specific attack surfaces.
New Examples and Attack Scenarios: The 2023 version provides updated examples tailored to API scenarios, including:
Using SSRF to initiate internal port scans through an API that accepts a user-supplied URL (e.g., uploading a profile picture via URL).
Exploiting API integration features (e.g., webhooks in security systems) to access sensitive internal resources like cloud credentials.
The 2021 version provides more general examples, such as exploiting SSRF to access internal files (e.g., /etc/passwd) or performing internal network port scans. While still relevant, these examples are not as focused on the unique API landscape.
Business Risk Focus: API7:2023 also emphasizes the need for business risk analysis when choosing a protection mechanism. It acknowledges that SSRF risks might not be fully eliminated in API architectures and suggests making decisions based on the balance of security and business needs.
This risk analysis approach is less emphasized in A10:2021, which is more focused on general technical mitigations.
Summary
The shift from A10:2021 to API7:2023 reflects the growing importance of securing APIs in modern applications and the increased risk posed by SSRF in complex, interconnected infrastructures. While the core principles of SSRF remain the same—exploiting improper validation of user-supplied URLs to access unauthorized systems—the 2023 API version emphasizes more specific risks related to APIs, cloud-native technologies, and business needs.
In conclusion, while A10:2021 introduces the basics of SSRF, API7:2023 refines this understanding to address the evolving challenges that arise in API-heavy architectures. As API usage becomes more prevalent in modern applications, it’s critical to adapt to the specific threats posed by SSRF in this context and implement the latest prevention strategies accordingly.
+
+
+
+
diff --git a/74 - OWASP API Security Top 10 2023/018 API82023 - Security Misconfiguration.html b/74 - OWASP API Security Top 10 2023/018 API82023 - Security Misconfiguration.html
new file mode 100644
index 0000000000000000000000000000000000000000..3425504b11fd3fa45bd4b2b9f76724db3f7c5020
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/018 API82023 - Security Misconfiguration.html
@@ -0,0 +1,69 @@
+
+
+
+
+
+ API82023 - Security Misconfiguration
+
+
+
+
+
+
+
API82023 - Security Misconfiguration
+
Please, check video lessons dedicated to Security Misconfiguration from the section about OWASP Top 10 2021.
API8:2023 - Security Misconfiguration
Security misconfiguration remains a prevalent and dangerous vulnerability in API security, particularly when it impacts the entire stack from network to application level. This lesson on API8:2023 explores the risks, attack scenarios, and prevention strategies for security misconfiguration in modern APIs and contrasts them with A05:2021 from OWASP Top 10 2021.
Similarities Between API8:2023 and A05:2021
Core Vulnerabilities: Both API8:2023 and A05:2021 focus on the dangers of insecure default configurations, unpatched systems, or misconfigured permissions, which can expose sensitive data or compromise systems.
Widespread Exploitability: Security misconfigurations in both APIs and applications are widespread, and attackers can easily exploit these vulnerabilities through public exploits, common endpoints, or unprotected files.
Prevention Strategies: Both versions emphasize the importance of automating hardening processes, enforcing secure default configurations, and continuously monitoring configurations to prevent exploitation.
Differences Between API8:2023 and A05:2021
API-Specific Focus: API8:2023 places a greater emphasis on API misconfigurations such as improper handling of HTTP verbs, Cross-Origin Resource Sharing (CORS) policy misconfigurations, and cache control directives. It recognizes unique risks in APIs that are less common in traditional web applications.
Modern Cloud Architectures: API8:2023 highlights misconfigurations in cloud services and APIs, such as improperly configured permissions in cloud storage (e.g., S3 buckets), which can lead to unauthorized data access. A05:2021 also addresses cloud risks but with less specific focus on API-driven systems.
New Attack Scenarios: API8:2023 provides API-specific attack scenarios like exploiting default configurations in logging utilities or caching sensitive information without proper cache control headers, making APIs especially vulnerable in modern environments.
Attack Scenarios in API8:2023
Exploiting Insecure Logging Configurations: Attackers can inject malicious code into API logs due to insecure default configurations in logging utilities.
Caching Sensitive Information: Failure to include cache control headers can lead to sensitive API responses (e.g., private conversations) being stored in browser caches, where attackers can retrieve them.
Prevention Strategies
Automated Hardening and Configuration Review: Implement automated processes to ensure consistent configuration across API components, orchestration files, and cloud services.
Security Headers and CORS Policies: Ensure APIs use secure CORS policies, cache control headers, and encryption (TLS) to protect sensitive communications and data.
Minimal Feature Deployment: Only enable necessary API features (e.g., HTTP verbs) and disable everything else to minimize the attack surface.
Summary and Conclusion
This lesson underscores the growing importance of Security Misconfiguration in APIs, which can expose sensitive systems and data if not properly addressed. With the shift to cloud-native applications and APIs, it’s crucial to maintain strong configuration practices, regularly update systems, and implement automated testing to prevent vulnerabilities.
+
+
+
+
diff --git a/74 - OWASP API Security Top 10 2023/019 API92023 Improper Inventory Management - Part 1_en.srt b/74 - OWASP API Security Top 10 2023/019 API92023 Improper Inventory Management - Part 1_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..722d00c7b8b6c77fd85b6b139609bd8d585ba4be
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/019 API92023 Improper Inventory Management - Part 1_en.srt
@@ -0,0 +1,1244 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:11,000
+In this lesson we are going to learn improper inventory management and how to avoid it.
+
+3
+00:00:12,000 --> 00:00:19,000
+We will start with the fundamentals exploring what API inventory management means and why it's so important
+
+4
+00:00:19,000 --> 00:00:21,000
+for maintaining robust security.
+
+5
+00:00:22,000 --> 00:00:28,000
+Next, we'll address common challenges that organizations face in keeping their API inventories up to
+
+6
+00:00:28,000 --> 00:00:29,000
+date and accurate.
+
+7
+00:00:30,000 --> 00:00:35,000
+We'll discuss how improper inventory management can lead to security vulnerabilities and the steps you
+
+8
+00:00:35,000 --> 00:00:37,000
+can take to mitigate these issues.
+
+9
+00:00:38,000 --> 00:00:44,000
+We'll then move on to a detailed discussion of key risks associated with improper API inventory management.
+
+10
+00:00:44,000 --> 00:00:50,000
+This includes understanding how vulnerabilities can be exploited, how risks can amplify within your
+
+11
+00:00:50,000 --> 00:00:56,000
+system, and the challenges related to maintaining cross compatibility between different API versions.
+
+12
+00:00:57,000 --> 00:01:04,000
+To bring these concepts to life we'll review real world examples of security breaches caused by poor
+
+13
+00:01:04,000 --> 00:01:05,000
+inventory management.
+
+14
+00:01:06,000 --> 00:01:13,000
+These case studies will highlight the severe consequences of not managing your API inventory properly.
+
+15
+00:01:13,000 --> 00:01:19,000
+Following that, we'll dive into the specific challenges posed by legacy APIs.
+
+16
+00:01:19,000 --> 00:01:26,000
+We'll discuss the delicate balance between maintaining backward compatibility and ensuring robust security.
+
+17
+00:01:26,000 --> 00:01:31,000
+Next, we'll outline strategies for effective API inventory management.
+
+18
+00:01:32,000 --> 00:01:38,000
+This will include best practices for maintaining an updated inventory, managing backward compatibility,
+
+19
+00:01:38,000 --> 00:01:43,000
+and ensuring thorough documentation and timely security updates.
+
+20
+00:01:43,000 --> 00:01:50,000
+Finally, we'll look at practical examples through source code reviews, where we'll analyze both problematic
+
+21
+00:01:50,000 --> 00:01:52,000
+and well-managed scenarios.
+
+22
+00:01:52,000 --> 00:01:58,000
+This hands on approach will help you see the difference between poor and effective inventory management
+
+23
+00:01:58,000 --> 00:02:05,000
+in action So let's get started and explore the essential aspects of API inventory management to ensure
+
+24
+00:02:05,000 --> 00:02:08,000
+your systems are secure and well managed.
+
+25
+00:02:09,000 --> 00:02:14,000
+To begin with, let us delve into the concept of API inventory management.
+
+26
+00:02:14,000 --> 00:02:21,000
+API inventory management refers to the systematic process of tracking and documenting all the APIs within
+
+27
+00:02:21,000 --> 00:02:24,000
+an organization's digital ecosystem.
+
+28
+00:02:24,000 --> 00:02:32,000
+This includes keeping a detailed record of each APIs, version endpoints, and associated security vulnerabilities.
+
+29
+00:02:33,000 --> 00:02:39,000
+The significance of maintaining such an inventory cannot be overstated, as it provides a comprehensive
+
+30
+00:02:39,000 --> 00:02:44,000
+view of the organization's API landscape, which is crucial for identifying and mitigating potential
+
+31
+00:02:44,000 --> 00:02:45,000
+security risks.
+
+32
+00:02:46,000 --> 00:02:52,000
+Moving forward, it's important to recognize the common challenges associated with maintaining API inventories.
+
+33
+00:02:53,000 --> 00:02:59,000
+One significant challenge is dealing with outdated or unsupported APIs, which can still be accessible
+
+34
+00:02:59,000 --> 00:03:01,000
+despite having known vulnerabilities.
+
+35
+00:03:02,000 --> 00:03:09,000
+This legacy APIs often remain in use due to backward compatibility requirements, but they can introduce
+
+36
+00:03:09,000 --> 00:03:12,000
+significant security risks if not properly managed.
+
+37
+00:03:13,000 --> 00:03:19,000
+Additionally, the sheer volume of APIs and their frequent updates can make it difficult to keep the
+
+38
+00:03:19,000 --> 00:03:23,000
+inventory up to date, leading to gaps in security coverage.
+
+39
+00:03:24,000 --> 00:03:31,000
+Furthermore, effective API inventory management plays a pivotal role in enhancing overall API security
+
+40
+00:03:32,000 --> 00:03:34,000
+by maintaining a current and accurate inventory.
+
+41
+00:03:34,000 --> 00:03:40,000
+Organizations can proactively address vulnerabilities in both current and legacy APIs.
+
+42
+00:03:41,000 --> 00:03:48,000
+This comprehensive management approach ensures that security patches and updates are applied consistently
+
+43
+00:03:48,000 --> 00:03:50,000
+across all API versions.
+
+44
+00:03:50,000 --> 00:03:57,000
+Moreover, it enables organizations to quickly identify and deprecate obsolete APIs, thereby reducing
+
+45
+00:03:57,000 --> 00:04:01,000
+the risk of exploitation through outdated Endpoints.
+
+46
+00:04:01,000 --> 00:04:09,000
+Understanding API inventory management involves appreciating its definition and significance, acknowledging
+
+47
+00:04:09,000 --> 00:04:17,000
+the common challenges faced, and recognizing its critical role in bolstering API security by effectively
+
+48
+00:04:17,000 --> 00:04:19,000
+managing the API inventory.
+
+49
+00:04:19,000 --> 00:04:26,000
+Organizations can safeguard their systems from potential threats and ensure a robust security posture.
+
+50
+00:04:27,000 --> 00:04:33,000
+Let us now turn our attention to the key risks associated with improper API inventory management.
+
+51
+00:04:34,000 --> 00:04:40,000
+Understanding these risks is crucial for developing effective strategies to safeguard our APIs and ensure
+
+52
+00:04:40,000 --> 00:04:42,000
+robust security.
+
+53
+00:04:43,000 --> 00:04:50,000
+First and foremost, the exploitation of vulnerabilities presents a significant risk when APIs are not
+
+54
+00:04:50,000 --> 00:04:52,000
+properly inventoried and managed.
+
+55
+00:04:52,000 --> 00:04:56,000
+Older versions with known vulnerabilities may remain accessible.
+
+56
+00:04:56,000 --> 00:05:02,000
+This can occur because outdated endpoints are sometimes retained for backward compatibility or due to
+
+57
+00:05:02,000 --> 00:05:04,000
+lapses in the update process.
+
+58
+00:05:04,000 --> 00:05:10,000
+Attackers can exploit these vulnerabilities to gain unauthorized access, execute malicious actions,
+
+59
+00:05:10,000 --> 00:05:12,000
+or extract sensitive data.
+
+60
+00:05:13,000 --> 00:05:18,000
+For instance, a vulnerability that has been patched in the latest API version may still be present
+
+61
+00:05:18,000 --> 00:05:23,000
+in older versions that are still active, providing an entry point for exploitation.
+
+62
+00:05:24,000 --> 00:05:29,000
+Hence, it's imperative to continuously monitor and address these vulnerabilities to mitigate the risk
+
+63
+00:05:29,000 --> 00:05:31,000
+of exploitation.
+
+64
+00:05:31,000 --> 00:05:35,000
+Next, let us consider the amplification of risks.
+
+65
+00:05:35,000 --> 00:05:43,000
+This risk arises when a vulnerability in an older or unsupported API is not isolated, but rather influences
+
+66
+00:05:43,000 --> 00:05:44,000
+other parts of the system.
+
+67
+00:05:45,000 --> 00:05:51,000
+For example, if a trusted API relies on an outdated and vulnerable component, any security issues
+
+68
+00:05:51,000 --> 00:05:55,000
+within that component can potentially propagate through the entire system.
+
+69
+00:05:56,000 --> 00:06:02,000
+This amplification effect can escalate the impact of the vulnerability leading to broader and more severe
+
+70
+00:06:02,000 --> 00:06:04,000
+consequences.
+
+71
+00:06:04,000 --> 00:06:11,000
+Effective API inventory management helps in isolating and addressing these risks before they can cause
+
+72
+00:06:11,000 --> 00:06:13,000
+widespread damage.
+
+73
+00:06:13,000 --> 00:06:17,000
+Finally, we must address the issue of cross compatibility.
+
+74
+00:06:17,000 --> 00:06:24,000
+As organizations strive to maintain functionality across different API versions, challenges often arise.
+
+75
+00:06:25,000 --> 00:06:31,000
+Supporting multiple versions of an API can lead to cross compatibility issues, where interactions between
+
+76
+00:06:31,000 --> 00:06:37,000
+different versions may not work as intended or introduce security vulnerabilities.
+
+77
+00:06:37,000 --> 00:06:45,000
+For instance, an API designed to be backward compatible with older versions might inadvertently expose
+
+78
+00:06:45,000 --> 00:06:49,000
+security flaws that were intended to be fixed in newer versions.
+
+79
+00:06:50,000 --> 00:06:56,000
+Balancing the need for compatibility with the imperative to address security concerns is a delicate
+
+80
+00:06:56,000 --> 00:07:03,000
+task that requires meticulous management and planning To illustrate the impact of poor API inventory
+
+81
+00:07:03,000 --> 00:07:10,000
+management, let's examine some real world examples where inadequate inventory control led to significant
+
+82
+00:07:10,000 --> 00:07:11,000
+security breaches.
+
+83
+00:07:11,000 --> 00:07:18,000
+These examples underscore the importance of maintaining a thorough and up to date API inventory to prevent
+
+84
+00:07:18,000 --> 00:07:20,000
+similar incidents.
+
+85
+00:07:21,000 --> 00:07:25,000
+Scenario one exploiting an undocumented feature.
+
+86
+00:07:26,000 --> 00:07:30,000
+Imagine an e-commerce platform that recently launched a new mobile app.
+
+87
+00:07:31,000 --> 00:07:37,000
+This app includes an API designed for user authentication and data access aimed at enhancing user experience
+
+88
+00:07:37,000 --> 00:07:38,000
+and functionality.
+
+89
+00:07:39,000 --> 00:07:44,000
+During the development phase, the team created a legacy API endpoint intended solely for internal testing.
+
+90
+00:07:45,000 --> 00:07:51,000
+This endpoint, accessible at slash internal slash user data, was not documented or included in the
+
+91
+00:07:51,000 --> 00:07:53,000
+official API documentation.
+
+92
+00:07:53,000 --> 00:08:00,000
+Importantly, this endpoint employs weak authentication mechanisms, specifically basic username and
+
+93
+00:08:00,000 --> 00:08:07,000
+password and provides access to sensitive user data such as names, addresses and payment details.
+
+94
+00:08:08,000 --> 00:08:15,000
+How attacked happened an attacker uses automated tools to scan the e-commerce platforms network for
+
+95
+00:08:15,000 --> 00:08:16,000
+exposed APIs.
+
+96
+00:08:17,000 --> 00:08:24,000
+Through this scanning, they come across the undocumented slash internal slash user data endpoint.
+
+97
+00:08:25,000 --> 00:08:31,000
+The attacker then attempts to guess the basic authentication credentials required to access the endpoint.
+
+98
+00:08:32,000 --> 00:08:38,000
+Given the simplicity of basic authentication, this step may not be particularly challenging.
+
+99
+00:08:38,000 --> 00:08:45,000
+Upon successfully accessing the endpoint, the attacker gains access to a significant amount of sensitive
+
+100
+00:08:45,000 --> 00:08:46,000
+user data.
+
+101
+00:08:47,000 --> 00:08:53,000
+This breach could lead to identity theft, financial fraud, and severe reputational damage for the
+
+102
+00:08:53,000 --> 00:08:54,000
+company.
+
+103
+00:08:55,000 --> 00:09:03,000
+Scenario two attacking a forgotten API Consider a financial institution that has recently transitioned
+
+104
+00:09:03,000 --> 00:09:05,000
+to a new API architecture.
+
+105
+00:09:05,000 --> 00:09:12,000
+In the process, the older version of the API used for various internal applications was retired.
+
+106
+00:09:12,000 --> 00:09:19,000
+However, the IT team overlooked the need to remove this old API from the network and disable access
+
+107
+00:09:19,000 --> 00:09:20,000
+to it.
+
+108
+00:09:20,000 --> 00:09:26,000
+The retired API version 1.0 remains accessible at its original URL.
+
+109
+00:09:27,000 --> 00:09:33,000
+This version contains known vulnerabilities such as SQL injection flaws due to the lack of updates and
+
+110
+00:09:33,000 --> 00:09:34,000
+patches.
+
+111
+00:09:34,000 --> 00:09:36,000
+Let's analyze the process of this attack.
+
+112
+00:09:37,000 --> 00:09:43,000
+An attacker conducting research on potential targets discovers information about the financial institution's
+
+113
+00:09:43,000 --> 00:09:44,000
+past systems.
+
+114
+00:09:44,000 --> 00:09:49,000
+This information might be found in web archives, online forums, or documentation.
+
+115
+00:09:50,000 --> 00:09:56,000
+The attacker scans the exposed old API and identifies the SQL injection vulnerability.
+
+116
+00:09:57,000 --> 00:10:03,000
+The attacker crafts a specially designed request to exploit the SQL injection vulnerability.
+
+117
+00:10:04,000 --> 00:10:10,000
+This could allow unauthorized access to sensitive financial data or even compromise internal systems.
+
+118
+00:10:11,000 --> 00:10:17,000
+These scenarios highlight the critical risks associated with inadequate API inventory management.
+
+119
+00:10:18,000 --> 00:10:24,000
+In both cases, vulnerabilities were exploited due to the lack of proper documentation and oversight
+
+120
+00:10:24,000 --> 00:10:26,000
+of API endpoints.
+
+121
+00:10:26,000 --> 00:10:32,000
+By maintaining an up to date inventory and ensuring that all endpoints are properly documented and secured,
+
+122
+00:10:32,000 --> 00:10:38,000
+organizations can mitigate these risks and protect their systems from similar breaches.
+
+123
+00:10:39,000 --> 00:10:45,000
+To further underscore the critical nature of API inventory management, let's examine the Optus breach
+
+124
+00:10:45,000 --> 00:10:49,000
+and notable example from September 2022.
+
+125
+00:10:50,000 --> 00:10:56,000
+Optus is the second largest telecommunications company in Australia, experienced a significant data
+
+126
+00:10:56,000 --> 00:11:02,000
+breach that exposed sensitive information of approximately 11.2 7.2 million customers.
+
+127
+00:11:03,000 --> 00:11:09,000
+Optus operates an API designed to manage customer accounts and handle various account related functions.
+
+128
+00:11:09,000 --> 00:11:14,000
+This API was crucial for accessing and updating customer information.
+
+129
+00:11:14,000 --> 00:11:20,000
+The breach occurred due to a security vulnerability in this API, which allowed unauthorised access
+
+130
+00:11:20,000 --> 00:11:21,000
+to sensitive customer data.
+
+131
+00:11:22,000 --> 00:11:27,000
+Specifically, the vulnerability exposed personal identifiable information including names, addresses,
+
+132
+00:11:27,000 --> 00:11:28,000
+and phone numbers.
+
+133
+00:11:29,000 --> 00:11:35,000
+Attackers identified the vulnerability in the API, potentially through automated scanning tools or
+
+134
+00:11:35,000 --> 00:11:39,000
+exploiting known weaknesses in the API's security protocols.
+
+135
+00:11:40,000 --> 00:11:46,000
+By leveraging this vulnerability, the attackers gained unauthorized access to the API.
+
+136
+00:11:46,000 --> 00:11:52,000
+This breach allowed them to extract a vast amount of personal data from Optus database.
+
+137
+00:11:52,000 --> 00:11:59,000
+The compromised data included sensitive customer information, leading to significant privacy concerns.
+
+138
+00:11:59,000 --> 00:12:06,000
+The breach not only jeopardize the personal information of millions, but also caused severe reputational
+
+139
+00:12:06,000 --> 00:12:07,000
+damage to Optus.
+
+140
+00:12:08,000 --> 00:12:16,000
+The company was forced to allocate $140 million to manage the fallout from the breach, including legal
+
+141
+00:12:16,000 --> 00:12:20,000
+fees, customer notifications and other remediation costs.
+
+142
+00:12:21,000 --> 00:12:27,000
+The Optus breach illustrates several key lessons about API security and inventory management.
+
+143
+00:12:28,000 --> 00:12:34,000
+The incident highlights the need for ongoing auditing and risk assessments of all APIs.
+
+144
+00:12:35,000 --> 00:12:40,000
+Regular reviews can help identify vulnerabilities before they are exploited.
+
+145
+00:12:40,000 --> 00:12:44,000
+Proper API inventory management is essential.
+
+146
+00:12:45,000 --> 00:12:52,000
+It ensures that all APIs are accounted for and assessed for potential security risks, preventing vulnerabilities
+
+147
+00:12:52,000 --> 00:12:53,000
+from going unnoticed.
+
+148
+00:12:54,000 --> 00:13:01,000
+Failure to address vulnerabilities in a timely manner can result in severe consequences, both financially
+
+149
+00:13:01,000 --> 00:13:03,000
+and reputationally.
+
+150
+00:13:04,000 --> 00:13:09,000
+The high costs associated with the breach emphasized the importance of proactive security measures.
+
+151
+00:13:10,000 --> 00:13:18,000
+In conclusion, the Optus breach serves as a stark reminder of the crucial role that effective API inventory
+
+152
+00:13:18,000 --> 00:13:24,000
+management plays in protecting sensitive data and maintaining organizational security.
+
+153
+00:13:25,000 --> 00:13:32,000
+Let us delve into the realm of legacy APIs, which are integral to understanding modern API security.
+
+154
+00:13:33,000 --> 00:13:40,000
+Legacy APIs are older versions of application programming interfaces that continue to operate alongside
+
+155
+00:13:40,000 --> 00:13:42,000
+more recent versions.
+
+156
+00:13:43,000 --> 00:13:48,000
+These APIs were typically developed to fulfill specific needs and were well suited to the technology
+
+157
+00:13:48,000 --> 00:13:49,000
+of their time.
+
+158
+00:13:50,000 --> 00:13:56,000
+However, as systems evolve and new versions are introduced, these older APIs often remain in use due
+
+159
+00:13:56,000 --> 00:14:00,000
+to their role in maintaining backward compatibility with existing systems.
+
+160
+00:14:01,000 --> 00:14:05,000
+Legacy APIs present a unique set of security challenges.
+
+161
+00:14:05,000 --> 00:14:11,000
+Firstly, these APIs were often developed without the benefit of contemporary security practices or
+
+162
+00:14:11,000 --> 00:14:12,000
+technologies.
+
+163
+00:14:12,000 --> 00:14:18,000
+Over time, as security vulnerabilities are discovered and addressed in newer versions, older APIs
+
+164
+00:14:18,000 --> 00:14:21,000
+may not receive the same updates or patches.
+
+165
+00:14:22,000 --> 00:14:26,000
+Consequently, they can become a significant vector for security breaches.
+
+166
+00:14:27,000 --> 00:14:34,000
+For instance, legacy APIs may utilize outdated authentication mechanisms, lack modern encryption protocols,
+
+167
+00:14:34,000 --> 00:14:40,000
+or be exposed to vulnerabilities that were identified and fixed in newer versions.
+
+168
+00:14:41,000 --> 00:14:47,000
+This can lead to unauthorized access, data breaches, and other security incidents if the APIs are
+
+169
+00:14:47,000 --> 00:14:50,000
+not adequately managed or updated.
+
+170
+00:14:51,000 --> 00:14:58,000
+One of the primary challenges with legacy APIs is balancing the need for backward compatibility with
+
+171
+00:14:58,000 --> 00:15:05,000
+the imperative of maintaining robust security organizations often face the dilemma of continuing support
+
+172
+00:15:05,000 --> 00:15:13,000
+for legacy APIs to avoid disrupting existing systems and users while simultaneously addressing their
+
+173
+00:15:13,000 --> 00:15:15,000
+security shortcomings.
+
+174
+00:15:15,000 --> 00:15:23,000
+Backward compatibility ensures that existing applications and systems that rely on older APIs continue
+
+175
+00:15:23,000 --> 00:15:25,000
+to function correctly.
+
+176
+00:15:26,000 --> 00:15:33,000
+However, this can hinder the adoption of newer, more secure API versions and introduce potential vulnerabilities.
+
+177
+00:15:34,000 --> 00:15:40,000
+Hence, organizations must carefully weigh the necessity of supporting legacy APIs against the risks
+
+178
+00:15:40,000 --> 00:15:43,000
+posed by their security vulnerabilities.
+
+179
+00:15:44,000 --> 00:15:51,000
+Effective API inventory management is crucial for maintaining robust security and operational efficiency
+
+180
+00:15:51,000 --> 00:15:53,000
+within modern software systems.
+
+181
+00:15:54,000 --> 00:16:00,000
+To ensure that your API inventory is managed effectively, several best practices and strategies should
+
+182
+00:16:00,000 --> 00:16:01,000
+be employed.
+
+183
+00:16:01,000 --> 00:16:04,000
+Let's delve deeper into each of these strategies.
+
+184
+00:16:05,000 --> 00:16:13,000
+Maintaining an updated API inventory involves several best practices that ensure all APIs within your
+
+185
+00:16:13,000 --> 00:16:16,000
+ecosystem are accounted for and managed appropriately.
+
+186
+00:16:17,000 --> 00:16:23,000
+Firstly, establish a comprehensive inventory system that tracks every API endpoint, its version,
+
+187
+00:16:23,000 --> 00:16:25,000
+and its associated metadata.
+
+188
+00:16:25,000 --> 00:16:30,000
+This system should be dynamic and capable of integrating with your development tools and deployment
+
+189
+00:16:30,000 --> 00:16:31,000
+processes.
+
+190
+00:16:32,000 --> 00:16:38,000
+Regularly update the inventory to reflect changes such as the addition of new APIs, the deprecation
+
+191
+00:16:38,000 --> 00:16:42,000
+of old ones, or modifications to existing endpoints.
+
+192
+00:16:42,000 --> 00:16:49,000
+Implement automated tools that can scan your code base and infrastructure to identify and catalog APIs,
+
+193
+00:16:49,000 --> 00:16:54,000
+minimizing manual effort and reducing the risk of oversight.
+
+194
+00:16:55,000 --> 00:17:00,000
+Furthermore, maintain a clear and organized repository of this inventory that is easily accessible
+
+195
+00:17:00,000 --> 00:17:06,000
+to all relevant stakeholders, including developers, security teams and operations staff.
+
+196
+00:17:08,000 --> 00:17:14,000
+Managing backward compatibility is essential for ensuring that updates or changes to your APIs do not
+
+197
+00:17:14,000 --> 00:17:20,000
+disrupt existing applications and services that depend on older versions.
+
+198
+00:17:20,000 --> 00:17:28,000
+To evaluate backward compatibility, start by assessing the dependencies and integration points of your
+
+199
+00:17:28,000 --> 00:17:28,000
+APIs.
+
+200
+00:17:29,000 --> 00:17:35,000
+This involves understanding how different versions of APIs interact with various components and systems
+
+201
+00:17:35,000 --> 00:17:37,000
+within your infrastructure.
+
+202
+00:17:38,000 --> 00:17:44,000
+Adopt a versioning strategy that allows for smooth transitions between API versions.
+
+203
+00:17:44,000 --> 00:17:50,000
+This could involve semantic versioning, where changes to the version number indicate the nature of
+
+204
+00:17:50,000 --> 00:17:51,000
+the updates.
+
+205
+00:17:51,000 --> 00:17:58,000
+For example, major, minor, or patch changes when introducing new versions, provide clear migration
+
+206
+00:17:58,000 --> 00:18:02,000
+paths and support for deprecated versions for a reasonable period.
+
+207
+00:18:03,000 --> 00:18:10,000
+This ensures that clients have adequate time to adapt to new versions without facing immediate disruptions.
+
+208
+00:18:11,000 --> 00:18:17,000
+Additionally, use automated testing and regression testing to validate that new versions of APIs do
+
+209
+00:18:17,000 --> 00:18:20,000
+not break existing functionality.
+
+210
+00:18:20,000 --> 00:18:27,000
+Implementing continuous integration and continuous deployment pipelines can help manage and test backward
+
+211
+00:18:27,000 --> 00:18:29,000
+compatibility efficiently.
+
+212
+00:18:31,000 --> 00:18:37,000
+Effective documentation and communication are foundational to successful API inventory management.
+
+213
+00:18:37,000 --> 00:18:44,000
+Comprehensive documentation should cover all aspects of your APIs, including their purpose and points,
+
+214
+00:18:44,000 --> 00:18:50,000
+request and response formats, authentication methods, and error handling.
+
+215
+00:18:50,000 --> 00:18:56,000
+This documentation should be kept up to date and easily accessible to all team members involved in the
+
+216
+00:18:56,000 --> 00:19:00,000
+development, maintenance, and usage of APIs.
+
+217
+00:19:01,000 --> 00:19:03,000
+Communication within teams is equally crucial.
+
+218
+00:19:04,000 --> 00:19:09,000
+Ensure that there are clear channels for reporting and discussing changes to API's, potential issues
+
+219
+00:19:09,000 --> 00:19:11,000
+and security vulnerabilities.
+
+220
+00:19:11,000 --> 00:19:16,000
+Regular meetings or briefings can help keep everyone informed about the status of the API inventory,
+
+221
+00:19:16,000 --> 00:19:18,000
+and any updates or changes.
+
+222
+00:19:19,000 --> 00:19:24,000
+Encourage feedback from developers and users to identify areas for improvement and to address any issues
+
+223
+00:19:24,000 --> 00:19:25,000
+promptly.
+
+224
+00:19:26,000 --> 00:19:28,000
+Secure non-production deployments.
+
+225
+00:19:29,000 --> 00:19:35,000
+Non-production environments often mirror production systems, but can be less secure if not properly
+
+226
+00:19:35,000 --> 00:19:36,000
+managed.
+
+227
+00:19:37,000 --> 00:19:38,000
+Avoid real data.
+
+228
+00:19:38,000 --> 00:19:42,000
+Do not use real sensitive data in non-production environments.
+
+229
+00:19:42,000 --> 00:19:49,000
+Instead, utilize anonymized or synthetic data to mitigate risks associated with data breaches.
+
+230
+00:19:51,000 --> 00:19:57,000
+Ensure that non-production environments adhere to security measures comparable to those in production.
+
+231
+00:19:58,000 --> 00:20:03,000
+This includes applying the same authentication, Indication, authorization and monitoring controls
+
+232
+00:20:03,000 --> 00:20:08,000
+to prevent vulnerabilities and unauthorized access in these environments.
+
+233
+00:20:09,000 --> 00:20:15,000
+Implementing timely security updates for older API versions is vital to protecting your system from
+
+234
+00:20:15,000 --> 00:20:16,000
+vulnerabilities.
+
+235
+00:20:17,000 --> 00:20:23,000
+Even if an API version is deprecated or not actively supported, it can still be a target for attacks
+
+236
+00:20:23,000 --> 00:20:25,000
+if it remains accessible.
+
+237
+00:20:26,000 --> 00:20:32,000
+Establish a process for regularly reviewing and applying security patches to older API versions.
+
+238
+00:20:32,000 --> 00:20:39,000
+This involves monitoring security advisories, vulnerability databases, and industry best practices
+
+239
+00:20:39,000 --> 00:20:42,000
+to stay informed about potential threats.
+
+240
+00:20:43,000 --> 00:20:49,000
+When a vulnerability is discovered, assess its impact on the affected API versions and apply the necessary
+
+241
+00:20:49,000 --> 00:20:51,000
+patches or mitigations as quickly as possible.
+
+242
+00:20:52,000 --> 00:20:57,000
+Consider implementing security controls such as rate limiting, logging, and access restrictions to
+
+243
+00:20:57,000 --> 00:21:02,000
+protect older API versions from unauthorized access while they remain in use.
+
+244
+00:21:03,000 --> 00:21:09,000
+Additionally, communicate with stakeholders about the status of security updates and encourage them
+
+245
+00:21:09,000 --> 00:21:14,000
+to transition to newer, more secure versions of APIs.
+
+246
+00:21:15,000 --> 00:21:17,000
+Secure access to APIs.
+
+247
+00:21:18,000 --> 00:21:24,000
+Implementing strong authentication and authorization mechanisms is crucial for safeguarding your APIs.
+
+248
+00:21:25,000 --> 00:21:33,000
+Use robust authentication methods such as OAuth, JWT, or multi-factor authentication to ensure that
+
+249
+00:21:33,000 --> 00:21:37,000
+only legitimate users and systems can access your APIs.
+
+250
+00:21:38,000 --> 00:21:44,000
+Apply the principle of least privilege by granting access only to authorized individuals and applications.
+
+251
+00:21:45,000 --> 00:21:50,000
+This minimizes the risk of unauthorized access and potential misuse.
+
+252
+00:21:50,000 --> 00:21:56,000
+Ensure that different levels of access are well defined and enforced, based on the specific needs of
+
+253
+00:21:56,000 --> 00:21:58,000
+users or systems.
+
+254
+00:21:59,000 --> 00:22:06,000
+Perform a risk analysis to determine the potential impact of each legacy API on overall system security.
+
+255
+00:22:07,000 --> 00:22:15,000
+This analysis should include an evaluation of the data exposed by each API and the likelihood of exploitation.
+
+256
+00:22:16,000 --> 00:22:21,000
+Use this information to prioritize which APIs need urgent updates or remediation.
+
+257
+00:22:22,000 --> 00:22:28,000
+For legacy APIs that must remain in use, implement additional security measures to mitigate risks.
+
+258
+00:22:29,000 --> 00:22:34,000
+This may include deploying firewalls, implementing stringent access controls, and using modern encryption
+
+259
+00:22:34,000 --> 00:22:37,000
+methods to protect data in transit and at rest.
+
+260
+00:22:38,000 --> 00:22:44,000
+In the realm of modern software development, managing APIs effectively is crucial for ensuring security,
+
+261
+00:22:44,000 --> 00:22:46,000
+functionality, and efficiency.
+
+262
+00:22:47,000 --> 00:22:52,000
+Leveraging the right tools and technologies can significantly enhance API inventory management.
+
+263
+00:22:52,000 --> 00:22:59,000
+Let's explore some of the key tools and techniques that facilitate API discovery, documentation and
+
+264
+00:22:59,000 --> 00:23:00,000
+security.
+
+265
+00:23:01,000 --> 00:23:06,000
+Several tools are available to aid in the discovery and management of APIs.
+
+266
+00:23:07,000 --> 00:23:12,000
+These tools play a vital role in automating the process of identifying and cataloging.
+
+267
+00:23:12,000 --> 00:23:15,000
+APIs across your ecosystem.
+
+268
+00:23:16,000 --> 00:23:24,000
+Tools like Apigee or AWS API Gateway and Azure API management provide comprehensive solutions for API
+
+269
+00:23:24,000 --> 00:23:26,000
+discovery, management, and monitoring.
+
+270
+00:23:27,000 --> 00:23:34,000
+These platforms offer features such as automated API documentation, version control, and detailed
+
+271
+00:23:34,000 --> 00:23:37,000
+analytics on API usage and performance.
+
+272
+00:23:38,000 --> 00:23:45,000
+Tools such as swagger, open API, and postman help in discovering and documenting APIs.
+
+273
+00:23:46,000 --> 00:23:53,000
+Swagger allows you to define and document APIs using a standard format that can be used to generate
+
+274
+00:23:53,000 --> 00:23:54,000
+interactive documentation.
+
+275
+00:23:55,000 --> 00:24:01,000
+Postman, on the other hand, provides functionality for testing and monitoring APIs, which can be
+
+276
+00:24:01,000 --> 00:24:03,000
+integrated into the discovery process.
+
+277
+00:24:04,000 --> 00:24:11,000
+Tools like sonar, cube, and snake scan your codebase for API related vulnerabilities and provide insights
+
+278
+00:24:11,000 --> 00:24:15,000
+into how APIs are utilized within the application.
+
+279
+00:24:16,000 --> 00:24:21,000
+These tools help in identifying undocumented or insecure API endpoints.
+
+280
+00:24:22,000 --> 00:24:26,000
+Automated documentation generation and integration with CI.
+
+281
+00:24:26,000 --> 00:24:34,000
+CD pipelines are essential for maintaining up to date API documentation and ensuring that APIs are continuously
+
+282
+00:24:34,000 --> 00:24:35,000
+tested and validated.
+
+283
+00:24:36,000 --> 00:24:43,000
+Tools such as swagger UI and Redux generate interactive API documentation automatically from API definitions
+
+284
+00:24:43,000 --> 00:24:46,000
+written in formats like OpenAPI.
+
+285
+00:24:47,000 --> 00:24:54,000
+This ensures that documentation is always in sync with the API's current state and accessible to developers
+
+286
+00:24:54,000 --> 00:24:55,000
+and stakeholders.
+
+287
+00:24:56,000 --> 00:25:02,000
+Incorporating automated API documentation into your CI, CD pipelines helps maintain consistency and
+
+288
+00:25:02,000 --> 00:25:03,000
+accuracy.
+
+289
+00:25:03,000 --> 00:25:09,000
+For example, integrating swagger, Codegen, or OpenAPI generator into your CI CD workflows allows
+
+290
+00:25:09,000 --> 00:25:14,000
+for the automatic generation of client libraries, server stops, and API documentation as part of the
+
+291
+00:25:14,000 --> 00:25:15,000
+build process.
+
+292
+00:25:16,000 --> 00:25:22,000
+This integration ensures that every deployment is accompanied by updated documentation, minimizing
+
+293
+00:25:22,000 --> 00:25:24,000
+discrepancies and errors.
+
+294
+00:25:25,000 --> 00:25:33,000
+Tools like unit, jest and Postman can be used within CI CD pipelines to run automated tests on APIs.
+
+295
+00:25:33,000 --> 00:25:40,000
+These tests verify that APIs function correctly and adhere to expected contracts, helping to catch
+
+296
+00:25:40,000 --> 00:25:43,000
+issues early in the development cycle.
+
+297
+00:25:44,000 --> 00:25:51,000
+Securing all versions of your APIs is paramount for safeguarding against vulnerabilities and potential
+
+298
+00:25:51,000 --> 00:25:51,000
+breaches.
+
+299
+00:25:52,000 --> 00:25:57,000
+Several advanced security solutions can help monitor and protect APIs effectively.
+
+300
+00:25:58,000 --> 00:26:05,000
+Solutions like API Gateway and Web Application firewall offer real time protection for APIs by filtering
+
+301
+00:26:05,000 --> 00:26:07,000
+and monitoring incoming traffic.
+
+302
+00:26:08,000 --> 00:26:14,000
+They can enforce security policies such as rate limiting and IP whitelisting, and provide protection
+
+303
+00:26:14,000 --> 00:26:18,000
+against common threats like SQL injection and cross-site scripting.
+
+304
+00:26:20,000 --> 00:26:26,000
+Comprehensive platforms like Traceable and Data Serum offer in-depth security analysis and monitoring
+
+305
+00:26:26,000 --> 00:26:29,000
+across all versions of your APIs.
+
+306
+00:26:29,000 --> 00:26:36,000
+These platforms provide capabilities such as threat detection, vulnerability management, and security
+
+307
+00:26:36,000 --> 00:26:37,000
+posture assessments.
+
+308
+00:26:38,000 --> 00:26:45,000
+Tools such as New Relic, Datadog, and Prometheus offer monitoring and analytics capabilities that
+
+309
+00:26:45,000 --> 00:26:49,000
+provide visibility into API performance and usage.
+
+310
+00:26:49,000 --> 00:26:56,000
+They can help detect anomalies, monitor traffic patterns, and provide insights into potential security
+
+311
+00:26:56,000 --> 00:26:57,000
+issues or breaches
+
diff --git a/74 - OWASP API Security Top 10 2023/020 API92023 Improper Inventory Management - Part 2 (Practice)_en.srt b/74 - OWASP API Security Top 10 2023/020 API92023 Improper Inventory Management - Part 2 (Practice)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..5cbd17176f2939f2c73e9f639e74bb09f259e31c
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/020 API92023 Improper Inventory Management - Part 2 (Practice)_en.srt
@@ -0,0 +1,552 @@
+1
+00:00:04,000 --> 00:00:06,000
+Let's review source code examples.
+
+2
+00:00:06,000 --> 00:00:11,000
+Now we'll review source code of the problem and then we will review solution.
+
+3
+00:00:12,000 --> 00:00:16,000
+As always you can find all source code examples in attachments to the lesson.
+
+4
+00:00:17,000 --> 00:00:20,000
+In case during the explanation something will be not clear for you.
+
+5
+00:00:20,000 --> 00:00:27,000
+Or in case you have any questions regarding the example, please don't wait till the end of the lesson.
+
+6
+00:00:27,000 --> 00:00:31,000
+Just post your question below the video and I will be happy to answer.
+
+7
+00:00:32,000 --> 00:00:35,000
+So let's start review the code from the problem statement.
+
+8
+00:00:35,000 --> 00:00:41,000
+And at first, let me give you some context about the example and what this class is supposed to do.
+
+9
+00:00:41,000 --> 00:00:48,000
+The problem debugging for servlet class is a simple Java servlet designed to provide debugging information
+
+10
+00:00:49,000 --> 00:00:52,000
+when accessed via an HTTP get request.
+
+11
+00:00:52,000 --> 00:00:56,000
+It outputs sensitive server and application information.
+
+12
+00:00:56,000 --> 00:01:03,000
+The intention behind this servlet might be to assist developers or system administrators by providing
+
+13
+00:01:03,000 --> 00:01:08,000
+immediate access to critical information needed for troubleshooting and debugging.
+
+14
+00:01:09,000 --> 00:01:14,000
+Because the application may be deployed on different servers, and sometimes you need to get this information
+
+15
+00:01:14,000 --> 00:01:15,000
+quickly.
+
+16
+00:01:16,000 --> 00:01:20,000
+In a typical business environment, such debugging information could be valuable.
+
+17
+00:01:20,000 --> 00:01:23,000
+For instance, when a system encounters issues.
+
+18
+00:01:23,000 --> 00:01:30,000
+Administrators or developers might need quick access to server details and application logs to diagnose
+
+19
+00:01:30,000 --> 00:01:31,000
+and resolve problems.
+
+20
+00:01:31,000 --> 00:01:38,000
+This server therefore, could be intended to simplify the process of gathering such information without
+
+21
+00:01:38,000 --> 00:01:41,000
+needing to access server logs directly.
+
+22
+00:01:41,000 --> 00:01:48,000
+In technical terms, the server is designed to print out server related and application specific data.
+
+23
+00:01:48,000 --> 00:01:55,000
+The server Info string includes details about the server operating system, Java version, and JVM arguments,
+
+24
+00:01:55,000 --> 00:01:59,000
+while the app log string provides recent log entries.
+
+25
+00:01:59,000 --> 00:02:05,000
+Such information can be crucial for understanding the state of the system and identifying issues.
+
+26
+00:02:06,000 --> 00:02:13,000
+Now let's highlight the security issues associated with this servlet, specifically focusing on improper
+
+27
+00:02:13,000 --> 00:02:14,000
+inventory management.
+
+28
+00:02:15,000 --> 00:02:22,000
+This servlet is labeled as a deprecated endpoint for debugging purposes, which suggests that it might
+
+29
+00:02:22,000 --> 00:02:26,000
+have been intended for use only during development or troubleshooting phases.
+
+30
+00:02:26,000 --> 00:02:29,000
+However, it's still present in the production environment.
+
+31
+00:02:30,000 --> 00:02:35,000
+Leaving such endpoints exposed can lead to significant security risks.
+
+32
+00:02:35,000 --> 00:02:41,000
+Attackers could exploit this endpoint to gather sensitive information about the server and application,
+
+33
+00:02:41,000 --> 00:02:45,000
+potentially using this information to launch more targeted attacks.
+
+34
+00:02:46,000 --> 00:02:52,000
+The servlet exposes sensitive server and application details that should ideally be kept confidential.
+
+35
+00:02:53,000 --> 00:02:58,000
+For example, knowing the operating system, Java version and recent application logs can provide attackers
+
+36
+00:02:58,000 --> 00:03:02,000
+with insights into potential vulnerabilities or misconfigurations.
+
+37
+00:03:03,000 --> 00:03:09,000
+Such information might be used to craft specific attacks or exploit known issues related to the disclosed
+
+38
+00:03:09,000 --> 00:03:10,000
+components.
+
+39
+00:03:10,000 --> 00:03:16,000
+This endpoint does not implement any form of access control or authentication.
+
+40
+00:03:17,000 --> 00:03:21,000
+Consequently, anyone who knows the endpoints URL can access it.
+
+41
+00:03:21,000 --> 00:03:25,000
+Making it a potential target for unauthorized access.
+
+42
+00:03:26,000 --> 00:03:31,000
+Proper inventory management should include not just tracking the existence of such endpoints, but also
+
+43
+00:03:31,000 --> 00:03:35,000
+ensuring they are properly secured or removed if no longer needed.
+
+44
+00:03:36,000 --> 00:03:38,000
+And you may think so what?
+
+45
+00:03:38,000 --> 00:03:45,000
+How is the information about the server, its operating system or recent logs may harm the application
+
+46
+00:03:45,000 --> 00:03:47,000
+or impact the business.
+
+47
+00:03:48,000 --> 00:03:55,000
+I have huge experience in IT consultancy and sometimes I was involved on stages when it is already too
+
+48
+00:03:55,000 --> 00:03:56,000
+late to change something.
+
+49
+00:03:57,000 --> 00:04:01,000
+So I clearly realise the potential impact of this vulnerability.
+
+50
+00:04:02,000 --> 00:04:03,000
+Let me elaborate on it.
+
+51
+00:04:04,000 --> 00:04:10,000
+Details about the server and application environment such as the operating system, Java version and
+
+52
+00:04:10,000 --> 00:04:15,000
+JVM arguments provide attackers with valuable insights.
+
+53
+00:04:15,000 --> 00:04:21,000
+With this information, they can identify potential vulnerabilities associated with specific versions
+
+54
+00:04:21,000 --> 00:04:23,000
+or configurations.
+
+55
+00:04:23,000 --> 00:04:29,000
+For example, if the exposed Java version has known vulnerabilities, attackers might use this knowledge
+
+56
+00:04:29,000 --> 00:04:33,000
+to craft targeted attacks exploiting those weaknesses.
+
+57
+00:04:33,000 --> 00:04:37,000
+Access to application logs can reveal more than just error messages.
+
+58
+00:04:38,000 --> 00:04:43,000
+Logs may contain details about application behavior, error patterns, or even hints about underlying
+
+59
+00:04:43,000 --> 00:04:44,000
+vulnerabilities.
+
+60
+00:04:45,000 --> 00:04:50,000
+Attackers can analyze these logs to understand how the application operates and locate potential security
+
+61
+00:04:50,000 --> 00:04:52,000
+flaws that can be exploited.
+
+62
+00:04:53,000 --> 00:04:59,000
+Knowing the internal workings of a system, including configurations and runtime information, allows
+
+63
+00:04:59,000 --> 00:05:03,000
+attackers to tailor their attacks more precisely.
+
+64
+00:05:03,000 --> 00:05:10,000
+For instance, if an attacker learns that certain debugging features are enabled, or that specific
+
+65
+00:05:10,000 --> 00:05:17,000
+configurations are used, they can design attacks that specifically target those configurations, bypassing
+
+66
+00:05:17,000 --> 00:05:19,000
+general security measures.
+
+67
+00:05:20,000 --> 00:05:25,000
+Exposure of sensitive information can lead to significant reputational damage.
+
+68
+00:05:25,000 --> 00:05:32,000
+If customers or stakeholders learn that an organization's security practices are weak, it can erode
+
+69
+00:05:32,000 --> 00:05:35,000
+trust and damage the organization's public image.
+
+70
+00:05:35,000 --> 00:05:42,000
+This could have long term consequences, including loss of customer confidence and potential financial
+
+71
+00:05:42,000 --> 00:05:43,000
+impacts.
+
+72
+00:05:43,000 --> 00:05:50,000
+Depending on the nature of the exposed information and the jurisdiction, there may be legal and regulatory
+
+73
+00:05:50,000 --> 00:05:51,000
+implications.
+
+74
+00:05:51,000 --> 00:05:59,000
+Organizations are often required to protect sensitive data and ensure that such information is not inadvertently
+
+75
+00:05:59,000 --> 00:06:00,000
+exposed.
+
+76
+00:06:00,000 --> 00:06:07,000
+Failure to do so can result in legal penalties, fines, or sanctions, especially if the exposure violates
+
+77
+00:06:07,000 --> 00:06:12,000
+data protection regulations like GDPR or CcpA.
+
+78
+00:06:13,000 --> 00:06:18,000
+So while the problem debugging for servlet might have been created with good intentions for ease of
+
+79
+00:06:18,000 --> 00:06:19,000
+debugging.
+
+80
+00:06:19,000 --> 00:06:23,000
+It demonstrates a classic example of improper inventory management.
+
+81
+00:06:24,000 --> 00:06:30,000
+The presence of deprecated or unnecessary endpoints in a production environment, combined with the
+
+82
+00:06:30,000 --> 00:06:35,000
+exposure of sensitive information, highlights significant security concerns.
+
+83
+00:06:36,000 --> 00:06:42,000
+Proper inventory management involves not only keeping track of all APIs and endpoints, but also ensuring
+
+84
+00:06:42,000 --> 00:06:48,000
+that any deprecated or sensitive ones are adequately protected or removed to avoid potential misuse.
+
+85
+00:06:49,000 --> 00:06:55,000
+Understanding these aspects of security helps in creating more secure systems and avoiding common pitfalls
+
+86
+00:06:55,000 --> 00:06:58,000
+that can lead to data breaches or system compromises.
+
+87
+00:06:58,000 --> 00:07:04,000
+Always ensure that your inventory is up to date, and that all endpoints are appropriately secured to
+
+88
+00:07:04,000 --> 00:07:07,000
+maintain a strong security posture.
+
+89
+00:07:07,000 --> 00:07:14,000
+And now let's examine an updated version of a servlet designed to handle sensitive debugging information.
+
+90
+00:07:15,000 --> 00:07:21,000
+Our focus will be on how this improved code addresses issues related to improper inventory management.
+
+91
+00:07:22,000 --> 00:07:27,000
+Let's begin by understanding the context and purpose of the solution.
+
+92
+00:07:27,000 --> 00:07:29,000
+Secure debug info servlet.
+
+93
+00:07:30,000 --> 00:07:36,000
+This servlet is an enhancement of the previous problem debug info servlet, which had significant security
+
+94
+00:07:36,000 --> 00:07:39,000
+issues due to improper access control.
+
+95
+00:07:40,000 --> 00:07:46,000
+Now let's look at the updated servlet code and see how it fixes these issues.
+
+96
+00:07:47,000 --> 00:07:53,000
+The Secure Debug Info servlet is designed to provide debugging information in a controlled and secure
+
+97
+00:07:53,000 --> 00:07:56,000
+manner, unlike its predecessor.
+
+98
+00:07:56,000 --> 00:08:00,000
+This servlet includes several important security measures.
+
+99
+00:08:00,000 --> 00:08:06,000
+When a request is made to this servlet, the first thing it does is check for an existing session with
+
+100
+00:08:06,000 --> 00:08:08,000
+request get session method.
+
+101
+00:08:09,000 --> 00:08:15,000
+This ensures that if there is no session or if it's an unauthorized session, the servlet will immediately
+
+102
+00:08:15,000 --> 00:08:22,000
+respond with a 401 unauthorized status and a message indicating that access is not permitted.
+
+103
+00:08:23,000 --> 00:08:28,000
+This is a crucial improvement because it prevents unauthorized users from even reaching the point where
+
+104
+00:08:28,000 --> 00:08:30,000
+sensitive information is exposed.
+
+105
+00:08:30,000 --> 00:08:36,000
+Following this, the servlet further verifies that the authenticated user has the appropriate role.
+
+106
+00:08:37,000 --> 00:08:41,000
+In this case, it checks if the user's role is admin.
+
+107
+00:08:41,000 --> 00:08:47,000
+If the user does not have the admin role, the servlet responds with a 403 forbidden status.
+
+108
+00:08:48,000 --> 00:08:54,000
+This role based access control ensures that only users with the right privileges can access sensitive
+
+109
+00:08:54,000 --> 00:09:00,000
+debugging information, thereby significantly reducing the risk of unauthorized access.
+
+110
+00:09:01,000 --> 00:09:08,000
+Once these checks are passed, the servlet proceeds to provide minimal and sanitized debugging information.
+
+111
+00:09:08,000 --> 00:09:15,000
+It only includes general server information and indicates that detailed logs are restricted.
+
+112
+00:09:15,000 --> 00:09:22,000
+This approach minimizes the risk of exposing critical server details that could be exploited if they
+
+113
+00:09:22,000 --> 00:09:29,000
+were revealed To summarize the solutions, secure debugging for serverless addresses the vulnerabilities
+
+114
+00:09:29,000 --> 00:09:35,000
+present in the previous version by implementing robust authentication and authorization checks.
+
+115
+00:09:35,000 --> 00:09:41,000
+It restricts access based on user roles and provides only necessary and sanitized information.
+
+116
+00:09:42,000 --> 00:09:49,000
+This not only secures the debugging endpoint, but also demonstrates best practices for managing sensitive
+
+117
+00:09:49,000 --> 00:09:54,000
+information and mitigating risks associated with improper inventory management.
+
+118
+00:09:55,000 --> 00:10:01,000
+By incorporating these security measures, this service shows how to properly manage and protect sensitive
+
+119
+00:10:01,000 --> 00:10:08,000
+endpoints in your applications and thus mitigate improper inventory management vulnerability.
+
+120
+00:10:08,000 --> 00:10:15,000
+This is a critical aspect of API and application security, and understanding these concepts is essential
+
+121
+00:10:15,000 --> 00:10:17,000
+for developing secure systems.
+
+122
+00:10:18,000 --> 00:10:21,000
+That's all what I wanted to share with you in this lesson.
+
+123
+00:10:21,000 --> 00:10:24,000
+Let's recap what we have learned from the lesson.
+
+124
+00:10:25,000 --> 00:10:32,000
+We began by defining API inventory management and understanding its importance in maintaining a secure
+
+125
+00:10:32,000 --> 00:10:33,000
+and functional system.
+
+126
+00:10:34,000 --> 00:10:41,000
+We explored common challenges associated with managing API inventories and how they can impact overall
+
+127
+00:10:41,000 --> 00:10:42,000
+security.
+
+128
+00:10:42,000 --> 00:10:48,000
+We examined the critical roles that proper inventory management plays in enhancing API security.
+
+129
+00:10:48,000 --> 00:10:54,000
+We discussed key risks, including the exploitation of vulnerabilities, amplification of risks, and
+
+130
+00:10:54,000 --> 00:10:56,000
+issues with cross compatibility.
+
+131
+00:10:56,000 --> 00:11:02,000
+We reviewed real world examples of security breaches caused by poor inventory management to see these
+
+132
+00:11:02,000 --> 00:11:03,000
+issues in action.
+
+133
+00:11:03,000 --> 00:11:09,000
+We analyze the challenges posed by legacy APIs, including the need to balance backward compatibility
+
+134
+00:11:09,000 --> 00:11:11,000
+with modern security practices.
+
+135
+00:11:12,000 --> 00:11:18,000
+Lastly, we explored effective strategies for API inventory management and reviewed a practical example
+
+136
+00:11:18,000 --> 00:11:21,000
+to illustrate both the problems and solutions.
+
+137
+00:11:22,000 --> 00:11:24,000
+Thank you all for your attention.
+
+138
+00:11:24,000 --> 00:11:27,000
+Have a great day and see you in the next lesson.
+
diff --git a/74 - OWASP API Security Top 10 2023/020 Source-code-examples-from-the-lesson.url b/74 - OWASP API Security Top 10 2023/020 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..e9f4049abd29ab017cfce87e4f052e38d26170fd
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/020 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/iim
\ No newline at end of file
diff --git a/74 - OWASP API Security Top 10 2023/021 API102023 Unsafe Consumption of APIs - Part 1_en.srt b/74 - OWASP API Security Top 10 2023/021 API102023 Unsafe Consumption of APIs - Part 1_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..58be41a10c241256a0b8bde1d7c6bdef05ec1683
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/021 API102023 Unsafe Consumption of APIs - Part 1_en.srt
@@ -0,0 +1,1436 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:11,000
+In this lesson we will learn how to avoid unsafe consumption of APIs.
+
+3
+00:00:11,000 --> 00:00:14,000
+So here's what we'll be covering today.
+
+4
+00:00:14,000 --> 00:00:20,000
+We will start by defining the concept of unsafe API consumption and explaining why it's important to
+
+5
+00:00:20,000 --> 00:00:21,000
+address this issue.
+
+6
+00:00:22,000 --> 00:00:28,000
+I'll clarify some common misconceptions about API security to ensure we're on the same page.
+
+7
+00:00:28,000 --> 00:00:35,000
+Then we'll dive into understanding why APIs are inherently vulnerable, focusing on the key vulnerabilities
+
+8
+00:00:35,000 --> 00:00:37,000
+that make them susceptible to attacks.
+
+9
+00:00:37,000 --> 00:00:43,000
+We'll explore the main risks associated with unsafe API consumption, highlighting the potential impact
+
+10
+00:00:43,000 --> 00:00:45,000
+on your applications and data.
+
+11
+00:00:45,000 --> 00:00:51,000
+To make it more tangible, we'll review real world examples and case studies that illustrate these vulnerabilities
+
+12
+00:00:51,000 --> 00:00:52,000
+in action.
+
+13
+00:00:52,000 --> 00:00:58,000
+Next, we'll discuss how to identify unsafe API consumption vulnerabilities.
+
+14
+00:00:58,000 --> 00:01:04,000
+I'll provide you with practical tips and techniques for spotting these issues before they become problems.
+
+15
+00:01:04,000 --> 00:01:10,000
+Following that, we'll delve into effective mitigation strategies to protect your APIs and minimise
+
+16
+00:01:10,000 --> 00:01:11,000
+risks.
+
+17
+00:01:11,000 --> 00:01:17,000
+We'll wrap up the lesson with a discussion on best practices for secure API consumption.
+
+18
+00:01:17,000 --> 00:01:23,000
+Finally, I'll present a practical example of source code comparing a problematic implementation with
+
+19
+00:01:23,000 --> 00:01:29,000
+a secure solution to illustrate how to address and fix these issues in your own projects.
+
+20
+00:01:29,000 --> 00:01:34,000
+Let's get started on making your APIs safer and more secure.
+
+21
+00:01:35,000 --> 00:01:42,000
+In today's lecture, we'll delve into a critical component of API security, specifically API ten 2023,
+
+22
+00:01:42,000 --> 00:01:46,000
+which focuses on unsafe consumption of APIs.
+
+23
+00:01:47,000 --> 00:01:54,000
+Understanding this concept is essential for grasping how APIs can be exploited if not properly managed.
+
+24
+00:01:55,000 --> 00:02:00,000
+Firstly, let's define what we mean by unsafe consumption of APIs.
+
+25
+00:02:01,000 --> 00:02:08,000
+This term refers to the risks and vulnerabilities that arise when APIs interact with other APIs or external
+
+26
+00:02:08,000 --> 00:02:11,000
+services without adequate security measures.
+
+27
+00:02:11,000 --> 00:02:17,000
+Essentially, it's about ensuring that your API doesn't inadvertently become a victim of compromised
+
+28
+00:02:17,000 --> 00:02:19,000
+or malicious third party services.
+
+29
+00:02:19,000 --> 00:02:25,000
+This area of concern has gained prominence because APIs are increasingly used to integrate with various
+
+30
+00:02:25,000 --> 00:02:29,000
+external services, making it crucial to handle these interactions securely.
+
+31
+00:02:30,000 --> 00:02:36,000
+To fully appreciate the significance of unsafe API consumption, we must consider why this issue is
+
+32
+00:02:36,000 --> 00:02:38,000
+so important.
+
+33
+00:02:38,000 --> 00:02:44,000
+APIs often facilitate the exchange of sensitive data and operational commands between systems.
+
+34
+00:02:44,000 --> 00:02:52,000
+When these APIs interact with untrusted or insecure external APIs, the risk of data breaches, unauthorized
+
+35
+00:02:52,000 --> 00:02:55,000
+access, or system compromise increases.
+
+36
+00:02:56,000 --> 00:03:02,000
+This is particularly concerning because a vulnerability in one API can potentially cascade into other
+
+37
+00:03:02,000 --> 00:03:05,000
+systems, amplifying the overall risk.
+
+38
+00:03:06,000 --> 00:03:10,000
+Now let's address some common misconceptions about API security.
+
+39
+00:03:11,000 --> 00:03:18,000
+Many developers mistakenly assume that APIs, unlike user facing applications, are inherently secure
+
+40
+00:03:18,000 --> 00:03:21,000
+if they're only accessed programmatically.
+
+41
+00:03:21,000 --> 00:03:28,000
+There is a belief that since APIs are meant to interact with other software components, they are less
+
+42
+00:03:28,000 --> 00:03:31,000
+prone to security issues compared to user interfaces.
+
+43
+00:03:32,000 --> 00:03:34,000
+However, this is a misconception.
+
+44
+00:03:34,000 --> 00:03:41,000
+APIs can be just as vulnerable, if not more so, especially if they are not designed with robust security
+
+45
+00:03:41,000 --> 00:03:42,000
+controls.
+
+46
+00:03:43,000 --> 00:03:46,000
+So why are APIs particularly vulnerable?
+
+47
+00:03:46,000 --> 00:03:49,000
+The core reason lies in the nature and usage.
+
+48
+00:03:50,000 --> 00:03:56,000
+APIs are designed to be versatile and reusable, which means they are often integrated with other services
+
+49
+00:03:56,000 --> 00:03:57,000
+and applications.
+
+50
+00:03:57,000 --> 00:04:04,000
+This interconnectivity, while beneficial for functionality and efficiency, also introduces risks.
+
+51
+00:04:05,000 --> 00:04:13,000
+APIs that blindly trust incoming data or interactions from other APIs without validation and proper
+
+52
+00:04:13,000 --> 00:04:16,000
+security checks can become conduits for malicious activities.
+
+53
+00:04:17,000 --> 00:04:23,000
+Unsafe consumption of APIs highlights the critical need for secure practices when interacting with external
+
+54
+00:04:23,000 --> 00:04:24,000
+services.
+
+55
+00:04:24,000 --> 00:04:29,000
+Understanding this concept is fundamental in developing secure applications and mitigating risks associated
+
+56
+00:04:29,000 --> 00:04:31,000
+with API integration.
+
+57
+00:04:32,000 --> 00:04:38,000
+As we move forward, we'll explore how to identify these vulnerabilities and implement effective security
+
+58
+00:04:38,000 --> 00:04:42,000
+measures to safeguard your APIs and the data they handle.
+
+59
+00:04:43,000 --> 00:04:50,000
+As we continue our exploration of unsafe consumption of APIs, it's essential to examine the key vulnerabilities
+
+60
+00:04:50,000 --> 00:04:54,000
+that can expose an API to significant risks.
+
+61
+00:04:54,000 --> 00:05:01,000
+These vulnerabilities include unencrypted communication channels, lack of input, validation and sanitization,
+
+62
+00:05:01,000 --> 00:05:07,000
+blindly following redirects, resource mismanagement, and absence of timeouts.
+
+63
+00:05:07,000 --> 00:05:14,000
+Each of these factors contributes to potential security weaknesses that can be exploited by attackers.
+
+64
+00:05:14,000 --> 00:05:18,000
+Let's delve into each of these vulnerabilities in more detail.
+
+65
+00:05:19,000 --> 00:05:24,000
+Firstly, let's discuss unencrypted communication channels.
+
+66
+00:05:24,000 --> 00:05:30,000
+APIs often exchange sensitive information such as personal data or authentication tokens.
+
+67
+00:05:30,000 --> 00:05:38,000
+When these communications occur over unencrypted channels such as plain HTTP instead of Https, the
+
+68
+00:05:38,000 --> 00:05:42,000
+data can be intercepted and read by malicious actors.
+
+69
+00:05:42,000 --> 00:05:49,000
+This vulnerability is critical because it compromises the confidentiality and integrity of the data
+
+70
+00:05:49,000 --> 00:05:50,000
+being transmitted.
+
+71
+00:05:50,000 --> 00:05:56,000
+Without encryption, data is exposed to risks such as man in the middle attacks where an attacker intercepts
+
+72
+00:05:56,000 --> 00:05:59,000
+and potentially alters the data in transit.
+
+73
+00:06:00,000 --> 00:06:03,000
+Moving on, we have the lack of input, validation and sanitization.
+
+74
+00:06:03,000 --> 00:06:10,000
+APIs frequently accept data from external sources, and if this data is not properly validated and sanitized,
+
+75
+00:06:10,000 --> 00:06:15,000
+it can lead to various types of attacks, including injection attacks.
+
+76
+00:06:15,000 --> 00:06:22,000
+For example, an attacker might exploit a vulnerability in an API by sending malicious inputs that contains
+
+77
+00:06:22,000 --> 00:06:27,000
+SQL injection payloads, which can compromise the back end database.
+
+78
+00:06:28,000 --> 00:06:34,000
+Proper validation involves checking that input data adheres to expected formats and constraints, while
+
+79
+00:06:35,000 --> 00:06:42,000
+sanitization ensures that any potentially harmful content is removed or neutralized before processing.
+
+80
+00:06:42,000 --> 00:06:47,000
+Another critical vulnerability is blindly following redirects.
+
+81
+00:06:47,000 --> 00:06:54,000
+APIs that automatically follow HTTP redirects from external services can be tricked into sending sensitive
+
+82
+00:06:54,000 --> 00:06:58,000
+information to unintended or malicious destinations.
+
+83
+00:06:58,000 --> 00:07:04,000
+For instance, if an API receives a redirect response from a third party service and follows it without
+
+84
+00:07:04,000 --> 00:07:11,000
+verification, it might unintentionally expose sensitive data to an attacker's server.
+
+85
+00:07:12,000 --> 00:07:18,000
+This vulnerability is dangerous because it can lead to unauthorized access and data breaches if the
+
+86
+00:07:18,000 --> 00:07:21,000
+redirect is manipulated by an attacker.
+
+87
+00:07:22,000 --> 00:07:26,000
+Resource mismanagement is another significant concern.
+
+88
+00:07:26,000 --> 00:07:34,000
+APIs often need to manage resources such as memory, CPU, and bandwidth when processing requests.
+
+89
+00:07:34,000 --> 00:07:40,000
+If an API does not implement proper controls to limit resource usage, it can be susceptible to denial
+
+90
+00:07:40,000 --> 00:07:48,000
+of service attacks where an attacker overwhelms the API with excessive requests or consumes resources
+
+91
+00:07:48,000 --> 00:07:51,000
+in a manner that degrades performance or availability.
+
+92
+00:07:52,000 --> 00:07:57,000
+Effective resource management includes implementing quotas, rate limits, and proper handling of resource
+
+93
+00:07:57,000 --> 00:08:02,000
+intensive operations to prevent abuse and ensure stable API performance.
+
+94
+00:08:02,000 --> 00:08:06,000
+Lastly, the absence of timeouts is a crucial vulnerability.
+
+95
+00:08:07,000 --> 00:08:12,000
+Timeouts are mechanisms that specify how long an API should wait for a response from an external service
+
+96
+00:08:12,000 --> 00:08:16,000
+before giving up and handling the situation gracefully.
+
+97
+00:08:16,000 --> 00:08:22,000
+Without appropriate timeouts, an API can become unresponsive or hang indefinitely while waiting for
+
+98
+00:08:23,000 --> 00:08:23,000
+a response.
+
+99
+00:08:24,000 --> 00:08:31,000
+This not only affects the API's performance, but can also lead to resource exhaustion and degradation
+
+100
+00:08:31,000 --> 00:08:32,000
+of service.
+
+101
+00:08:32,000 --> 00:08:39,000
+Implementing timeouts ensures that API interactions remain efficient and that the system can recover
+
+102
+00:08:39,000 --> 00:08:43,000
+from delays or unresponsive external services.
+
+103
+00:08:44,000 --> 00:08:51,000
+When examining the risks inherent in unsafe API consumption, we need to address three critical areas
+
+104
+00:08:51,000 --> 00:08:58,000
+IRS data, exposure and loss of confidentiality, injection attacks, and denial of service attacks.
+
+105
+00:08:59,000 --> 00:09:05,000
+Each of these risks can have profound implications for the security and functionality of API driven
+
+106
+00:09:05,000 --> 00:09:06,000
+applications.
+
+107
+00:09:07,000 --> 00:09:13,000
+Let us delve into these risks to understand their nature and the measures needed to counteract them.
+
+108
+00:09:14,000 --> 00:09:20,000
+Firstly, data exposure and loss of confidentiality are pivotal concerns in API security.
+
+109
+00:09:21,000 --> 00:09:27,000
+APIs often handle sensitive and confidential information such as personal identifiers, financial data,
+
+110
+00:09:27,000 --> 00:09:30,000
+or confidential business information.
+
+111
+00:09:30,000 --> 00:09:37,000
+If the API fails to encrypt the data during transmission, it becomes vulnerable to interception and
+
+112
+00:09:37,000 --> 00:09:38,000
+unauthorized access.
+
+113
+00:09:39,000 --> 00:09:46,000
+For example, consider an API that transmits user login credentials over an unencrypted HTTP connection.
+
+114
+00:09:47,000 --> 00:09:52,000
+An attacker who can intercept this traffic might easily capture the credentials, leading to potential
+
+115
+00:09:52,000 --> 00:09:54,000
+unauthorized access to user accounts.
+
+116
+00:09:54,000 --> 00:10:00,000
+This breach of confidentiality can undermine the trust between users and the application, leading to
+
+117
+00:10:00,000 --> 00:10:06,000
+reputational damage and legal consequences, especially under regulations such as GDPR or CcpA.
+
+118
+00:10:07,000 --> 00:10:15,000
+To mitigate this risk, it is imperative to use encryption protocols such as Https for all data transmitted
+
+119
+00:10:15,000 --> 00:10:17,000
+between APIs and their clients.
+
+120
+00:10:18,000 --> 00:10:24,000
+Encryption ensures that even if data is intercepted, it remains incomprehensible without the decryption
+
+121
+00:10:24,000 --> 00:10:25,000
+key.
+
+122
+00:10:26,000 --> 00:10:32,000
+Next, injection attacks, including SQL injection present a significant threat.
+
+123
+00:10:32,000 --> 00:10:40,000
+Injection attacks occur when untrusted data is included in a command or query executed by an application,
+
+124
+00:10:40,000 --> 00:10:42,000
+leading to unintended actions.
+
+125
+00:10:43,000 --> 00:10:46,000
+Take SQL injection as an illustrative example.
+
+126
+00:10:47,000 --> 00:10:53,000
+An attacker might submit malicious inputs through an API endpoint designed to accept user data.
+
+127
+00:10:53,000 --> 00:11:00,000
+If the API directly incorporates this input into a SQL query without proper sanitization, the attacker
+
+128
+00:11:00,000 --> 00:11:04,000
+can manipulate the query to execute arbitrary SQL commands.
+
+129
+00:11:05,000 --> 00:11:13,000
+This could result in unauthorized data access, data modification, or even complete database compromise.
+
+130
+00:11:13,000 --> 00:11:20,000
+For instance, an SQL injection attack might allow an attacker to bypass authentication controls or
+
+131
+00:11:20,000 --> 00:11:23,000
+extract sensitive information from the database.
+
+132
+00:11:24,000 --> 00:11:31,000
+To counteract such vulnerabilities, APIs must implement stringent input validation and employ parameterized
+
+133
+00:11:31,000 --> 00:11:37,000
+queries or prepared statements to separate user input from SQL code, thereby neutralizing the risk
+
+134
+00:11:37,000 --> 00:11:38,000
+of injection.
+
+135
+00:11:40,000 --> 00:11:47,000
+Lastly, the denial of service attacks aimed to disrupt the availability of an API by overwhelming it
+
+136
+00:11:47,000 --> 00:11:51,000
+with excessive requests or resource intensive operations.
+
+137
+00:11:52,000 --> 00:11:58,000
+Such attacks can render the API unresponsive, preventing legitimate users from accessing its services.
+
+138
+00:11:59,000 --> 00:12:06,000
+For instance, an attacker might exploit an APIs lack of rate limiting by flooding it with a high volume
+
+139
+00:12:06,000 --> 00:12:07,000
+of requests.
+
+140
+00:12:07,000 --> 00:12:13,000
+This flood of requests can exhaust the APIs resources, such as CPU or memory, leading to degraded
+
+141
+00:12:13,000 --> 00:12:16,000
+performance or complete service outages.
+
+142
+00:12:16,000 --> 00:12:22,000
+To protect against DDoS attacks, it is essential to implement rate limiting and quotas to control the
+
+143
+00:12:22,000 --> 00:12:26,000
+volume of requests an API can handle within a given time frame.
+
+144
+00:12:26,000 --> 00:12:32,000
+Additionally, resource management practices such as setting timeouts and implementing circuit breakers
+
+145
+00:12:32,000 --> 00:12:37,000
+can help maintain API availability even under attack conditions.
+
+146
+00:12:38,000 --> 00:12:45,000
+To concretize our understanding of unsafe API consumption, it is useful to examine real world examples
+
+147
+00:12:45,000 --> 00:12:51,000
+and case studies that highlight how these vulnerabilities can manifest in practice and their consequences.
+
+148
+00:12:52,000 --> 00:12:59,000
+These examples provide insight into the impact of API security weaknesses and the importance of implementing
+
+149
+00:12:59,000 --> 00:13:00,000
+robust protective measures.
+
+150
+00:13:01,000 --> 00:13:05,000
+Real world example log for shell vulnerability.
+
+151
+00:13:06,000 --> 00:13:13,000
+The log for shell vulnerability, discovered in December 2021, stands as one of the most significant
+
+152
+00:13:13,000 --> 00:13:15,000
+security incidents in recent years.
+
+153
+00:13:16,000 --> 00:13:24,000
+This critical flaw found in the Apache log for J login library, had far reaching implications due to
+
+154
+00:13:24,000 --> 00:13:29,000
+the library's widespread use across various web services and applications.
+
+155
+00:13:29,000 --> 00:13:37,000
+At its core, the log for shell vulnerability stemmed from an unsafe API consumption practice within
+
+156
+00:13:37,000 --> 00:13:38,000
+log for J.
+
+157
+00:13:39,000 --> 00:13:45,000
+Specifically, it involved the library's handling of user supplied data without sufficient validation.
+
+158
+00:13:46,000 --> 00:13:53,000
+Log Look for JS login capabilities allowed for the inclusion of dynamic content within log messages,
+
+159
+00:13:53,000 --> 00:13:58,000
+and this feature was exploited through a process known as log injection.
+
+160
+00:13:58,000 --> 00:14:05,000
+The vulnerability arose from Log Forge's capability to deserialize user supplied data.
+
+161
+00:14:05,000 --> 00:14:12,000
+Deserialization is the process of converting data from a format suitable for storage or transmission
+
+162
+00:14:12,000 --> 00:14:15,000
+back into a format suitable for execution.
+
+163
+00:14:15,000 --> 00:14:22,000
+In this case, log for J allowed data to be deserialized without properly checking its integrity or
+
+164
+00:14:22,000 --> 00:14:23,000
+authenticity.
+
+165
+00:14:24,000 --> 00:14:32,000
+Attackers were able to exploit this flaw by sending specially crafted log messages that contained malicious
+
+166
+00:14:32,000 --> 00:14:32,000
+code.
+
+167
+00:14:33,000 --> 00:14:39,000
+When these messages were processed by the Log Forge library, the embedded malicious code was executed
+
+168
+00:14:39,000 --> 00:14:40,000
+on the server.
+
+169
+00:14:41,000 --> 00:14:46,000
+This effectively allowed attackers to run arbitrary code on any system using the vulnerable version
+
+170
+00:14:46,000 --> 00:14:48,000
+of Log4j2.
+
+171
+00:14:49,000 --> 00:14:52,000
+The potential impact of this exploit was enormous.
+
+172
+00:14:52,000 --> 00:14:58,000
+Attackers could gain full control over affected systems, leading to unauthorized access, data breaches,
+
+173
+00:14:58,000 --> 00:15:01,000
+and even further exploitation of connected systems.
+
+174
+00:15:01,000 --> 00:15:07,000
+The vulnerabilities reach extended across numerous sectors, affecting countless organizations globally,
+
+175
+00:15:07,000 --> 00:15:10,000
+from small businesses to large enterprises.
+
+176
+00:15:11,000 --> 00:15:17,000
+The log for shell incident underscored several critical lessons about API security and software development.
+
+177
+00:15:18,000 --> 00:15:24,000
+The vulnerability highlighted the necessity of rigorous input, validation and sanitization practices,
+
+178
+00:15:24,000 --> 00:15:29,000
+especially when dealing with data that could be executed or interpreted by the system.
+
+179
+00:15:29,000 --> 00:15:36,000
+Proper validation can prevent malicious code from being executed, thus protecting against a wide range
+
+180
+00:15:36,000 --> 00:15:37,000
+of potential attacks.
+
+181
+00:15:38,000 --> 00:15:44,000
+The incident brought attention to the risks associated with deserializing data from untrusted Trusted
+
+182
+00:15:44,000 --> 00:15:45,000
+sources.
+
+183
+00:15:45,000 --> 00:15:52,000
+The serialization flaws can be particularly dangerous, as they allow attackers to inject and execute
+
+184
+00:15:52,000 --> 00:15:53,000
+arbitrary code.
+
+185
+00:15:53,000 --> 00:16:00,000
+Ensuring that deserialization processes are secure and well validated is crucial in preventing such
+
+186
+00:16:00,000 --> 00:16:01,000
+vulnerabilities.
+
+187
+00:16:02,000 --> 00:16:09,000
+The log for shell vulnerability also demonstrated how vulnerabilities in widely used libraries can have
+
+188
+00:16:09,000 --> 00:16:16,000
+a global impact, since Log4j2 is a foundational component in many applications.
+
+189
+00:16:16,000 --> 00:16:23,000
+A flaw in this library could compromise countless systems, illustrating the importance of maintaining
+
+190
+00:16:23,000 --> 00:16:25,000
+and updating critical dependencies.
+
+191
+00:16:26,000 --> 00:16:33,000
+The swift identification, response, and patching of vulnerabilities are essential following the discovery
+
+192
+00:16:33,000 --> 00:16:34,000
+of log for shell.
+
+193
+00:16:34,000 --> 00:16:41,000
+A rapid response was required to mitigate the risk, with organizations worldwide scrambling to update
+
+194
+00:16:41,000 --> 00:16:44,000
+their systems to secure versions of log for J.
+
+195
+00:16:45,000 --> 00:16:51,000
+Let us consider an example where an API is designed to integrate with a third party service provider
+
+196
+00:16:51,000 --> 00:16:55,000
+for securely storing sensitive user medical information.
+
+197
+00:16:55,000 --> 00:16:59,000
+In this scenario, an API request might look something like.
+
+198
+00:16:59,000 --> 00:17:01,000
+You can see on the slide.
+
+199
+00:17:01,000 --> 00:17:08,000
+In an ideal world, this request is sent over a secure channel, ensuring that the data, such as a
+
+200
+00:17:08,000 --> 00:17:12,000
+user's genome information, is transmitted confidentially.
+
+201
+00:17:12,000 --> 00:17:17,000
+However, if the third party API has been compromised, it can introduce significant vulnerabilities.
+
+202
+00:17:18,000 --> 00:17:25,000
+Imagine the third party API is exploited and starts issuing HTTP 308 permanent redirect responses,
+
+203
+00:17:25,000 --> 00:17:26,000
+for example.
+
+204
+00:17:26,000 --> 00:17:33,000
+The response might contain 308 response status code and contain header location that will redirect request
+
+205
+00:17:33,000 --> 00:17:34,000
+to attacker.
+
+206
+00:17:34,000 --> 00:17:34,000
+Com.
+
+207
+00:17:35,000 --> 00:17:41,000
+The issue arises when the integrating API blindly follows this redirect instruction without validating
+
+208
+00:17:41,000 --> 00:17:42,000
+the destination.
+
+209
+00:17:43,000 --> 00:17:49,000
+As a result, the original request, which includes sensitive user data, is forwarded to an attacker
+
+210
+00:17:49,000 --> 00:17:50,000
+controlled server.
+
+211
+00:17:51,000 --> 00:17:56,000
+This is a classic example of a man in the middle attack, where the attacker intercepts and redirects
+
+212
+00:17:56,000 --> 00:18:03,000
+sensitive data to their own server, thus compromising data confidentiality and integrity.
+
+213
+00:18:04,000 --> 00:18:08,000
+In another scenario, let's examine a situation involving SQL injection.
+
+214
+00:18:09,000 --> 00:18:14,000
+Consider a web application that interacts with a repository through a third party service.
+
+215
+00:18:14,000 --> 00:18:20,000
+An attacker could exploit this by creating a malicious repository with a name designed to execute SQL
+
+216
+00:18:20,000 --> 00:18:21,000
+commands.
+
+217
+00:18:21,000 --> 00:18:24,000
+For instance drop db.
+
+218
+00:18:24,000 --> 00:18:30,000
+Pay attention that the syntax and if you are familiar with SQL syntax, you already may understand how
+
+219
+00:18:30,000 --> 00:18:32,000
+this can be injected into the SQL query.
+
+220
+00:18:33,000 --> 00:18:38,000
+When this malicious repository name is integrated into the application, the application builds an SQL
+
+221
+00:18:38,000 --> 00:18:41,000
+query to interact with its database.
+
+222
+00:18:41,000 --> 00:18:43,000
+Assuming the repository name is safe.
+
+223
+00:18:44,000 --> 00:18:49,000
+If the application does not adequately validate or sanitize this input, the injected SQL commands are
+
+224
+00:18:49,000 --> 00:18:51,000
+executed directly on the database.
+
+225
+00:18:52,000 --> 00:18:53,000
+Here's what happens in detail.
+
+226
+00:18:54,000 --> 00:18:59,000
+The attacker crafts the repository name to include SQL commands.
+
+227
+00:18:59,000 --> 00:19:06,000
+In this case, drop db is designed to terminate the current SQL command and insert a new one that drops
+
+228
+00:19:06,000 --> 00:19:08,000
+deletes the database.
+
+229
+00:19:09,000 --> 00:19:15,000
+The application incorporates this untrusted input into an SQL query without proper validation.
+
+230
+00:19:15,000 --> 00:19:22,000
+For instance, if the query was initially something like select all from repositories where name is
+
+231
+00:19:22,000 --> 00:19:29,000
+equal to malicious repo, the attacker's input transforms it into the query that you can see on the
+
+232
+00:19:29,000 --> 00:19:33,000
+slide, and the query will contain drop db statement.
+
+233
+00:19:34,000 --> 00:19:41,000
+The SQL command drop db is executed, leading to the destruction of the entire database.
+
+234
+00:19:41,000 --> 00:19:50,000
+The command ensures that the rest of the query is ignored, preventing syntax errors when it comes to
+
+235
+00:19:50,000 --> 00:19:51,000
+securing APIs.
+
+236
+00:19:51,000 --> 00:19:56,000
+One of the critical aspects is recognizing unsafe consumption vulnerabilities.
+
+237
+00:19:56,000 --> 00:20:01,000
+These vulnerabilities can leave your application exposed to a range of security threats.
+
+238
+00:20:01,000 --> 00:20:06,000
+Let's delve into how to effectively identify these risks.
+
+239
+00:20:07,000 --> 00:20:13,000
+The first indicator of unsafe API consumption is the use of unencrypted communication channels.
+
+240
+00:20:14,000 --> 00:20:20,000
+To spot this vulnerability, you should check if the API interactions are taking place over Https rather
+
+241
+00:20:20,000 --> 00:20:21,000
+than HTTP.
+
+242
+00:20:22,000 --> 00:20:28,000
+Https encrypts the data transmitted between the client and the server, protecting it from eavesdroppers.
+
+243
+00:20:28,000 --> 00:20:30,000
+Here's how you can assess this.
+
+244
+00:20:30,000 --> 00:20:35,000
+Ensure that the documentation specifies the use of Https for all endpoints.
+
+245
+00:20:35,000 --> 00:20:41,000
+Use tools like Wireshark or browser developer tools to verify that requests and responses are encrypted.
+
+246
+00:20:42,000 --> 00:20:47,000
+Verify server and API configurations to ensure that only encrypted connections are allowed.
+
+247
+00:20:48,000 --> 00:20:54,000
+Another crucial vulnerability is the lack of proper input, validation and sanitization.
+
+248
+00:20:54,000 --> 00:20:56,000
+To identify this issue.
+
+249
+00:20:56,000 --> 00:21:01,000
+Look for places in the code where input data is received and processed.
+
+250
+00:21:01,000 --> 00:21:08,000
+Ensure that there are validation mechanisms in place to check for acceptable data formats and values.
+
+251
+00:21:08,000 --> 00:21:15,000
+Perform tests using various types of malformed or unexpected inputs to see if the API can handle them
+
+252
+00:21:15,000 --> 00:21:16,000
+gracefully.
+
+253
+00:21:17,000 --> 00:21:22,000
+For example, input and SQL injection payloads to check for vulnerabilities.
+
+254
+00:21:23,000 --> 00:21:30,000
+Check logs for errors that indicate the API is processing inputs incorrectly or failing to sanitize
+
+255
+00:21:30,000 --> 00:21:31,000
+data before use.
+
+256
+00:21:32,000 --> 00:21:38,000
+APIs that follow redirects without proper validation can be vulnerable to attacks.
+
+257
+00:21:38,000 --> 00:21:40,000
+Here's how to spot this issue.
+
+258
+00:21:41,000 --> 00:21:50,000
+Inspect how the API handles redirection responses, particularly those involving three x HTTP status
+
+259
+00:21:50,000 --> 00:21:50,000
+codes.
+
+260
+00:21:51,000 --> 00:21:56,000
+Ensures that the API validates and restricts where redirects can point to.
+
+261
+00:21:56,000 --> 00:22:03,000
+Review the API settings to ensure there are controls in place to limit redirect destinations to trusted
+
+262
+00:22:03,000 --> 00:22:04,000
+sources.
+
+263
+00:22:05,000 --> 00:22:11,000
+Perform security audits to identify any potential redirection vulnerabilities that could be exploited
+
+264
+00:22:11,000 --> 00:22:12,000
+by malicious actors.
+
+265
+00:22:13,000 --> 00:22:20,000
+Resource mismanagement involves improper handling of API resources such as unregulated access or resource
+
+266
+00:22:20,000 --> 00:22:21,000
+exhaustion.
+
+267
+00:22:22,000 --> 00:22:28,000
+To detect this vulnerability, ensure that the API has appropriate rate limits and quotas to prevent
+
+268
+00:22:28,000 --> 00:22:31,000
+abuse and overuse of resources.
+
+269
+00:22:32,000 --> 00:22:38,000
+Verify that the API enforces limits on resource allocation to prevent scenarios where an API consumes
+
+270
+00:22:38,000 --> 00:22:46,000
+excessive resources, continuously monitor API usage patterns for unusual spikes or patterns that may
+
+271
+00:22:46,000 --> 00:22:48,000
+indicate resource mismanagement.
+
+272
+00:22:48,000 --> 00:22:54,000
+Absence of timeouts can lead to API calls hanging indefinitely, which may cause denial of service.
+
+273
+00:22:55,000 --> 00:22:58,000
+To identify this issue, review API timeout settings.
+
+274
+00:22:58,000 --> 00:23:02,000
+Check the APIs configuration for timeout settings on requests and responses.
+
+275
+00:23:02,000 --> 00:23:06,000
+Ensure that appropriate timeouts are set to prevent indefinite hangs.
+
+276
+00:23:07,000 --> 00:23:14,000
+Test API behavior conduct load testing to see how the API behaves when subjected to high traffic or
+
+277
+00:23:14,000 --> 00:23:17,000
+slow responses from external services.
+
+278
+00:23:18,000 --> 00:23:19,000
+Inspect error handling.
+
+279
+00:23:20,000 --> 00:23:26,000
+Ensure that the API has mechanisms to handle timeout errors gracefully, and does not leave processes
+
+280
+00:23:26,000 --> 00:23:27,000
+in an unstable state.
+
+281
+00:23:29,000 --> 00:23:35,000
+As we delve into the topic of mitigating unsafe API consumption vulnerabilities, it is essential to
+
+282
+00:23:35,000 --> 00:23:40,000
+understand and apply effective strategies to safeguard your applications.
+
+283
+00:23:41,000 --> 00:23:47,000
+We will explore five critical mitigation strategies that, when properly implemented, can significantly
+
+284
+00:23:47,000 --> 00:23:50,000
+enhance the security of your APIs.
+
+285
+00:23:51,000 --> 00:23:57,000
+To begin with, ensuring secure communications through Transport Layer Security, TLS is fundamental.
+
+286
+00:23:58,000 --> 00:24:03,000
+TLS encrypts the data transmitted between clients and servers, which is crucial in protecting sensitive
+
+287
+00:24:03,000 --> 00:24:07,000
+information from being intercepted or tampered with by malicious actors.
+
+288
+00:24:07,000 --> 00:24:13,000
+Therefore, you must ensure that all API interactions are conducted over Https rather than HTTP.
+
+289
+00:24:13,000 --> 00:24:19,000
+By implementing TLS, you not only protect the confidentiality and integrity of the data in transit,
+
+290
+00:24:19,000 --> 00:24:23,000
+but also establish trustworthiness in your API communications.
+
+291
+00:24:24,000 --> 00:24:31,000
+Ensure that your server configurations enforce TLS for all endpoints, and regularly update your TLS
+
+292
+00:24:31,000 --> 00:24:34,000
+certificates to maintain strong encryption standards.
+
+293
+00:24:35,000 --> 00:24:42,000
+Next, validating and sanitizing data received from external sources is imperative to prevent security
+
+294
+00:24:42,000 --> 00:24:45,000
+vulnerabilities such as injection attacks.
+
+295
+00:24:45,000 --> 00:24:52,000
+Validation involves checking that the input data conforms to expected formats and constraints, while
+
+296
+00:24:52,000 --> 00:24:57,000
+sanitization involves cleaning the data to remove any harmful content.
+
+297
+00:24:58,000 --> 00:25:05,000
+To implement this, incorporate robust input validation rules within your API endpoints and apply consistent
+
+298
+00:25:05,000 --> 00:25:07,000
+data sanitization processes.
+
+299
+00:25:08,000 --> 00:25:15,000
+By doing so, you ensure that any data processed by your application is safe and conforms to predefined
+
+300
+00:25:15,000 --> 00:25:20,000
+criteria, thus mitigating risks associated with malicious inputs.
+
+301
+00:25:21,000 --> 00:25:27,000
+Moving on managing API redirects appropriately is crucial to prevent redirect based attacks.
+
+302
+00:25:28,000 --> 00:25:35,000
+In particular, APIs that blindly follow redirects from third party services can be exploited to redirect
+
+303
+00:25:35,000 --> 00:25:38,000
+sensitive data to unauthorized destinations.
+
+304
+00:25:39,000 --> 00:25:45,000
+To mitigate this risk, you should enforce strict controls on allowable redirect destinations.
+
+305
+00:25:45,000 --> 00:25:52,000
+This means implementing a whitelist of trusted redirect locations and validating any redirection responses
+
+306
+00:25:52,000 --> 00:25:53,000
+before processing them.
+
+307
+00:25:54,000 --> 00:26:00,000
+By managing redirects carefully, you reduce the risk of inadvertently exposing sensitive information
+
+308
+00:26:00,000 --> 00:26:01,000
+to malicious entities.
+
+309
+00:26:02,000 --> 00:26:08,000
+In addition, resource limitation and timeout implementation are vital for protecting your API from
+
+310
+00:26:08,000 --> 00:26:11,000
+abuse and potential denial of service attacks.
+
+311
+00:26:12,000 --> 00:26:18,000
+Resource limitation involves setting quotas and rate limits to prevent excessive consumption of system
+
+312
+00:26:18,000 --> 00:26:21,000
+resources by any single user or process.
+
+313
+00:26:22,000 --> 00:26:30,000
+Similarly, implementing timeouts ensures that API requests that take too long are terminated, preventing
+
+314
+00:26:30,000 --> 00:26:33,000
+them from hanging indefinitely and affecting system performance.
+
+315
+00:26:34,000 --> 00:26:39,000
+By configuring these limits and timeouts, you can maintain the stability and availability of your API
+
+316
+00:26:39,000 --> 00:26:42,000
+while defending against resource exhaustion attacks.
+
+317
+00:26:43,000 --> 00:26:49,000
+Finally, evaluating third party APIs is a key strategy to ensure that the APIs you integrate with do
+
+318
+00:26:49,000 --> 00:26:52,000
+not introduce vulnerabilities into your own systems.
+
+319
+00:26:53,000 --> 00:27:00,000
+This involves conducting thorough security assessments of the third party APIs, including reviewing
+
+320
+00:27:00,000 --> 00:27:07,000
+the security practices, conducting vulnerability scans, and ensuring that they adhere to your security
+
+321
+00:27:07,000 --> 00:27:08,000
+requirements.
+
+322
+00:27:08,000 --> 00:27:16,000
+By rigorously evaluating and monitoring third party APIs, you mitigate the risks associated with integrating
+
+323
+00:27:16,000 --> 00:27:20,000
+external services and ensure that they meet your security standards.
+
+324
+00:27:22,000 --> 00:27:28,000
+When it comes to securing APIs and ensuring their integrity, following best practices is essential
+
+325
+00:27:28,000 --> 00:27:31,000
+for maintaining a robust security posture.
+
+326
+00:27:32,000 --> 00:27:39,000
+In this segment, we will discuss three fundamental best practices for creating and using security checklists,
+
+327
+00:27:39,000 --> 00:27:45,000
+integrating security into the API development lifecycle, and conducting regular security audits and
+
+328
+00:27:45,000 --> 00:27:46,000
+monitoring.
+
+329
+00:27:47,000 --> 00:27:53,000
+To begin with, creating and using security checklists is a proactive approach to ensure that all necessary
+
+330
+00:27:53,000 --> 00:27:55,000
+security measures are in place.
+
+331
+00:27:56,000 --> 00:28:03,000
+A security checklist is a comprehensive document that outlines the essential security controls and practices
+
+332
+00:28:03,000 --> 00:28:07,000
+that must be implemented throughout the API development process.
+
+333
+00:28:07,000 --> 00:28:14,000
+This checklist should include items such as proper authentication mechanisms, secure data transmission
+
+334
+00:28:14,000 --> 00:28:19,000
+protocols, input validation requirements, and protection against common vulnerabilities.
+
+335
+00:28:20,000 --> 00:28:25,000
+By systematically following this checklist, development teams can ensure that no critical security
+
+336
+00:28:25,000 --> 00:28:27,000
+aspects are overlooked.
+
+337
+00:28:27,000 --> 00:28:33,000
+Additionally, regularly updating the checklist to reflect new security threats and industry best practices
+
+338
+00:28:33,000 --> 00:28:40,000
+ensures that your API security measures remain current and effective moving forward.
+
+339
+00:28:40,000 --> 00:28:45,000
+Integrating security into the API development life cycle is a crucial practice for embedding security
+
+340
+00:28:45,000 --> 00:28:49,000
+measures from the outset of the development process.
+
+341
+00:28:49,000 --> 00:28:56,000
+This means incorporating security considerations at every stage, from design and development to testing
+
+342
+00:28:56,000 --> 00:28:57,000
+and deployment.
+
+343
+00:28:58,000 --> 00:29:04,000
+During the design phase ensures that security requirements are defined and addressed in the development
+
+344
+00:29:04,000 --> 00:29:08,000
+phase, implement secure coding practices and perform regular code reviews.
+
+345
+00:29:09,000 --> 00:29:15,000
+During testing, conduct security assessments such as penetration testing and vulnerability scanning.
+
+346
+00:29:16,000 --> 00:29:24,000
+By embedding security into the API development life cycle, you adopt a shift left approach where security
+
+347
+00:29:24,000 --> 00:29:31,000
+is considered early and continuously throughout the development process, rather than as an After sort.
+
+348
+00:29:31,000 --> 00:29:38,000
+Finally, regular security audits and monitoring are essential for maintaining the ongoing security
+
+349
+00:29:38,000 --> 00:29:39,000
+of your APIs.
+
+350
+00:29:40,000 --> 00:29:46,000
+Security audits involve systematic evaluations of your APIs, security controls, and configurations
+
+351
+00:29:46,000 --> 00:29:50,000
+to identify any vulnerabilities or weaknesses.
+
+352
+00:29:50,000 --> 00:29:56,000
+These audits should be performed periodically, as well as after significant changes to the API or its
+
+353
+00:29:56,000 --> 00:29:57,000
+environment.
+
+354
+00:29:58,000 --> 00:30:04,000
+Monitoring, on the other hand, involves continuously tracking API activity to detect and respond to
+
+355
+00:30:04,000 --> 00:30:07,000
+potential security incidents in real time.
+
+356
+00:30:08,000 --> 00:30:15,000
+This includes implementing logging and alerting mechanisms to monitor for unusual behavior or unauthorized
+
+357
+00:30:15,000 --> 00:30:16,000
+access attempts.
+
+358
+00:30:16,000 --> 00:30:23,000
+By conducting regular audits and maintaining vigilant monitoring, you can proactively address security
+
+359
+00:30:23,000 --> 00:30:26,000
+issues and respond swiftly to any emerging threats
+
diff --git a/74 - OWASP API Security Top 10 2023/022 API102023 Unsafe Consumption of APIs - Part 2 (Practice)_en.srt b/74 - OWASP API Security Top 10 2023/022 API102023 Unsafe Consumption of APIs - Part 2 (Practice)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..690a48b88bdc7d86f744307b4f6ec90c2bf80157
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/022 API102023 Unsafe Consumption of APIs - Part 2 (Practice)_en.srt
@@ -0,0 +1,444 @@
+1
+00:00:04,000 --> 00:00:06,000
+Let's review source code examples.
+
+2
+00:00:06,000 --> 00:00:11,000
+Now we'll review source code of the problem and then we will review solution.
+
+3
+00:00:12,000 --> 00:00:16,000
+As always you can find all source code examples in attachments to the lesson.
+
+4
+00:00:17,000 --> 00:00:21,000
+In case during the explanation something will be not clear for you.
+
+5
+00:00:21,000 --> 00:00:27,000
+Or in case you have any questions regarding the example, please don't wait till the end of the lesson.
+
+6
+00:00:27,000 --> 00:00:32,000
+Just post your question below the video and I will be happy to answer.
+
+7
+00:00:32,000 --> 00:00:35,000
+So let's start review the code from the problem statement.
+
+8
+00:00:35,000 --> 00:00:41,000
+And at first, let me give you some context about the example and what this class is supposed to do.
+
+9
+00:00:42,000 --> 00:00:47,000
+This survey is designed to handle payment processing through an external payment gateway.
+
+10
+00:00:47,000 --> 00:00:55,000
+A crucial component for any e-commerce application by enabling customers to make transactions securely.
+
+11
+00:00:55,000 --> 00:01:02,000
+The survey plays a key role in the overall user experience and trustworthiness of the online store.
+
+12
+00:01:03,000 --> 00:01:09,000
+Let's dive into the code and examine it line by line, explaining its functionality and identifying
+
+13
+00:01:09,000 --> 00:01:11,000
+potential vulnerabilities along the way.
+
+14
+00:01:12,000 --> 00:01:15,000
+The Dopost method will handle post requests made to the servlet.
+
+15
+00:01:16,000 --> 00:01:21,000
+We retrieve the payment data from the incoming request using request Getparameter method.
+
+16
+00:01:21,000 --> 00:01:24,000
+This data is expected to contain sensitive payment information.
+
+17
+00:01:25,000 --> 00:01:30,000
+We also define the URL of the payment gateway where we will send this data.
+
+18
+00:01:30,000 --> 00:01:36,000
+Of course, this URL may be stored in your properties or outside of the class, but for the sake of
+
+19
+00:01:36,000 --> 00:01:39,000
+example, I will keep everything in one class.
+
+20
+00:01:40,000 --> 00:01:43,000
+Next, we establish a connection to the payment gateway.
+
+21
+00:01:43,000 --> 00:01:50,000
+We create a URL object from the API url and open an http url connection.
+
+22
+00:01:50,000 --> 00:01:55,000
+We set the request method to post and indicate that we intend to send data.
+
+23
+00:01:56,000 --> 00:02:02,000
+The payment data is then sent to the payment gateway by writing it to the output stream.
+
+24
+00:02:03,000 --> 00:02:09,000
+After sending the payment data, we capture the HTTP response code from the payment gateway.
+
+25
+00:02:09,000 --> 00:02:16,000
+This code helps us determine the outcome of our request, for example success, redirection or error.
+
+26
+00:02:17,000 --> 00:02:23,000
+In this conditional block, we check if the response code indicates a redirect, either temporary or
+
+27
+00:02:23,000 --> 00:02:24,000
+permanent.
+
+28
+00:02:24,000 --> 00:02:29,000
+If a redirect is indicated, we retrieve the new location from the response headers.
+
+29
+00:02:30,000 --> 00:02:33,000
+The following lines is where the vulnerability lies.
+
+30
+00:02:34,000 --> 00:02:39,000
+The code constructs a new URL from the redirect location and opens a new connection to it.
+
+31
+00:02:40,000 --> 00:02:41,000
+Without any validation.
+
+32
+00:02:41,000 --> 00:02:45,000
+It blindly follows the redirect and sends the payment data again.
+
+33
+00:02:46,000 --> 00:02:48,000
+This could lead to serious security risks.
+
+34
+00:02:49,000 --> 00:02:53,000
+Then we read the response from the initial connection to the payment gateway.
+
+35
+00:02:54,000 --> 00:02:59,000
+We use a Bufferedreader to process the response line by line and construct a response string.
+
+36
+00:03:00,000 --> 00:03:02,000
+Finally, we send the response back to the client.
+
+37
+00:03:03,000 --> 00:03:07,000
+The servlet writes the accumulated response string to the client's output stream.
+
+38
+00:03:08,000 --> 00:03:13,000
+Now that we have gone through the code, let's discuss the vulnerabilities present in this servlet.
+
+39
+00:03:14,000 --> 00:03:19,000
+The primary vulnerability is the code's ability to follow redirects without any validation.
+
+40
+00:03:20,000 --> 00:03:27,000
+If an attacker can manipulate the redirect response, for instance through a compromised payment gateway,
+
+41
+00:03:28,000 --> 00:03:33,000
+the servlet might send sensitive payment data to an attacker controlled server.
+
+42
+00:03:34,000 --> 00:03:39,000
+The threats arising from this vulnerability include the following ones.
+
+43
+00:03:40,000 --> 00:03:46,000
+Sensitive payment information could be intercepted by attackers, leading to fraud and financial loss.
+
+44
+00:03:46,000 --> 00:03:52,000
+An attacker could redirect payments to their own account, resulting in unauthorized access to funds
+
+45
+00:03:53,000 --> 00:03:56,000
+if customer's payment data is compromised.
+
+46
+00:03:56,000 --> 00:04:01,000
+The e-commerce business could suffer severe reputational harm and loss of customer trust.
+
+47
+00:04:03,000 --> 00:04:09,000
+So while the vulnerable payment servlet serves a critical function in processing payments, it is essential
+
+48
+00:04:09,000 --> 00:04:16,000
+to implement security measures to protect sensitive information by validating redirect URLs and ensuring
+
+49
+00:04:16,000 --> 00:04:19,000
+that only trusted domains are followed.
+
+50
+00:04:19,000 --> 00:04:24,000
+We can significantly mitigate the risks associated with unsafe API consumption.
+
+51
+00:04:25,000 --> 00:04:32,000
+This emphasizes the importance of secure coding practices in safeguarding applications and user data.
+
+52
+00:04:32,000 --> 00:04:38,000
+Let's review another source code example and learn how to avoid unsafe consumption of APIs.
+
+53
+00:04:38,000 --> 00:04:44,000
+Let's analyze the Secure Payment servlet, which is an improved version of the vulnerable payment servlet
+
+54
+00:04:44,000 --> 00:04:45,000
+we examined earlier.
+
+55
+00:04:46,000 --> 00:04:52,000
+This survey is designed to handle payment processing in an e-commerce context while addressing vulnerabilities
+
+56
+00:04:52,000 --> 00:04:55,000
+related to unsafe API consumption.
+
+57
+00:04:56,000 --> 00:05:02,000
+We define our servlet class in a similar way as previous one, and here is the first difference.
+
+58
+00:05:02,000 --> 00:05:07,000
+We introduce a new constant allowed redirect domains.
+
+59
+00:05:07,000 --> 00:05:13,000
+This array will store the trusted domains to which redirects can be safely followed.
+
+60
+00:05:13,000 --> 00:05:20,000
+This is a crucial addition that addresses a significant vulnerability present in the previous code.
+
+61
+00:05:20,000 --> 00:05:28,000
+Similar to the previous example, we retrieve the payment data and define the payment gateway URL.
+
+62
+00:05:29,000 --> 00:05:34,000
+The context remains the same processing payment information for the online store.
+
+63
+00:05:35,000 --> 00:05:39,000
+We establish a connection to the payment gateway and sends the payment data.
+
+64
+00:05:39,000 --> 00:05:46,000
+Just like in the previous survey, however, this is where the vulnerabilities begin to be addressed
+
+65
+00:05:46,000 --> 00:05:48,000
+in the following lines.
+
+66
+00:05:49,000 --> 00:05:52,000
+We check the response code and see if it indicates a redirect.
+
+67
+00:05:53,000 --> 00:05:55,000
+If so, we retrieve the new location.
+
+68
+00:05:56,000 --> 00:05:58,000
+This is where the key difference lies.
+
+69
+00:05:59,000 --> 00:06:05,000
+The code now validates the redirect URL using the Isallowed redirect domain method before proceeding.
+
+70
+00:06:06,000 --> 00:06:14,000
+The method checks if the redirect URL belongs to the trusted domains, ensuring that we only follow
+
+71
+00:06:14,000 --> 00:06:20,000
+safe redirects only if the redirect URL is validated as belonging to a trusted domain.
+
+72
+00:06:20,000 --> 00:06:21,000
+Do we follow it?
+
+73
+00:06:22,000 --> 00:06:28,000
+This prevents potentially malicious redirects from being followed, significantly enhancing security.
+
+74
+00:06:28,000 --> 00:06:34,000
+We read and process the response from the redirected connection and send it back to the client.
+
+75
+00:06:34,000 --> 00:06:40,000
+This functionality is similar to the previous example, but now it only occurs if the redirect is deemed
+
+76
+00:06:40,000 --> 00:06:40,000
+safe.
+
+77
+00:06:41,000 --> 00:06:47,000
+If the redirect URL is not trusted, we respond with a 400 bad request error.
+
+78
+00:06:48,000 --> 00:06:55,000
+This proactive error handling is a new addition that enhances security by preventing unauthorized actions.
+
+79
+00:06:56,000 --> 00:07:02,000
+The remainder of the code reads and processes the original response from the payment gateway, similar
+
+80
+00:07:02,000 --> 00:07:04,000
+to the previous example.
+
+81
+00:07:04,000 --> 00:07:08,000
+Let's summarize key differences in comparison with previous example.
+
+82
+00:07:09,000 --> 00:07:14,000
+The addition of the Isallowed redirect domain method is the most significant improvement.
+
+83
+00:07:14,000 --> 00:07:20,000
+It checks whether the redirect URL belongs to a trusted domain, preventing the servlet from following
+
+84
+00:07:21,000 --> 00:07:23,000
+potentially malicious redirects.
+
+85
+00:07:24,000 --> 00:07:30,000
+The server now includes logic to handle cases where a redirect to an untrusted domain is detected.
+
+86
+00:07:31,000 --> 00:07:38,000
+This proactive error handling is crucial for maintaining the security of sensitive payment data by preventing
+
+87
+00:07:38,000 --> 00:07:40,000
+unauthorized redirects.
+
+88
+00:07:40,000 --> 00:07:46,000
+This servlet protects sensitive payment information from being exposed to attackers, ensuring that
+
+89
+00:07:46,000 --> 00:07:50,000
+user data remains secure throughout the transaction process.
+
+90
+00:07:51,000 --> 00:07:57,000
+So, the Secure Payment Servlet addresses the vulnerabilities found in its predecessor by implementing
+
+91
+00:07:57,000 --> 00:08:03,000
+robust security measures for handling redirects, by validating external requests, and proactively
+
+92
+00:08:03,000 --> 00:08:05,000
+managing potential threats.
+
+93
+00:08:05,000 --> 00:08:12,000
+This servlet enhances the security of the payment processing system, thereby safeguarding both the
+
+94
+00:08:12,000 --> 00:08:14,000
+business and its customers.
+
+95
+00:08:15,000 --> 00:08:21,000
+This example reinforces the importance of secure coding practices and thorough validation in protecting
+
+96
+00:08:21,000 --> 00:08:23,000
+against unsafe API consumption.
+
+97
+00:08:24,000 --> 00:08:27,000
+Now you know how to avoid the vulnerability in your code.
+
+98
+00:08:27,000 --> 00:08:30,000
+That's all what I planned to share in the lesson.
+
+99
+00:08:31,000 --> 00:08:33,000
+Let's recap what you've learned from the lesson.
+
+100
+00:08:35,000 --> 00:08:40,000
+We defined the concept of unsafe API consumption and discussed its importance in application security.
+
+101
+00:08:40,000 --> 00:08:46,000
+We addressed common misconceptions about API security to clarify key principles.
+
+102
+00:08:46,000 --> 00:08:52,000
+We explored the reasons why APIs are vulnerable, emphasizing their unique risks.
+
+103
+00:08:52,000 --> 00:08:58,000
+We identified key vulnerabilities associated with unsafe API consumption.
+
+104
+00:08:58,000 --> 00:09:04,000
+We examined the potential risks and impacts of these vulnerabilities through real world examples and
+
+105
+00:09:04,000 --> 00:09:05,000
+case studies.
+
+106
+00:09:06,000 --> 00:09:12,000
+We learned how to spot unsafe API consumption vulnerabilities in our own applications.
+
+107
+00:09:12,000 --> 00:09:19,000
+Lastly, we covered effective mitigation strategies and best practices to secure our APIs against potential
+
+108
+00:09:19,000 --> 00:09:20,000
+threats.
+
+109
+00:09:21,000 --> 00:09:22,000
+That's all for the lesson.
+
+110
+00:09:23,000 --> 00:09:24,000
+Thanks a lot for your attention.
+
+111
+00:09:24,000 --> 00:09:27,000
+Have a great day and see you in the next lesson.
+
diff --git a/74 - OWASP API Security Top 10 2023/022 Source-code-examples-from-the-lesson.url b/74 - OWASP API Security Top 10 2023/022 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..c2ce71aaac01dd65b43f574f3a3c6bc7324ae90e
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/022 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/uca
\ No newline at end of file
diff --git a/74 - OWASP API Security Top 10 2023/external-links.txt b/74 - OWASP API Security Top 10 2023/external-links.txt
new file mode 100644
index 0000000000000000000000000000000000000000..aec5f76b90cd646c4275fa04307df024a58002d4
--- /dev/null
+++ b/74 - OWASP API Security Top 10 2023/external-links.txt
@@ -0,0 +1,24 @@
+
+003 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/commit/6f7f9cce32e4a535ac0b21deab0a4ccaa8d87bc4
+
+007 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/commit/42ee72c9ea198a0f66d42ce8cab8a501d8995600
+
+009 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/bopla
+
+011 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/urc
+
+013 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/bfla
+
+016 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/uasbf
+
+020 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/iim
+
+022 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.web/src/main/java/com/itbulls/learnit/onlinestore/web/owasp/uca
diff --git a/75 - Logging in Java/001 Logging in Java Part 1 (Logging theory, Logging Levels, Java Logging Framework)_en.srt b/75 - Logging in Java/001 Logging in Java Part 1 (Logging theory, Logging Levels, Java Logging Framework)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..1f6fa870eeea80672d6313cd26c0622069d07792
--- /dev/null
+++ b/75 - Logging in Java/001 Logging in Java Part 1 (Logging theory, Logging Levels, Java Logging Framework)_en.srt
@@ -0,0 +1,1448 @@
+1
+00:00:06,000 --> 00:00:06,000
+Hello, Jim.
+
+2
+00:00:06,000 --> 00:00:10,000
+In this lesson, we are going to learn logging in Java.
+
+3
+00:00:10,000 --> 00:00:15,000
+Logging is very important and not a quick topic to learn.
+
+4
+00:00:15,000 --> 00:00:19,000
+So today we start learning an important topic.
+
+5
+00:00:19,000 --> 00:00:22,000
+I will split this topic into multiple parts.
+
+6
+00:00:23,000 --> 00:00:26,000
+We're going to learn what logging and logs are.
+
+7
+00:00:26,000 --> 00:00:29,000
+I will explain the goals of logging.
+
+8
+00:00:29,000 --> 00:00:33,000
+We're going to hold an overview of libraries for loading in Java.
+
+9
+00:00:34,000 --> 00:00:38,000
+During this topic, we are going to learn different libraries for logging.
+
+10
+00:00:38,000 --> 00:00:46,000
+They are Java, log in framework, log for G, log back and a self for G.
+
+11
+00:00:47,000 --> 00:00:53,000
+For each of the logging libraries, we are going to learn specifics of log in levels, key features,
+
+12
+00:00:53,000 --> 00:00:59,000
+main structure, elements of the library, practical examples and others.
+
+13
+00:00:59,000 --> 00:01:06,000
+Also, we will learn log for G Library will learn different triggering policies and rollover strategies.
+
+14
+00:01:07,000 --> 00:01:10,000
+I'm going to explain you what is a.
+
+15
+00:01:10,000 --> 00:01:12,000
+We have a lot of things to do.
+
+16
+00:01:12,000 --> 00:01:14,000
+Let's start our lesson.
+
+17
+00:01:15,000 --> 00:01:22,000
+But before we start the lesson, I'd like to highlight what is in scope and what is out of the scope
+
+18
+00:01:22,000 --> 00:01:23,000
+of this lesson.
+
+19
+00:01:23,000 --> 00:01:31,000
+Logging management tools like Splunk, Elastic and other things are out of the scope of this lesson.
+
+20
+00:01:31,000 --> 00:01:38,000
+In this lesson, we'll focus on the implementation of logging inside our application.
+
+21
+00:01:38,000 --> 00:01:46,000
+Also, this lesson partially overlaps with the lesson from my course about our top ten, namely.
+
+22
+00:01:46,000 --> 00:01:53,000
+This lesson may overlap with the lesson from a top ten course that is called insufficient logging and
+
+23
+00:01:53,000 --> 00:01:54,000
+monitoring.
+
+24
+00:01:55,000 --> 00:02:03,000
+In that lesson, we also reviewed some login basics and discussed vulnerabilities related with insufficient
+
+25
+00:02:03,000 --> 00:02:04,000
+logging.
+
+26
+00:02:04,000 --> 00:02:11,000
+In this lesson, we will not review security vulnerabilities, but we'll focus instead on the implementation
+
+27
+00:02:11,000 --> 00:02:13,000
+part of the log in.
+
+28
+00:02:14,000 --> 00:02:21,000
+It's the first question that we have to address is the definition of logging and logs in computing.
+
+29
+00:02:21,000 --> 00:02:29,000
+A log file is a file that records is events that occur in operating system or application logging.
+
+30
+00:02:29,000 --> 00:02:32,000
+Is the act of keeping the log.
+
+31
+00:02:32,000 --> 00:02:37,000
+In the simplest case, messages are rhythm to a single log file.
+
+32
+00:02:38,000 --> 00:02:46,000
+A log in a computing context is automatically produced and timestamped documentation of events relevant
+
+33
+00:02:46,000 --> 00:02:50,000
+to a particular system or application.
+
+34
+00:02:50,000 --> 00:02:55,000
+Most of software applications and systems produce log files.
+
+35
+00:02:55,000 --> 00:03:03,000
+There are also separate libraries for logging and applications that helps to gather, analyze and navigate
+
+36
+00:03:03,000 --> 00:03:04,000
+in logs.
+
+37
+00:03:04,000 --> 00:03:08,000
+They are called log management applications.
+
+38
+00:03:08,000 --> 00:03:12,000
+There are really a lot of them for different languages.
+
+39
+00:03:12,000 --> 00:03:17,000
+In this lesson, we're going to review libraries and tools that are most popular while working with
+
+40
+00:03:17,000 --> 00:03:19,000
+Java applications.
+
+41
+00:03:20,000 --> 00:03:22,000
+So why do we need locks?
+
+42
+00:03:22,000 --> 00:03:25,000
+What goals we want to achieve with logging?
+
+43
+00:03:25,000 --> 00:03:29,000
+There are four main target uses of the logs.
+
+44
+00:03:30,000 --> 00:03:34,000
+Problem diagnosis by end users and system administrators.
+
+45
+00:03:34,000 --> 00:03:43,000
+This consists of simple logging of common problems that can be fixed or tracked locally, such as running
+
+46
+00:03:43,000 --> 00:03:48,000
+out of resources, security failures and simple configuration errors.
+
+47
+00:03:49,000 --> 00:03:53,000
+Problem Diagnosis by field service engineers.
+
+48
+00:03:53,000 --> 00:04:02,000
+The logging information used by field service engineers may be considerably more complex and verbose
+
+49
+00:04:02,000 --> 00:04:05,000
+than that required by system administrators.
+
+50
+00:04:05,000 --> 00:04:11,000
+Typically, such information will require extra logging within particular subsystems.
+
+51
+00:04:12,000 --> 00:04:15,000
+Problem Diagnosis by the Development Organization.
+
+52
+00:04:16,000 --> 00:04:23,000
+When a problem occurs in the field, it may be necessary to return the captured logging information
+
+53
+00:04:23,000 --> 00:04:27,000
+to the original development team for diagnosis.
+
+54
+00:04:27,000 --> 00:04:34,000
+This log in information may be extremely detailed and fairly inscrutable.
+
+55
+00:04:34,000 --> 00:04:41,000
+Such information might include detailed tracing on the internal execution of particular subsystems.
+
+56
+00:04:42,000 --> 00:04:44,000
+Problem diagnosis by developers.
+
+57
+00:04:45,000 --> 00:04:51,000
+The log in APIs may also be used to help debug an application under development.
+
+58
+00:04:52,000 --> 00:04:59,000
+This may include log in information generated by the target application as well as log in information
+
+59
+00:04:59,000 --> 00:05:02,000
+generated by low level libraries.
+
+60
+00:05:03,000 --> 00:05:11,000
+Note, however, that while this use is perfectly reasonable, the log in APIs are not intended to replace
+
+61
+00:05:11,000 --> 00:05:19,000
+the normal debugging and profiling tools that may already exist in the development environment.
+
+62
+00:05:19,000 --> 00:05:26,000
+Today, in this course, we are going to review real life examples of implementation of different log
+
+63
+00:05:26,000 --> 00:05:27,000
+in frameworks.
+
+64
+00:05:27,000 --> 00:05:30,000
+Before we jump to practical examples.
+
+65
+00:05:30,000 --> 00:05:36,000
+Let me hold a high level overview of the login frameworks that we are going to learn today.
+
+66
+00:05:36,000 --> 00:05:38,000
+Java Login Framework.
+
+67
+00:05:39,000 --> 00:05:44,000
+Java has its own login framework that is built into the JDK.
+
+68
+00:05:44,000 --> 00:05:49,000
+Honestly, the Java login framework not very popular nowadays.
+
+69
+00:05:49,000 --> 00:05:57,000
+Unfortunately, the JDK didn't include logging in its original release, so by the time the Java login
+
+70
+00:05:57,000 --> 00:06:03,000
+API was added, several other login frameworks had become widely used.
+
+71
+00:06:04,000 --> 00:06:05,000
+Lock for J.
+
+72
+00:06:06,000 --> 00:06:14,000
+Lock for J is a Java login framework that supports log in to files, output streams and other targets
+
+73
+00:06:14,000 --> 00:06:18,000
+and allows the configuration via config files.
+
+74
+00:06:18,000 --> 00:06:19,000
+Log back.
+
+75
+00:06:20,000 --> 00:06:24,000
+Log Back is intended to be the successor of work for G.
+
+76
+00:06:24,000 --> 00:06:32,000
+It was developed by the original log four G developer and features a lightweight architecture as self
+
+77
+00:06:32,000 --> 00:06:33,000
+for G.
+
+78
+00:06:34,000 --> 00:06:41,000
+A self for G is a framework that acts as a simple interface for various other log in libraries, allowing
+
+79
+00:06:41,000 --> 00:06:46,000
+developers to plug in the desert implementation and deployment time.
+
+80
+00:06:47,000 --> 00:06:55,000
+So basically you can write the code relying on the interface provided by a self for G and then decide
+
+81
+00:06:55,000 --> 00:06:58,000
+which log you want to use.
+
+82
+00:06:58,000 --> 00:07:05,000
+Because a self for JS supports really a lot of different connectors, including connectors for log for
+
+83
+00:07:05,000 --> 00:07:07,000
+G and log back.
+
+84
+00:07:07,000 --> 00:07:10,000
+Let's start from the Java logging framework.
+
+85
+00:07:10,000 --> 00:07:17,000
+On this slide, I'm going to make an overview of the Java logging package and the key types from this
+
+86
+00:07:17,000 --> 00:07:18,000
+package.
+
+87
+00:07:19,000 --> 00:07:26,000
+As I already said, it is not the most popular framework for logging nowadays, but taking into account
+
+88
+00:07:26,000 --> 00:07:32,000
+that this is logging framework that is provided with JDK, we have to know it.
+
+89
+00:07:32,000 --> 00:07:40,000
+Moreover, if we talk about Oracle JDK, this is a slogan framework that is supported by Oracle and
+
+90
+00:07:40,000 --> 00:07:44,000
+recommended to be used in Java enterprise projects.
+
+91
+00:07:44,000 --> 00:07:51,000
+You're going to find that developers often use other log frameworks, but still, as a Java software
+
+92
+00:07:51,000 --> 00:07:56,000
+engineer, we have to know how to use Java log in framework.
+
+93
+00:07:57,000 --> 00:08:06,000
+The key elements of this package include log the main entity on which applications make logging calls
+
+94
+00:08:06,000 --> 00:08:07,000
+and log in.
+
+95
+00:08:07,000 --> 00:08:14,000
+Object is used to log messages for a specific system or application component.
+
+96
+00:08:15,000 --> 00:08:24,000
+Log crackers used to pass logging requests between the logging framework and individual log handlers.
+
+97
+00:08:25,000 --> 00:08:34,000
+Handler Exports Log records objects to a variety of destinations, including memory output streams,
+
+98
+00:08:34,000 --> 00:08:37,000
+consoles, files and sockets.
+
+99
+00:08:38,000 --> 00:08:42,000
+A variety of handler subclasses exist for this purpose.
+
+100
+00:08:43,000 --> 00:08:50,000
+Additional handlers may be developed by third parties and delivered on top of the core platform.
+
+101
+00:08:51,000 --> 00:08:58,000
+Level defines a set of standards, lodging levels that can be used to control logging output.
+
+102
+00:08:58,000 --> 00:09:05,000
+Programs can be configured to output logging for some levels while ignoring output for others.
+
+103
+00:09:06,000 --> 00:09:15,000
+Filter provides fine grained control over what gets logged beyond the control provided by log levels.
+
+104
+00:09:16,000 --> 00:09:25,000
+The logging API supports a general purpose filter mechanism that allows application code to attach arbitrary
+
+105
+00:09:25,000 --> 00:09:27,000
+filters to control log and output.
+
+106
+00:09:28,000 --> 00:09:34,000
+Her mother provides support for for Martin Locke records objects.
+
+107
+00:09:34,000 --> 00:09:41,000
+This package includes two for mother's simple for Marta and for Marta.
+
+108
+00:09:42,000 --> 00:09:43,000
+Four for Martin.
+
+109
+00:09:43,000 --> 00:09:47,000
+Log records in plain text or X amount, respectively.
+
+110
+00:09:47,000 --> 00:09:53,000
+As with handlers, additional for mothers may be developed by third parties.
+
+111
+00:09:54,000 --> 00:09:58,000
+The concept of log levels present in different loggers.
+
+112
+00:09:59,000 --> 00:10:07,000
+Even despite the fact that levels are named differently in different log libraries, the concept is
+
+113
+00:10:07,000 --> 00:10:08,000
+almost the same.
+
+114
+00:10:08,000 --> 00:10:15,000
+Let's learn the concept first, and after that we are going to learn the specifics of each concrete
+
+115
+00:10:15,000 --> 00:10:17,000
+Java log in library.
+
+116
+00:10:17,000 --> 00:10:25,000
+As we already learned, there is a library that is called Self for J that is used as a top level interface
+
+117
+00:10:25,000 --> 00:10:27,000
+for log implementations.
+
+118
+00:10:28,000 --> 00:10:33,000
+Log levels is that we are going to review now are from self for J Library.
+
+119
+00:10:34,000 --> 00:10:37,000
+That's why they become so popular.
+
+120
+00:10:37,000 --> 00:10:46,000
+Java log levels are a set of standard severities of the log in message tells how important the log record
+
+121
+00:10:46,000 --> 00:10:47,000
+is.
+
+122
+00:10:47,000 --> 00:10:56,000
+A log level of log severity is a piece of information telling how important a given log message is.
+
+123
+00:10:57,000 --> 00:11:04,000
+It is a simple, yet very powerful way of distinguishing log events from each other.
+
+124
+00:11:04,000 --> 00:11:12,000
+Using different log levels, it is easier to navigate between different logs and filter all information
+
+125
+00:11:12,000 --> 00:11:13,000
+that you need.
+
+126
+00:11:13,000 --> 00:11:21,000
+The log levels can help in reducing the information noise, starting from the most critical level.
+
+127
+00:11:21,000 --> 00:11:27,000
+At the very least level this sound like this fatal error.
+
+128
+00:11:27,000 --> 00:11:31,000
+Vaughn Info debug trace.
+
+129
+00:11:32,000 --> 00:11:42,000
+Let me just briefly explain each log level fatal the log level indicating that your application encountered
+
+130
+00:11:42,000 --> 00:11:48,000
+an event that prevents it from working or a crucial part of it from working.
+
+131
+00:11:49,000 --> 00:11:57,000
+A fatal log level is, for example, an inability to connect the database that your system relies on,
+
+132
+00:11:57,000 --> 00:12:04,000
+or an external payment system that is needed to check how the basket in your ecommerce system.
+
+133
+00:12:05,000 --> 00:12:13,000
+Error lock levels that indicates an issue with a system that prevents certain functionality from working.
+
+134
+00:12:14,000 --> 00:12:22,000
+For example, if you provide login where social media as one way of logging into your system, the failure
+
+135
+00:12:22,000 --> 00:12:27,000
+of such a model is an error level log for sure.
+
+136
+00:12:27,000 --> 00:12:31,000
+But taking into account log in feature still works.
+
+137
+00:12:31,000 --> 00:12:38,000
+This is not like fatal error that describes complete inability to log in the fails the difference.
+
+138
+00:12:39,000 --> 00:12:42,000
+Warm lock levels.
+
+139
+00:12:42,000 --> 00:12:49,000
+It usually indicates a state of the application that might be a problematic or unusual execution is
+
+140
+00:12:49,000 --> 00:12:50,000
+detected.
+
+141
+00:12:50,000 --> 00:12:56,000
+Something may be wrong, but it doesn't mean that the application failed.
+
+142
+00:12:56,000 --> 00:13:02,000
+For example, if a message wasn't passed correctly because it was not correct.
+
+143
+00:13:03,000 --> 00:13:10,000
+The code execution is continuing, but we could log that with the warden level to inform us and others
+
+144
+00:13:10,000 --> 00:13:15,000
+that potential problems are happening in full.
+
+145
+00:13:15,000 --> 00:13:23,000
+The standard level of log information that indicates normal application action, for example, created
+
+146
+00:13:23,000 --> 00:13:32,000
+the user with a D is an example of a log message on an info level that gives you information about certain
+
+147
+00:13:32,000 --> 00:13:35,000
+processes that finished with a success.
+
+148
+00:13:35,000 --> 00:13:43,000
+In most cases, if you are not looking into how your application performs, you could ignore most,
+
+149
+00:13:43,000 --> 00:13:44,000
+if not all, of the info.
+
+150
+00:13:44,000 --> 00:13:45,000
+Level.
+
+151
+00:13:45,000 --> 00:13:45,000
+Logs.
+
+152
+00:13:46,000 --> 00:13:47,000
+The bar.
+
+153
+00:13:48,000 --> 00:13:56,000
+Last granules and trace level, but still more granular is an info level and more detailed than you
+
+154
+00:13:56,000 --> 00:14:04,000
+need in your normal everyday use that the bulk level should be used for information that can be useful
+
+155
+00:14:04,000 --> 00:14:10,000
+for troubleshooting and is not needed for looking at the everyday application state.
+
+156
+00:14:11,000 --> 00:14:12,000
+Trace.
+
+157
+00:14:12,000 --> 00:14:20,000
+Very fine grained information only used in a rare case where you need the full visibility of what is
+
+158
+00:14:20,000 --> 00:14:25,000
+happening in most cases is a trace level will be very verbose.
+
+159
+00:14:25,000 --> 00:14:33,000
+But you can also expect a lot of information about the application used for annotating the steps in
+
+160
+00:14:33,000 --> 00:14:37,000
+your program that are not relevant in everyday use.
+
+161
+00:14:38,000 --> 00:14:45,000
+As I already said, in different lawyers, there are different levels, but in general the concept is
+
+162
+00:14:45,000 --> 00:14:46,000
+the same.
+
+163
+00:14:46,000 --> 00:14:54,000
+Currently we are learning Java login framework, so let's learn what log levels exist in Java util log
+
+164
+00:14:54,000 --> 00:14:55,000
+in package.
+
+165
+00:14:56,000 --> 00:15:03,000
+There is a class that is called level and it contains constants of the level type.
+
+166
+00:15:03,000 --> 00:15:09,000
+They are of severe warning info config.
+
+167
+00:15:09,000 --> 00:15:12,000
+Fine, fine, finest.
+
+168
+00:15:12,000 --> 00:15:20,000
+All to help you understand for what kind of events it is recommended to use which level.
+
+169
+00:15:20,000 --> 00:15:28,000
+Let me present the map in between the self log log levels that we have learned and Java log in framework
+
+170
+00:15:28,000 --> 00:15:29,000
+log levels.
+
+171
+00:15:29,000 --> 00:15:34,000
+On this slide you can see the mapping that I created for you.
+
+172
+00:15:34,000 --> 00:15:41,000
+Please press pause for a minute if you need to investigate mapping between log levels in Java, log
+
+173
+00:15:41,000 --> 00:15:44,000
+in framework and in a self for g.
+
+174
+00:15:45,000 --> 00:15:51,000
+Once you are done with reviewing slide quick resume button to proceed with the lesson.
+
+175
+00:15:52,000 --> 00:15:55,000
+Now it is time for practical example.
+
+176
+00:15:55,000 --> 00:16:03,000
+As we already learned from the slide, the log is the main entity that an application uses to make logging
+
+177
+00:16:03,000 --> 00:16:04,000
+calls.
+
+178
+00:16:04,000 --> 00:16:08,000
+To capture log records to the appropriate handler.
+
+179
+00:16:09,000 --> 00:16:16,000
+The Lock record or log in event is an entity used to pass the log in or request between the framework
+
+180
+00:16:16,000 --> 00:16:22,000
+that is used for logging and the handlers that are responsible for log shaping.
+
+181
+00:16:23,000 --> 00:16:31,000
+The log object is usually used for a single clause or a single component to provide context bound to
+
+182
+00:16:31,000 --> 00:16:32,000
+a specific use case.
+
+183
+00:16:33,000 --> 00:16:39,000
+All examples will be shown today in the lesson you can find in the log in package.
+
+184
+00:16:39,000 --> 00:16:44,000
+I will leave the reference to the source code in attachments to the lesson.
+
+185
+00:16:44,000 --> 00:16:48,000
+I open examples from Java log in package.
+
+186
+00:16:48,000 --> 00:16:52,000
+I open my logger class here on top.
+
+187
+00:16:52,000 --> 00:17:01,000
+I left command lines with short summary information about log levels, default handlers and for masters.
+
+188
+00:17:01,000 --> 00:17:09,000
+By the way, we only learned what handlers are, but we didn't discuss what handlers exist in the Java
+
+189
+00:17:09,000 --> 00:17:10,000
+log in package.
+
+190
+00:17:10,000 --> 00:17:13,000
+They are console handler.
+
+191
+00:17:13,000 --> 00:17:19,000
+Obviously this one works with console file handler from its name you can guess it.
+
+192
+00:17:19,000 --> 00:17:21,000
+It works with files.
+
+193
+00:17:21,000 --> 00:17:31,000
+Stream handler publishes all log messages to an output stream socket handler publishes log records to
+
+194
+00:17:31,000 --> 00:17:34,000
+network stream connection memory handler.
+
+195
+00:17:34,000 --> 00:17:38,000
+It is used to keep log records into memory buffer.
+
+196
+00:17:39,000 --> 00:17:44,000
+You can also create your own handler by extending the handler class.
+
+197
+00:17:44,000 --> 00:17:51,000
+To do this, you can extend abstract handler class and implement three abstract methods.
+
+198
+00:17:51,000 --> 00:18:01,000
+They are publish, slash and close custom handler template class contains a skeleton of new custom handler.
+
+199
+00:18:02,000 --> 00:18:07,000
+Also here I left the names of some basic for martyrs.
+
+200
+00:18:07,000 --> 00:18:11,000
+Their simple for martyr and XML for martyr.
+
+201
+00:18:11,000 --> 00:18:17,000
+In our today's example, we are going to create our own HTML for martyr.
+
+202
+00:18:17,000 --> 00:18:21,000
+So let's jump to the code example itself.
+
+203
+00:18:22,000 --> 00:18:28,000
+This is a class of the logger that I will configure and will use across the application.
+
+204
+00:18:29,000 --> 00:18:32,000
+I can configure different loggers as much as they need.
+
+205
+00:18:33,000 --> 00:18:38,000
+In this particular example, I will show you how I can configure global logger.
+
+206
+00:18:38,000 --> 00:18:42,000
+Global means that it is for all application.
+
+207
+00:18:42,000 --> 00:18:51,000
+Here is file handler for simple text and simple form author and file handler for logs in the HTML form
+
+208
+00:18:51,000 --> 00:18:52,000
+and variables.
+
+209
+00:18:52,000 --> 00:18:59,000
+It will be initialized with our custom HTML format in a few seconds, and we're going to show you how
+
+210
+00:18:59,000 --> 00:19:04,000
+we initialized these variables in the setup method.
+
+211
+00:19:04,000 --> 00:19:06,000
+I get the reference to the logger.
+
+212
+00:19:06,000 --> 00:19:12,000
+You can use get logger method of logger class and pause as stream values.
+
+213
+00:19:12,000 --> 00:19:15,000
+It will be used as a logger identifier.
+
+214
+00:19:16,000 --> 00:19:20,000
+In this case I use constant global logger name.
+
+215
+00:19:20,000 --> 00:19:22,000
+That is simple string.
+
+216
+00:19:22,000 --> 00:19:27,000
+If a logger has already been created with a given name, it is returned.
+
+217
+00:19:28,000 --> 00:19:31,000
+Otherwise a new logger is created.
+
+218
+00:19:31,000 --> 00:19:34,000
+We can set a level to the logger.
+
+219
+00:19:34,000 --> 00:19:36,000
+What does this mean?
+
+220
+00:19:36,000 --> 00:19:39,000
+Set level method sets the log level.
+
+221
+00:19:39,000 --> 00:19:44,000
+Specify which message levels will be logged by this logger.
+
+222
+00:19:45,000 --> 00:19:49,000
+Message levels lower than this value will be discarded.
+
+223
+00:19:50,000 --> 00:19:51,000
+Why is this is needed?
+
+224
+00:19:52,000 --> 00:19:59,000
+For example, you can configure one logger to write in the file all messages, including finest or trace
+
+225
+00:19:59,000 --> 00:20:07,000
+level log records, and you can use another logger that will print into output stream on the log messages
+
+226
+00:20:07,000 --> 00:20:10,000
+with one error and fatal level.
+
+227
+00:20:11,000 --> 00:20:16,000
+After that, we initialize our file handlers with file handler object.
+
+228
+00:20:17,000 --> 00:20:24,000
+One file store logs in simple text format and another one will store logs in HTML format.
+
+229
+00:20:25,000 --> 00:20:33,000
+Another important point you can limit logs with a specific level by setting level not to the logger,
+
+230
+00:20:33,000 --> 00:20:35,000
+but to the handler itself.
+
+231
+00:20:36,000 --> 00:20:43,000
+Message levels lower than one with pores in the set level mask will be discarded.
+
+232
+00:20:44,000 --> 00:20:51,000
+The intention is to allow developers to churn on voluminous log, but to limit the messages that are
+
+233
+00:20:51,000 --> 00:20:52,000
+sent to certain handler.
+
+234
+00:20:53,000 --> 00:20:58,000
+And for simple text file handler, I set up severe level.
+
+235
+00:20:59,000 --> 00:21:02,000
+After that, I create four martyrs.
+
+236
+00:21:02,000 --> 00:21:06,000
+I create the fourth symbol for martyr object from JDK.
+
+237
+00:21:07,000 --> 00:21:10,000
+This is a class from Java YouTube logon package.
+
+238
+00:21:11,000 --> 00:21:13,000
+I set format for the file handler.
+
+239
+00:21:14,000 --> 00:21:23,000
+Now when log records will be published as a file simple format or will format text messages, one logger
+
+240
+00:21:23,000 --> 00:21:25,000
+can have multiple handlers.
+
+241
+00:21:25,000 --> 00:21:33,000
+In this example, I'm going to add multiple handlers to my global logger, and as a beginning, I add
+
+242
+00:21:33,000 --> 00:21:36,000
+file handler for simple text to my logger.
+
+243
+00:21:36,000 --> 00:21:38,000
+With the help of add handler.
+
+244
+00:21:38,000 --> 00:21:39,000
+Massive.
+
+245
+00:21:40,000 --> 00:21:43,000
+After that I create HTML for matter.
+
+246
+00:21:43,000 --> 00:21:45,000
+This is a custom type.
+
+247
+00:21:45,000 --> 00:21:47,000
+Let me show it to you.
+
+248
+00:21:47,000 --> 00:21:54,000
+We can create formatter simply by extending offset formatter class from Java to log in package.
+
+249
+00:21:54,000 --> 00:22:00,000
+We have to implement format method that takes log record as a parameter.
+
+250
+00:22:00,000 --> 00:22:04,000
+This is the only one abstract massive in form master class.
+
+251
+00:22:05,000 --> 00:22:08,000
+But also we can override get that method.
+
+252
+00:22:08,000 --> 00:22:16,000
+It should return the header three four set of format records and get tail mass as it should return the
+
+253
+00:22:16,000 --> 00:22:19,000
+tail string for a set of formatted records.
+
+254
+00:22:20,000 --> 00:22:22,000
+That's basically what I did here.
+
+255
+00:22:23,000 --> 00:22:29,000
+Don't worry, I will share with you the source code and you will be able to look through the details
+
+256
+00:22:29,000 --> 00:22:29,000
+here.
+
+257
+00:22:30,000 --> 00:22:37,000
+Don't see a lot of sense me going over line by line, because what I do here is basically building a
+
+258
+00:22:37,000 --> 00:22:40,000
+HTML string with styles and table.
+
+259
+00:22:41,000 --> 00:22:44,000
+I have separate lessons about HTML and CSS.
+
+260
+00:22:45,000 --> 00:22:48,000
+That's why we wouldn't stop on this.
+
+261
+00:22:49,000 --> 00:22:52,000
+Let me return back to my logger class.
+
+262
+00:22:52,000 --> 00:22:59,000
+And in the same way I set Ford Motor to the file handler for HTML and add handler.
+
+263
+00:23:00,000 --> 00:23:03,000
+It is time to check how it works.
+
+264
+00:23:04,000 --> 00:23:07,000
+There is a separate class that is called Logger Demo.
+
+265
+00:23:08,000 --> 00:23:13,000
+In this class I have main method where I create instance of this type.
+
+266
+00:23:13,000 --> 00:23:20,000
+I set up my logger first and after that I go last do Samson and Law.
+
+267
+00:23:21,000 --> 00:23:24,000
+In this method I play with different levels.
+
+268
+00:23:24,000 --> 00:23:29,000
+Pay attention that usually logger is a static final field in the class.
+
+269
+00:23:30,000 --> 00:23:38,000
+I get the reference using the constant for global logger and in the last do something and log I use
+
+270
+00:23:38,000 --> 00:23:39,000
+my logger object.
+
+271
+00:23:40,000 --> 00:23:45,000
+I set level severe and after that I want to log few messages.
+
+272
+00:23:46,000 --> 00:23:55,000
+Only severe log records will locked once I have changed the level of the logger to info only info warning
+
+273
+00:23:55,000 --> 00:23:57,000
+and severe log will be logged.
+
+274
+00:23:57,000 --> 00:24:01,000
+Finest log records will not be logged.
+
+275
+00:24:02,000 --> 00:24:03,000
+Let me run this program.
+
+276
+00:24:04,000 --> 00:24:12,000
+As you can see, console handler is present by default in global logger, but we can disable it if we
+
+277
+00:24:12,000 --> 00:24:12,000
+need.
+
+278
+00:24:13,000 --> 00:24:17,000
+Also, file handlers created files for us.
+
+279
+00:24:18,000 --> 00:24:24,000
+I will open text file in the text editor and each HTML file in the web browser.
+
+280
+00:24:25,000 --> 00:24:33,000
+In the HTML, you can see that we log severe log first and after that when we change the log level,
+
+281
+00:24:33,000 --> 00:24:39,000
+we have severe warning and info log message in the text file.
+
+282
+00:24:39,000 --> 00:24:42,000
+We don't have so many log messages.
+
+283
+00:24:42,000 --> 00:24:46,000
+Why do remember that when we configure it?
+
+284
+00:24:46,000 --> 00:24:50,000
+Logger We set the level for the simple text file.
+
+285
+00:24:50,000 --> 00:24:55,000
+Handler We set severe level for simple text file.
+
+286
+00:24:55,000 --> 00:25:00,000
+Handler That's why we see only two severe messages here.
+
+287
+00:25:00,000 --> 00:25:01,000
+Is it clear?
+
+288
+00:25:02,000 --> 00:25:09,000
+And now the important thing is that you can use configuration file to configure logger the java log
+
+289
+00:25:09,000 --> 00:25:17,000
+in API default allows logging properties in the Java home JIRA Leap.
+
+290
+00:25:17,000 --> 00:25:26,000
+This is for Java eight and before starting from Java nine and above the logging properties file moved
+
+291
+00:25:26,000 --> 00:25:28,000
+to Java home conf.
+
+292
+00:25:29,000 --> 00:25:30,000
+Let me show it to you.
+
+293
+00:25:31,000 --> 00:25:36,000
+Logging properties file contains a lot of command lines.
+
+294
+00:25:36,000 --> 00:25:40,000
+The results of configuration of default console handler.
+
+295
+00:25:41,000 --> 00:25:44,000
+Some default configurations of file handler.
+
+296
+00:25:45,000 --> 00:25:49,000
+Take your time to explore these properties in your GTK folder.
+
+297
+00:25:50,000 --> 00:25:56,000
+Theoretically, you can remove all the command line and configure the logger as you need.
+
+298
+00:25:57,000 --> 00:26:00,000
+Your configuration may look like this.
+
+299
+00:26:01,000 --> 00:26:08,000
+Also, if you don't want to keep this configuration and the ticket directory, you can add login properties
+
+300
+00:26:08,000 --> 00:26:15,000
+to the resource folder of your MAVEN application and upload disease configs when it will be needed.
+
+301
+00:26:16,000 --> 00:26:17,000
+Let me show it to you.
+
+302
+00:26:18,000 --> 00:26:20,000
+I open files.
+
+303
+00:26:20,000 --> 00:26:28,000
+It is called Login Properties Demo so you can see static initialization block because we need to change
+
+304
+00:26:28,000 --> 00:26:30,000
+system properties.
+
+305
+00:26:30,000 --> 00:26:33,000
+It points out to the log in configurations.
+
+306
+00:26:33,000 --> 00:26:37,000
+We need to do this before obtaining any longer in the program.
+
+307
+00:26:38,000 --> 00:26:44,000
+We get the past, our logging properties and we have changed our system property.
+
+308
+00:26:44,000 --> 00:26:48,000
+Now we can obtain logger and log messages.
+
+309
+00:26:49,000 --> 00:26:53,000
+Let me execute this program and what do we have here?
+
+310
+00:26:53,000 --> 00:26:58,000
+We have log message and console and they see only severe log message.
+
+311
+00:26:58,000 --> 00:26:59,000
+Why?
+
+312
+00:27:00,000 --> 00:27:03,000
+Because I configured level four logger.
+
+313
+00:27:03,000 --> 00:27:07,000
+Let me open logging properties and show it to you.
+
+314
+00:27:08,000 --> 00:27:12,000
+You can see that I configured file handler and console handler.
+
+315
+00:27:13,000 --> 00:27:16,000
+I configure it level four Global Logger.
+
+316
+00:27:16,000 --> 00:27:18,000
+I set it to severe.
+
+317
+00:27:18,000 --> 00:27:25,000
+As you can see, file handler will save files to the user's home directory.
+
+318
+00:27:25,000 --> 00:27:27,000
+We're going to review it in a minute.
+
+319
+00:27:28,000 --> 00:27:33,000
+And XML formatter will be used for console handler.
+
+320
+00:27:33,000 --> 00:27:38,000
+We're going to set level info and we will use simple formatter.
+
+321
+00:27:39,000 --> 00:27:42,000
+We can even specify format of the log message.
+
+322
+00:27:43,000 --> 00:27:46,000
+This is something what you have to pay attention to.
+
+323
+00:27:46,000 --> 00:27:53,000
+When you configure logger, you have to be careful to include only necessary information about event
+
+324
+00:27:53,000 --> 00:28:01,000
+in order to log just enough information to be able to troubleshoot incident in case this will be necessary.
+
+325
+00:28:02,000 --> 00:28:04,000
+Also, pay attention here.
+
+326
+00:28:04,000 --> 00:28:10,000
+I can configure different loggers in case I will use class name for loggers.
+
+327
+00:28:10,000 --> 00:28:13,000
+I can configure the tree of loggers.
+
+328
+00:28:13,000 --> 00:28:22,000
+In this particular case, I configured level for loggers from Komatsu's learning online store package.
+
+329
+00:28:22,000 --> 00:28:31,000
+That means that even despite console handler can process log records with info level and higher log
+
+330
+00:28:31,000 --> 00:28:39,000
+records from the specified package simply will not be submitted to the console handler because we set
+
+331
+00:28:39,000 --> 00:28:42,000
+restriction on the level of package.
+
+332
+00:28:42,000 --> 00:28:43,000
+Is it clear?
+
+333
+00:28:44,000 --> 00:28:49,000
+And I promised to show you the log file for my users home director.
+
+334
+00:28:50,000 --> 00:28:51,000
+Here it is.
+
+335
+00:28:51,000 --> 00:28:53,000
+Excellent for model.
+
+336
+00:28:53,000 --> 00:28:57,000
+Helped us to format log record in eczema form.
+
+337
+00:28:57,000 --> 00:28:58,000
+Pay attention.
+
+338
+00:28:58,000 --> 00:29:02,000
+Is that in this case, I don't use global logger.
+
+339
+00:29:02,000 --> 00:29:05,000
+I use logger with the class name.
+
+340
+00:29:05,000 --> 00:29:13,000
+So what is a common practice to use global logger for all the times or to use logger with the name of
+
+341
+00:29:13,000 --> 00:29:14,000
+the class?
+
+342
+00:29:15,000 --> 00:29:16,000
+Let's figure it out together.
+
+343
+00:29:17,000 --> 00:29:24,000
+There is a practice of using logger per class and now example with Java two logging.
+
+344
+00:29:24,000 --> 00:29:32,000
+I showed you also how to configure one global logger, but it is possible to have logger per class like
+
+345
+00:29:32,000 --> 00:29:39,000
+I showed you in the second example where the name of the logger is the same as the name of the class.
+
+346
+00:29:39,000 --> 00:29:43,000
+This is pretty common practice and has some advantages.
+
+347
+00:29:43,000 --> 00:29:50,000
+Namely, using one logger per class makes it easy to capture the source of the log message.
+
+348
+00:29:50,000 --> 00:29:53,000
+That is a class right into the law.
+
+349
+00:29:53,000 --> 00:30:01,000
+If you don't have one logger per class, but instead you have one logger for the entire app, you need
+
+350
+00:30:01,000 --> 00:30:08,000
+to make additional actions to clarify whether the log message is a common form using logger.
+
+351
+00:30:09,000 --> 00:30:14,000
+Plus, you will always know where a particular log statement came from.
+
+352
+00:30:14,000 --> 00:30:22,000
+If you include the name of the logger in your log output form, you can control what log statements
+
+353
+00:30:22,000 --> 00:30:30,000
+you see at the fine grained level by turning certain loggers on or off or setting the level.
+
+354
+00:30:31,000 --> 00:30:38,000
+Just wanted to highlight that this can be considered as a part of code in style or common practice when
+
+355
+00:30:38,000 --> 00:30:41,000
+we create multiple loggers per each class.
+
+356
+00:30:42,000 --> 00:30:46,000
+These are the main things that I wanted to tell you about the Java logging framework.
+
+357
+00:30:47,000 --> 00:30:51,000
+I also left the source code examples in attachments to the lesson.
+
+358
+00:30:52,000 --> 00:30:53,000
+Feel free to check those.
+
+359
+00:30:54,000 --> 00:30:55,000
+Definitely.
+
+360
+00:30:55,000 --> 00:31:01,000
+You have to practice your skills with logging, even in case something will be not clear.
+
+361
+00:31:01,000 --> 00:31:08,000
+Please do not hesitate to ask your questions below this video and I will be happy to answer.
+
+362
+00:31:09,000 --> 00:31:10,000
+Let's move on.
+
diff --git a/75 - Logging in Java/001 Source-code-examples-from-the-lesson.url b/75 - Logging in Java/001 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..d2584199f66ec6740563c410f1952d319ebc81b7
--- /dev/null
+++ b/75 - Logging in Java/001 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.core/src/main/java/com/itbulls/learnit/onlinestore/core/logging
\ No newline at end of file
diff --git a/75 - Logging in Java/001 java.util.logging-package-official-documentation.url b/75 - Logging in Java/001 java.util.logging-package-official-documentation.url
new file mode 100644
index 0000000000000000000000000000000000000000..900e27b0b287aee253e40f75606959aa204fd5a2
--- /dev/null
+++ b/75 - Logging in Java/001 java.util.logging-package-official-documentation.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://docs.oracle.com/en/java/javase/17/docs/api/java.logging/java/util/logging/package-summary.html
\ No newline at end of file
diff --git a/75 - Logging in Java/002 Log4J-2-Official-Documentation-about-Layouts.url b/75 - Logging in Java/002 Log4J-2-Official-Documentation-about-Layouts.url
new file mode 100644
index 0000000000000000000000000000000000000000..8607f1ecbc113eac797bccbaa87341014f2d34d2
--- /dev/null
+++ b/75 - Logging in Java/002 Log4J-2-Official-Documentation-about-Layouts.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://logging.apache.org/log4j/2.x/manual/layouts.html
\ No newline at end of file
diff --git a/75 - Logging in Java/002 Log4J-2-Official-documentation-about-Appenders.url b/75 - Logging in Java/002 Log4J-2-Official-documentation-about-Appenders.url
new file mode 100644
index 0000000000000000000000000000000000000000..45682e15fd07cc52752aed1031dc9cd2350b43b8
--- /dev/null
+++ b/75 - Logging in Java/002 Log4J-2-Official-documentation-about-Appenders.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://logging.apache.org/log4j/2.x/manual/appenders.html
\ No newline at end of file
diff --git a/75 - Logging in Java/002 Logback-configuration-documentation.url b/75 - Logging in Java/002 Logback-configuration-documentation.url
new file mode 100644
index 0000000000000000000000000000000000000000..2bcc33fa3942c693a90505c09b15963f81a35386
--- /dev/null
+++ b/75 - Logging in Java/002 Logback-configuration-documentation.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://logback.qos.ch/manual/configuration.html
\ No newline at end of file
diff --git a/75 - Logging in Java/002 Logging in Java Part 2 (Log4J, Logback, SLF4J)_en.srt b/75 - Logging in Java/002 Logging in Java Part 2 (Log4J, Logback, SLF4J)_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..73bac4d01ca7a8f5fed2531c9df2580553122bfb
--- /dev/null
+++ b/75 - Logging in Java/002 Logging in Java Part 2 (Log4J, Logback, SLF4J)_en.srt
@@ -0,0 +1,1432 @@
+1
+00:00:03,000 --> 00:00:07,000
+Now let's learn log for J and review how we can use it.
+
+2
+00:00:07,000 --> 00:00:14,000
+Before we jump to practical examples, let me hold an overview of log for J Library.
+
+3
+00:00:14,000 --> 00:00:18,000
+Partial log for J is a Java based log utility.
+
+4
+00:00:19,000 --> 00:00:25,000
+It is a part of a partial log and services a project of the purchase of foundation.
+
+5
+00:00:26,000 --> 00:00:36,000
+The partial log for G team developed log for G two in response to the problems of rock for J 1.21.3
+
+6
+00:00:36,000 --> 00:00:43,000
+Java to log in and log back addressing issues which appear in those frameworks.
+
+7
+00:00:43,000 --> 00:00:53,000
+In addition, log for G two offered a plugin architecture which makes it more extensible than its predecessor.
+
+8
+00:00:54,000 --> 00:01:03,000
+On December 9th, 20/21, a zero day vulnerability involving arbitrary code execution in log four G
+
+9
+00:01:03,000 --> 00:01:07,000
+was published by the Alibaba Cloud Security Team.
+
+10
+00:01:07,000 --> 00:01:15,000
+It has been characterized by some cybersecurity experts as the single biggest, most critical vulnerability
+
+11
+00:01:15,000 --> 00:01:17,000
+of the last decade.
+
+12
+00:01:17,000 --> 00:01:27,000
+Apache Log 4g2 is a successor of the log 4g1, which was released as ag8 version in July 2014.
+
+13
+00:01:29,000 --> 00:01:32,000
+J stands for general availability.
+
+14
+00:01:32,000 --> 00:01:39,000
+G A general products and features are open to all customers ready for production use.
+
+15
+00:01:40,000 --> 00:01:48,000
+The framework was rewritten from scratch and has been inspired by existing log in solutions, including
+
+16
+00:01:48,000 --> 00:01:51,000
+Lock for G one and Jabber to log in.
+
+17
+00:01:52,000 --> 00:02:00,000
+One of the most recognized features of Log for G two is the performance of the asynchronous loggers.
+
+18
+00:02:00,000 --> 00:02:04,000
+Let's now check log for g rock levels.
+
+19
+00:02:05,000 --> 00:02:13,000
+The table on the slide defines the built in log levels in log four g in decreasing order of severity.
+
+20
+00:02:13,000 --> 00:02:21,000
+The left column reads the lock level designation in lock for G, and the right column provides a brief
+
+21
+00:02:21,000 --> 00:02:29,000
+description of each lock level we reviewed already with view lock levels for a4g.
+
+22
+00:02:29,000 --> 00:02:35,000
+As you can see, lock levels of lock for G are pretty similar.
+
+23
+00:02:35,000 --> 00:02:38,000
+That's why I wouldn't stop on them now.
+
+24
+00:02:39,000 --> 00:02:44,000
+Feel free to press a pause in the video to read the slide attentively.
+
+25
+00:02:45,000 --> 00:02:50,000
+Log for G two allows users to define their own lock levels.
+
+26
+00:02:51,000 --> 00:02:57,000
+Custom lock levels can either complement or replace the built in lock levels.
+
+27
+00:02:58,000 --> 00:03:03,000
+Let's review three key structural elements of work for J Library.
+
+28
+00:03:04,000 --> 00:03:12,000
+They are loggers, pandas and layouts, loggers log message destinations.
+
+29
+00:03:12,000 --> 00:03:16,000
+They are the names that are known to the Java application.
+
+30
+00:03:17,000 --> 00:03:22,000
+Each logger is independently configurable as to what level of logging.
+
+31
+00:03:22,000 --> 00:03:24,000
+It currently logs.
+
+32
+00:03:24,000 --> 00:03:29,000
+A logger can send lock messages to multiple pandas.
+
+33
+00:03:30,000 --> 00:03:33,000
+A panda makes the actual output.
+
+34
+00:03:33,000 --> 00:03:41,000
+There are numerous pandas available with descriptive names such as file a panda rolling, file a panda
+
+35
+00:03:41,000 --> 00:03:51,000
+console, a panda socket, a panda syslog, a panda and a SMTP panda log for G to add the pandas.
+
+36
+00:03:51,000 --> 00:03:54,000
+Is it right to approach a flume?
+
+37
+00:03:54,000 --> 00:04:04,000
+The Java Persistence API Apache, Kafka, NoSQL databases, memory map files, random access files and
+
+38
+00:04:04,000 --> 00:04:13,000
+zero and Q and points multiple pandas can be attached to any longer, so it's possible to log the same
+
+39
+00:04:13,000 --> 00:04:21,000
+information to multiple outputs, for example, to a file locally and to a socket listener on another
+
+40
+00:04:21,000 --> 00:04:22,000
+computer.
+
+41
+00:04:23,000 --> 00:04:30,000
+Layouts are used to format log entries, a popular way to format one line at a time.
+
+42
+00:04:31,000 --> 00:04:34,000
+Log files is portion layout.
+
+43
+00:04:34,000 --> 00:04:44,000
+There are also HTML layout and X layout formats for use when HTML or XML formats are more convenient
+
+44
+00:04:44,000 --> 00:04:45,000
+respectively.
+
+45
+00:04:45,000 --> 00:04:52,000
+Look for G to edit the layouts for CC ray lock extended lock format.
+
+46
+00:04:52,000 --> 00:04:54,000
+JSON yaml.
+
+47
+00:04:55,000 --> 00:04:58,000
+Let's proceed with a demo of the lock for J.
+
+48
+00:04:59,000 --> 00:05:05,000
+First of all, before proceeding with the demo, we need to add a dependency to our form XML.
+
+49
+00:05:06,000 --> 00:05:13,000
+Since this is external library, we need to tell our build to the execute role of the dependency manager
+
+50
+00:05:13,000 --> 00:05:18,000
+that we need to add external library to the class boss.
+
+51
+00:05:18,000 --> 00:05:25,000
+You can check maven wrapper and find that there are really a lot of different libraries published for
+
+52
+00:05:25,000 --> 00:05:25,000
+log.
+
+53
+00:05:25,000 --> 00:05:31,000
+For G, we look for G core and look for g API.
+
+54
+00:05:31,000 --> 00:05:32,000
+Here.
+
+55
+00:05:32,000 --> 00:05:35,000
+You can see I added those into the XML.
+
+56
+00:05:36,000 --> 00:05:42,000
+Two words about configuration of lock for gene lock for GE can be configured through a configuration
+
+57
+00:05:42,000 --> 00:05:45,000
+file or through Java code.
+
+58
+00:05:45,000 --> 00:05:52,000
+Configuration files can be written in XML, JSON, YAML or properties file format.
+
+59
+00:05:53,000 --> 00:06:00,000
+Within a configuration, you can define three main components loggers, offenders and layouts.
+
+60
+00:06:01,000 --> 00:06:09,000
+Configuring log where file has the advantage that logging can be turned on or off without modifying
+
+61
+00:06:09,000 --> 00:06:12,000
+the application that uses log for G.
+
+62
+00:06:12,000 --> 00:06:21,000
+For example, the application can be allowed to run with logging off and users problem and then logging
+
+63
+00:06:21,000 --> 00:06:26,000
+can be turned back on simply by modifying the configuration file.
+
+64
+00:06:26,000 --> 00:06:34,000
+We already configured Java log in framework from the code and with the help of properties format.
+
+65
+00:06:34,000 --> 00:06:42,000
+Let me show you how to configure log for G was XML format in the resources source folder, you can find
+
+66
+00:06:43,000 --> 00:06:45,000
+XML configuration for log for G.
+
+67
+00:06:46,000 --> 00:06:49,000
+Let's go over it to review key things.
+
+68
+00:06:50,000 --> 00:06:55,000
+Configuration the route element of log for j to configuration file.
+
+69
+00:06:55,000 --> 00:07:02,000
+The status attribute represents the level at which internal log for J events should be log.
+
+70
+00:07:03,000 --> 00:07:06,000
+After that, we declare multiple offenders.
+
+71
+00:07:06,000 --> 00:07:15,000
+You can see here, console a panda pay attention that inside each offender we describe layout how actually
+
+72
+00:07:15,000 --> 00:07:19,000
+our log messages will be printed.
+
+73
+00:07:19,000 --> 00:07:25,000
+Notice as a part of layout element, this determines how message should look like.
+
+74
+00:07:26,000 --> 00:07:36,000
+In our example, the pardon consists from parameters where person sign determines date pawn person sign
+
+75
+00:07:36,000 --> 00:07:47,000
+p output of low level person side output of locked message and person sign and adds a new line character.
+
+76
+00:07:48,000 --> 00:07:50,000
+More info about Portland.
+
+77
+00:07:50,000 --> 00:07:57,000
+You can find unofficial lock for G two page and want to leave a reference in attachments to the lesson
+
+78
+00:07:57,000 --> 00:08:01,000
+to the log for g to documentation about layouts.
+
+79
+00:08:02,000 --> 00:08:04,000
+Next we have file a panda.
+
+80
+00:08:05,000 --> 00:08:14,000
+Also nothing special here will just handle the log records and we'll bring them into the file here.
+
+81
+00:08:14,000 --> 00:08:18,000
+I specified file name and pattern layout for messages.
+
+82
+00:08:19,000 --> 00:08:20,000
+Roland File and.
+
+83
+00:08:21,000 --> 00:08:23,000
+This is an interesting one.
+
+84
+00:08:23,000 --> 00:08:25,000
+Let me elaborate a bit more about it.
+
+85
+00:08:26,000 --> 00:08:31,000
+Morgan Everson into single file is, of course, not ideal.
+
+86
+00:08:31,000 --> 00:08:39,000
+It's usually much better to roll over the active log file regularly, which is exactly what the Roland
+
+87
+00:08:39,000 --> 00:08:41,000
+File append does.
+
+88
+00:08:41,000 --> 00:08:50,000
+You'll also be able to go beyond the basics with this type of append and configure both a custom trigger
+
+89
+00:08:50,000 --> 00:08:58,000
+and policy, as well as a rollover strategy before going in first as a prepared configuration example.
+
+90
+00:08:58,000 --> 00:09:04,000
+Let's make sure we understand triggering policies and rollover strategies.
+
+91
+00:09:04,000 --> 00:09:13,000
+The trigger and policy determines when the log file is rolled, meaning a new file is created while
+
+92
+00:09:13,000 --> 00:09:19,000
+the rollover strategy determines how the file is rolled.
+
+93
+00:09:19,000 --> 00:09:22,000
+Let me explain triggering policies first.
+
+94
+00:09:23,000 --> 00:09:25,000
+There are different triggering policies.
+
+95
+00:09:26,000 --> 00:09:29,000
+The composite trigger and policy.
+
+96
+00:09:30,000 --> 00:09:38,000
+It combines multiple triggering policies and returns true if any of the configured policies return true.
+
+97
+00:09:38,000 --> 00:09:46,000
+The composite triggering policy is configured simply by wrapping other policies in the policies element.
+
+98
+00:09:47,000 --> 00:09:49,000
+Crown triggering policy.
+
+99
+00:09:49,000 --> 00:09:55,000
+The current trigger and policy triggers rollover based on a common expression.
+
+100
+00:09:56,000 --> 00:10:05,000
+This policy is controlled by a time and is asynchronous to process in log events, so it is possible
+
+101
+00:10:05,000 --> 00:10:14,000
+that events from the previous or next time period may appear at the beginning or end of the log file.
+
+102
+00:10:15,000 --> 00:10:20,000
+The final part, an attribute of the panda should contain a timestamp.
+
+103
+00:10:20,000 --> 00:10:25,000
+Otherwise, the target file will be overridden on each revolver.
+
+104
+00:10:26,000 --> 00:10:35,000
+Start startup trading policy and you look for is created every time the gvm starts size based trigger
+
+105
+00:10:35,000 --> 00:10:36,000
+and policy.
+
+106
+00:10:36,000 --> 00:10:40,000
+The file is rolled when it reaches a certain size.
+
+107
+00:10:41,000 --> 00:10:50,000
+The size can be specified in bytes with the suffix k, b and B, g, b, or TB, for example.
+
+108
+00:10:50,000 --> 00:10:59,000
+20 megabytes the size may also contain a fractional value, such as 1.5 megabytes.
+
+109
+00:10:59,000 --> 00:11:01,000
+Time based triggering policy.
+
+110
+00:11:02,000 --> 00:11:07,000
+The log file is rolled based on a date time point.
+
+111
+00:11:07,000 --> 00:11:15,000
+The time based triggering policy causes error rollover once the date time pardon no longer applies to
+
+112
+00:11:15,000 --> 00:11:17,000
+the active file.
+
+113
+00:11:17,000 --> 00:11:25,000
+This policy accepts an internal attribute which indicates how frequently the rollover should occur based
+
+114
+00:11:25,000 --> 00:11:29,000
+on the time pattern and the modulate boolean attribute.
+
+115
+00:11:30,000 --> 00:11:36,000
+In case you don't specify within the interval there is a default values.
+
+116
+00:11:36,000 --> 00:11:37,000
+It is equal to one.
+
+117
+00:11:38,000 --> 00:11:47,000
+So if you have a part like year, months day, our file would be rolled every hour and if it is year
+
+118
+00:11:47,000 --> 00:11:51,000
+month, the file would be rolled every day.
+
+119
+00:11:52,000 --> 00:11:53,000
+That's it.
+
+120
+00:11:53,000 --> 00:11:55,000
+Regarding triggering policies.
+
+121
+00:11:55,000 --> 00:11:58,000
+Let's learn rollover strategies now.
+
+122
+00:11:59,000 --> 00:12:01,000
+There are different strategies.
+
+123
+00:12:02,000 --> 00:12:04,000
+Let's reduce them one by one.
+
+124
+00:12:05,000 --> 00:12:07,000
+Default Revolver Strategy.
+
+125
+00:12:08,000 --> 00:12:16,000
+The Default Revolver Strategy accepts both a daytime point and an integer from the file partnership
+
+126
+00:12:16,000 --> 00:12:18,000
+specified on the Roland File.
+
+127
+00:12:18,000 --> 00:12:20,000
+Append that itself.
+
+128
+00:12:21,000 --> 00:12:23,000
+User data important is present.
+
+129
+00:12:23,000 --> 00:12:28,000
+It will be replaced with the current date and time values.
+
+130
+00:12:28,000 --> 00:12:31,000
+It is a part and contains an integer.
+
+131
+00:12:31,000 --> 00:12:38,000
+It will be implemented on each rollover if the file part on ads was GC
+
+132
+00:12:38,000 --> 00:12:44,000
+.0.2.3.
+
+133
+00:12:44,000 --> 00:12:48,000
+pack 200 or dot x z.
+
+134
+00:12:48,000 --> 00:12:55,000
+The resulting archive will be compressed using the compression scheme that matches the surface.
+
+135
+00:12:56,000 --> 00:13:02,000
+The Default Revolver strategy supports three variations for incrementing the counter.
+
+136
+00:13:03,000 --> 00:13:05,000
+To illustrate how it works.
+
+137
+00:13:05,000 --> 00:13:09,000
+Suppose that the main attribute is set to one.
+
+138
+00:13:09,000 --> 00:13:12,000
+The max attribute is set to three.
+
+139
+00:13:12,000 --> 00:13:21,000
+The file name is Foo dot lock and the file name portion is foo dash person sign i log.
+
+140
+00:13:22,000 --> 00:13:25,000
+Explore on the slide number of rollovers.
+
+141
+00:13:25,000 --> 00:13:32,000
+Active Output Target Archived log files and description.
+
+142
+00:13:32,000 --> 00:13:37,000
+This should give you an understanding of how a rollover strategy will be applied.
+
+143
+00:13:39,000 --> 00:13:47,000
+Direct write rollover strategy is a direct rollover strategy causes events to be written directly to
+
+144
+00:13:47,000 --> 00:13:56,000
+files represented by the file form with this strategy file when names are not perform is the size based
+
+145
+00:13:56,000 --> 00:14:02,000
+triggering policies causes multiple files to be written during the specified time period.
+
+146
+00:14:03,000 --> 00:14:10,000
+They will be numbered starting at one and continually incremented until a time based rollover occurs.
+
+147
+00:14:11,000 --> 00:14:16,000
+And also there are two actions that can be used during the rollover.
+
+148
+00:14:16,000 --> 00:14:22,000
+They are delete action and assign and custom file attribute on a rollover.
+
+149
+00:14:23,000 --> 00:14:33,000
+Delete on a rollover log for G 2.5 introduces a delete action that gives users more control over what
+
+150
+00:14:33,000 --> 00:14:41,000
+files are deleted at a lower time than what was possible with the default rollover strategy marks attribute.
+
+151
+00:14:42,000 --> 00:14:50,000
+The Delete action lets users configure one or more conditions that select the files to delete relative
+
+152
+00:14:50,000 --> 00:14:52,000
+to base directory.
+
+153
+00:14:53,000 --> 00:15:02,000
+And in the custom file attribute log for g 2.9 introduces a positive view attribute action that gives
+
+154
+00:15:02,000 --> 00:15:10,000
+users more control over which file attribute permissions owner and group should be applied.
+
+155
+00:15:10,000 --> 00:15:19,000
+The Process View Attribute Action lets users configure one or more conditions that select the eligible
+
+156
+00:15:19,000 --> 00:15:22,000
+files relative to a base directory.
+
+157
+00:15:23,000 --> 00:15:27,000
+Now let's get back to our example of configuration.
+
+158
+00:15:29,000 --> 00:15:32,000
+Here you can see different rolling file offenders.
+
+159
+00:15:32,000 --> 00:15:39,000
+I created different configurations on purpose in order to demo how different triggering policies work
+
+160
+00:15:39,000 --> 00:15:40,000
+on practice.
+
+161
+00:15:41,000 --> 00:15:46,000
+You can see roll by size and roll by time and roll by time and size.
+
+162
+00:15:46,000 --> 00:15:47,000
+Append.
+
+163
+00:15:48,000 --> 00:15:52,000
+These examples may be useful for you in practice.
+
+164
+00:15:52,000 --> 00:15:55,000
+In the case you would need to configure logger.
+
+165
+00:15:55,000 --> 00:15:57,000
+You can refer to this learning materials.
+
+166
+00:15:58,000 --> 00:15:59,000
+Pay attention.
+
+167
+00:15:59,000 --> 00:16:05,000
+Like I already said in case file pardon name is ended with the extension of the archive.
+
+168
+00:16:06,000 --> 00:16:10,000
+Log for will, archive logs and compress files.
+
+169
+00:16:10,000 --> 00:16:14,000
+Thus we will save the space on the hard drive.
+
+170
+00:16:15,000 --> 00:16:23,000
+A Jersey file is an Archived file compressed by the standard G and u z compression algorithm.
+
+171
+00:16:24,000 --> 00:16:29,000
+J zip is primarily used on the UNIX operating systems for file compression.
+
+172
+00:16:30,000 --> 00:16:35,000
+I will share with you the source code of all examples and configurations.
+
+173
+00:16:35,000 --> 00:16:38,000
+Feel free to find them in attachments to the video.
+
+174
+00:16:39,000 --> 00:16:45,000
+Take your time to look through them and ask your questions below the video in case something is not
+
+175
+00:16:45,000 --> 00:16:48,000
+clear and I will be happy to answer.
+
+176
+00:16:49,000 --> 00:16:57,000
+And after that, I declare loggers for loggers in some specific package, I can override level.
+
+177
+00:16:57,000 --> 00:17:03,000
+I can configure concrete loggers and attach a pandas to them that we have prepared.
+
+178
+00:17:03,000 --> 00:17:08,000
+By the way, this is the name of the class that will use for Dharma.
+
+179
+00:17:09,000 --> 00:17:15,000
+As we have discussed, one of the features of Log for G2 is a synchronous log in.
+
+180
+00:17:15,000 --> 00:17:22,000
+This will help you to increase performance of your application by not making your program waiting until
+
+181
+00:17:22,000 --> 00:17:27,000
+log records will be processed to enable a synchronous log.
+
+182
+00:17:27,000 --> 00:17:32,000
+You need to add l mox disrupter library to your x amount.
+
+183
+00:17:33,000 --> 00:17:38,000
+Musk's disruptor is a free internet communication library.
+
+184
+00:17:38,000 --> 00:17:42,000
+I added this library into XML on the global level.
+
+185
+00:17:42,000 --> 00:17:43,000
+Here it is.
+
+186
+00:17:44,000 --> 00:17:51,000
+Now, when we added this library into the class pass, we need to make some changes in our configuration
+
+187
+00:17:51,000 --> 00:17:51,000
+file.
+
+188
+00:17:51,000 --> 00:18:01,000
+We need to add a root element and inside it will specify a pandas that we want to make work asynchronously.
+
+189
+00:18:01,000 --> 00:18:07,000
+Now, when we are done with configuration, let's jump to code examples.
+
+190
+00:18:07,000 --> 00:18:14,000
+All code examples related to log for g two are located in the package that is called log for G.
+
+191
+00:18:15,000 --> 00:18:17,000
+We have two classes here.
+
+192
+00:18:17,000 --> 00:18:18,000
+Log for J.
+
+193
+00:18:18,000 --> 00:18:25,000
+Two demo is a simple one and this class will just take longer and log some messages.
+
+194
+00:18:26,000 --> 00:18:27,000
+Nothing special.
+
+195
+00:18:28,000 --> 00:18:33,000
+This is just simple example, just to get you more familiar with the API.
+
+196
+00:18:33,000 --> 00:18:41,000
+For the second example, we can figure it all in file a pandas and here specific logic that will allow
+
+197
+00:18:41,000 --> 00:18:45,000
+us to reproduce different triggering policies that we have configured.
+
+198
+00:18:46,000 --> 00:18:49,000
+I configure delays and multiple iterations.
+
+199
+00:18:49,000 --> 00:18:54,000
+In this case, you will be able to see different triggering and policies in action.
+
+200
+00:18:55,000 --> 00:18:58,000
+Run these two programs on your computer.
+
+201
+00:18:58,000 --> 00:19:03,000
+Locks will be generated into the folders that we have configured.
+
+202
+00:19:04,000 --> 00:19:10,000
+We can just open the files with logs and even by the different amount of files in each folder.
+
+203
+00:19:10,000 --> 00:19:16,000
+You may guess that offenders work a little bit differently because of different configuration.
+
+204
+00:19:17,000 --> 00:19:24,000
+So the way how logs are separated between the files is different because we provided different configurations
+
+205
+00:19:24,000 --> 00:19:27,000
+for all and file offenders.
+
+206
+00:19:27,000 --> 00:19:31,000
+That tension is that we can figure out our pandas in that way.
+
+207
+00:19:31,000 --> 00:19:34,000
+That logs will be archived.
+
+208
+00:19:34,000 --> 00:19:42,000
+If you remember I said already, this is in case in our file name partner with specified archive extension,
+
+209
+00:19:42,000 --> 00:19:46,000
+then a log for g will archive our logs.
+
+210
+00:19:46,000 --> 00:19:50,000
+This feature will help you to save the space on your hard drive.
+
+211
+00:19:51,000 --> 00:19:56,000
+And it looks like that's all what I wanted to share with you regarding log for Jay.
+
+212
+00:19:56,000 --> 00:20:04,000
+And as I already said, even in case you have any questions, please don't hesitate to ask your questions
+
+213
+00:20:04,000 --> 00:20:07,000
+below this video and I will be happy to answer.
+
+214
+00:20:07,000 --> 00:20:09,000
+Let's continue with learning.
+
+215
+00:20:09,000 --> 00:20:10,000
+Log back library.
+
+216
+00:20:11,000 --> 00:20:18,000
+Log backs started as an intended successor to the first version of the Log for G project, claiming
+
+217
+00:20:18,000 --> 00:20:25,000
+faster implementation, better tests, native support for integration and more.
+
+218
+00:20:25,000 --> 00:20:33,000
+It is built out of three main modules and integrates with several containers such as Stump, Card or
+
+219
+00:20:33,000 --> 00:20:40,000
+Jetty to provide HTTP access log functionality similar to the log for Jay Z.
+
+220
+00:20:40,000 --> 00:20:44,000
+Log back architecture consists of three key elements.
+
+221
+00:20:44,000 --> 00:20:51,000
+They are logger, append and layout, and log is a context for log messages.
+
+222
+00:20:51,000 --> 00:20:57,000
+This is a class that applications interact with to create log messages.
+
+223
+00:20:57,000 --> 00:21:01,000
+Offenders place log messages in their final destinations.
+
+224
+00:21:02,000 --> 00:21:04,000
+A log can have more than one append.
+
+225
+00:21:05,000 --> 00:21:12,000
+And again, if you watched the lesson about Java, log in framework and log for G, you can see that
+
+226
+00:21:12,000 --> 00:21:18,000
+the concept is similar to what we have already learned and layout element.
+
+227
+00:21:18,000 --> 00:21:22,000
+It is used to prepare messages for output and formatted.
+
+228
+00:21:22,000 --> 00:21:30,000
+Log Back supports the creation of custom classes for formatting messages as well as robust configuration
+
+229
+00:21:30,000 --> 00:21:32,000
+options for the existing ones.
+
+230
+00:21:33,000 --> 00:21:38,000
+The Log Back project is organized in the main three modules.
+
+231
+00:21:38,000 --> 00:21:44,000
+The log back core contains the basic log and functionality.
+
+232
+00:21:44,000 --> 00:21:51,000
+Log back classic contains additional log in improvements such as a self for G support.
+
+233
+00:21:52,000 --> 00:21:59,000
+Log Back Access provides integration with the servlet containers such as Tomcat and Jetty.
+
+234
+00:22:00,000 --> 00:22:07,000
+So why would you opt for log back instead of log for G two, for example, to be completely honest with
+
+235
+00:22:07,000 --> 00:22:08,000
+you, log for G.
+
+236
+00:22:08,000 --> 00:22:15,000
+Version two nowadays probably is the most flexible tool with the best performance on the market, and
+
+237
+00:22:15,000 --> 00:22:21,000
+it is hard for me to find advantages that log back has over log for G.
+
+238
+00:22:21,000 --> 00:22:29,000
+Two Most of the advantages that you would find in the Internet and comparisons with Log for G are related
+
+239
+00:22:29,000 --> 00:22:36,000
+to the comparisons with the log for G version one, but not log for G version two.
+
+240
+00:22:36,000 --> 00:22:44,000
+One of the most important advantages of log back is that log back natively implements the self for G
+
+241
+00:22:44,000 --> 00:22:45,000
+API.
+
+242
+00:22:45,000 --> 00:22:51,000
+This means that if you are using log back, you are actually using the self for API.
+
+243
+00:22:52,000 --> 00:22:59,000
+You could theoretically use the internals of the log back API directly for log in, but that is highly
+
+244
+00:22:59,000 --> 00:23:00,000
+discouraged.
+
+245
+00:23:00,000 --> 00:23:08,000
+All log back documentation and examples on loggers are written in terms of the self for G API.
+
+246
+00:23:08,000 --> 00:23:11,000
+Let's have a demo and learn how to use.
+
+247
+00:23:11,000 --> 00:23:13,000
+Log back on practice.
+
+248
+00:23:13,000 --> 00:23:19,000
+The first thing that we need to do is to add all required dependencies into the class POS.
+
+249
+00:23:19,000 --> 00:23:23,000
+You can add on the log back plus dependency.
+
+250
+00:23:23,000 --> 00:23:30,000
+It contains dependencies on other required modules and it will then load all necessary modules.
+
+251
+00:23:31,000 --> 00:23:39,000
+This single dependency is enough as it will transitive the log back core and a self for API dependencies.
+
+252
+00:23:40,000 --> 00:23:44,000
+The next thing that you need to do is to define configuration.
+
+253
+00:23:44,000 --> 00:23:47,000
+With no custom configuration is defined.
+
+254
+00:23:47,000 --> 00:23:53,000
+Log back provides a simple automatic configuration on its own by default.
+
+255
+00:23:54,000 --> 00:24:00,000
+This ensures that log statements are presented to the console at the box level.
+
+256
+00:24:00,000 --> 00:24:08,000
+Consequently, you can now obtain a logger instance and start writing log messages using the default
+
+257
+00:24:08,000 --> 00:24:09,000
+basic config.
+
+258
+00:24:10,000 --> 00:24:13,000
+But let's create some basic configuration.
+
+259
+00:24:13,000 --> 00:24:18,000
+Again in the resources folder we can create a configuration for log back.
+
+260
+00:24:19,000 --> 00:24:23,000
+There are three valid standard file names you can choose from.
+
+261
+00:24:24,000 --> 00:24:27,000
+Log back, dash test XML.
+
+262
+00:24:27,000 --> 00:24:30,000
+Log back, groovy log back.
+
+263
+00:24:30,000 --> 00:24:37,000
+That XML in my example configuration file is called Log Back XML.
+
+264
+00:24:37,000 --> 00:24:40,000
+Let's take a look at it again.
+
+265
+00:24:40,000 --> 00:24:43,000
+This configuration is in XML format.
+
+266
+00:24:44,000 --> 00:24:46,000
+We have configuration element.
+
+267
+00:24:47,000 --> 00:24:50,000
+We can declare as much and pandas as we need.
+
+268
+00:24:50,000 --> 00:24:52,000
+The principle is the same.
+
+269
+00:24:53,000 --> 00:24:56,000
+Let's configure console, append and file append.
+
+270
+00:24:57,000 --> 00:25:01,000
+We can declare a loggers and override level for loggers.
+
+271
+00:25:02,000 --> 00:25:07,000
+In this particular example, we attach to a pandas to the root logger.
+
+272
+00:25:07,000 --> 00:25:08,000
+That's it.
+
+273
+00:25:09,000 --> 00:25:10,000
+This is a simple log back.
+
+274
+00:25:10,000 --> 00:25:11,000
+Configuration.
+
+275
+00:25:12,000 --> 00:25:19,000
+On top of all this, you can configure a SMTP, append email where you would like to receive locks,
+
+276
+00:25:19,000 --> 00:25:21,000
+configure levels for different offenders.
+
+277
+00:25:21,000 --> 00:25:29,000
+Basically, you can do the same level of configuration as we can do with lock for GE to take into account.
+
+278
+00:25:29,000 --> 00:25:32,000
+We covered lock for GE too already.
+
+279
+00:25:32,000 --> 00:25:34,000
+I wouldn't stop on this too much.
+
+280
+00:25:35,000 --> 00:25:41,000
+Anyway, in case you have any questions, please let me know and I will be happy to answer.
+
+281
+00:25:42,000 --> 00:25:48,000
+Source code of full examples related to the log back located in the log back package.
+
+282
+00:25:48,000 --> 00:25:52,000
+Let me open, close the scope log back demo.
+
+283
+00:25:52,000 --> 00:25:53,000
+This is simple clause.
+
+284
+00:25:54,000 --> 00:25:56,000
+Nothing extraordinary.
+
+285
+00:25:56,000 --> 00:26:03,000
+The only things that I'd like to draw your attention to is that I did a self for g import statements.
+
+286
+00:26:03,000 --> 00:26:09,000
+Do you remember I told that log back uses a self for API from out of the box?
+
+287
+00:26:10,000 --> 00:26:12,000
+That's exactly about this.
+
+288
+00:26:12,000 --> 00:26:19,000
+And when I run this program will lock message into console and into the file.
+
+289
+00:26:19,000 --> 00:26:23,000
+Taking into account we have to open this in our configuration file.
+
+290
+00:26:24,000 --> 00:26:31,000
+Definitely there are tons of other configurations, but they're similar to the log for G two that we
+
+291
+00:26:31,000 --> 00:26:34,000
+have reviewed and applied to specific cases.
+
+292
+00:26:35,000 --> 00:26:38,000
+Let me know in case you have any questions.
+
+293
+00:26:38,000 --> 00:26:39,000
+Let's continue.
+
+294
+00:26:40,000 --> 00:26:45,000
+And the last, but not the least is that we are going to review this lesson is a self for Jay.
+
+295
+00:26:46,000 --> 00:26:49,000
+Let's learn what it is a self for.
+
+296
+00:26:49,000 --> 00:26:52,000
+Jay stands for simple login facade for Java.
+
+297
+00:26:53,000 --> 00:26:58,000
+It provides a Java log in API by means of a simple facade pattern.
+
+298
+00:26:58,000 --> 00:27:06,000
+The underlying log in backend is determined at runtime by adding the desired binding to the class pass
+
+299
+00:27:06,000 --> 00:27:08,000
+and may be one of the following.
+
+300
+00:27:08,000 --> 00:27:19,000
+The standard Java to log in from JDK log for G, reload for G, log back tiny log in simple words,
+
+301
+00:27:19,000 --> 00:27:27,000
+you use interfaces and types from the self for G library, but at the same time you use any log in library
+
+302
+00:27:27,000 --> 00:27:28,000
+you want.
+
+303
+00:27:29,000 --> 00:27:37,000
+This is common handy when you want to achieve flexibility and you don't want be dependent on the API
+
+304
+00:27:37,000 --> 00:27:39,000
+of some specific library.
+
+305
+00:27:40,000 --> 00:27:48,000
+You use abstractions in your code, you write your code with interfaces from the self log library and
+
+306
+00:27:48,000 --> 00:27:56,000
+after that you just add implementation library to the class bus and that's it is a separation of the
+
+307
+00:27:56,000 --> 00:28:04,000
+client API from the log in back and reduces the coupling between an application and any particular log
+
+308
+00:28:04,000 --> 00:28:05,000
+in framework.
+
+309
+00:28:06,000 --> 00:28:14,000
+This can make it easier to integrate with existing or third party code or to deliver code into other
+
+310
+00:28:14,000 --> 00:28:18,000
+projects that have already made the choice of log in backend.
+
+311
+00:28:19,000 --> 00:28:27,000
+In January 2020 first, self for G was ranked as the second most popular project according to the MAVEN
+
+312
+00:28:27,000 --> 00:28:28,000
+Repository.
+
+313
+00:28:28,000 --> 00:28:31,000
+It is very popular across engineers.
+
+314
+00:28:31,000 --> 00:28:38,000
+Usually developers use a self for g together with log for G or a self for G was log back.
+
+315
+00:28:38,000 --> 00:28:39,000
+Probably.
+
+316
+00:28:39,000 --> 00:28:43,000
+These two combinations are the most popular nowadays across developers.
+
+317
+00:28:44,000 --> 00:28:45,000
+Let's proceed with the demo.
+
+318
+00:28:46,000 --> 00:28:47,000
+To use herself for phone.
+
+319
+00:28:48,000 --> 00:28:55,000
+We need to add bridge between the logger implementation that we are going to use and a self log.
+
+320
+00:28:55,000 --> 00:29:01,000
+For example, if I want to use a self for Jay was lock for Jay Z.
+
+321
+00:29:01,000 --> 00:29:06,000
+I need to add a log for Jay Self for Jay Input library to the class space.
+
+322
+00:29:07,000 --> 00:29:14,000
+This library in has its own transitive dependency and it will fetch a self for g API library.
+
+323
+00:29:15,000 --> 00:29:16,000
+That's it.
+
+324
+00:29:16,000 --> 00:29:25,000
+For the sake of the example, let's remove log back dependency because in case log back dependency will
+
+325
+00:29:25,000 --> 00:29:26,000
+be in the class.
+
+326
+00:29:26,000 --> 00:29:35,000
+Pass a self for g will use log back implementation to now we have only log for G two dependency and
+
+327
+00:29:35,000 --> 00:29:36,000
+bridge with a self for G.
+
+328
+00:29:37,000 --> 00:29:39,000
+Let me open examples.
+
+329
+00:29:39,000 --> 00:29:41,000
+It is called a self for G demo.
+
+330
+00:29:41,000 --> 00:29:49,000
+In this demo I use a self for g API to get the logger and when I run the program log for g two.
+
+331
+00:29:49,000 --> 00:29:53,000
+Implementation is used to actually perform log in.
+
+332
+00:29:53,000 --> 00:30:02,000
+That means this log for G configuration is read and the message is a captured with a configured appendix.
+
+333
+00:30:02,000 --> 00:30:06,000
+Let me open log for G two example log here it is.
+
+334
+00:30:07,000 --> 00:30:11,000
+All the events that we have just logged in our program here.
+
+335
+00:30:12,000 --> 00:30:20,000
+In case I would return back, log back dependency into the class POS log back configuration will be
+
+336
+00:30:20,000 --> 00:30:21,000
+used to.
+
+337
+00:30:22,000 --> 00:30:28,000
+Let's make sure that the MAVEN configuration is updated and run our program one more time.
+
+338
+00:30:30,000 --> 00:30:38,000
+You can see that a surfer told us that multiple bindings are found in the class space, but from the
+
+339
+00:30:38,000 --> 00:30:43,000
+log messages we can see that lock back implementation is used for logging.
+
+340
+00:30:44,000 --> 00:30:49,000
+So a self log gives you great flexibility with the self.
+
+341
+00:30:49,000 --> 00:30:57,000
+For G, you can actually write the code relying on the API and types from the self log library and you're
+
+342
+00:30:57,000 --> 00:31:03,000
+free to change log in library when you need, just like I showed you in the example.
+
+343
+00:31:04,000 --> 00:31:07,000
+That's all what I wanted to share with you about the fog.
+
+344
+00:31:08,000 --> 00:31:11,000
+Let's recap what we have learned in this lesson.
+
+345
+00:31:12,000 --> 00:31:13,000
+Wow.
+
+346
+00:31:13,000 --> 00:31:16,000
+We have learned really a lot in this topic.
+
+347
+00:31:16,000 --> 00:31:18,000
+Now you can become logging guru.
+
+348
+00:31:19,000 --> 00:31:21,000
+Let's recap what we have learned.
+
+349
+00:31:21,000 --> 00:31:24,000
+We learned what the logging and logs are.
+
+350
+00:31:25,000 --> 00:31:27,000
+We discussed goals of logging.
+
+351
+00:31:27,000 --> 00:31:31,000
+We reviewed different libraries for logging in Java.
+
+352
+00:31:32,000 --> 00:31:38,000
+We learned Java log in framework, log for J, log back and the self log.
+
+353
+00:31:39,000 --> 00:31:46,000
+We learned what the logging levels are and we reviewed practical examples with a review of configuration
+
+354
+00:31:46,000 --> 00:31:47,000
+for each library.
+
+355
+00:31:47,000 --> 00:31:51,000
+Now you know what triggering policies and rollover strategies are.
+
+356
+00:31:52,000 --> 00:31:54,000
+That's all for this lesson.
+
+357
+00:31:54,000 --> 00:31:56,000
+Thanks a lot for your attention.
+
+358
+00:31:56,000 --> 00:31:59,000
+Have a great day and see you in the next lesson.
+
diff --git a/75 - Logging in Java/002 Source-code-examples-from-the-lesson.url b/75 - Logging in Java/002 Source-code-examples-from-the-lesson.url
new file mode 100644
index 0000000000000000000000000000000000000000..d2584199f66ec6740563c410f1952d319ebc81b7
--- /dev/null
+++ b/75 - Logging in Java/002 Source-code-examples-from-the-lesson.url
@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.core/src/main/java/com/itbulls/learnit/onlinestore/core/logging
\ No newline at end of file
diff --git a/75 - Logging in Java/external-links.txt b/75 - Logging in Java/external-links.txt
new file mode 100644
index 0000000000000000000000000000000000000000..16f7bfb158f9a46ada61edad4f64a2c01a95e4e0
--- /dev/null
+++ b/75 - Logging in Java/external-links.txt
@@ -0,0 +1,18 @@
+
+001 java.util.logging-package-official-documentation
+https://docs.oracle.com/en/java/javase/17/docs/api/java.logging/java/util/logging/package-summary.html
+
+001 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.core/src/main/java/com/itbulls/learnit/onlinestore/core/logging
+
+002 Log4J-2-Official-Documentation-about-Layouts
+https://logging.apache.org/log4j/2.x/manual/layouts.html
+
+002 Log4J-2-Official-documentation-about-Appenders
+https://logging.apache.org/log4j/2.x/manual/appenders.html
+
+002 Logback-configuration-documentation
+https://logback.qos.ch/manual/configuration.html
+
+002 Source-code-examples-from-the-lesson
+https://github.com/AndriiPiatakha/java-learnit-web-online-store/tree/master/online-store.core/src/main/java/com/itbulls/learnit/onlinestore/core/logging
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/001 Introduction to Cybersecurity p.1 - Overview of current cyber threat landscape_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/001 Introduction to Cybersecurity p.1 - Overview of current cyber threat landscape_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..66ab02bce33dc50072f452a74906be0a2b52eb62
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/001 Introduction to Cybersecurity p.1 - Overview of current cyber threat landscape_en.srt
@@ -0,0 +1,392 @@
+1
+00:00:06,000 --> 00:00:11,000
+Hello dear students, in this lesson I'd like to make an introduction to the cybersecurity topic.
+
+2
+00:00:11,000 --> 00:00:15,000
+It will help you to understand what we are going to learn in this course, and how to navigate between
+
+3
+00:00:15,000 --> 00:00:17,000
+different lessons in the course.
+
+4
+00:00:18,000 --> 00:00:22,000
+Today we'll cover a comprehensive range of topics in cybersecurity.
+
+5
+00:00:22,000 --> 00:00:28,000
+We'll start with the definition and importance of cybersecurity, establishing why it's critical in
+
+6
+00:00:28,000 --> 00:00:29,000
+today's digital landscape.
+
+7
+00:00:29,000 --> 00:00:35,000
+Next, we'll explore the current cyber threat landscape, diving into various types of threats, including
+
+8
+00:00:35,000 --> 00:00:39,000
+malware, phishing attacks, and advanced persistent threats.
+
+9
+00:00:40,000 --> 00:00:46,000
+We'll also analyze real world case studies of cyber attacks to gain insights into their impact and the
+
+10
+00:00:46,000 --> 00:00:47,000
+lessons learned.
+
+11
+00:00:47,000 --> 00:00:54,000
+Following that, I'll introduce you to several threat analysis models, such as Stride and Dread, highlighting
+
+12
+00:00:54,000 --> 00:00:57,000
+how these frameworks help identify and mitigate risks.
+
+13
+00:00:58,000 --> 00:01:05,000
+Next, we'll discuss the OWASp framework and its significant role in enhancing application security,
+
+14
+00:01:05,000 --> 00:01:10,000
+including tools and standards like the Application Security Verification Standard.
+
+15
+00:01:11,000 --> 00:01:18,000
+We'll then delve into security architecture design and best practices, emphasizing the principles of
+
+16
+00:01:18,000 --> 00:01:20,000
+being secure by design.
+
+17
+00:01:20,000 --> 00:01:27,000
+We'll also cover the types of security controls, including preventive, detective and corrective measures,
+
+18
+00:01:27,000 --> 00:01:33,000
+and discuss the importance of writing and maintaining a security design document.
+
+19
+00:01:33,000 --> 00:01:38,000
+Additionally, we'll look at the significance of documenting security requirements and controls.
+
+20
+00:01:38,000 --> 00:01:44,000
+Finally, we'll wrap up with an overview of the Security Operations Center and discuss incident management
+
+21
+00:01:44,000 --> 00:01:47,000
+and its critical role in cyber security.
+
+22
+00:01:47,000 --> 00:01:49,000
+Let's start our lesson.
+
+23
+00:01:50,000 --> 00:01:56,000
+Cyber security is fundamentally the practice of protecting systems, networks and programs from digital
+
+24
+00:01:56,000 --> 00:01:57,000
+attacks.
+
+25
+00:01:57,000 --> 00:02:03,000
+In today's interconnected world, where technology plays a crucial role in our daily lives, the importance
+
+26
+00:02:03,000 --> 00:02:06,000
+of cybersecurity cannot be overstated.
+
+27
+00:02:06,000 --> 00:02:14,000
+Firstly, it serves to safeguard sensitive data, including personal, financial and confidential information
+
+28
+00:02:14,000 --> 00:02:16,000
+from unauthorized access and breaches.
+
+29
+00:02:17,000 --> 00:02:23,000
+As we increasingly rely on digital platforms, the threat of cyber attacks such as malware and ransomware
+
+30
+00:02:23,000 --> 00:02:26,000
+poses significant risks to individuals and organizations alike.
+
+31
+00:02:26,000 --> 00:02:32,000
+Therefore, effective cybersecurity measures are vital to prevent these attacks and ensure the continuity
+
+32
+00:02:32,000 --> 00:02:33,000
+of operations.
+
+33
+00:02:33,000 --> 00:02:40,000
+Moreover, a robust cybersecurity framework helps maintain trust between organizations and their customers.
+
+34
+00:02:40,000 --> 00:02:46,000
+When individuals know that their information is secure, they are more likely to engage with the business,
+
+35
+00:02:46,000 --> 00:02:49,000
+thus fostering a loyal customer base.
+
+36
+00:02:49,000 --> 00:02:55,000
+Additionally, compliance with regulatory requirements is another critical aspect.
+
+37
+00:02:55,000 --> 00:03:01,000
+Organizations must adhere to various legal standards that mandate the protection of data.
+
+38
+00:03:01,000 --> 00:03:05,000
+Furthermore, cybersecurity plays a key role in business continuity.
+
+39
+00:03:06,000 --> 00:03:13,000
+In the event of a cyber incident, having effective response strategies in place ensures that operations
+
+40
+00:03:13,000 --> 00:03:15,000
+can continue with minimal disruption.
+
+41
+00:03:16,000 --> 00:03:24,000
+Lastly, protecting an organization's reputation is crucial as a single data breach can lead to significant
+
+42
+00:03:24,000 --> 00:03:27,000
+damage to credibility and trust in the market.
+
+43
+00:03:28,000 --> 00:03:34,000
+As we delve into the current cyber threat landscape, it's essential to understand the various dimensions
+
+44
+00:03:34,000 --> 00:03:38,000
+of threats that organizations and individuals face today.
+
+45
+00:03:38,000 --> 00:03:45,000
+The digital world is constantly evolving, and with it, the tactics employed by cyber criminals have
+
+46
+00:03:45,000 --> 00:03:47,000
+become increasingly sophisticated.
+
+47
+00:03:48,000 --> 00:03:54,000
+I want to make a note that this is an overview lesson, and you have multiple hours still to watch and
+
+48
+00:03:54,000 --> 00:03:57,000
+learn from my course about cybersecurity.
+
+49
+00:03:57,000 --> 00:04:03,000
+So right now I will make a high level overview that should help you to navigate in the course and understand
+
+50
+00:04:03,000 --> 00:04:06,000
+at least some details about what we are going to learn.
+
+51
+00:04:07,000 --> 00:04:10,000
+And during the course, we are going to learn cyber threats in depth.
+
+52
+00:04:10,000 --> 00:04:16,000
+And of course, if you have any questions, please do not hesitate to post your questions below the
+
+53
+00:04:16,000 --> 00:04:18,000
+video and I will be happy to answer.
+
+54
+00:04:19,000 --> 00:04:23,000
+To begin with, we see a significant rise in malware attacks.
+
+55
+00:04:23,000 --> 00:04:29,000
+Malware, which includes viruses, trojans, and ransomware, is designed to infiltrate and disrupt
+
+56
+00:04:29,000 --> 00:04:30,000
+systems.
+
+57
+00:04:31,000 --> 00:04:38,000
+Ransomware, in particular, has gained notoriety as attackers encrypt an organization's data and demand
+
+58
+00:04:38,000 --> 00:04:39,000
+payment for its release.
+
+59
+00:04:39,000 --> 00:04:46,000
+This threat highlights the urgent need for robust cyber security measures, as the financial and reputational
+
+60
+00:04:46,000 --> 00:04:49,000
+damage from such attacks can be devastating.
+
+61
+00:04:49,000 --> 00:04:53,000
+In addition to malware, phishing attacks have become alarmingly prevalent.
+
+62
+00:04:54,000 --> 00:05:00,000
+These attacks typically involve deceptive emails or messages designed to trick individuals into revealing
+
+63
+00:05:00,000 --> 00:05:03,000
+sensitive information such as login credentials.
+
+64
+00:05:03,000 --> 00:05:10,000
+As technology advances, so too do the tactics used in phishing, making it more challenging for individuals
+
+65
+00:05:10,000 --> 00:05:13,000
+to discern legitimate communications from malicious ones.
+
+66
+00:05:14,000 --> 00:05:19,000
+Consequently, awareness and education are critical in combating this threat.
+
+67
+00:05:19,000 --> 00:05:25,000
+Furthermore, we cannot overlook the risks associated with man in the middle attacks.
+
+68
+00:05:26,000 --> 00:05:32,000
+In this scenario, an attacker secretly intercepts and relays messages between two parties, often without
+
+69
+00:05:32,000 --> 00:05:33,000
+their knowledge.
+
+70
+00:05:34,000 --> 00:05:40,000
+This type of threat underscores the importance of secure communication channels, such as the use of
+
+71
+00:05:40,000 --> 00:05:43,000
+encryption to protect sensitive information during transmission.
+
+72
+00:05:44,000 --> 00:05:49,000
+Moreover, denial of service attacks present another significant challenge.
+
+73
+00:05:49,000 --> 00:05:54,000
+These attacks aim to overwhelm a system with traffic, rendering it inoperable.
+
+74
+00:05:54,000 --> 00:06:01,000
+Such disruptions can lead to severe operational downtime, highlighting the necessity for organizations
+
+75
+00:06:01,000 --> 00:06:06,000
+to implement effective mitigation strategies to maintain service availability.
+
+76
+00:06:07,000 --> 00:06:12,000
+In recent years, we have also witnessed an increase in insider threats.
+
+77
+00:06:12,000 --> 00:06:18,000
+These can come from employees or contractors who intentionally or unintentionally compromise security.
+
+78
+00:06:18,000 --> 00:06:24,000
+This phenomenon emphasizes the need for comprehensive security training and policies that address not
+
+79
+00:06:24,000 --> 00:06:29,000
+only external threats, but also the potential risks from within an organization.
+
+80
+00:06:30,000 --> 00:06:34,000
+Additionally, we should be aware of the emerging threat of social engineering.
+
+81
+00:06:34,000 --> 00:06:41,000
+This encompasses a range of tactics that exploit human psychology to manipulate individuals into divulging
+
+82
+00:06:41,000 --> 00:06:43,000
+confidential information.
+
+83
+00:06:44,000 --> 00:06:50,000
+Social engineering can take many forms, including pretexting, baiting, and tailgating.
+
+84
+00:06:51,000 --> 00:06:58,000
+The human factor is often the weakest link in security, reinforcing the need for ongoing security awareness
+
+85
+00:06:58,000 --> 00:07:00,000
+training for all employees.
+
+86
+00:07:01,000 --> 00:07:07,000
+Lastly, the rise of advanced persistent threats poses a significant concern for organizations, particularly
+
+87
+00:07:07,000 --> 00:07:10,000
+in sectors such as finance and government.
+
+88
+00:07:10,000 --> 00:07:16,000
+Advanced persistent threats involve prolonged and targeted cyber attacks, where attackers gain unauthorized
+
+89
+00:07:16,000 --> 00:07:21,000
+access to a network and remain undetected for extended periods.
+
+90
+00:07:21,000 --> 00:07:27,000
+This necessitates the implementation of advanced threat detection and response capabilities, as well
+
+91
+00:07:27,000 --> 00:07:29,000
+as a proactive security posture.
+
+92
+00:07:30,000 --> 00:07:35,000
+Finally, it's important to recognize the evolving nature of cyber threats, driven in part by advancements
+
+93
+00:07:35,000 --> 00:07:36,000
+in technology.
+
+94
+00:07:37,000 --> 00:07:42,000
+With the rise of the Internet of Things, for instance, more devices are connected to the internet
+
+95
+00:07:42,000 --> 00:07:43,000
+than ever before.
+
+96
+00:07:43,000 --> 00:07:46,000
+Expanding the attack surface available to cyber criminals.
+
+97
+00:07:46,000 --> 00:07:52,000
+Consequently, organizations must remain vigilant and proactive in their cybersecurity efforts to adapt
+
+98
+00:07:52,000 --> 00:07:53,000
+to this changing landscape.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/002 Introduction to Cybersecurity p.2 - Case Studies, Threat Analysis Models & More_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/002 Introduction to Cybersecurity p.2 - Case Studies, Threat Analysis Models & More_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..67f2d529995a64ef6b5b963871ed5d46ab57a550
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/002 Introduction to Cybersecurity p.2 - Case Studies, Threat Analysis Models & More_en.srt
@@ -0,0 +1,896 @@
+1
+00:00:03,000 --> 00:00:09,000
+To truly understand the implications of cybersecurity, it is beneficial to examine real world case
+
+2
+00:00:09,000 --> 00:00:11,000
+studies of cyber attacks.
+
+3
+00:00:11,000 --> 00:00:17,000
+These examples illustrate not only the tactics employed by cybercriminals, but also the profound impact
+
+4
+00:00:17,000 --> 00:00:20,000
+such attacks can have on organizations and individuals.
+
+5
+00:00:22,000 --> 00:00:26,000
+One of the most notable examples is the Equifax breach of 2017.
+
+6
+00:00:26,000 --> 00:00:34,000
+This incident exposed the personal information of approximately 147 million people, including Social
+
+7
+00:00:34,000 --> 00:00:37,000
+Security numbers, birth dates and addresses.
+
+8
+00:00:37,000 --> 00:00:44,000
+The breach occurred due to a vulnerability in a web application framework that Equifax had failed to
+
+9
+00:00:44,000 --> 00:00:45,000
+patch.
+
+10
+00:00:45,000 --> 00:00:51,000
+This case highlights the critical importance of timely software updates and the need for organizations
+
+11
+00:00:51,000 --> 00:00:53,000
+to prioritize vulnerability management.
+
+12
+00:00:53,000 --> 00:00:59,000
+Furthermore, it emphasizes the potential consequences of inadequate security practices, which can
+
+13
+00:00:59,000 --> 00:01:03,000
+lead to significant reputational damage and financial loss.
+
+14
+00:01:04,000 --> 00:01:09,000
+Another significant case is the WannaCry ransomware attack, which affected hundreds of thousands of
+
+15
+00:01:09,000 --> 00:01:14,000
+computers in over 150 countries in May 2017.
+
+16
+00:01:14,000 --> 00:01:21,000
+This attack exploited a vulnerability in Microsoft Windows, encrypting users files and demanding ransom
+
+17
+00:01:21,000 --> 00:01:23,000
+payments in Bitcoin.
+
+18
+00:01:24,000 --> 00:01:30,000
+The rapid spread of WannaCry illustrated how quickly malware can propagate across networks, particularly
+
+19
+00:01:30,000 --> 00:01:33,000
+in environments that lack proper security measures.
+
+20
+00:01:33,000 --> 00:01:39,000
+Additionally, it underscored the necessity for organizations to implement comprehensive backup strategies
+
+21
+00:01:39,000 --> 00:01:46,000
+as those with secure backups were able to restore their systems without succumbing to the ransom demands.
+
+22
+00:01:47,000 --> 00:01:54,000
+We must also consider the target data breach of 2013, which compromised the credit and debit card information
+
+23
+00:01:54,000 --> 00:01:56,000
+of over 40 million customers.
+
+24
+00:01:56,000 --> 00:02:03,000
+This breach originated from network credentials stolen from a third party vendor, highlighting the
+
+25
+00:02:03,000 --> 00:02:05,000
+risks associated with supply chain security.
+
+26
+00:02:06,000 --> 00:02:12,000
+The incident serves as a reminder that organizations must extend their cybersecurity measures beyond
+
+27
+00:02:12,000 --> 00:02:18,000
+their internal systems to encompass all third party relationships, reinforcing the importance of vendor
+
+28
+00:02:18,000 --> 00:02:20,000
+management and rigorous security assessments.
+
+29
+00:02:22,000 --> 00:02:28,000
+Moreover, the SolarWinds attack, which came to light in late 2020, is another compelling case study.
+
+30
+00:02:28,000 --> 00:02:34,000
+This sophisticated supply chain attack involved the insertion of malicious code into a widely used software
+
+31
+00:02:34,000 --> 00:02:40,000
+platform, impacting thousands of organizations, including government agencies.
+
+32
+00:02:40,000 --> 00:02:46,000
+The SolarWinds incident showcases the growing threat of advanced persistent threats, where attackers
+
+33
+00:02:46,000 --> 00:02:51,000
+employ stealthy tactics to maintain long term access to compromised systems.
+
+34
+00:02:52,000 --> 00:02:59,000
+This case emphasizes the need for organizations to adopt a proactive and layered security approach,
+
+35
+00:02:59,000 --> 00:03:05,000
+incorporating threat detection and incident response capabilities to mitigate such risks.
+
+36
+00:03:06,000 --> 00:03:13,000
+Lastly, we should examine the Colonial Pipeline ransomware attack in May 2021, which resulted in the
+
+37
+00:03:13,000 --> 00:03:18,000
+shutdown of a major fuel pipeline supplying the East Coast of the United States.
+
+38
+00:03:18,000 --> 00:03:25,000
+This attack not only disrupted fuel supply, but also prompted widespread panic buying at gas stations.
+
+39
+00:03:25,000 --> 00:03:32,000
+The incident underscores the potential impact of cyber attacks on critical infrastructure and the interconnectedness
+
+40
+00:03:32,000 --> 00:03:34,000
+of various sectors.
+
+41
+00:03:34,000 --> 00:03:39,000
+It highlights the need for enhanced cyber security measures in critical industries, as well as the
+
+42
+00:03:39,000 --> 00:03:43,000
+importance of developing effective incident response plans.
+
+43
+00:03:44,000 --> 00:03:50,000
+As we delve into the realm of cyber security, understanding threat analysis models is essential for
+
+44
+00:03:50,000 --> 00:03:53,000
+effectively identifying and mitigating potential risks.
+
+45
+00:03:53,000 --> 00:04:00,000
+These models provide structured frameworks that help organizations assess threats in a systematic way,
+
+46
+00:04:00,000 --> 00:04:03,000
+ensuring a comprehensive approach to security.
+
+47
+00:04:03,000 --> 00:04:06,000
+And again, I want to highlight the goal of this lesson.
+
+48
+00:04:07,000 --> 00:04:09,000
+In this lesson we are making an overview.
+
+49
+00:04:09,000 --> 00:04:13,000
+All the details you will be able to learn gradually during the course.
+
+50
+00:04:13,000 --> 00:04:14,000
+So no stress.
+
+51
+00:04:14,000 --> 00:04:20,000
+And in case you have any questions, please post them below the video and I will be happy to answer.
+
+52
+00:04:22,000 --> 00:04:26,000
+To begin with, one of the most widely recognized models is Stride.
+
+53
+00:04:26,000 --> 00:04:33,000
+This acronym stands for spoofing, tampering, repudiation, information disclosure, Denial of Service,
+
+54
+00:04:33,000 --> 00:04:34,000
+and Elevation of Privilege.
+
+55
+00:04:34,000 --> 00:04:41,000
+Each element of Stride represents a distinct category of threats that can compromise system security.
+
+56
+00:04:41,000 --> 00:04:48,000
+For example, spoofing refers to an attacker impersonating a legitimate user or device, while tampering
+
+57
+00:04:48,000 --> 00:04:51,000
+involves unauthorized modifications to data.
+
+58
+00:04:51,000 --> 00:04:57,000
+By utilizing the Stride model, organizations can systematically evaluate their systems for vulnerabilities
+
+59
+00:04:57,000 --> 00:05:03,000
+associated with each of these threat categories, allowing them to implement targeted security controls.
+
+60
+00:05:04,000 --> 00:05:11,000
+Another important model is dread, which stands for damage, reproducibility, exploitability affected
+
+61
+00:05:11,000 --> 00:05:13,000
+users and discoverability.
+
+62
+00:05:13,000 --> 00:05:20,000
+Dread focuses on quantifying and prioritizing threats based on these five factors.
+
+63
+00:05:20,000 --> 00:05:26,000
+For instance, assessing the damage a potential threat could cause helps organizations gauge the severity
+
+64
+00:05:26,000 --> 00:05:27,000
+of its impact.
+
+65
+00:05:28,000 --> 00:05:34,000
+Exploitability examines how easily an attacker could execute a threat, while affected users evaluates
+
+66
+00:05:34,000 --> 00:05:36,000
+how many individuals would be impacted.
+
+67
+00:05:37,000 --> 00:05:43,000
+By assigning numerical values to these factors, organizations can prioritize threats based on their
+
+68
+00:05:43,000 --> 00:05:49,000
+overall risk, allowing for more effective resource allocation in mitigation efforts.
+
+69
+00:05:50,000 --> 00:05:56,000
+Additionally, the Bulgarian hexad offers a more nuanced view by incorporating six elements confidentiality,
+
+70
+00:05:56,000 --> 00:06:01,000
+integrity, availability, authenticity, possession, and utility.
+
+71
+00:06:01,000 --> 00:06:07,000
+This model emphasizes that security is not solely about protecting information, but also involves ensuring
+
+72
+00:06:07,000 --> 00:06:10,000
+that it is accessible and usable when needed.
+
+73
+00:06:11,000 --> 00:06:17,000
+By evaluating threats against these six dimensions, organizations can gain a comprehensive understanding
+
+74
+00:06:17,000 --> 00:06:20,000
+of their security posture and address potential weaknesses.
+
+75
+00:06:22,000 --> 00:06:26,000
+Furthermore, attack trees are another useful tool in threat analysis.
+
+76
+00:06:26,000 --> 00:06:32,000
+This model visualizes the various ways an attacker could achieve a specific goal, breaking it down
+
+77
+00:06:32,000 --> 00:06:33,000
+into a tree.
+
+78
+00:06:33,000 --> 00:06:35,000
+Structure of potential attack vectors.
+
+79
+00:06:35,000 --> 00:06:41,000
+Each branch represents a different method of attack, allowing security professionals to identify the
+
+80
+00:06:41,000 --> 00:06:43,000
+most likely and impactful threats.
+
+81
+00:06:43,000 --> 00:06:50,000
+This approach facilitates proactive defense strategies by enabling organizations to focus on high risk
+
+82
+00:06:50,000 --> 00:06:51,000
+areas.
+
+83
+00:06:52,000 --> 00:06:57,000
+Incorporating threat modeling into the software development life cycle is also crucial.
+
+84
+00:06:57,000 --> 00:07:02,000
+By integrating models like Stride and Dread early in the design phase.
+
+85
+00:07:02,000 --> 00:07:09,000
+Organizations can identify and address potential vulnerabilities before they are embedded in the system.
+
+86
+00:07:09,000 --> 00:07:15,000
+This proactive approach not only enhances security, but also reduces the cost of remediation in later
+
+87
+00:07:15,000 --> 00:07:16,000
+stages.
+
+88
+00:07:18,000 --> 00:07:24,000
+To understand the landscape of cybersecurity, it is essential to recognize the contributions of the
+
+89
+00:07:24,000 --> 00:07:28,000
+Open Web Application Security Project, founded in 2001.
+
+90
+00:07:29,000 --> 00:07:34,000
+OWASp is a non-profit organization dedicated to improving the security of software.
+
+91
+00:07:34,000 --> 00:07:41,000
+Its mission is to provide unbiased, practical information about computer security and to promote secure
+
+92
+00:07:41,000 --> 00:07:43,000
+software development practices.
+
+93
+00:07:43,000 --> 00:07:50,000
+At the heart of OWASp initiatives is the OWASp top ten, a regularly updated list that outlines the
+
+94
+00:07:50,000 --> 00:07:53,000
+most critical security vulnerabilities affecting web applications.
+
+95
+00:07:53,000 --> 00:07:59,000
+Each entry on this list highlights common threats such as injection attacks, broken authentication,
+
+96
+00:07:59,000 --> 00:08:03,000
+and cross-site scripting by focusing on these prevalent issues.
+
+97
+00:08:03,000 --> 00:08:10,000
+OWASp empowers organizations to prioritize their security efforts and allocate resources effectively
+
+98
+00:08:10,000 --> 00:08:12,000
+to mitigate these risks.
+
+99
+00:08:12,000 --> 00:08:19,000
+The OWASp top ten serves as both an educational tool and a practical guide for developers and security
+
+100
+00:08:19,000 --> 00:08:20,000
+professionals alike.
+
+101
+00:08:21,000 --> 00:08:27,000
+In addition to the top ten, OWASp offers a variety of resources and projects that contribute to the
+
+102
+00:08:27,000 --> 00:08:29,000
+field of cybersecurity.
+
+103
+00:08:29,000 --> 00:08:36,000
+For instance, the OWASp Application Security Verification Standard provides a framework for specifying
+
+104
+00:08:36,000 --> 00:08:43,000
+security requirements and verifying the security of web applications by establishing a standard for
+
+105
+00:08:43,000 --> 00:08:44,000
+security verification.
+
+106
+00:08:44,000 --> 00:08:51,000
+Organizations can ensure that their applications are robust and resistant to common vulnerabilities.
+
+107
+00:08:53,000 --> 00:09:00,000
+AOSp also promotes the use of security testing tools through its projects such as the OWASp Zed Attack
+
+108
+00:09:00,000 --> 00:09:01,000
+Proxy.
+
+109
+00:09:01,000 --> 00:09:07,000
+Zap is a powerful open source tool designed for finding vulnerabilities in web applications during the
+
+110
+00:09:07,000 --> 00:09:12,000
+testing phase by incorporating tools like Zap into the development process.
+
+111
+00:09:12,000 --> 00:09:19,000
+Organizations can identify and address security issues early, ultimately leading to more secure software.
+
+112
+00:09:20,000 --> 00:09:26,000
+Moreover, OWASp emphasizes the importance of community involvement in advancing cybersecurity knowledge
+
+113
+00:09:26,000 --> 00:09:28,000
+through various chapters and local events.
+
+114
+00:09:28,000 --> 00:09:34,000
+OWASp fosters collaboration among security professionals, developers, and organizations.
+
+115
+00:09:34,000 --> 00:09:40,000
+This sense of community not only encourages knowledge sharing, but also drives the development of innovative
+
+116
+00:09:40,000 --> 00:09:43,000
+security solutions and best practices.
+
+117
+00:09:44,000 --> 00:09:51,000
+Another significant aspect of OWASp role in cybersecurity is its focus on training and education.
+
+118
+00:09:51,000 --> 00:09:57,000
+The organization offers numerous resources including online courses, documentation, and community
+
+119
+00:09:57,000 --> 00:09:58,000
+driven workshops.
+
+120
+00:09:58,000 --> 00:10:04,000
+These educational initiatives are crucial for raising awareness about security issues and equipping
+
+121
+00:10:04,000 --> 00:10:08,000
+professionals with the skills needed to address them effectively.
+
+122
+00:10:09,000 --> 00:10:17,000
+Additionally, OWASp provides guidance on secure coding practices and development methodologies by integrating
+
+123
+00:10:17,000 --> 00:10:20,000
+security into the software development life cycle.
+
+124
+00:10:20,000 --> 00:10:27,000
+Organizations can adopt a proactive approach to security, ensuring that security is not an afterthought
+
+125
+00:10:27,000 --> 00:10:30,000
+but a fundamental aspect of the development process.
+
+126
+00:10:31,000 --> 00:10:37,000
+As we explore the domain of security architecture design, it becomes clear that establishing a robust
+
+127
+00:10:37,000 --> 00:10:42,000
+framework is fundamental to protecting an organization's information systems.
+
+128
+00:10:42,000 --> 00:10:48,000
+Security architecture involves the structured design of security protocols and controls that safeguard
+
+129
+00:10:48,000 --> 00:10:55,000
+data and ensure the integrity of IT infrastructure by implementing best practices in this area.
+
+130
+00:10:55,000 --> 00:11:01,000
+Organizations can significantly enhance their security posture to begin with.
+
+131
+00:11:01,000 --> 00:11:05,000
+A key principle in security architecture design is the concept of defense in depth.
+
+132
+00:11:06,000 --> 00:11:11,000
+This strategy involves layering multiple security controls to protect assets at various levels.
+
+133
+00:11:11,000 --> 00:11:17,000
+For example, an organization might use firewalls, intrusion detection systems, and endpoint protection
+
+134
+00:11:17,000 --> 00:11:23,000
+in tandem by creating multiple layers of defense even if one layer is breached.
+
+135
+00:11:23,000 --> 00:11:28,000
+Other layers can still provide protection, thereby reducing the overall risk.
+
+136
+00:11:29,000 --> 00:11:33,000
+Another critical aspect is the implementation of a zero trust model.
+
+137
+00:11:33,000 --> 00:11:40,000
+This approach operates under the premise that no user or device, whether inside or outside the network,
+
+138
+00:11:40,000 --> 00:11:41,000
+should be trusted by default.
+
+139
+00:11:41,000 --> 00:11:46,000
+Instead, every access request must be verified and authenticated.
+
+140
+00:11:46,000 --> 00:11:53,000
+This model emphasizes strict identity and access management controls, ensuring that users have only
+
+141
+00:11:53,000 --> 00:11:56,000
+the minimum access necessary to perform their tasks.
+
+142
+00:11:57,000 --> 00:12:03,000
+By adopting a zero trust architecture, organizations can better safeguard their systems against internal
+
+143
+00:12:03,000 --> 00:12:05,000
+and external threats.
+
+144
+00:12:06,000 --> 00:12:12,000
+Moreover, incorporating security by design into the software development life cycle is essential.
+
+145
+00:12:12,000 --> 00:12:18,000
+This principle advocates for integrating security considerations from the outset of a project, rather
+
+146
+00:12:18,000 --> 00:12:20,000
+than treating it as an afterthought.
+
+147
+00:12:21,000 --> 00:12:27,000
+By identifying potential security risks during the design phase, developers can implement appropriate
+
+148
+00:12:27,000 --> 00:12:30,000
+controls and reduce vulnerabilities in the final product.
+
+149
+00:12:31,000 --> 00:12:38,000
+This proactive approach not only enhances security, but also minimizes the costs associated with post-deployment
+
+150
+00:12:38,000 --> 00:12:39,000
+fixes.
+
+151
+00:12:40,000 --> 00:12:45,000
+Additionally, risk assessment plays a vital role in security architecture design.
+
+152
+00:12:45,000 --> 00:12:51,000
+Conducting regular risk assessments allows organizations to identify, analyze, and prioritize potential
+
+153
+00:12:51,000 --> 00:12:53,000
+threats to their systems.
+
+154
+00:12:53,000 --> 00:12:59,000
+This process helps in allocating resources effectively, ensuring that the most critical vulnerabilities
+
+155
+00:12:59,000 --> 00:13:00,000
+are addressed first.
+
+156
+00:13:01,000 --> 00:13:07,000
+By integrating risk management into the architecture, design organizations can create a tailored security
+
+157
+00:13:07,000 --> 00:13:11,000
+strategy that aligns with their specific needs and risk tolerance.
+
+158
+00:13:12,000 --> 00:13:17,000
+Furthermore, it is essential to establish clear security policies and governance structures.
+
+159
+00:13:17,000 --> 00:13:23,000
+A well-defined security policy outlines the organization's approach to security, including roles and
+
+160
+00:13:23,000 --> 00:13:27,000
+responsibilities, acceptable use, and incident response procedures.
+
+161
+00:13:27,000 --> 00:13:34,000
+Governance frameworks such as Cobit or NIST can guide organizations in aligning their security practices
+
+162
+00:13:34,000 --> 00:13:38,000
+with business objectives and regulatory requirements.
+
+163
+00:13:38,000 --> 00:13:44,000
+This alignment ensures that security is integrated into the overall organizational strategy.
+
+164
+00:13:45,000 --> 00:13:50,000
+Another best practice is the use of secure configurations for hardware and software.
+
+165
+00:13:50,000 --> 00:13:57,000
+Ensuring that all systems are configured securely from the start can significantly reduce vulnerabilities.
+
+166
+00:13:57,000 --> 00:14:00,000
+This includes disabling unnecessary services.
+
+167
+00:14:01,000 --> 00:14:08,000
+Applying security patches promptly and ensuring proper network segmentation by establishing baseline
+
+168
+00:14:08,000 --> 00:14:11,000
+configurations and regularly reviewing them.
+
+169
+00:14:11,000 --> 00:14:15,000
+Organizations can maintain a strong security posture.
+
+170
+00:14:15,000 --> 00:14:22,000
+Finally, ongoing monitoring and incident response are critical components of effective security architecture.
+
+171
+00:14:23,000 --> 00:14:29,000
+Continuous monitoring of systems and networks allows organizations to detect and respond to security
+
+172
+00:14:29,000 --> 00:14:30,000
+incidents swiftly.
+
+173
+00:14:31,000 --> 00:14:37,000
+Implementing a robust incident response plan ensures that when a breach occurs, the organization can
+
+174
+00:14:37,000 --> 00:14:43,000
+mitigate its impact, recover swiftly, and learn from the incident to improve future security measures.
+
+175
+00:14:45,000 --> 00:14:51,000
+As we examine the principles of Secure by Design, it becomes evident that this approach is fundamental
+
+176
+00:14:51,000 --> 00:14:54,000
+to creating resilient and secure software systems.
+
+177
+00:14:54,000 --> 00:15:01,000
+Secure by design emphasizes integrating security considerations into every phase of the software development
+
+178
+00:15:01,000 --> 00:15:02,000
+life cycle.
+
+179
+00:15:02,000 --> 00:15:08,000
+Rather than treating security as an afterthought, this proactive methodology not only enhances the
+
+180
+00:15:08,000 --> 00:15:14,000
+security of applications, but also mitigates potential risks early in the development process.
+
+181
+00:15:15,000 --> 00:15:21,000
+To begin with, one of the core tenets of Secure by Design is the principle of least privilege.
+
+182
+00:15:21,000 --> 00:15:26,000
+This principle dictates that users and systems should have the minimum level of access necessary to
+
+183
+00:15:26,000 --> 00:15:28,000
+perform their functions.
+
+184
+00:15:28,000 --> 00:15:34,000
+By restricting access rights, organizations can significantly reduce the risk of unauthorized access
+
+185
+00:15:34,000 --> 00:15:39,000
+and limit the potential damage that could arise from a compromised account.
+
+186
+00:15:39,000 --> 00:15:46,000
+Implementing this principle requires careful consideration during the design phase, ensuring that roles
+
+187
+00:15:46,000 --> 00:15:48,000
+and permissions are clearly defined and enforced.
+
+188
+00:15:49,000 --> 00:15:54,000
+Another important aspect of secure by design is input validation.
+
+189
+00:15:54,000 --> 00:16:01,000
+Applications often rely on user input, which can be a vector for various attacks such as SQL injection
+
+190
+00:16:01,000 --> 00:16:03,000
+and cross-site scripting.
+
+191
+00:16:03,000 --> 00:16:09,000
+By incorporating strict input validation mechanisms from the outset, developers can ensure that only
+
+192
+00:16:09,000 --> 00:16:12,000
+properly formatted data is processed by the application.
+
+193
+00:16:13,000 --> 00:16:19,000
+This approach not only enhances security but also improves the overall robustness of the application,
+
+194
+00:16:19,000 --> 00:16:22,000
+making it less susceptible to exploitation.
+
+195
+00:16:23,000 --> 00:16:29,000
+Furthermore, defense in depth is a critical principle that aligns with the secure by design philosophy.
+
+196
+00:16:30,000 --> 00:16:35,000
+This concept advocates for multiple layers of security controls throughout the system.
+
+197
+00:16:35,000 --> 00:16:42,000
+For instance, even if an attacker bypasses one layer of defense, additional layers such as firewalls,
+
+198
+00:16:42,000 --> 00:16:47,000
+encryption, and intrusion detection systems can still provide protection.
+
+199
+00:16:47,000 --> 00:16:53,000
+Integrating these layers during the design phase ensures a comprehensive security strategy that addresses
+
+200
+00:16:53,000 --> 00:16:56,000
+potential vulnerabilities from various angles.
+
+201
+00:16:57,000 --> 00:17:03,000
+In addition, the principle of fail securely emphasizes that systems should be designed to fail in a
+
+202
+00:17:03,000 --> 00:17:04,000
+secure manner.
+
+203
+00:17:04,000 --> 00:17:10,000
+This means that when a failure occurs, whether due to a bug, an attack, or an unexpected event,
+
+204
+00:17:10,000 --> 00:17:15,000
+the system should not expose sensitive information or create new vulnerabilities.
+
+205
+00:17:16,000 --> 00:17:22,000
+For example, if an application crashes, it should not reveal debugging information or internal states
+
+206
+00:17:22,000 --> 00:17:23,000
+that could aid an attacker.
+
+207
+00:17:23,000 --> 00:17:29,000
+This principle highlights the importance of considering security implications during failure scenarios.
+
+208
+00:17:30,000 --> 00:17:35,000
+Moreover, regular security testing should be an integral part of the secure by design approach.
+
+209
+00:17:35,000 --> 00:17:42,000
+This includes both static analysis where code is examined without execution, and dynamic testing where
+
+210
+00:17:42,000 --> 00:17:45,000
+the application is tested in a running state.
+
+211
+00:17:45,000 --> 00:17:51,000
+By incorporating testing early and often, developers can identify and remediate security vulnerabilities
+
+212
+00:17:51,000 --> 00:17:57,000
+before deployment, significantly reducing the risk of breaches in production environments.
+
+213
+00:17:58,000 --> 00:18:03,000
+Another essential aspect is documentation and clear coding standards.
+
+214
+00:18:03,000 --> 00:18:10,000
+Establishing comprehensive security documentation and coding guidelines ensures that all developers
+
+215
+00:18:10,000 --> 00:18:13,000
+are on the same page regarding security practices.
+
+216
+00:18:14,000 --> 00:18:19,000
+This fosters a culture of security awareness within the development team and helps maintain consistent
+
+217
+00:18:19,000 --> 00:18:22,000
+security standards across all projects.
+
+218
+00:18:22,000 --> 00:18:28,000
+When security principles are well documented and communicated, they are more likely to be followed.
+
+219
+00:18:29,000 --> 00:18:35,000
+Finally, collaboration between security and development teams is vital for the success of secure by
+
+220
+00:18:35,000 --> 00:18:37,000
+design initiatives.
+
+221
+00:18:37,000 --> 00:18:44,000
+Engaging security professionals during the design and development phases ensures that security considerations
+
+222
+00:18:44,000 --> 00:18:46,000
+are integrated from the start.
+
+223
+00:18:47,000 --> 00:18:53,000
+This collaboration not only enhances the overall security of the application, but also facilitates
+
+224
+00:18:53,000 --> 00:18:57,000
+knowledge sharing, leading to a more security conscious development environment.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/003 Introduction to Cybersecurity p.3 - Security Controls, SDD, SOC_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/003 Introduction to Cybersecurity p.3 - Security Controls, SDD, SOC_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..9324a7026d1eca0b8e9aac3b1f3915eb2d33fbe9
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/003 Introduction to Cybersecurity p.3 - Security Controls, SDD, SOC_en.srt
@@ -0,0 +1,1068 @@
+1
+00:00:04,000 --> 00:00:09,000
+As we explore the various types of security controls, it is essential to understand their distinct
+
+2
+00:00:09,000 --> 00:00:14,000
+roles in protecting information systems and mitigating risks.
+
+3
+00:00:14,000 --> 00:00:20,000
+Security controls are the measures implemented to safeguard assets and ensure the confidentiality,
+
+4
+00:00:20,000 --> 00:00:23,000
+integrity and availability of data.
+
+5
+00:00:23,000 --> 00:00:29,000
+They can be categorized into three primary types preventive, detective, and corrective controls.
+
+6
+00:00:30,000 --> 00:00:34,000
+Each type plays a unique role in a comprehensive security strategy.
+
+7
+00:00:35,000 --> 00:00:40,000
+To begin with, preventive controls are designed to deter security incidents before they occur.
+
+8
+00:00:40,000 --> 00:00:45,000
+These controls aim to reduce the likelihood of a threat exploiting a vulnerability.
+
+9
+00:00:45,000 --> 00:00:50,000
+Examples of preventive controls include firewalls, which act as a barrier between trusted internal
+
+10
+00:00:50,000 --> 00:00:57,000
+networks and untrusted external networks, as well as access controls that limit who can enter or interact
+
+11
+00:00:57,000 --> 00:00:59,000
+with sensitive systems.
+
+12
+00:00:59,000 --> 00:01:06,000
+Additionally, implementing strong password policies and multi-factor authentication are crucial preventive
+
+13
+00:01:06,000 --> 00:01:11,000
+measures that enhance security by making unauthorized access more challenging.
+
+14
+00:01:11,000 --> 00:01:18,000
+By focusing on prevention, organizations can proactively safeguard their assets and reduce the risk
+
+15
+00:01:18,000 --> 00:01:19,000
+of breaches.
+
+16
+00:01:20,000 --> 00:01:27,000
+In contrast, detective controls are implemented to identify and alert security teams of potential security
+
+17
+00:01:27,000 --> 00:01:28,000
+incidents as they occur.
+
+18
+00:01:29,000 --> 00:01:35,000
+These controls play a critical role in monitoring systems and networks for suspicious activity.
+
+19
+00:01:35,000 --> 00:01:42,000
+For instance, intrusion detection systems analyze network traffic for signs of unauthorized access
+
+20
+00:01:42,000 --> 00:01:48,000
+or anomalies, while log management solutions aggregate and analyze event logs from various sources
+
+21
+00:01:48,000 --> 00:01:50,000
+to detect unusual patterns.
+
+22
+00:01:51,000 --> 00:01:58,000
+The effectiveness of detective controls hinges on timely alerts and accurate reporting, enabling organizations
+
+23
+00:01:58,000 --> 00:02:02,000
+to respond quickly to potential threats by focusing on detection.
+
+24
+00:02:02,000 --> 00:02:08,000
+Organizations can minimize the impact of incidents that do occur and facilitate.
+
+25
+00:02:08,000 --> 00:02:10,000
+Timely response efforts.
+
+26
+00:02:11,000 --> 00:02:13,000
+Finally, corrective controls are designed to.
+
+27
+00:02:13,000 --> 00:02:17,000
+Respond to security incidents after they have been detected.
+
+28
+00:02:17,000 --> 00:02:24,000
+These controls aim to restore systems to normal operation and mitigate the damage caused by the incident.
+
+29
+00:02:25,000 --> 00:02:31,000
+Examples of corrective controls include incident response plans that outline the steps to take when
+
+30
+00:02:31,000 --> 00:02:37,000
+a breach occurs, as well as data recovery procedures to restore lost or compromised data from backups.
+
+31
+00:02:37,000 --> 00:02:44,000
+Additionally, conducting Post-incident analysis allows organizations to learn from incidents, refining
+
+32
+00:02:44,000 --> 00:02:49,000
+their security policies and controls to prevent similar occurrences in the future.
+
+33
+00:02:49,000 --> 00:02:54,000
+By focusing on correction, organizations can improve their resilience and ensure that they are better
+
+34
+00:02:54,000 --> 00:02:56,000
+prepared for future threats.
+
+35
+00:02:57,000 --> 00:03:03,000
+It is important to note that these types of controls do not operate in isolation, rather, they complement
+
+36
+00:03:03,000 --> 00:03:06,000
+each other within a holistic security framework.
+
+37
+00:03:06,000 --> 00:03:13,000
+For example, while preventive controls aim to stop incidents from happening, detective controls provide
+
+38
+00:03:13,000 --> 00:03:18,000
+the necessary oversight to identify breaches that slip through preventive measures.
+
+39
+00:03:18,000 --> 00:03:25,000
+Subsequently, corrective controls ensure that organisations can effectively respond and recover from
+
+40
+00:03:25,000 --> 00:03:25,000
+incidents.
+
+41
+00:03:26,000 --> 00:03:33,000
+Furthermore, the integration of all three types of controls is vital for developing a robust security
+
+42
+00:03:33,000 --> 00:03:34,000
+posture.
+
+43
+00:03:34,000 --> 00:03:40,000
+Organisations should conduct regular assessments to identify potential vulnerabilities and gaps in their
+
+44
+00:03:40,000 --> 00:03:42,000
+security controls.
+
+45
+00:03:42,000 --> 00:03:48,000
+By understanding the effectiveness of their preventive detective and corrective measures, organisations
+
+46
+00:03:48,000 --> 00:03:53,000
+can enhance their overall security strategy and better protect their assets.
+
+47
+00:03:55,000 --> 00:04:02,000
+Writing and maintaining a security design document is a critical aspect of developing secure applications
+
+48
+00:04:02,000 --> 00:04:02,000
+and systems.
+
+49
+00:04:03,000 --> 00:04:09,000
+The Security Design document serves as a comprehensive blueprint that outlines the security architecture,
+
+50
+00:04:09,000 --> 00:04:15,000
+controls, and processes to be implemented throughout the software development lifecycle.
+
+51
+00:04:16,000 --> 00:04:23,000
+By effectively crafting and updating this document, organizations can ensure that security considerations
+
+52
+00:04:23,000 --> 00:04:26,000
+are integrated into their projects from the outset.
+
+53
+00:04:26,000 --> 00:04:31,000
+To begin with, security design documents should clearly articulate the security requirements of the
+
+54
+00:04:31,000 --> 00:04:32,000
+project.
+
+55
+00:04:32,000 --> 00:04:38,000
+This involves identifying and documenting specific security needs based on the nature of the application,
+
+56
+00:04:38,000 --> 00:04:42,000
+regulatory obligations, and organizational policies.
+
+57
+00:04:42,000 --> 00:04:48,000
+By establishing clear security requirements, the Security Design document provides a foundation for
+
+58
+00:04:48,000 --> 00:04:53,000
+subsequent design decisions and ensures that security is aligned with business objectives.
+
+59
+00:04:54,000 --> 00:05:00,000
+Next, the security design document should include a detailed security architecture section that describes
+
+60
+00:05:00,000 --> 00:05:04,000
+the overall design and structure of the security controls to be implemented.
+
+61
+00:05:04,000 --> 00:05:11,000
+This includes specifying the security mechanisms such as firewalls, encryption protocols, and authentication
+
+62
+00:05:11,000 --> 00:05:16,000
+methods, as well as how these components interact within the system.
+
+63
+00:05:16,000 --> 00:05:22,000
+By providing a clear architectural overview, the Security Design document helps stakeholders understand
+
+64
+00:05:22,000 --> 00:05:29,000
+how security will be integrated into the application and the rationale behind these design choices.
+
+65
+00:05:29,000 --> 00:05:36,000
+Moreover, the Security Design document should encompass a risk assessment that identifies potential
+
+66
+00:05:36,000 --> 00:05:40,000
+threats and vulnerabilities associated with the application.
+
+67
+00:05:40,000 --> 00:05:47,000
+This assessment involves evaluating the likelihood and impact of various risks, which informs the design
+
+68
+00:05:47,000 --> 00:05:49,000
+of appropriate security controls.
+
+69
+00:05:49,000 --> 00:05:56,000
+By systematically addressing risks in the security design document, Organizations can prioritize security
+
+70
+00:05:56,000 --> 00:06:01,000
+efforts and allocate resources effectively to mitigate the most critical threats.
+
+71
+00:06:03,000 --> 00:06:09,000
+Another important aspect of a security design document is the inclusion of security testing and validation
+
+72
+00:06:09,000 --> 00:06:10,000
+strategies.
+
+73
+00:06:10,000 --> 00:06:16,000
+This section outlines the methodologies that will be employed to assess the security posture of the
+
+74
+00:06:16,000 --> 00:06:23,000
+application, such as penetration testing, vulnerability assessments, and code reviews.
+
+75
+00:06:23,000 --> 00:06:30,000
+By specifying testing procedures in the Security Design document, organizations can ensure that security
+
+76
+00:06:30,000 --> 00:06:36,000
+is evaluated at various stages of development and that any identified vulnerabilities are addressed
+
+77
+00:06:36,000 --> 00:06:37,000
+promptly.
+
+78
+00:06:38,000 --> 00:06:43,000
+Additionally, the Security Design document should detail the incident response plan relevant to the
+
+79
+00:06:43,000 --> 00:06:44,000
+application.
+
+80
+00:06:44,000 --> 00:06:51,000
+This plan outlines the steps to be taken in the event of a security breach or incident, ensuring that
+
+81
+00:06:51,000 --> 00:06:56,000
+the organization is prepared to respond Bond effectively including an incident response strategy in
+
+82
+00:06:56,000 --> 00:07:02,000
+the security design document, reinforces the importance of being proactive in addressing potential
+
+83
+00:07:02,000 --> 00:07:03,000
+security threats.
+
+84
+00:07:04,000 --> 00:07:10,000
+It is also crucial to recognize that a security design document is a living document.
+
+85
+00:07:10,000 --> 00:07:17,000
+As the application evolves and new threats emerge, the security design document must be updated to
+
+86
+00:07:17,000 --> 00:07:19,000
+reflect changes in the security landscape.
+
+87
+00:07:20,000 --> 00:07:26,000
+Regular reviews and updates should be scheduled to ensure that the document remains relevant and accurately
+
+88
+00:07:26,000 --> 00:07:28,000
+represents the current state of the application.
+
+89
+00:07:28,000 --> 00:07:29,000
+Security posture.
+
+90
+00:07:30,000 --> 00:07:37,000
+This ongoing maintenance helps organizations adapt to new challenges and ensures that security considerations
+
+91
+00:07:37,000 --> 00:07:41,000
+continue to be prioritized throughout the development lifecycle.
+
+92
+00:07:42,000 --> 00:07:48,000
+Finally, collaboration among various stakeholders such as developers, security teams, and project
+
+93
+00:07:48,000 --> 00:07:54,000
+managers is essential in creating and maintaining an effective security design document.
+
+94
+00:07:54,000 --> 00:08:00,000
+By fostering communication and collaboration, organizations can ensure that security requirements are
+
+95
+00:08:00,000 --> 00:08:03,000
+well understood and integrated into the design process.
+
+96
+00:08:04,000 --> 00:08:10,000
+This collective effort promotes a culture of security, awareness and accountability across the organization.
+
+97
+00:08:12,000 --> 00:08:18,000
+Documenting security requirements and controls is a crucial component of an organization's cyber security
+
+98
+00:08:18,000 --> 00:08:18,000
+strategy.
+
+99
+00:08:18,000 --> 00:08:25,000
+This practice not only establishes a clear framework for security, but also enhances compliance, facilitates
+
+100
+00:08:25,000 --> 00:08:29,000
+communication, and strengthens overall security posture.
+
+101
+00:08:30,000 --> 00:08:36,000
+To begin with, comprehensive documentation of security requirements ensures that all stakeholders have
+
+102
+00:08:36,000 --> 00:08:41,000
+a shared understanding of the security needs associated with a system or application.
+
+103
+00:08:42,000 --> 00:08:47,000
+By clearly defining these requirements, organizations can align their security measures with business
+
+104
+00:08:47,000 --> 00:08:51,000
+objectives, regulatory obligations, and industry standards.
+
+105
+00:08:51,000 --> 00:08:57,000
+For instance, documenting specific security controls such as access restrictions or data encryption
+
+106
+00:08:57,000 --> 00:09:04,000
+methods provides a reference point for both development and operational teams, ensuring that security
+
+107
+00:09:04,000 --> 00:09:09,000
+considerations are consistently applied throughout the software development life cycle.
+
+108
+00:09:09,000 --> 00:09:16,000
+Moreover, documenting security controls enables organizations to establish a systematic approach to
+
+109
+00:09:16,000 --> 00:09:22,000
+risk management by detailing the specific controls implemented to mitigate identified risks.
+
+110
+00:09:22,000 --> 00:09:26,000
+Organizations can assess their effectiveness and identify any gaps.
+
+111
+00:09:27,000 --> 00:09:34,000
+This documentation serves as a foundation for ongoing risk assessments, allowing organizations to adapt
+
+112
+00:09:34,000 --> 00:09:38,000
+their security strategies in response to evolving threats.
+
+113
+00:09:39,000 --> 00:09:45,000
+For example, if a new vulnerability is discovered, having a clear record of existing controls makes
+
+114
+00:09:45,000 --> 00:09:50,000
+it easier to evaluate their sufficiency and make necessary adjustments.
+
+115
+00:09:50,000 --> 00:09:57,000
+In addition, several documentation plays a significant role in compliance and auditing.
+
+116
+00:09:57,000 --> 00:10:04,000
+Many industries are subject to regulatory frameworks that require strict adherence to security standards,
+
+117
+00:10:04,000 --> 00:10:10,000
+such as HIPAA for healthcare or PCI, DSS for payment card processing.
+
+118
+00:10:10,000 --> 00:10:17,000
+By documenting security requirements and controls, organizations can demonstrate their commitment to
+
+119
+00:10:17,000 --> 00:10:18,000
+compliance during audits.
+
+120
+00:10:19,000 --> 00:10:25,000
+This not only helps in avoiding penalties, but also builds trust with customers and stakeholders who
+
+121
+00:10:25,000 --> 00:10:27,000
+expect their data to be handled securely.
+
+122
+00:10:29,000 --> 00:10:35,000
+Furthermore, effective documentation fosters communication and collaboration among teams.
+
+123
+00:10:35,000 --> 00:10:40,000
+Security requirements and controls should not only be the concern of the IT or security departments,
+
+124
+00:10:40,000 --> 00:10:44,000
+they must be understood and implemented across the organization.
+
+125
+00:10:44,000 --> 00:10:51,000
+By documenting these elements clearly, organizations can facilitate training and awareness programs
+
+126
+00:10:51,000 --> 00:10:54,000
+that engage all employees in security practices.
+
+127
+00:10:54,000 --> 00:11:00,000
+This shared understanding promotes a culture of security within the organization, where everyone recognizes
+
+128
+00:11:00,000 --> 00:11:03,000
+their role in maintaining a secure environment.
+
+129
+00:11:04,000 --> 00:11:08,000
+Another important aspect of documentation is its role in incident response.
+
+130
+00:11:09,000 --> 00:11:15,000
+In the event of a security breach, having a detailed record of security requirements and controls allows
+
+131
+00:11:15,000 --> 00:11:20,000
+incident response teams to quickly assess what measures were in place and how they may have failed.
+
+132
+00:11:21,000 --> 00:11:27,000
+This information is invaluable for conducting post-incident analyses, helping organizations learn from
+
+133
+00:11:27,000 --> 00:11:30,000
+breaches and improve their security measures.
+
+134
+00:11:30,000 --> 00:11:37,000
+By documenting lessons learned and recommendations for future improvements, organizations can continuously
+
+135
+00:11:37,000 --> 00:11:39,000
+enhance their security posture.
+
+136
+00:11:40,000 --> 00:11:46,000
+Finally, as organizations grow and evolve, so too do their security needs.
+
+137
+00:11:46,000 --> 00:11:53,000
+Documenting security requirements and controls creates a living resource that can be updated to reflect
+
+138
+00:11:53,000 --> 00:11:57,000
+changes in technology, threats and business operations.
+
+139
+00:11:58,000 --> 00:12:04,000
+Regular reviews and updates to this documentation ensure that it remains relevant and effective.
+
+140
+00:12:04,000 --> 00:12:10,000
+This adaptability is essential in a dynamic cybersecurity landscape where new threats and vulnerabilities
+
+141
+00:12:10,000 --> 00:12:12,000
+emerge constantly.
+
+142
+00:12:14,000 --> 00:12:17,000
+As we delve into the realm of cybersecurity.
+
+143
+00:12:17,000 --> 00:12:22,000
+Understanding the role and function of a security operations center is essential.
+
+144
+00:12:22,000 --> 00:12:28,000
+A security operations Center serves as the centralized unit responsible for monitoring, detecting,
+
+145
+00:12:28,000 --> 00:12:32,000
+and responding to security incidents within an organization.
+
+146
+00:12:32,000 --> 00:12:39,000
+It plays a critical role in maintaining the overall security, posture, and resilience of an organization
+
+147
+00:12:39,000 --> 00:12:42,000
+in an increasingly complex threat landscape.
+
+148
+00:12:43,000 --> 00:12:48,000
+To begin with, the primary function of a security operations center is continuous monitoring of an
+
+149
+00:12:48,000 --> 00:12:50,000
+organization's information systems.
+
+150
+00:12:50,000 --> 00:12:57,000
+This involves utilizing various tools and technologies to analyze network traffic logs and other data
+
+151
+00:12:57,000 --> 00:13:01,000
+sources for signs of suspicious activity or potential breaches.
+
+152
+00:13:01,000 --> 00:13:07,000
+By maintaining a constant watch over the IT environment, the Security Operations Center can identify
+
+153
+00:13:07,000 --> 00:13:14,000
+and respond to threats in real time, minimizing the impact of incidents and enhancing overall security.
+
+154
+00:13:14,000 --> 00:13:20,000
+Furthermore, a security operations center typically employs a range of security information and event
+
+155
+00:13:20,000 --> 00:13:22,000
+management systems.
+
+156
+00:13:22,000 --> 00:13:28,000
+These systems aggregate and analyze security data from various sources, enabling analysts to identify
+
+157
+00:13:28,000 --> 00:13:32,000
+patterns and anomalies that may indicate a security threat.
+
+158
+00:13:32,000 --> 00:13:39,000
+By leveraging security information and event management tools, Security Operations Center personnel
+
+159
+00:13:39,000 --> 00:13:46,000
+can correlate events across the network and gain insights into potential vulnerabilities, facilitating
+
+160
+00:13:46,000 --> 00:13:48,000
+a more effective response to incidents.
+
+161
+00:13:49,000 --> 00:13:55,000
+In addition to monitoring, the Security Operations Center is responsible for incident response.
+
+162
+00:13:55,000 --> 00:14:01,000
+When a security incident is detected, the Security Operations Center team activates an established
+
+163
+00:14:01,000 --> 00:14:06,000
+incident Response plan to contain, eradicate and recover from the threat.
+
+164
+00:14:07,000 --> 00:14:14,000
+This involves coordinating efforts across various departments such as IT, legal and communications,
+
+165
+00:14:14,000 --> 00:14:16,000
+to ensure a comprehensive response.
+
+166
+00:14:17,000 --> 00:14:24,000
+By having a dedicated incident response capability, organizations can minimize downtime and reduce
+
+167
+00:14:24,000 --> 00:14:27,000
+the potential damage caused by security breaches.
+
+168
+00:14:28,000 --> 00:14:35,000
+Another critical function of the Security Operations Center is threat intelligence gathering and analysis.
+
+169
+00:14:35,000 --> 00:14:42,000
+This involves collecting and analyzing information about emerging threats, vulnerabilities, and attack
+
+170
+00:14:42,000 --> 00:14:43,000
+methodologies.
+
+171
+00:14:43,000 --> 00:14:47,000
+By staying informed about the latest cyber threats.
+
+172
+00:14:47,000 --> 00:14:54,000
+Security Operations Center teams can proactively enhance their defenses and adjust their monitoring
+
+173
+00:14:54,000 --> 00:14:55,000
+strategies accordingly.
+
+174
+00:14:56,000 --> 00:15:02,000
+Incorporating threat intelligence into their operations allows security operations centers to anticipate
+
+175
+00:15:02,000 --> 00:15:05,000
+and prepare for potential attacks before they occur.
+
+176
+00:15:05,000 --> 00:15:11,000
+Moreover, forensics and post-incident analysis are essential components of a security operations center's
+
+177
+00:15:11,000 --> 00:15:15,000
+responsibilities after an incident is resolved.
+
+178
+00:15:15,000 --> 00:15:21,000
+Security Operations Center personnel conduct a thorough analysis to understand the root cause and assess
+
+179
+00:15:21,000 --> 00:15:23,000
+the effectiveness of the response.
+
+180
+00:15:23,000 --> 00:15:30,000
+This forensic analysis helps identify lessons learned and informs future security practices and policies.
+
+181
+00:15:30,000 --> 00:15:36,000
+By continuously improving based on past experiences, security operations centers can enhance their
+
+182
+00:15:36,000 --> 00:15:38,000
+readiness for future threats.
+
+183
+00:15:39,000 --> 00:15:44,000
+Collaboration with other teams and departments within the organization is also vital for the success
+
+184
+00:15:44,000 --> 00:15:46,000
+of a security operations center.
+
+185
+00:15:46,000 --> 00:15:53,000
+Effective communication between the Security Operations Center, IT and risk management teams ensures
+
+186
+00:15:53,000 --> 00:16:00,000
+that security measures align with overall business objectives and that potential risks are identified
+
+187
+00:16:00,000 --> 00:16:02,000
+and addressed promptly.
+
+188
+00:16:02,000 --> 00:16:10,000
+This Cross-departmental collaboration fosters a culture of security, awareness and responsibility across
+
+189
+00:16:10,000 --> 00:16:11,000
+the organization.
+
+190
+00:16:12,000 --> 00:16:19,000
+Lastly, it is important to recognize that a security operations center can be structured in different
+
+191
+00:16:19,000 --> 00:16:22,000
+ways depending on the size and needs of the organization.
+
+192
+00:16:23,000 --> 00:16:29,000
+Some organizations may choose to maintain an in-house security operations center staffed by dedicated
+
+193
+00:16:29,000 --> 00:16:36,000
+security professionals, while others may opt for a managed Security Operations Center service, leveraging
+
+194
+00:16:36,000 --> 00:16:38,000
+external expertise and resources.
+
+195
+00:16:39,000 --> 00:16:45,000
+Regardless of the approach, the fundamental goals of monitoring, detecting and responding to security
+
+196
+00:16:45,000 --> 00:16:47,000
+threats remain the same.
+
+197
+00:16:49,000 --> 00:16:55,000
+In the realm of cyber security, incident management plays a pivotal role in ensuring that organizations
+
+198
+00:16:55,000 --> 00:16:59,000
+can effectively respond to and recover from security incidents.
+
+199
+00:17:00,000 --> 00:17:06,000
+This process encompasses the policies, procedures, and tools necessary to identify, assess, and
+
+200
+00:17:06,000 --> 00:17:12,000
+mitigate incidents, ultimately minimizing the impact on business operations.
+
+201
+00:17:12,000 --> 00:17:19,000
+To begin with, the primary goal of incident management is to restore normal operations as quickly as
+
+202
+00:17:19,000 --> 00:17:21,000
+possible while minimizing damage.
+
+203
+00:17:21,000 --> 00:17:26,000
+This involves having a structured approach to manage incidents, which includes clear definitions of
+
+204
+00:17:26,000 --> 00:17:32,000
+what constitutes an incident, roles and responsibilities, and predefined response strategies.
+
+205
+00:17:33,000 --> 00:17:39,000
+By establishing a well-defined incident management framework, organizations can ensure a swift and
+
+206
+00:17:39,000 --> 00:17:41,000
+coordinated response to potential threats.
+
+207
+00:17:42,000 --> 00:17:47,000
+A key component of incident management is the Incident Response Plan.
+
+208
+00:17:47,000 --> 00:17:54,000
+This plan outlines the step by step procedures that should be followed when a security incident occurs.
+
+209
+00:17:55,000 --> 00:18:01,000
+It typically includes processes for incident identification, containment, eradication, recovery,
+
+210
+00:18:01,000 --> 00:18:03,000
+and lessons learned.
+
+211
+00:18:04,000 --> 00:18:10,000
+By having a comprehensive incident response plan in place, organizations can ensure that their teams
+
+212
+00:18:10,000 --> 00:18:16,000
+are prepared to act effectively in the face of an incident, reducing confusion and uncertainty.
+
+213
+00:18:17,000 --> 00:18:21,000
+Another critical aspect is incident detection and reporting.
+
+214
+00:18:21,000 --> 00:18:28,000
+This involves the use of monitoring tools and technologies such as security information and event management
+
+215
+00:18:28,000 --> 00:18:33,000
+systems, to identify potential incidents in real time.
+
+216
+00:18:33,000 --> 00:18:40,000
+Early detection is essential as it allows for quicker response times and can significantly mitigate
+
+217
+00:18:40,000 --> 00:18:42,000
+the impact of a breach.
+
+218
+00:18:42,000 --> 00:18:49,000
+Moreover, encouraging a culture of reporting among employees helps to ensure that any suspicious activity
+
+219
+00:18:49,000 --> 00:18:52,000
+is communicated to the appropriate teams promptly.
+
+220
+00:18:54,000 --> 00:19:00,000
+Once an incident is detected, the next step is incident classification and prioritization.
+
+221
+00:19:01,000 --> 00:19:06,000
+This process involves assessing the severity and impact of the incident to determine the appropriate
+
+222
+00:19:06,000 --> 00:19:07,000
+response.
+
+223
+00:19:08,000 --> 00:19:15,000
+Incidents can vary widely in nature, from minor security breaches to major data leaks, and understanding
+
+224
+00:19:15,000 --> 00:19:20,000
+the potential consequences helps teams allocate resources effectively.
+
+225
+00:19:21,000 --> 00:19:27,000
+For instance, a critical incident that compromises sensitive customer data will require a more immediate
+
+226
+00:19:27,000 --> 00:19:31,000
+and robust response compared to a minor malware infection.
+
+227
+00:19:32,000 --> 00:19:37,000
+Following classification, the focus shifts to containment and eradication.
+
+228
+00:19:37,000 --> 00:19:42,000
+Containment strategies aim to limit the spread of the incident and prevent further damage.
+
+229
+00:19:42,000 --> 00:19:49,000
+This might involve isolating the affected systems or disabling compromised accounts once contained.
+
+230
+00:19:49,000 --> 00:19:55,000
+The next step is to eradicate the root cause of the incident, ensuring that the vulnerability is addressed
+
+231
+00:19:55,000 --> 00:19:57,000
+and cannot be exploited again.
+
+232
+00:19:57,000 --> 00:20:01,000
+Cause recovery is another vital phase of incident management.
+
+233
+00:20:02,000 --> 00:20:06,000
+This involves restoring affected systems and services to normal operation.
+
+234
+00:20:07,000 --> 00:20:13,000
+During this phase, it is essential to ensure that all systems are thoroughly scanned and secured before
+
+235
+00:20:13,000 --> 00:20:14,000
+bringing them back online.
+
+236
+00:20:15,000 --> 00:20:21,000
+Additionally, organisations should continuously monitor the environment to ensure that the incident
+
+237
+00:20:21,000 --> 00:20:25,000
+has been fully resolved and that no residual effects remain.
+
+238
+00:20:26,000 --> 00:20:32,000
+Finally, Post-incident analysis is crucial for improving future incident management efforts after an
+
+239
+00:20:32,000 --> 00:20:34,000
+incident is resolved.
+
+240
+00:20:34,000 --> 00:20:41,000
+Conducting a thorough review of the response process helps identify lessons learned and areas for improvement.
+
+241
+00:20:41,000 --> 00:20:47,000
+This analysis should examine the effectiveness of the incident response plan, the performance of the
+
+242
+00:20:47,000 --> 00:20:51,000
+response team, and any communication gaps that may have arisen.
+
+243
+00:20:51,000 --> 00:20:57,000
+By incorporating these insights into the Incident Management framework, organizations can enhance their
+
+244
+00:20:57,000 --> 00:21:00,000
+preparedness for future incidents.
+
+245
+00:21:01,000 --> 00:21:04,000
+That's all what I wanted to share with you in this lesson.
+
+246
+00:21:04,000 --> 00:21:08,000
+As I already mentioned, we have a long journey planned for this course.
+
+247
+00:21:08,000 --> 00:21:12,000
+We will make a deep dive into different cybersecurity topics.
+
+248
+00:21:12,000 --> 00:21:17,000
+We will review code examples and learn how to make our systems more secure and protected.
+
+249
+00:21:19,000 --> 00:21:21,000
+Let's recap what we've learned in the lesson.
+
+250
+00:21:23,000 --> 00:21:29,000
+We learned the definition and importance of cyber security, establishing a foundational understanding
+
+251
+00:21:29,000 --> 00:21:31,000
+of its role in protecting information.
+
+252
+00:21:32,000 --> 00:21:38,000
+We explored the current cyber threat landscape, examining various types of threats such as Malware,
+
+253
+00:21:38,000 --> 00:21:41,000
+phishing, and insider threats.
+
+254
+00:21:41,000 --> 00:21:48,000
+Through case studies, we analyzed real world cyber attacks to understand their impact and the lessons
+
+255
+00:21:48,000 --> 00:21:48,000
+learned.
+
+256
+00:21:49,000 --> 00:21:55,000
+We introduced several threat analysis models, including Stride and Dread, highlighting their application
+
+257
+00:21:55,000 --> 00:21:57,000
+in identifying and mitigating risks.
+
+258
+00:21:58,000 --> 00:22:04,000
+We discussed the OWASp framework and its significance in enhancing application security, focusing on
+
+259
+00:22:04,000 --> 00:22:08,000
+tools and standards like Application Security Verification Standard.
+
+260
+00:22:09,000 --> 00:22:15,000
+We covered best practices in security architecture design and the principles of being secure by design,
+
+261
+00:22:15,000 --> 00:22:19,000
+emphasizing their importance in developing resilient systems.
+
+262
+00:22:19,000 --> 00:22:25,000
+Lastly, we reviewed incident management processes and the critical role they play in responding to
+
+263
+00:22:25,000 --> 00:22:28,000
+and recovering from cybersecurity incidents.
+
+264
+00:22:29,000 --> 00:22:30,000
+That's all for this lesson.
+
+265
+00:22:30,000 --> 00:22:31,000
+Stay tuned.
+
+266
+00:22:31,000 --> 00:22:33,000
+Thanks a lot for your attention.
+
+267
+00:22:33,000 --> 00:22:35,000
+Have a great day and see you in the next lesson.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/004 Zero Trust Architecture and Modern Authentication_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/004 Zero Trust Architecture and Modern Authentication_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..95b6c84e8e879e3e8439f165f37b941c26807dd2
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/004 Zero Trust Architecture and Modern Authentication_en.srt
@@ -0,0 +1,1152 @@
+1
+00:00:06,000 --> 00:00:07,000
+Hello team.
+
+2
+00:00:07,000 --> 00:00:13,000
+In this session, we'll cover the essential practices for strengthening system security, focusing on
+
+3
+00:00:13,000 --> 00:00:17,000
+strategies that prioritize continuous verification of users and devices.
+
+4
+00:00:17,000 --> 00:00:24,000
+These methods ensure that access is granted only when necessary, minimizing the risk of unauthorized
+
+5
+00:00:24,000 --> 00:00:28,000
+access by challenging traditional models that assume trust within the network.
+
+6
+00:00:28,000 --> 00:00:34,000
+These approaches offer a more adaptive and resilient security framework, addressing both external and
+
+7
+00:00:34,000 --> 00:00:35,000
+internal threats.
+
+8
+00:00:36,000 --> 00:00:42,000
+As we delve deeper, we'll explore practices that adjust security measures based on real time conditions,
+
+9
+00:00:42,000 --> 00:00:46,000
+ensuring that only the right users have access at the right time.
+
+10
+00:00:47,000 --> 00:00:53,000
+We will also examine how these methods can dynamically adapt to potential risks, ensuring that your
+
+11
+00:00:53,000 --> 00:00:58,000
+security system is flexible and responsive to evolving threats.
+
+12
+00:00:58,000 --> 00:01:05,000
+This comprehensive approach helps create a secure environment, safeguarding sensitive data and critical
+
+13
+00:01:05,000 --> 00:01:07,000
+resources from various vulnerabilities.
+
+14
+00:01:08,000 --> 00:01:14,000
+In the lesson about Zero trust architecture and modern authentication best practices, we will explore
+
+15
+00:01:14,000 --> 00:01:19,000
+a range of techniques designed to enhance security in modern systems.
+
+16
+00:01:20,000 --> 00:01:26,000
+The practices on this slide are organized by relevance, starting with high relevance measures that
+
+17
+00:01:26,000 --> 00:01:33,000
+focus on critical threat mitigation, such as adopting the zero trust principle where no user or device
+
+18
+00:01:34,000 --> 00:01:35,000
+is trusted by default.
+
+19
+00:01:36,000 --> 00:01:41,000
+We'll discuss how multi-factor authentication and biometric verification methods like fingerprint and
+
+20
+00:01:41,000 --> 00:01:46,000
+facial recognition provide a robust defence against credential based attacks.
+
+21
+00:01:46,000 --> 00:01:52,000
+Additionally, continuous monitoring and the principle of least privilege access help to minimize security
+
+22
+00:01:52,000 --> 00:01:57,000
+risks by ensuring only necessary access is granted based on real time behavior and identity.
+
+23
+00:01:58,000 --> 00:02:04,000
+Moving on to moderate relevance practices, we will explore the importance of integrating strong identity
+
+24
+00:02:04,000 --> 00:02:06,000
+and access management systems.
+
+25
+00:02:06,000 --> 00:02:13,000
+Micro segmentation for limiting the lateral movement of attackers, and device trust policies that ensure
+
+26
+00:02:13,000 --> 00:02:16,000
+only secure devices access critical systems.
+
+27
+00:02:16,000 --> 00:02:23,000
+We will also highlight how context aware access controls and zero trust for cloud environments can further
+
+28
+00:02:23,000 --> 00:02:29,000
+strengthen security by considering user context and enforcing least privilege in the cloud.
+
+29
+00:02:30,000 --> 00:02:36,000
+Finally, we'll touch on low relevance practices that address edge cases, including behavioral biometrics,
+
+30
+00:02:36,000 --> 00:02:43,000
+continuous session validation and login and auditing to ensure full visibility and adaptability in dynamic
+
+31
+00:02:43,000 --> 00:02:44,000
+security environments.
+
+32
+00:02:46,000 --> 00:02:52,000
+In this second list, we approach zero trust architecture and modern authentication best practices by
+
+33
+00:02:52,000 --> 00:02:56,000
+categorizing them based on complexity rather than relevance.
+
+34
+00:02:57,000 --> 00:03:04,000
+This method allows for a gradual understanding of the concepts, starting from basic principles like
+
+35
+00:03:04,000 --> 00:03:09,000
+adopting the zero trust principle and enforcing least privilege access.
+
+36
+00:03:09,000 --> 00:03:16,000
+These foundational practices establish the groundwork for secure access control by ensuring that no
+
+37
+00:03:16,000 --> 00:03:21,000
+user or device is trusted by default, and that all access is restricted to what is necessary.
+
+38
+00:03:21,000 --> 00:03:27,000
+As you build on these basics, multi-factor authentication and session validation further enhance security
+
+39
+00:03:27,000 --> 00:03:30,000
+by adding layers of identity verification and monitoring.
+
+40
+00:03:30,000 --> 00:03:32,000
+Session integrity.
+
+41
+00:03:32,000 --> 00:03:38,000
+As you progress to intermediate and advanced techniques, the focus shifts to more complex practices
+
+42
+00:03:38,000 --> 00:03:44,000
+like biometric verification, continuous monitoring, and device trust policies, which help ensure
+
+43
+00:03:44,000 --> 00:03:49,000
+that only authorized secure users and devices have access.
+
+44
+00:03:50,000 --> 00:03:57,000
+Context aware access controls and behavioral biometrics come into play at the advanced level, providing
+
+45
+00:03:57,000 --> 00:04:02,000
+a more nuanced, real time analysis of user behavior to detect anomalies.
+
+46
+00:04:02,000 --> 00:04:10,000
+This categorization by complexity allows for a step by step learning approach, making it easier to
+
+47
+00:04:10,000 --> 00:04:13,000
+grasp and apply these security measures effectively.
+
+48
+00:04:13,000 --> 00:04:20,000
+Depending on your comfort level, you can choose to start with the basics or dive deeper into more complex
+
+49
+00:04:20,000 --> 00:04:23,000
+techniques as your understanding grows.
+
+50
+00:04:24,000 --> 00:04:28,000
+As I promised, let's provide a detailed overview of each technique.
+
+51
+00:04:29,000 --> 00:04:32,000
+As you saw, there are different ways to group these practices.
+
+52
+00:04:33,000 --> 00:04:38,000
+However, for the sake of this lesson, let's organize all the techniques by relevance and review them
+
+53
+00:04:38,000 --> 00:04:39,000
+in that order.
+
+54
+00:04:39,000 --> 00:04:44,000
+And in case you have any questions during the lesson, no need to wait till the end of the lesson.
+
+55
+00:04:44,000 --> 00:04:49,000
+Write them in the Q&A section below the video and I will be happy to answer.
+
+56
+00:04:51,000 --> 00:04:57,000
+Now let's explore in more detail the critical best practices within Zero Trust architecture and modern
+
+57
+00:04:57,000 --> 00:05:04,000
+authentication, focusing on how each strategy strengthens security by addressing specific risks.
+
+58
+00:05:05,000 --> 00:05:12,000
+First, we have the adoption of the zero Trust principle, which fundamentally changes how we approach
+
+59
+00:05:12,000 --> 00:05:13,000
+security.
+
+60
+00:05:13,000 --> 00:05:20,000
+Instead of assuming that anyone inside the network perimeter can be trusted, Zero Trust operates on
+
+61
+00:05:20,000 --> 00:05:24,000
+the belief that no one and nothing is trusted by default.
+
+62
+00:05:24,000 --> 00:05:30,000
+This means every user, device, and connection must be verified before being granted access.
+
+63
+00:05:30,000 --> 00:05:35,000
+Even if a user is within the company's network, they still need to prove their identity and authorization
+
+64
+00:05:35,000 --> 00:05:38,000
+before accessing sensitive resources.
+
+65
+00:05:38,000 --> 00:05:44,000
+This approach is crucial in today's landscape, where insider threats and lateral movement attacks,
+
+66
+00:05:44,000 --> 00:05:50,000
+where an attacker gains access to one part of the network and then moves to more sensitive areas are
+
+67
+00:05:50,000 --> 00:05:52,000
+major concerns.
+
+68
+00:05:52,000 --> 00:05:59,000
+By implementing zero trust, we make sure that every access attempt is thoroughly checked, reducing
+
+69
+00:05:59,000 --> 00:06:00,000
+the risk of breaches from within.
+
+70
+00:06:01,000 --> 00:06:06,000
+Next, we come to the implementation of multi-factor authentication.
+
+71
+00:06:06,000 --> 00:06:13,000
+Multi-factor authentication enhances security by requiring users to provide more than one method of
+
+72
+00:06:13,000 --> 00:06:17,000
+verification before they can access a system or resource.
+
+73
+00:06:17,000 --> 00:06:24,000
+This typically involves something the user knows, like a password and something they have, like a
+
+74
+00:06:24,000 --> 00:06:26,000
+phone or a hardware token.
+
+75
+00:06:27,000 --> 00:06:34,000
+The reasoning behind this is simple if a password is compromised, the attacker would still need the
+
+76
+00:06:34,000 --> 00:06:39,000
+second factor, making it significantly harder to gain unauthorized access.
+
+77
+00:06:40,000 --> 00:06:47,000
+Multi-factor authentication is especially important in preventing credential based attacks like phishing,
+
+78
+00:06:47,000 --> 00:06:54,000
+brute force attacks, or password theft, where stealing a password alone might otherwise be sufficient
+
+79
+00:06:54,000 --> 00:06:56,000
+to breach an account.
+
+80
+00:06:57,000 --> 00:07:03,000
+We also see the increasing importance of biometric verification methods such as fingerprints, facial
+
+81
+00:07:03,000 --> 00:07:08,000
+recognition, or voice recognition, which add an additional layer of security.
+
+82
+00:07:09,000 --> 00:07:15,000
+These methods are based on unique physical traits, making them far more difficult to fake or steal
+
+83
+00:07:15,000 --> 00:07:18,000
+than traditional credentials like passwords.
+
+84
+00:07:18,000 --> 00:07:25,000
+In systems where high security measures are required, biometrics are a powerful tool to prevent unauthorized
+
+85
+00:07:25,000 --> 00:07:25,000
+access.
+
+86
+00:07:26,000 --> 00:07:32,000
+For example, accessing sensitive areas of a system might require both a password and a fingerprint
+
+87
+00:07:32,000 --> 00:07:35,000
+scan, ensuring that the user is who they claim to be.
+
+88
+00:07:35,000 --> 00:07:41,000
+This method not only reduces reliance on passwords, but also protects against credential based attacks
+
+89
+00:07:41,000 --> 00:07:45,000
+by requiring physical characteristics that cannot be replicated easily.
+
+90
+00:07:46,000 --> 00:07:51,000
+Another essential practice is the use of continuous monitoring and behavioral analytics.
+
+91
+00:07:51,000 --> 00:07:58,000
+This involves real time tracking of user activity to detect any unusual patterns or behaviors.
+
+92
+00:07:58,000 --> 00:08:06,000
+For example, if a user suddenly logs in from an unfamiliar location or starts accessing resources they
+
+93
+00:08:06,000 --> 00:08:12,000
+don't typically use, the system will flag these anomalies as potential threats.
+
+94
+00:08:13,000 --> 00:08:20,000
+The key benefit of continuous monitoring is that it helps detect compromised accounts or insider threats
+
+95
+00:08:20,000 --> 00:08:24,000
+early, often before a significant breach occurs.
+
+96
+00:08:24,000 --> 00:08:31,000
+Security teams can act quickly to lock accounts or take other preventive measures based on these alerts,
+
+97
+00:08:31,000 --> 00:08:35,000
+minimizing the potential damage caused by malicious actors.
+
+98
+00:08:36,000 --> 00:08:42,000
+Lastly, the enforcement of least privileged access based on real time context is another crucial aspect
+
+99
+00:08:42,000 --> 00:08:44,000
+of zero trust.
+
+100
+00:08:44,000 --> 00:08:50,000
+This practice ensures that users are only granted access to the resources they need to perform their
+
+101
+00:08:50,000 --> 00:08:52,000
+tasks, and nothing more.
+
+102
+00:08:53,000 --> 00:08:55,000
+However, this isn't a static policy.
+
+103
+00:08:55,000 --> 00:09:02,000
+It dynamically changes based on the user's behavior, identity, and the context of their actions.
+
+104
+00:09:02,000 --> 00:09:10,000
+For example, a user might only have access to specific files during their normal working hours, or
+
+105
+00:09:10,000 --> 00:09:14,000
+their permissions might be reduced if their activity seems suspicious.
+
+106
+00:09:15,000 --> 00:09:21,000
+This principle significantly limits the scope of what an attacker can do if an account is compromised.
+
+107
+00:09:22,000 --> 00:09:28,000
+By ensuring that no user has more access than necessary at any given time, the potential impact of
+
+108
+00:09:28,000 --> 00:09:33,000
+a breach is contained and unauthorized lateral movement within the system is prevented.
+
+109
+00:09:35,000 --> 00:09:41,000
+Let's dive deeper into the moderate relevance best practices within zero trust architecture and modern
+
+110
+00:09:41,000 --> 00:09:47,000
+authentication, which address common yet vital security concerns in modern systems.
+
+111
+00:09:47,000 --> 00:09:53,000
+These practices form a critical layer in securing your infrastructure, particularly in environments
+
+112
+00:09:53,000 --> 00:09:56,000
+that are increasingly complex and decentralized.
+
+113
+00:09:57,000 --> 00:10:02,000
+We begin with the integration of strong identity and access management systems.
+
+114
+00:10:02,000 --> 00:10:08,000
+These systems are vital because they centralize the management of user identities, ensuring that only
+
+115
+00:10:08,000 --> 00:10:13,000
+authenticated and authorized individuals and devices can access your systems.
+
+116
+00:10:14,000 --> 00:10:20,000
+This involves setting up role based access control, where each user is assigned specific roles with
+
+117
+00:10:20,000 --> 00:10:21,000
+clearly defined permissions.
+
+118
+00:10:22,000 --> 00:10:28,000
+With identity and access management, we reduce the complexity of managing user access across multiple
+
+119
+00:10:28,000 --> 00:10:31,000
+systems by centralizing it in one place.
+
+120
+00:10:32,000 --> 00:10:38,000
+For example, with an identity and access management system, you can instantly revoke a user's access
+
+121
+00:10:38,000 --> 00:10:46,000
+across all applications when they leave the company, ensuring there are no gaps in security without
+
+122
+00:10:46,000 --> 00:10:53,000
+identity and access management managing who has access to what can become chaotic, increasing the risk
+
+123
+00:10:53,000 --> 00:10:54,000
+of unauthorised access.
+
+124
+00:10:55,000 --> 00:11:03,000
+Next, we have network segmentation using micro segmentation, which plays a key role in limiting the
+
+125
+00:11:03,000 --> 00:11:05,000
+impact of a security breach.
+
+126
+00:11:05,000 --> 00:11:08,000
+Imagine your network as a single large area.
+
+127
+00:11:08,000 --> 00:11:13,000
+If an attacker gets in, they have free movement across all resources.
+
+128
+00:11:14,000 --> 00:11:21,000
+Micro segmentation solves this by breaking the network into smaller, isolated zones with strict access
+
+129
+00:11:21,000 --> 00:11:24,000
+controls applied to each segment.
+
+130
+00:11:25,000 --> 00:11:31,000
+In the event of a breach, attackers would be limited to just one segment, unable to move laterally
+
+131
+00:11:31,000 --> 00:11:35,000
+across the network to access more sensitive areas.
+
+132
+00:11:36,000 --> 00:11:43,000
+For example, a compromised user might be restricted to access and only basic services, preventing
+
+133
+00:11:43,000 --> 00:11:45,000
+them from reaching critical databases.
+
+134
+00:11:46,000 --> 00:11:52,000
+This limits the potential damage and provides better visibility into what's happening in each zone.
+
+135
+00:11:53,000 --> 00:12:00,000
+The implementation of device trust policies adds another layer of security by ensuring that only secure,
+
+136
+00:12:00,000 --> 00:12:03,000
+compliant devices can access critical systems.
+
+137
+00:12:04,000 --> 00:12:10,000
+With the rise of remote work and bring your own device policies, the variety of devices accessing corporate
+
+138
+00:12:10,000 --> 00:12:13,000
+networks has exploded.
+
+139
+00:12:13,000 --> 00:12:19,000
+By enforcing device trust policies, we ensure that only devices that meet specific security requirements,
+
+140
+00:12:19,000 --> 00:12:26,000
+such as running up to date operating systems, have an antivirus software and using secure configurations,
+
+141
+00:12:26,000 --> 00:12:29,000
+are allowed to access sensitive resources.
+
+142
+00:12:29,000 --> 00:12:35,000
+This reduces the risk of compromised devices introducing malware or serving as entry points for attackers.
+
+143
+00:12:36,000 --> 00:12:41,000
+For instance, a laptop with outdated software would be blocked from accessing the network until it's
+
+144
+00:12:41,000 --> 00:12:45,000
+updated ensures that only secure devices are permitted.
+
+145
+00:12:46,000 --> 00:12:52,000
+The next practice, Context Aware Access Controls, focuses on analyzing the context of each access
+
+146
+00:12:52,000 --> 00:12:55,000
+request to assess risk before granting access.
+
+147
+00:12:56,000 --> 00:13:02,000
+Traditional security models often rely solely on usernames and passwords for access control, but in
+
+148
+00:13:02,000 --> 00:13:05,000
+modern environments this is insufficient.
+
+149
+00:13:06,000 --> 00:13:13,000
+Context aware controls add additional layers of security by considering factors such as the user's location,
+
+150
+00:13:13,000 --> 00:13:17,000
+device time of access, and even the user's behavior.
+
+151
+00:13:18,000 --> 00:13:24,000
+For example, if a user typically logs in from the office but suddenly tries to log in from another
+
+152
+00:13:24,000 --> 00:13:32,000
+country at an unusual time, this can trigger an alert or additional authentication steps like multi-factor
+
+153
+00:13:32,000 --> 00:13:33,000
+authentication.
+
+154
+00:13:34,000 --> 00:13:40,000
+This practice helps prevent attackers from gaining access using stolen credentials as it analyzes more
+
+155
+00:13:40,000 --> 00:13:43,000
+than just the user's login information.
+
+156
+00:13:43,000 --> 00:13:50,000
+Lastly, adoption of zero trust for cloud environments extends the principles of zero trust to cloud
+
+157
+00:13:50,000 --> 00:13:56,000
+based resources, which are becoming increasingly common in modern IT infrastructures.
+
+158
+00:13:56,000 --> 00:14:03,000
+Cloud environments operate differently from traditional on premises systems, so it's essential to enforce
+
+159
+00:14:03,000 --> 00:14:07,000
+strong identity verification and least privilege access for cloud users.
+
+160
+00:14:07,000 --> 00:14:15,000
+This ensures that users only have access to the specific cloud resources they need and nothing more.
+
+161
+00:14:15,000 --> 00:14:17,000
+Reducing the attack surface.
+
+162
+00:14:17,000 --> 00:14:23,000
+In case of a breach, for instance, a user with access to cloud storage may not need access to cloud
+
+163
+00:14:23,000 --> 00:14:25,000
+based databases.
+
+164
+00:14:26,000 --> 00:14:31,000
+By enforcing least privilege, we limit what an attacker can do, even if they compromise the user's
+
+165
+00:14:31,000 --> 00:14:33,000
+cloud credentials.
+
+166
+00:14:34,000 --> 00:14:41,000
+Let's explore these low relevance practices in more depth, focusing on how they address specific threats
+
+167
+00:14:41,000 --> 00:14:45,000
+within zero trust architecture and modern authentication.
+
+168
+00:14:46,000 --> 00:14:52,000
+While they may seem peripheral compared to high relevance practices, these techniques are invaluable
+
+169
+00:14:52,000 --> 00:14:59,000
+for handling edge cases and lesser known vulnerabilities that can undermine security if left unaddressed.
+
+170
+00:15:00,000 --> 00:15:04,000
+First, let's take a closer look at the use of behavioral biometrics.
+
+171
+00:15:05,000 --> 00:15:09,000
+This practice goes beyond static authentication measures like passwords.
+
+172
+00:15:09,000 --> 00:15:15,000
+By analyzing a user's behavioral patterns, how they type moves the mouse, or interact with the system.
+
+173
+00:15:15,000 --> 00:15:21,000
+Behavioral biometrics work in the background, continuously assessing whether the user is acting in
+
+174
+00:15:21,000 --> 00:15:23,000
+a way that matches their known behavior.
+
+175
+00:15:23,000 --> 00:15:30,000
+For example, even if an attacker successfully logs in with stolen credentials, they might type slower
+
+176
+00:15:30,000 --> 00:15:33,000
+or use different mouse movements than the legitimate user.
+
+177
+00:15:34,000 --> 00:15:41,000
+This subtle continuous monitoring adds an extra layer of security by identifying suspicious behavior
+
+178
+00:15:41,000 --> 00:15:43,000
+even after the login process is complete.
+
+179
+00:15:44,000 --> 00:15:49,000
+It provides a real time defense against account compromise by detecting deviations from normal user
+
+180
+00:15:49,000 --> 00:15:54,000
+behavior, making it difficult for attackers to maintain access.
+
+181
+00:15:55,000 --> 00:16:03,000
+Next, continuous session validation ensures that user sessions remain secure for their entire duration,
+
+182
+00:16:03,000 --> 00:16:05,000
+not just at the point of login.
+
+183
+00:16:05,000 --> 00:16:11,000
+After a user has authenticated, there is always the risk of session hijacking where an attacker takes
+
+184
+00:16:11,000 --> 00:16:13,000
+over an active session.
+
+185
+00:16:14,000 --> 00:16:20,000
+To mitigate this, continuous session validation requires periodic re-authentication to confirm that
+
+186
+00:16:20,000 --> 00:16:23,000
+the legitimate user is still in control.
+
+187
+00:16:23,000 --> 00:16:29,000
+This can be especially important for long sessions or high risk actions, such as accessing sensitive
+
+188
+00:16:29,000 --> 00:16:31,000
+data or making financial transactions.
+
+189
+00:16:32,000 --> 00:16:39,000
+For example, after a certain period of inactivity or before a critical action, the system might ask
+
+190
+00:16:39,000 --> 00:16:44,000
+the user to re-enter their credentials or provide multi-factor authentication.
+
+191
+00:16:45,000 --> 00:16:51,000
+This process ensures that even if an attacker has managed to hijack the session, they won't be able
+
+192
+00:16:51,000 --> 00:16:54,000
+to maintain access without being detected.
+
+193
+00:16:55,000 --> 00:17:01,000
+Then we come to login and auditing of all access attempts and activities, which is fundamental for
+
+194
+00:17:01,000 --> 00:17:05,000
+maintaining full visibility into what's happening in your system.
+
+195
+00:17:06,000 --> 00:17:13,000
+Login provides a detailed record of every user interaction who accessed what, when, and from where.
+
+196
+00:17:13,000 --> 00:17:18,000
+This is crucial for both real time threat detection and post-incident investigation.
+
+197
+00:17:19,000 --> 00:17:26,000
+By tracking all access attempts and user activities, organizations can spot unusual patterns such as
+
+198
+00:17:26,000 --> 00:17:32,000
+a spike in failed login attempts or an unexpected access to sensitive resources from an unusual location.
+
+199
+00:17:33,000 --> 00:17:35,000
+in the event of a security incident.
+
+200
+00:17:35,000 --> 00:17:40,000
+Having comprehensive locks allows security teams to retrace the steps of an attacker.
+
+201
+00:17:40,000 --> 00:17:44,000
+Figure out how they entered the system and determine what they did once inside.
+
+202
+00:17:45,000 --> 00:17:46,000
+Without server login.
+
+203
+00:17:46,000 --> 00:17:52,000
+Incidents can go undetected or leave critical gaps in understanding what went wrong.
+
+204
+00:17:53,000 --> 00:18:00,000
+Adaptive access policies build on this visibility by dynamically adjusting user privileges based on
+
+205
+00:18:00,000 --> 00:18:03,000
+the risk level at any given moment.
+
+206
+00:18:04,000 --> 00:18:11,000
+Traditional access control models grant users static levels of access, which can create security gaps
+
+207
+00:18:11,000 --> 00:18:17,000
+if the context changes, such as a user trying to access sensitive information from a different country
+
+208
+00:18:17,000 --> 00:18:20,000
+or on an unfamiliar device.
+
+209
+00:18:21,000 --> 00:18:28,000
+Adaptive access policies take these variables into account, adjusting access levels in real time based
+
+210
+00:18:28,000 --> 00:18:29,000
+on a risk assessment.
+
+211
+00:18:30,000 --> 00:18:37,000
+For example, if a user typically logs in from their office but suddenly tries to access the system
+
+212
+00:18:37,000 --> 00:18:42,000
+from an unrecognized device in a different country, the system might reduce their access privileges
+
+213
+00:18:42,000 --> 00:18:46,000
+or trigger an additional multi-factor authentication step.
+
+214
+00:18:47,000 --> 00:18:54,000
+This kind of context aware access control helps prevent unauthorized actions even when credentials are
+
+215
+00:18:54,000 --> 00:18:58,000
+compromised, making it much harder for attackers to escalate privileges.
+
+216
+00:18:59,000 --> 00:19:05,000
+Finally, we address the elimination of VPN reliance, moving toward zero trust principles.
+
+217
+00:19:06,000 --> 00:19:12,000
+Traditionally, VPNs have been used to create secure connections between remote users and a company's
+
+218
+00:19:12,000 --> 00:19:14,000
+internal network.
+
+219
+00:19:14,000 --> 00:19:17,000
+However, VPNs come with risks.
+
+220
+00:19:18,000 --> 00:19:25,000
+If a VPN is compromised, attackers can move laterally within the network, accessing resources they
+
+221
+00:19:25,000 --> 00:19:26,000
+shouldn't.
+
+222
+00:19:26,000 --> 00:19:33,000
+With zero trust, we move away from relying on the network perimeter for security, and instead focus
+
+223
+00:19:33,000 --> 00:19:40,000
+on authenticating and authorizing each individual access attempt, regardless of the user's location,
+
+224
+00:19:41,000 --> 00:19:46,000
+whether the user is inside the company network or accessing it remotely.
+
+225
+00:19:46,000 --> 00:19:52,000
+Zero trust ensures that each access request is evaluated in real time at the application level.
+
+226
+00:19:53,000 --> 00:19:59,000
+This approach eliminates the risk of VPN vulnerabilities by treating every access request as if it were
+
+227
+00:19:59,000 --> 00:20:04,000
+coming from an untrusted source, verifying and validating continuously.
+
+228
+00:20:05,000 --> 00:20:12,000
+Now that we have covered the key aspects of zero trust architecture and modern authentication, let's
+
+229
+00:20:12,000 --> 00:20:14,000
+take a step back and look at the big picture.
+
+230
+00:20:15,000 --> 00:20:22,000
+As we saw, these best practices are organized by their relevance, ranging from critical threat mitigation
+
+231
+00:20:22,000 --> 00:20:24,000
+to edge cases.
+
+232
+00:20:24,000 --> 00:20:31,000
+But each plays a significant role in securing modern digital infrastructures, starting with the high
+
+233
+00:20:31,000 --> 00:20:32,000
+relevance practices.
+
+234
+00:20:32,000 --> 00:20:35,000
+These are the foundation of zero trust.
+
+235
+00:20:35,000 --> 00:20:41,000
+The zero trust principle fundamentally changes how we approach security, rejecting the idea that anyone
+
+236
+00:20:41,000 --> 00:20:45,000
+or anything inside the network perimeter can be trusted.
+
+237
+00:20:45,000 --> 00:20:51,000
+Instead, every user and device must constantly prove its identity, using multi-factor authentication
+
+238
+00:20:51,000 --> 00:20:54,000
+as a key method to strengthen this verification process.
+
+239
+00:20:55,000 --> 00:21:01,000
+Beyond multi-factor authentication, the use of biometric verification further strengthens authentication
+
+240
+00:21:01,000 --> 00:21:08,000
+by relying on unique physical traits, making it nearly impossible for attackers to impersonate legitimate
+
+241
+00:21:08,000 --> 00:21:09,000
+users.
+
+242
+00:21:09,000 --> 00:21:16,000
+These strategies, along with continuous monitoring and enforcing least privilege access, help us limit
+
+243
+00:21:16,000 --> 00:21:21,000
+access to only what is necessary, reducing the chances of a successful breach.
+
+244
+00:21:22,000 --> 00:21:29,000
+These methods not only prevent external threats, but also reduces the risk of insider threats by ensuring
+
+245
+00:21:29,000 --> 00:21:32,000
+access is always based on identity and context.
+
+246
+00:21:33,000 --> 00:21:40,000
+In the moderate relevance category, we saw practices that address common but important security concerns.
+
+247
+00:21:40,000 --> 00:21:47,000
+The integration of strong identity and access management systems ensures that all users and devices
+
+248
+00:21:47,000 --> 00:21:50,000
+are properly authenticated before gaining access.
+
+249
+00:21:50,000 --> 00:21:58,000
+Adding an extra layer of security at the gateway to the network, Microsegmentation further strengthens
+
+250
+00:21:58,000 --> 00:22:04,000
+this by breaking the network into smaller, more manageable zones, limiting the damage of any potential
+
+251
+00:22:05,000 --> 00:22:07,000
+breach by preventing lateral movement.
+
+252
+00:22:08,000 --> 00:22:15,000
+Additionally, device trust policies ensure that only secure and compliant devices can access critical
+
+253
+00:22:15,000 --> 00:22:22,000
+systems, reducing the risk of compromised devices becoming entry points for attacks.
+
+254
+00:22:22,000 --> 00:22:28,000
+These controls are further enhanced by context aware access assessing each access requests.
+
+255
+00:22:28,000 --> 00:22:33,000
+Risk based on real time factors like location and device.
+
+256
+00:22:33,000 --> 00:22:37,000
+These principles, when applied to cloud environments, help extend.
+
+257
+00:22:37,000 --> 00:22:43,000
+Zero trust to cloud based resources, where identity verification and least privilege access must also
+
+258
+00:22:43,000 --> 00:22:45,000
+be strictly enforced.
+
+259
+00:22:46,000 --> 00:22:51,000
+Finally, in the low relevance category, we discussed practices that handle specific edge cases and
+
+260
+00:22:51,000 --> 00:22:53,000
+lesser known threats.
+
+261
+00:22:53,000 --> 00:22:59,000
+Behavioral biometrics, for example, adds a subtle but effective layer of security by analyzing unique
+
+262
+00:22:59,000 --> 00:23:06,000
+user behaviors such as typing speed or mouse movements, making it harder for attackers to mimic legitimate
+
+263
+00:23:06,000 --> 00:23:07,000
+users.
+
+264
+00:23:08,000 --> 00:23:14,000
+Additionally, continuous session validation ensures that authenticated sessions remain secure, requiring
+
+265
+00:23:14,000 --> 00:23:17,000
+periodic re-authentication to reduce the risk of session hijacking.
+
+266
+00:23:18,000 --> 00:23:23,000
+The importance of logging and auditing also cannot be overstated, as it provides visibility into every
+
+267
+00:23:23,000 --> 00:23:28,000
+access, attempt and action, enabling the detection of suspicious activities.
+
+268
+00:23:29,000 --> 00:23:36,000
+Finally, with the elimination of VPN, Reliance Zero Trust shifts security from network based solutions
+
+269
+00:23:36,000 --> 00:23:42,000
+to continuous identity verification, securing resources regardless of where users are located.
+
+270
+00:23:43,000 --> 00:23:46,000
+That's all things that I wanted to discuss with you today.
+
+271
+00:23:47,000 --> 00:23:50,000
+Let's recap what we have learned from the lesson.
+
+272
+00:23:50,000 --> 00:23:58,000
+We explored the core concept of zero trust architecture, understanding how it operates by not trusting
+
+273
+00:23:58,000 --> 00:24:02,000
+any user or device by default, even inside the network.
+
+274
+00:24:03,000 --> 00:24:09,000
+We discussed the importance of implementing multi-factor authentication across all systems to provide
+
+275
+00:24:09,000 --> 00:24:12,000
+stronger identity verification.
+
+276
+00:24:13,000 --> 00:24:19,000
+We reviewed how biometric authentication methods, such as fingerprint scanning and facial recognition,
+
+277
+00:24:19,000 --> 00:24:23,000
+enhance security by preventing credential based attacks.
+
+278
+00:24:24,000 --> 00:24:30,000
+We learned how continuous monitoring and behavioral analytics help detect unusual user behavior, allowing
+
+279
+00:24:30,000 --> 00:24:34,000
+for the identification of potential security threats in real time.
+
+280
+00:24:35,000 --> 00:24:43,000
+We examined the principle of least privileged access, ensuring users have only the minimum access necessary
+
+281
+00:24:43,000 --> 00:24:46,000
+based on their behavior, identity, and context.
+
+282
+00:24:47,000 --> 00:24:53,000
+We covered the integration of identity and access management systems, along with network segmentation,
+
+283
+00:24:53,000 --> 00:24:59,000
+to isolate sensitive resources and limit lateral movement in case of a breach.
+
+284
+00:25:00,000 --> 00:25:07,000
+Finally, we discussed the elimination of VPN reliance, focusing on how zero trust controls authenticate
+
+285
+00:25:07,000 --> 00:25:11,000
+and authorize users regardless of network location.
+
+286
+00:25:12,000 --> 00:25:14,000
+That's all for the lesson.
+
+287
+00:25:14,000 --> 00:25:16,000
+Thanks a lot for your attention.
+
+288
+00:25:16,000 --> 00:25:19,000
+Have a great day and see you in the next lesson.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/005 Encryption Essentials Protecting Data with Cryptography - Part 1_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/005 Encryption Essentials Protecting Data with Cryptography - Part 1_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..da0eed4050770bfecebb510dbe52109b299697f4
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/005 Encryption Essentials Protecting Data with Cryptography - Part 1_en.srt
@@ -0,0 +1,840 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:11,000
+In this lesson, we'll focus on the importance of protecting data through encryption and structured
+
+3
+00:00:11,000 --> 00:00:13,000
+logging practices.
+
+4
+00:00:13,000 --> 00:00:19,000
+These principles are categorized based on their significance, ranging from critical measures that address
+
+5
+00:00:19,000 --> 00:00:25,000
+the most serious security concerns to less frequent, but still important considerations.
+
+6
+00:00:26,000 --> 00:00:33,000
+The overall goal is to ensure that data remains secure, systems operate reliably, and any potential
+
+7
+00:00:33,000 --> 00:00:36,000
+issues are monitored and recorded effectively.
+
+8
+00:00:36,000 --> 00:00:42,000
+Implementing these practices helps create a strong security foundation, preventing unauthorized access,
+
+9
+00:00:42,000 --> 00:00:48,000
+ensuring compliance, and promoting proactive threat detection by prioritizing key areas.
+
+10
+00:00:48,000 --> 00:00:53,000
+Organizations can better manage their sensitive information, maintain system integrity, and be prepared
+
+11
+00:00:53,000 --> 00:00:55,000
+to respond to security challenges.
+
+12
+00:00:56,000 --> 00:01:03,000
+This structured approach ensures all aspects of data protection are covered, making systems more resilient.
+
+13
+00:01:03,000 --> 00:01:05,000
+Let's start our lesson.
+
+14
+00:01:05,000 --> 00:01:12,000
+In this session, we will delve into encryption essentials, protecting data with cryptography, focusing
+
+15
+00:01:12,000 --> 00:01:16,000
+on a structured list of cryptographic and login best practices.
+
+16
+00:01:16,000 --> 00:01:20,000
+These practices are organized by their relevance to security.
+
+17
+00:01:20,000 --> 00:01:26,000
+Starting with high relevance items that are critical for mitigating the most severe threats, such as
+
+18
+00:01:26,000 --> 00:01:31,000
+protecting master secrets and implementing cryptographic functions on trusted systems.
+
+19
+00:01:32,000 --> 00:01:38,000
+We'll also cover practices like secure random number generation and login vital security events, which
+
+20
+00:01:38,000 --> 00:01:41,000
+forms the foundation of strong encryption management.
+
+21
+00:01:42,000 --> 00:01:47,000
+As we move forward, we'll explore moderate relevance concerns like compliance with cryptographic standards,
+
+22
+00:01:47,000 --> 00:01:54,000
+login input validation failures, and preventing sensitive information from being exposed in error messages.
+
+23
+00:01:55,000 --> 00:02:02,000
+Lastly, we'll look at low relevance, but important edge cases such as error handling, key management
+
+24
+00:02:02,000 --> 00:02:05,000
+policies and securing login mechanisms.
+
+25
+00:02:05,000 --> 00:02:12,000
+Each of these areas plays a crucial role in ensuring robust cryptographic security, and we will discuss
+
+26
+00:02:12,000 --> 00:02:15,000
+the specific implementations and impacts in detail.
+
+27
+00:02:16,000 --> 00:02:22,000
+The second list groups cryptographic and logging best practices by complexity, providing a structured
+
+28
+00:02:22,000 --> 00:02:25,000
+approach to understanding these principles.
+
+29
+00:02:25,000 --> 00:02:30,000
+It categorizes practices into basic, intermediate, and advanced levels.
+
+30
+00:02:31,000 --> 00:02:37,000
+The basic section covers straightforward tasks like avoiding sensitive information disclosure in error
+
+31
+00:02:37,000 --> 00:02:44,000
+messages, ensuring proper error handling, and logging critical events such as authentication attempts
+
+32
+00:02:44,000 --> 00:02:46,000
+and input validation failures.
+
+33
+00:02:47,000 --> 00:02:53,000
+As you progress to the intermediate level, you will encounter slightly more complex tasks, such as
+
+34
+00:02:53,000 --> 00:02:59,000
+ensuring cryptographic functions run on trusted Untrusted systems, login TLS connection failures,
+
+35
+00:02:59,000 --> 00:03:03,000
+and using cryptographic hash functions for log integrity.
+
+36
+00:03:03,000 --> 00:03:10,000
+Finally, the advanced section deals with high level practices such as master secret protection, secure
+
+37
+00:03:10,000 --> 00:03:15,000
+random number generation, and the establishment of key management policies.
+
+38
+00:03:16,000 --> 00:03:20,000
+While this grouping by complexity is helpful, you are not limited to it.
+
+39
+00:03:20,000 --> 00:03:26,000
+Feel free to adopt a categorization technique that best suits your learning style.
+
+40
+00:03:27,000 --> 00:03:33,000
+For example, you could group practices by their real world impact, frequency of use, or the specific
+
+41
+00:03:33,000 --> 00:03:35,000
+area of application.
+
+42
+00:03:35,000 --> 00:03:41,000
+The goal is to make it easier for you to grasp the key principles of cryptography and logging, so don't
+
+43
+00:03:41,000 --> 00:03:47,000
+hesitate to experiment with different approaches that accelerate your understanding.
+
+44
+00:03:47,000 --> 00:03:51,000
+As I promised, let's provide a detailed overview of each technique.
+
+45
+00:03:52,000 --> 00:03:55,000
+As you saw, there are different ways to group these practices.
+
+46
+00:03:55,000 --> 00:04:01,000
+However, for the sake of this lesson, let's organize all the techniques by relevance and reviews them
+
+47
+00:04:01,000 --> 00:04:02,000
+in that order.
+
+48
+00:04:02,000 --> 00:04:07,000
+And in case you have any questions during the lesson, no need to wait till the end of the lesson.
+
+49
+00:04:07,000 --> 00:04:12,000
+Write them in the Q&A section below the video and I will be happy to answer.
+
+50
+00:04:12,000 --> 00:04:16,000
+First, let's talk about protecting master secrets.
+
+51
+00:04:16,000 --> 00:04:23,000
+Master secrets, such as encryption keys are absolutely critical because they are the foundation of
+
+52
+00:04:23,000 --> 00:04:25,000
+all cryptographic operations.
+
+53
+00:04:25,000 --> 00:04:32,000
+If these keys are compromised, an attacker can decrypt any sensitive data encrypted with them, regardless
+
+54
+00:04:32,000 --> 00:04:35,000
+of how secure the algorithm itself might be.
+
+55
+00:04:36,000 --> 00:04:42,000
+Therefore, it's essential to store these keys in secure environments like hardware security modules.
+
+56
+00:04:42,000 --> 00:04:47,000
+Hardware security modules provide physical and logical protection against tampering, ensuring that
+
+57
+00:04:47,000 --> 00:04:54,000
+even if someone gains access to the server, they can't extract the keys, for example, storing keys
+
+58
+00:04:54,000 --> 00:05:00,000
+in plain text on a shared network drive is a disaster waiting to happen, as anyone with access to the
+
+59
+00:05:00,000 --> 00:05:02,000
+drive could potentially steal those keys.
+
+60
+00:05:03,000 --> 00:05:08,000
+A better practice would be using a hardware security module with restricted access and multi-factor
+
+61
+00:05:08,000 --> 00:05:14,000
+authentication, to ensure that only authorized personnel can access the keys.
+
+62
+00:05:15,000 --> 00:05:21,000
+Next, we must ensure that all cryptographic functions are executed on trusted systems.
+
+63
+00:05:22,000 --> 00:05:24,000
+What do we mean by trusted systems?
+
+64
+00:05:25,000 --> 00:05:32,000
+This refers to secure, well audited servers or environments that have strict access control measures.
+
+65
+00:05:32,000 --> 00:05:38,000
+Running cryptographic operations in untrusted environments, like personal devices or poorly secured
+
+66
+00:05:38,000 --> 00:05:41,000
+cloud systems introduces the risk of tampering.
+
+67
+00:05:42,000 --> 00:05:48,000
+For instance, if encryption or decryption is performed on a system that an attacker controls, they
+
+68
+00:05:48,000 --> 00:05:55,000
+can potentially manipulate the process to weaken security By isolating cryptographic operations to secure
+
+69
+00:05:55,000 --> 00:06:00,000
+servers, we minimize the risk of tampering or malicious code injection.
+
+70
+00:06:01,000 --> 00:06:07,000
+The goal here is to create a barrier between sensitive cryptographic operations and potentially insecure
+
+71
+00:06:07,000 --> 00:06:12,000
+systems, thus maintaining the integrity of the encryption processes.
+
+72
+00:06:13,000 --> 00:06:17,000
+Now let's talk about secure failure of cryptographic modules.
+
+73
+00:06:17,000 --> 00:06:23,000
+Cryptographic modules, like any system, can fail whether due to hardware malfunctions or software
+
+74
+00:06:23,000 --> 00:06:24,000
+bugs.
+
+75
+00:06:25,000 --> 00:06:30,000
+When a failure happens, it's important that the system fails securely.
+
+76
+00:06:30,000 --> 00:06:37,000
+This means it should not reveal any sensitive information or leave the system vulnerable to attack.
+
+77
+00:06:37,000 --> 00:06:44,000
+For instance, imagine an encryption module failing in such a way that it starts outputting unencrypted
+
+78
+00:06:44,000 --> 00:06:45,000
+data.
+
+79
+00:06:45,000 --> 00:06:47,000
+That would be catastrophic.
+
+80
+00:06:47,000 --> 00:06:54,000
+A secure failure mechanism would shut down access entirely logs the incident and alerts the administrators.
+
+81
+00:06:54,000 --> 00:07:00,000
+It's essential that cryptographic systems don't degrade into insecure states, but rather stop function
+
+82
+00:07:00,000 --> 00:07:02,000
+altogether to avoid exposing sensitive data.
+
+83
+00:07:03,000 --> 00:07:08,000
+One of the less discussed but highly important aspects is secure random number generation.
+
+84
+00:07:09,000 --> 00:07:15,000
+Random numbers are the building blocks of secure encryption, key generation, guide creation, and
+
+85
+00:07:15,000 --> 00:07:15,000
+more.
+
+86
+00:07:16,000 --> 00:07:23,000
+If random numbers are predictable, then attackers can reverse engineer the process and break the encryption.
+
+87
+00:07:24,000 --> 00:07:31,000
+Unfortunately, many developers still use weak functions like rand to generate these values, which
+
+88
+00:07:31,000 --> 00:07:33,000
+are not cryptographically secure.
+
+89
+00:07:34,000 --> 00:07:40,000
+Instead, we should be using cryptographically secure random number generators that are approved by
+
+90
+00:07:40,000 --> 00:07:42,000
+standards like fabs.
+
+91
+00:07:42,000 --> 00:07:48,000
+This ensures that the values are truly unpredictable and safe from attacks.
+
+92
+00:07:49,000 --> 00:07:56,000
+A good example would be using a cryptographic library that implements NIST approved random number generators,
+
+93
+00:07:56,000 --> 00:07:59,000
+making it impossible for attackers to guess the output.
+
+94
+00:08:00,000 --> 00:08:07,000
+Next, let's look at the importance of login authentication attempts, particularly failed ones.
+
+95
+00:08:08,000 --> 00:08:14,000
+When someone tries to login to a system, especially when they fail, this could indicate the early
+
+96
+00:08:14,000 --> 00:08:22,000
+stages of an attack, like a brute force attempt to guess passwords by logging each attempt, especially
+
+97
+00:08:22,000 --> 00:08:26,000
+the failures, we can detect unusual activity patterns.
+
+98
+00:08:26,000 --> 00:08:32,000
+For example, if you notice hundreds of failed login attempts within a short period, it's likely that
+
+99
+00:08:32,000 --> 00:08:35,000
+someone is trying to break into your system.
+
+100
+00:08:36,000 --> 00:08:40,000
+Login this and alerting the security team can help stop the attack before it escalates.
+
+101
+00:08:41,000 --> 00:08:47,000
+On the other hand, systems that don't log authentication attempts leave administrators blind to these
+
+102
+00:08:47,000 --> 00:08:49,000
+types of attacks until it's too late.
+
+103
+00:08:51,000 --> 00:08:57,000
+Similarly, login access control failures is critical for detecting unauthorized access attempts.
+
+104
+00:08:58,000 --> 00:09:05,000
+Access control ensures that only authorized users can access certain data or perform specific actions.
+
+105
+00:09:05,000 --> 00:09:12,000
+If someone attempts to bypass these controls, whether by accident or maliciously, it's important to
+
+106
+00:09:12,000 --> 00:09:13,000
+log these failures.
+
+107
+00:09:14,000 --> 00:09:19,000
+Imagine an attacker trying to elevate their privileges or access files they shouldn't be able to.
+
+108
+00:09:19,000 --> 00:09:26,000
+If those attempts are logged, security teams can take action to investigate and block further attempts.
+
+109
+00:09:27,000 --> 00:09:33,000
+Failing to log access control failures means you're missing critical information that could indicate
+
+110
+00:09:33,000 --> 00:09:35,000
+an ongoing security breach.
+
+111
+00:09:35,000 --> 00:09:41,000
+Finally, we must also log any tampering events or unexpected changes in system state.
+
+112
+00:09:41,000 --> 00:09:48,000
+Tampering can include unauthorized changes to encrypted data or modifications to cryptographic settings.
+
+113
+00:09:49,000 --> 00:09:57,000
+If these changes go unnoticed, an attacker could potentially weaken the encryption or alter the data.
+
+114
+00:09:57,000 --> 00:10:04,000
+A good system will log any unexpected state changes and alert administrators so they can investigate.
+
+115
+00:10:04,000 --> 00:10:10,000
+For example, if someone tries to manipulate encrypted files or modify encryption settings, it should
+
+116
+00:10:10,000 --> 00:10:12,000
+immediately trigger an alert.
+
+117
+00:10:13,000 --> 00:10:19,000
+On the flip side, systems that don't monitor for such changes can be compromised without the administrators
+
+118
+00:10:19,000 --> 00:10:20,000
+even knowing.
+
+119
+00:10:21,000 --> 00:10:28,000
+Let's dive into the moderate relevance cryptographic concerns, which, while not as critical as the
+
+120
+00:10:28,000 --> 00:10:34,000
+essentials we discussed earlier, still play a vital role in strengthening overall security.
+
+121
+00:10:35,000 --> 00:10:41,000
+Let's start with compliance with Fips 142 or equivalent standards.
+
+122
+00:10:41,000 --> 00:10:48,000
+Compliance here ensures that the cryptographic modules you use are following best practices and are
+
+123
+00:10:48,000 --> 00:10:50,000
+approved by recognized standards.
+
+124
+00:10:51,000 --> 00:10:58,000
+Fips 142, in particular, is a government standard that dictates the security requirements for cryptographic
+
+125
+00:10:58,000 --> 00:10:59,000
+modules.
+
+126
+00:10:59,000 --> 00:11:05,000
+Compliance with this standard means that your cryptography meets the necessary criteria for secure key
+
+127
+00:11:05,000 --> 00:11:07,000
+management, encryption, and decryption.
+
+128
+00:11:08,000 --> 00:11:13,000
+This is especially crucial for industries like finance or healthcare, where regulatory compliance is
+
+129
+00:11:13,000 --> 00:11:14,000
+mandatory.
+
+130
+00:11:15,000 --> 00:11:21,000
+An example of best practice would be using a Fips validated cryptographic library in your application
+
+131
+00:11:21,000 --> 00:11:24,000
+to encrypt sensitive patient information.
+
+132
+00:11:24,000 --> 00:11:31,000
+On the other hand, using a non-certified homemade cryptographic library which might have vulnerabilities
+
+133
+00:11:31,000 --> 00:11:34,000
+could easily lead to data breaches.
+
+134
+00:11:34,000 --> 00:11:41,000
+Such libraries may not have gone through the rigorous validation processes that Fips certified modules
+
+135
+00:11:41,000 --> 00:11:46,000
+have, making them more prone to weaknesses that attackers could exploit.
+
+136
+00:11:47,000 --> 00:11:54,000
+Next, login input validation failures is a fundamental part of securing any system that handles user
+
+137
+00:11:54,000 --> 00:11:55,000
+inputs.
+
+138
+00:11:55,000 --> 00:12:02,000
+Every time a system rejects invalid input, it could signal an attempted attack such as SQL injection,
+
+139
+00:12:02,000 --> 00:12:06,000
+cross-site scripting, or buffer overflow attacks.
+
+140
+00:12:06,000 --> 00:12:12,000
+Logging these failures allows us to identify patterns and take proactive measures to defend against
+
+141
+00:12:12,000 --> 00:12:14,000
+potential exploits.
+
+142
+00:12:14,000 --> 00:12:21,000
+For example, if a system logs a high volume of failed input validation from a single source, this
+
+143
+00:12:21,000 --> 00:12:26,000
+could indicate that someone is attempting to manipulate the inputs to find a vulnerability.
+
+144
+00:12:26,000 --> 00:12:33,000
+A good example is a web application that logs all failed attempts to inject SQL into its input fields,
+
+145
+00:12:33,000 --> 00:12:37,000
+allowing administrators to detect and block potential attackers.
+
+146
+00:12:38,000 --> 00:12:44,000
+Conversely, not logging input validation failures means that attackers can repeatedly try different
+
+147
+00:12:44,000 --> 00:12:45,000
+techniques to break the system.
+
+148
+00:12:46,000 --> 00:12:50,000
+Without the system administrators even realizing that an attack is underway.
+
+149
+00:12:51,000 --> 00:12:56,000
+Similarly, login system exceptions is another essential practice.
+
+150
+00:12:57,000 --> 00:13:05,000
+System exceptions can reveal underlying issues that, if left unaddressed, may turn into security vulnerabilities.
+
+151
+00:13:05,000 --> 00:13:12,000
+Exceptions occur when the system encounters something unexpected, such as an out of bounds value,
+
+152
+00:13:12,000 --> 00:13:16,000
+a null reference, or an unauthorized action.
+
+153
+00:13:17,000 --> 00:13:24,000
+By logging these events, we gain insight into abnormal system behavior, which could be due to bugs
+
+154
+00:13:24,000 --> 00:13:25,000
+or malicious activity.
+
+155
+00:13:26,000 --> 00:13:33,000
+For instance, if your encryption process fails and logs an exception, it may indicate an issue with
+
+156
+00:13:33,000 --> 00:13:37,000
+the cryptographic key or module that requires immediate attention.
+
+157
+00:13:37,000 --> 00:13:44,000
+Failing to log these exceptions means you could be missing out on important signals of system misconfigurations
+
+158
+00:13:44,000 --> 00:13:46,000
+or potential security issues.
+
+159
+00:13:47,000 --> 00:13:54,000
+In contrast, a system that logs all exceptions and provides details about the context helps administrators
+
+160
+00:13:54,000 --> 00:13:57,000
+quickly identify and address these issues.
+
+161
+00:13:58,000 --> 00:14:03,000
+Moving on, we have avoidance of sensitive information disclosure in error messages.
+
+162
+00:14:04,000 --> 00:14:10,000
+Error messages are often overlooked, but they can reveal a lot about the system to attackers if not
+
+163
+00:14:10,000 --> 00:14:11,000
+handled properly.
+
+164
+00:14:12,000 --> 00:14:18,000
+A generic error message, like invalid input is safe because it provides no useful information to attackers.
+
+165
+00:14:19,000 --> 00:14:26,000
+However, if the system displays detailed error messages with stack traces, database details, session
+
+166
+00:14:26,000 --> 00:14:31,000
+identifiers, or other sensitive information, this can be a goldmine for attackers.
+
+167
+00:14:31,000 --> 00:14:35,000
+They could use this information to identify weaknesses in the system.
+
+168
+00:14:35,000 --> 00:14:41,000
+A good example of best practice is when an application returns a generic error like something went wrong.
+
+169
+00:14:41,000 --> 00:14:45,000
+Please try again without exposing any technical details.
+
+170
+00:14:45,000 --> 00:14:52,000
+On the other hand, if the error message reveals the database engine used, the table structure or session
+
+171
+00:14:52,000 --> 00:14:58,000
+IDs, this can give attackers the insights they need to craft more targeted attacks.
+
+172
+00:14:59,000 --> 00:15:06,000
+Another critical point is the use of cryptographic hash functions to validate log entry integrity.
+
+173
+00:15:07,000 --> 00:15:13,000
+Logs are one of the most important tools for tracing incidents and auditing activity in a system.
+
+174
+00:15:14,000 --> 00:15:19,000
+However, if logs can be tampered with, their reliability is compromised.
+
+175
+00:15:20,000 --> 00:15:30,000
+Using cryptographic hash functions such as Sha 256 to verify the integrity of log entries ensures that
+
+176
+00:15:30,000 --> 00:15:34,000
+any unauthorized modifications are immediately detectable.
+
+177
+00:15:35,000 --> 00:15:42,000
+For instance, each log entry can be hashed when it is created, and that hash can be stored separately.
+
+178
+00:15:42,000 --> 00:15:49,000
+Later, when reviewing the logs, you can check that the hashes match, ensuring that no tampering has
+
+179
+00:15:49,000 --> 00:15:49,000
+occurred.
+
+180
+00:15:49,000 --> 00:15:56,000
+Without this, an attacker who gains access to the logs could alter or delete entries to cover their
+
+181
+00:15:56,000 --> 00:16:00,000
+tracks, making it impossible to conduct a thorough investigation.
+
+182
+00:16:00,000 --> 00:16:06,000
+This is particularly important in environments that require forensic investigation after an incident.
+
+183
+00:16:06,000 --> 00:16:08,000
+Next login.
+
+184
+00:16:08,000 --> 00:16:13,000
+TLS connection failures is crucial for maintaining secure communications between systems.
+
+185
+00:16:14,000 --> 00:16:20,000
+TLS or Transport Layer Security is what protects data in transit by encrypting it.
+
+186
+00:16:20,000 --> 00:16:27,000
+If a TLS connection fails, it could mean that there is a configuration issue, such as an expired or
+
+187
+00:16:27,000 --> 00:16:34,000
+invalid certificate, or it could indicate a more serious issue, such as an attempted man in the middle
+
+188
+00:16:34,000 --> 00:16:35,000
+attack.
+
+189
+00:16:35,000 --> 00:16:41,000
+By logging these failures, you can quickly detect and diagnose problems before they lead to insecure
+
+190
+00:16:41,000 --> 00:16:42,000
+communications.
+
+191
+00:16:42,000 --> 00:16:49,000
+For example, a system that logs failed TLS handshakes with detailed reasons, for example, expired
+
+192
+00:16:49,000 --> 00:16:55,000
+certificates or mismatched protocols allows administrators to take quick corrective action.
+
+193
+00:16:55,000 --> 00:17:02,000
+On the other hand, not logging these failures means that expired certificates or misconfigured servers
+
+194
+00:17:02,000 --> 00:17:09,000
+could go unnoticed, potentially leaving data in transit unencrypted and vulnerable to interception.
+
+195
+00:17:10,000 --> 00:17:16,000
+Finally, login cryptographic module failures is key to understanding the health and security of the
+
+196
+00:17:16,000 --> 00:17:19,000
+cryptographic functions in your system.
+
+197
+00:17:19,000 --> 00:17:26,000
+Cryptographic modules handle sensitive tasks like encryption, decryption, and key management.
+
+198
+00:17:26,000 --> 00:17:33,000
+If one of these modules fails, it could weaken the overall security of the system, leaving data exposed
+
+199
+00:17:33,000 --> 00:17:37,000
+or causing the system to rely on weaker fallback mechanisms.
+
+200
+00:17:38,000 --> 00:17:44,000
+Logging these failures allows system administrators to investigate and fix the issue before it can be
+
+201
+00:17:44,000 --> 00:17:45,000
+exploited.
+
+202
+00:17:45,000 --> 00:17:51,000
+For example, if a cryptographic module fails during an encryption process, logging this event allows
+
+203
+00:17:51,000 --> 00:17:56,000
+the security team to investigate whether the failure was due to a hardware malfunction, a software
+
+204
+00:17:56,000 --> 00:17:58,000
+bug, or even a deliberate attack.
+
+205
+00:17:59,000 --> 00:18:05,000
+Not logging these failures could mean that degraded security conditions go unnoticed, potentially leaving
+
+206
+00:18:05,000 --> 00:18:07,000
+sensitive data unprotected.
+
+207
+00:18:08,000 --> 00:18:14,000
+By addressing each of these concerns, whether it's compliance, logging, or integrity checks, we
+
+208
+00:18:14,000 --> 00:18:18,000
+create a stronger, more resilient security posture.
+
+209
+00:18:18,000 --> 00:18:25,000
+This moderate relevance practices, while not as immediately urgent as key protection or encryption,
+
+210
+00:18:25,000 --> 00:18:30,000
+are fundamental to maintaining long term system integrity and security.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/006 Encryption Essentials Protecting Data with Cryptography - Part 2_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/006 Encryption Essentials Protecting Data with Cryptography - Part 2_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..fa427d8381977d315e6a8dbbfb516bbfcc1d6272
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/006 Encryption Essentials Protecting Data with Cryptography - Part 2_en.srt
@@ -0,0 +1,932 @@
+1
+00:00:03,000 --> 00:00:09,000
+Let's go through each of these low relevance cryptographic concerns in more detail, as they address
+
+2
+00:00:09,000 --> 00:00:16,000
+edge cases and uncommon threats that still have an impact on the overall security framework.
+
+3
+00:00:16,000 --> 00:00:23,000
+While they may not seem as urgent as high relevance issues, they are vital for building a comprehensive
+
+4
+00:00:23,000 --> 00:00:24,000
+and secure system.
+
+5
+00:00:25,000 --> 00:00:29,000
+First, establishing a policy for cryptographic key management is crucial.
+
+6
+00:00:30,000 --> 00:00:34,000
+Cryptographic keys are the most sensitive part of any encryption process.
+
+7
+00:00:34,000 --> 00:00:37,000
+They control access to encrypted data.
+
+8
+00:00:37,000 --> 00:00:41,000
+Therefore, having a robust key management policy is essential.
+
+9
+00:00:41,000 --> 00:00:47,000
+This policy should cover the full life cycle of keys, including secure key generation, storage, rotation
+
+10
+00:00:47,000 --> 00:00:49,000
+and deletion, for example.
+
+11
+00:00:49,000 --> 00:00:55,000
+Best practice is to rotate encryption keys regularly and ensure that all keys are securely destroyed
+
+12
+00:00:55,000 --> 00:00:57,000
+when they are no longer in use.
+
+13
+00:00:57,000 --> 00:01:02,000
+Failing to implement such a policy can lead to old or compromised.
+
+14
+00:01:02,000 --> 00:01:07,000
+Keys are being reused, which can expose sensitive data to unauthorized parties.
+
+15
+00:01:08,000 --> 00:01:15,000
+A scenario where encryption keys are stored in securely, such as in plain text files, would significantly
+
+16
+00:01:15,000 --> 00:01:17,000
+increase the risk of a breach.
+
+17
+00:01:18,000 --> 00:01:25,000
+Next, we have error handlers that do not expose debugging or stack trace details.
+
+18
+00:01:25,000 --> 00:01:31,000
+When an error occurs, especially in a production environment, it's important that the system does
+
+19
+00:01:31,000 --> 00:01:34,000
+not expose too much information to users.
+
+20
+00:01:35,000 --> 00:01:42,000
+Detailed error messages that include stack traces, file names, or other debugging information can
+
+21
+00:01:42,000 --> 00:01:46,000
+give attackers valuable insights into the internal workings of your system.
+
+22
+00:01:47,000 --> 00:01:53,000
+For instance, an attacker could use the stack trace to understand the structure of your application
+
+23
+00:01:53,000 --> 00:01:55,000
+and identify potential vulnerabilities.
+
+24
+00:01:56,000 --> 00:02:02,000
+Best practice is to return generic error messages like something went wrong while logging the detailed
+
+25
+00:02:02,000 --> 00:02:04,000
+information for internal review.
+
+26
+00:02:05,000 --> 00:02:11,000
+Failing to do this can result in accidental exposure of system details that attackers could exploit
+
+27
+00:02:12,000 --> 00:02:14,000
+to launch more sophisticated attacks.
+
+28
+00:02:15,000 --> 00:02:21,000
+The next point relates closely generic error messages and custom error pages.
+
+29
+00:02:21,000 --> 00:02:31,000
+When users encounter errors such as 404 page not found or 500 internal server error, the error page
+
+30
+00:02:31,000 --> 00:02:37,000
+displayed to them should be customized and user friendly, while also concealing system details.
+
+31
+00:02:38,000 --> 00:02:44,000
+A generic error message, perhaps combined with a friendly message like oops, something went wrong,
+
+32
+00:02:44,000 --> 00:02:48,000
+can prevent attackers from learning too much about your infrastructure.
+
+33
+00:02:48,000 --> 00:02:55,000
+For example, default server error pages often include information about the server software and version,
+
+34
+00:02:55,000 --> 00:02:59,000
+which can be used by attackers to craft targeted exploits.
+
+35
+00:02:59,000 --> 00:03:06,000
+Customizing these pages to be informative but Non-revealing ensures that the system is secure while
+
+36
+00:03:06,000 --> 00:03:09,000
+still providing a good user experience.
+
+37
+00:03:10,000 --> 00:03:11,000
+Moving on.
+
+38
+00:03:11,000 --> 00:03:16,000
+Handling application errors within the application itself is another best practice.
+
+39
+00:03:16,000 --> 00:03:22,000
+Rather than relying on server side error handling, the application should have mechanisms in place
+
+40
+00:03:22,000 --> 00:03:25,000
+to catch and manage exceptions internally.
+
+41
+00:03:25,000 --> 00:03:32,000
+This prevents the server from exposing unnecessary details about the application, and ensures that
+
+42
+00:03:32,000 --> 00:03:35,000
+errors are handled in a controlled and secure manner.
+
+43
+00:03:36,000 --> 00:03:41,000
+For example, catching an exception in your application code and displaying a generic error page to
+
+44
+00:03:41,000 --> 00:03:47,000
+the user is much more secure than allowing the server to handle it, which might expose unintended information
+
+45
+00:03:47,000 --> 00:03:49,000
+about the back end system.
+
+46
+00:03:49,000 --> 00:03:55,000
+If you rely only on server configurations, you risk missing critical error handling scenarios that
+
+47
+00:03:55,000 --> 00:03:57,000
+could expose your system to attackers.
+
+48
+00:03:58,000 --> 00:04:01,000
+Next, we have proper memory deallocation.
+
+49
+00:04:01,000 --> 00:04:03,000
+When error conditions occur.
+
+50
+00:04:03,000 --> 00:04:07,000
+This is a more technical point, but incredibly important.
+
+51
+00:04:07,000 --> 00:04:13,000
+When an error occurs, especially in languages like C or C plus plus, any memory that was allocated
+
+52
+00:04:13,000 --> 00:04:20,000
+during the process needs to be securely deallocated to prevent memory leaks or data retention.
+
+53
+00:04:20,000 --> 00:04:28,000
+If memory isn't properly released, sensitive information like cryptographic keys or personal data could
+
+54
+00:04:28,000 --> 00:04:31,000
+remain in memory and potentially be accessed by an attacker.
+
+55
+00:04:32,000 --> 00:04:39,000
+Best practice is to ensure that error handling routines always include secure memory deallocation,
+
+56
+00:04:39,000 --> 00:04:42,000
+particularly when sensitive data is involved.
+
+57
+00:04:42,000 --> 00:04:48,000
+Failing to do so can leave residual data in memory that could be exploited through memory corruption
+
+58
+00:04:48,000 --> 00:04:48,000
+attacks.
+
+59
+00:04:49,000 --> 00:04:57,000
+Another key point is denial of access by default in error handling logic associated with security controls.
+
+60
+00:04:57,000 --> 00:05:03,000
+When errors occur, especially in systems that handle sensitive data or access This control.
+
+61
+00:05:03,000 --> 00:05:10,000
+The default behavior should always be to deny access unless explicitly allowed.
+
+62
+00:05:11,000 --> 00:05:18,000
+This principle of fail safe ensures that even if something goes wrong, attackers can't exploit the
+
+63
+00:05:18,000 --> 00:05:21,000
+error to gain unauthorized access.
+
+64
+00:05:22,000 --> 00:05:28,000
+For instance, if an error occurs during the authentication process, it's better to deny access altogether
+
+65
+00:05:28,000 --> 00:05:33,000
+than to risk allowing an unauthorized user to enter the system.
+
+66
+00:05:33,000 --> 00:05:40,000
+Systems that allow access by default during failures introduce a significant security risk, as attackers
+
+67
+00:05:40,000 --> 00:05:44,000
+could intentionally trigger errors to bypass access controls.
+
+68
+00:05:46,000 --> 00:05:49,000
+Now let's discuss login controls on a trusted system.
+
+69
+00:05:50,000 --> 00:05:54,000
+All login operations should take place on a trusted secure system.
+
+70
+00:05:54,000 --> 00:06:01,000
+This is because logs often contain sensitive information such as error messages, user activity, and
+
+71
+00:06:01,000 --> 00:06:04,000
+even potentially sensitive data like Usernames.
+
+72
+00:06:05,000 --> 00:06:12,000
+Login on an untrusted or insecure system opens the door for tampering or unauthorized access to these
+
+73
+00:06:12,000 --> 00:06:16,000
+logs, which could compromise the entire audit trail.
+
+74
+00:06:16,000 --> 00:06:23,000
+Best practice is to centralize login on a dedicated secure server that is monitored and audited regularly.
+
+75
+00:06:23,000 --> 00:06:29,000
+For example, using a secure login server ensures that logs can't be tampered with or erased, which
+
+76
+00:06:29,000 --> 00:06:34,000
+would be a serious issue in environments where logs are critical for compliance or forensic analysis.
+
+77
+00:06:35,000 --> 00:06:40,000
+Speaking of logs, ensuring logs contain important event data is equally important.
+
+78
+00:06:41,000 --> 00:06:44,000
+Logs are only useful if they capture the right information.
+
+79
+00:06:45,000 --> 00:06:52,000
+Every log entry should include critical details such as timestamps, user IDs, IP addresses, and a
+
+80
+00:06:52,000 --> 00:06:54,000
+description of the event.
+
+81
+00:06:54,000 --> 00:07:00,000
+This information is vital for auditing, troubleshooting, and investigating security incidents.
+
+82
+00:07:01,000 --> 00:07:09,000
+For example, a failed login attempt log that includes the timestamp, username, and originating IP
+
+83
+00:07:09,000 --> 00:07:10,000
+address.
+
+84
+00:07:10,000 --> 00:07:16,000
+Allows security teams to track patterns of brute force attacks or unauthorized access attempts.
+
+85
+00:07:17,000 --> 00:07:23,000
+Logs that don't capture enough detail make it difficult to investigate issues or build a clear timeline
+
+86
+00:07:23,000 --> 00:07:26,000
+of events during an incident.
+
+87
+00:07:27,000 --> 00:07:33,000
+A related concern is preventing untrusted data in log entries from executing as code.
+
+88
+00:07:33,000 --> 00:07:38,000
+Logs often record user input, which can include potentially harmful data.
+
+89
+00:07:39,000 --> 00:07:45,000
+If this untrusted data is not sanitized, there is a risk that it could be executed as code when viewed
+
+90
+00:07:45,000 --> 00:07:51,000
+in certain log management systems or interfaces, leading to a log injection attack.
+
+91
+00:07:51,000 --> 00:07:58,000
+For example, a user might inject malicious code into a form field, and if that input is logged without
+
+92
+00:07:58,000 --> 00:08:03,000
+proper sanitization, the log viewer might accidentally execute it.
+
+93
+00:08:03,000 --> 00:08:09,000
+The best practice is to sanitize all user input before logging it to prevent such attacks.
+
+94
+00:08:10,000 --> 00:08:15,000
+Failure to do so could result in unauthorized code execution or further compromise of the system.
+
+95
+00:08:17,000 --> 00:08:21,000
+Next is restricting log access to authorized individuals only.
+
+96
+00:08:22,000 --> 00:08:28,000
+Logs contain sensitive data and should only be accessible to a select group of individuals, such as
+
+97
+00:08:28,000 --> 00:08:31,000
+system administrators or the security team.
+
+98
+00:08:32,000 --> 00:08:38,000
+Unauthorized access to logs can lead to exposure of critical information, like failed login attempts
+
+99
+00:08:38,000 --> 00:08:42,000
+or error messages, that might reveal system weaknesses.
+
+100
+00:08:43,000 --> 00:08:49,000
+Implementing strict access controls ensures that only authorized personnel can view and manage logs.
+
+101
+00:08:49,000 --> 00:08:55,000
+A secure system would, for instance, use role based access control to limit who can read, modify,
+
+102
+00:08:55,000 --> 00:08:56,000
+or delete logs.
+
+103
+00:08:57,000 --> 00:09:02,000
+Without these controls, unauthorized users could access logs and potentially use the information to
+
+104
+00:09:02,000 --> 00:09:03,000
+launch attacks.
+
+105
+00:09:03,000 --> 00:09:07,000
+We should also consider the utilization of a centralized login routine.
+
+106
+00:09:08,000 --> 00:09:14,000
+Rather than having logs scattered across different services or systems, it's best to implement a centralized
+
+107
+00:09:14,000 --> 00:09:16,000
+login mechanism.
+
+108
+00:09:16,000 --> 00:09:21,000
+This ensures consistency and makes log management far easier.
+
+109
+00:09:22,000 --> 00:09:30,000
+Centralized logging solutions like the Elk stack, Elasticsearch, Logstash, Kibana aggregate logs
+
+110
+00:09:30,000 --> 00:09:35,000
+from various sources into one place where they can be analyzed more effectively.
+
+111
+00:09:36,000 --> 00:09:43,000
+A centralized system allows security teams to detect patterns, correlate events, and identify anomalies
+
+112
+00:09:43,000 --> 00:09:44,000
+more efficiently.
+
+113
+00:09:44,000 --> 00:09:51,000
+In contrast, using scattered logs across different systems makes it hard to see the full picture and
+
+114
+00:09:51,000 --> 00:09:54,000
+can lead to missed security incidents.
+
+115
+00:09:55,000 --> 00:10:01,000
+Another important point is the avoidance of storing sensitive information in logs such as passwords,
+
+116
+00:10:01,000 --> 00:10:04,000
+session IDs, or system details.
+
+117
+00:10:05,000 --> 00:10:12,000
+Storing sensitive data in logs is risky because if logs are accessed by unauthorized users, that information
+
+118
+00:10:12,000 --> 00:10:15,000
+could be used to compromise the system further.
+
+119
+00:10:16,000 --> 00:10:22,000
+Best practice is to ensure that sensitive information is either masked or excluded from logs entirely.
+
+120
+00:10:23,000 --> 00:10:29,000
+For example, if a password is entered incorrectly, the log should not store the plaintext password
+
+121
+00:10:29,000 --> 00:10:29,000
+attempt.
+
+122
+00:10:30,000 --> 00:10:35,000
+Storing passwords or session tokens in logs without encryption is a critical security mistake that attackers
+
+123
+00:10:35,000 --> 00:10:36,000
+could exploit.
+
+124
+00:10:37,000 --> 00:10:41,000
+Ensuring that there is a mechanism for log analysis is also vital.
+
+125
+00:10:41,000 --> 00:10:44,000
+Logs are only useful if they are regularly analyzed.
+
+126
+00:10:44,000 --> 00:10:51,000
+This can be done manually, but in most cases automated tools like security information and event management
+
+127
+00:10:51,000 --> 00:10:56,000
+systems are used to review logs for anomalies or indicators of compromise.
+
+128
+00:10:56,000 --> 00:11:04,000
+Regular analysis allows for early detection of attacks or misconfigurations before they escalate into
+
+129
+00:11:04,000 --> 00:11:05,000
+larger issues.
+
+130
+00:11:05,000 --> 00:11:13,000
+A system that uses Automated log analysis can flag unusual activity such as repeated failed login attempts
+
+131
+00:11:13,000 --> 00:11:20,000
+or access to restricted areas, allowing security teams to respond quickly without a mechanism for log
+
+132
+00:11:20,000 --> 00:11:21,000
+analysis.
+
+133
+00:11:21,000 --> 00:11:25,000
+Logs will accumulate but provide little actionable insight.
+
+134
+00:11:26,000 --> 00:11:32,000
+Let's now focus on logging attempts to connect using invalid or expired session tokens.
+
+135
+00:11:33,000 --> 00:11:38,000
+This is an important practice for detecting potential session hijacking or replay attacks.
+
+136
+00:11:39,000 --> 00:11:45,000
+When a user presents an invalid or expired session token, it could be an indication that someone is
+
+137
+00:11:45,000 --> 00:11:50,000
+trying to reuse old session data to gain unauthorized access.
+
+138
+00:11:50,000 --> 00:11:56,000
+Logging these attempts enables administrators to detect and investigate suspicious activity early.
+
+139
+00:11:56,000 --> 00:12:03,000
+Failing to log these attempts could allow attackers to keep trying invalid tokens without anyone noticing,
+
+140
+00:12:03,000 --> 00:12:05,000
+potentially leading to a session based attack.
+
+141
+00:12:07,000 --> 00:12:07,000
+Finally.
+
+142
+00:12:07,000 --> 00:12:13,000
+login administrative functions, particularly changes to security settings or user management, is crucial
+
+143
+00:12:13,000 --> 00:12:20,000
+for maintaining accountability whenever an administrator makes changes, whether it's adjusting access
+
+144
+00:12:20,000 --> 00:12:25,000
+controls, updating security configurations, or managing user permissions.
+
+145
+00:12:25,000 --> 00:12:27,000
+These actions should be logged in detail.
+
+146
+00:12:28,000 --> 00:12:35,000
+This not only ensures accountability, but also allows for the investigation of any unauthorized changes
+
+147
+00:12:35,000 --> 00:12:37,000
+or insider threats.
+
+148
+00:12:37,000 --> 00:12:44,000
+For instance, logging every change made to a system's firewall settings can help detect if an attacker
+
+149
+00:12:44,000 --> 00:12:48,000
+or rogue insider is trying to weaken the system's defenses.
+
+150
+00:12:48,000 --> 00:12:55,000
+Without logging administrative functions, it becomes difficult to track who made critical changes which
+
+151
+00:12:55,000 --> 00:12:57,000
+can complicate security investigations.
+
+152
+00:12:58,000 --> 00:13:04,000
+By addressing these lower relevance issues in cryptographic and security practices, we create a comprehensive
+
+153
+00:13:04,000 --> 00:13:05,000
+security posture.
+
+154
+00:13:06,000 --> 00:13:10,000
+Although these may be edge cases or less commonly encountered threats.
+
+155
+00:13:10,000 --> 00:13:16,000
+They close gaps that could otherwise be exploited by attackers and provide a more resilient defense
+
+156
+00:13:16,000 --> 00:13:18,000
+against potential vulnerabilities.
+
+157
+00:13:20,000 --> 00:13:25,000
+Let's draw some key conclusions from our discussion of encryption essentials.
+
+158
+00:13:25,000 --> 00:13:27,000
+Protecting data with cryptography.
+
+159
+00:13:27,000 --> 00:13:29,000
+Broken down by relevance.
+
+160
+00:13:29,000 --> 00:13:30,000
+High relevance.
+
+161
+00:13:30,000 --> 00:13:31,000
+Moderate relevance and low relevance.
+
+162
+00:13:31,000 --> 00:13:32,000
+Categories.
+
+163
+00:13:33,000 --> 00:13:39,000
+Starting with high relevance practices, these are the critical measures we must prioritize to mitigate
+
+164
+00:13:39,000 --> 00:13:41,000
+the most severe security threats.
+
+165
+00:13:42,000 --> 00:13:48,000
+Protecting master secrets like encryption keys from unauthorized access is paramount.
+
+166
+00:13:48,000 --> 00:13:54,000
+If these keys are compromised, the integrity of your entire cryptographic system collapses, regardless
+
+167
+00:13:54,000 --> 00:13:56,000
+of the strengths of the algorithms.
+
+168
+00:13:56,000 --> 00:14:02,000
+All cryptographic operations should be executed on a trusted system, meaning on secure audited servers
+
+169
+00:14:02,000 --> 00:14:04,000
+to prevent tampering.
+
+170
+00:14:04,000 --> 00:14:10,000
+Moreover, cryptographic modules need to fail securely, ensuring that failures don't expose sensitive
+
+171
+00:14:10,000 --> 00:14:12,000
+data or reduce security protections.
+
+172
+00:14:13,000 --> 00:14:18,000
+Another critical aspect is the use of approved random number generators to create truly unpredictable
+
+173
+00:14:18,000 --> 00:14:21,000
+values for cryptographic operations.
+
+174
+00:14:21,000 --> 00:14:28,000
+Logging of failed authentication attempts and access control failures is also essential, as these are
+
+175
+00:14:28,000 --> 00:14:33,000
+often the first signs of brute force or privilege escalation attacks.
+
+176
+00:14:33,000 --> 00:14:41,000
+Lastly, monitoring and logging tampering events such as unexpected state changes helps detect active
+
+177
+00:14:41,000 --> 00:14:46,000
+attacks early, providing time to respond before significant damage occurs.
+
+178
+00:14:47,000 --> 00:14:49,000
+Moving to moderate relevance concerns.
+
+179
+00:14:49,000 --> 00:14:55,000
+These practices are common security measures that address important, though less critical, security
+
+180
+00:14:55,000 --> 00:14:56,000
+gaps.
+
+181
+00:14:57,000 --> 00:15:05,000
+Compliance with standards like Fips 142 ensures your cryptographic modules meet accepted guidelines
+
+182
+00:15:05,000 --> 00:15:11,000
+for security, which is especially important for regulated industries like healthcare or finance.
+
+183
+00:15:12,000 --> 00:15:20,000
+Login input validation failures is a key defense against injection attacks and other input based vulnerabilities.
+
+184
+00:15:21,000 --> 00:15:27,000
+Similarly, logging system exceptions provides valuable data to identify and address hidden security
+
+185
+00:15:27,000 --> 00:15:27,000
+issues.
+
+186
+00:15:28,000 --> 00:15:35,000
+Another important practice is to ensure that error responses don't disclose sensitive system details.
+
+187
+00:15:35,000 --> 00:15:42,000
+Stack traces, or session IDs in error messages can unintentionally help attackers understand how your
+
+188
+00:15:42,000 --> 00:15:43,000
+system works.
+
+189
+00:15:44,000 --> 00:15:50,000
+Additionally, cryptographic hash functions should be used to validate the integrity of logs, ensuring
+
+190
+00:15:50,000 --> 00:15:52,000
+they haven't been tampered with.
+
+191
+00:15:53,000 --> 00:15:59,000
+Finally, logging back end TLS connection failures and cryptographic module failures allows for quick
+
+192
+00:15:59,000 --> 00:16:07,000
+diagnosis and response to potential security issues, helping to maintain the confidentiality and integrity
+
+193
+00:16:07,000 --> 00:16:11,000
+of data in transit and during enduring cryptographic operations.
+
+194
+00:16:13,000 --> 00:16:18,000
+Lastly, we have the low relevance category covering edge cases and lesser known threats.
+
+195
+00:16:19,000 --> 00:16:25,000
+These practices address situations that are less frequently encountered but still important for overall
+
+196
+00:16:25,000 --> 00:16:26,000
+system resilience.
+
+197
+00:16:27,000 --> 00:16:33,000
+For instance, creating a policy for cryptographic key management ensures a disciplined approach to
+
+198
+00:16:33,000 --> 00:16:39,000
+generating, storing, and rotating keys, which is crucial for long term security.
+
+199
+00:16:39,000 --> 00:16:44,000
+It's also important to use error handlers that don't expose stack traces or debug details, preventing
+
+200
+00:16:44,000 --> 00:16:47,000
+attackers from gathering intelligence through error messages.
+
+201
+00:16:48,000 --> 00:16:54,000
+Generic error messages and custom error pages should be implemented to hide sensitive system details
+
+202
+00:16:54,000 --> 00:16:55,000
+from users.
+
+203
+00:16:55,000 --> 00:17:01,000
+Handling errors directly within the application, rather than relying solely on server configurations,
+
+204
+00:17:01,000 --> 00:17:05,000
+ensures more secure and controlled error responses.
+
+205
+00:17:06,000 --> 00:17:07,000
+Secure memory management.
+
+206
+00:17:07,000 --> 00:17:14,000
+Proper deallocation of memory when errors occur prevents attackers from accessing leftover sensitive
+
+207
+00:17:14,000 --> 00:17:14,000
+data.
+
+208
+00:17:15,000 --> 00:17:21,000
+Furthermore, error handling logic associated with security controls should default to denying access
+
+209
+00:17:21,000 --> 00:17:23,000
+when something goes wrong.
+
+210
+00:17:23,000 --> 00:17:30,000
+To prevent unauthorised access during error conditions, centralizing logging, ensuring log access
+
+211
+00:17:30,000 --> 00:17:37,000
+is restricted, and making sure logs contain important event data are all key to maintaining an accurate
+
+212
+00:17:37,000 --> 00:17:39,000
+and secure audit trail.
+
+213
+00:17:39,000 --> 00:17:45,000
+Finally, logging administrative functions, especially changes to security settings, is vital for
+
+214
+00:17:45,000 --> 00:17:50,000
+ensuring accountability and transparency in managing the system's security posture.
+
+215
+00:17:51,000 --> 00:17:55,000
+That's all what I wanted to discuss with you in this lesson.
+
+216
+00:17:55,000 --> 00:17:58,000
+Let's recap what we have learned today.
+
+217
+00:17:59,000 --> 00:18:05,000
+We covered the protection of master secrets and how to ensure secure cryptographic operations on trusted
+
+218
+00:18:05,000 --> 00:18:06,000
+systems.
+
+219
+00:18:06,000 --> 00:18:12,000
+You learned the importance of secure failure for cryptographic modules and generate an unguessable random
+
+220
+00:18:12,000 --> 00:18:15,000
+values using approved methods.
+
+221
+00:18:15,000 --> 00:18:22,000
+We explored the critical practice of login authentication, attempt's access control failures, and
+
+222
+00:18:22,000 --> 00:18:25,000
+tampering events for enhanced security monitoring.
+
+223
+00:18:25,000 --> 00:18:32,000
+Together, we examine the compliance of cryptographic modules with standards like Fips 142 and reviewed
+
+224
+00:18:32,000 --> 00:18:36,000
+login system exceptions and TLS connection failures.
+
+225
+00:18:36,000 --> 00:18:41,000
+You learned how to prevent sensitive data exposure in error messages and validate log entry integrity
+
+226
+00:18:41,000 --> 00:18:43,000
+with cryptographic hash functions.
+
+227
+00:18:43,000 --> 00:18:49,000
+We discussed the establishment of key management policies and handling application errors securely,
+
+228
+00:18:49,000 --> 00:18:53,000
+including memory deallocation during error conditions.
+
+229
+00:18:53,000 --> 00:19:00,000
+Lastly, we reviewed login practices to ensure logs are secured, analyzed, and used for monitoring
+
+230
+00:19:00,000 --> 00:19:03,000
+administrative changes and session token usage.
+
+231
+00:19:03,000 --> 00:19:05,000
+That's all for this lesson.
+
+232
+00:19:05,000 --> 00:19:07,000
+Thanks a lot for your attention.
+
+233
+00:19:07,000 --> 00:19:10,000
+Have a great day and see you in the next lesson.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/007 Defending Data Strategies for Protecting Sensitive Information_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/007 Defending Data Strategies for Protecting Sensitive Information_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..fddbecc30b5c19deed6a0dc68601669f70abe13a
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/007 Defending Data Strategies for Protecting Sensitive Information_en.srt
@@ -0,0 +1,1028 @@
+1
+00:00:05,000 --> 00:00:07,000
+Hello dear students.
+
+2
+00:00:07,000 --> 00:00:13,000
+In this lesson we will focus on essential strategies for protecting sensitive information and securing
+
+3
+00:00:13,000 --> 00:00:14,000
+data effectively.
+
+4
+00:00:14,000 --> 00:00:20,000
+You will learn how to prioritize various security practices based on the level of threat they mitigate,
+
+5
+00:00:20,000 --> 00:00:26,000
+helping you identify which actions are most crucial for safeguarding your systems.
+
+6
+00:00:26,000 --> 00:00:32,000
+We'll explore how to implement robust defenses that cover everything from critical vulnerabilities to
+
+7
+00:00:32,000 --> 00:00:36,000
+more subtle risks, ensuring comprehensive protection.
+
+8
+00:00:36,000 --> 00:00:41,000
+Throughout this session, you will gain a deeper understanding of key principles that form the foundation
+
+9
+00:00:41,000 --> 00:00:43,000
+of strong data security.
+
+10
+00:00:43,000 --> 00:00:49,000
+We'll discuss the importance of applying these practices to prevent unauthorized access, protect sensitive
+
+11
+00:00:49,000 --> 00:00:52,000
+data, and address common security challenges.
+
+12
+00:00:53,000 --> 00:00:58,000
+By the end of the lesson, you will be equipped with the knowledge to effectively assess and improve
+
+13
+00:00:58,000 --> 00:01:04,000
+the security of any system, Focusing on what matters most for defending against both high impact and
+
+14
+00:01:04,000 --> 00:01:06,000
+lesser known threats.
+
+15
+00:01:06,000 --> 00:01:08,000
+Let's start our lesson.
+
+16
+00:01:09,000 --> 00:01:16,000
+In this overview, we'll explore a list of data protection best practices organized by relevance.
+
+17
+00:01:16,000 --> 00:01:23,000
+The list starts with high relevance practices, which are critical for mitigating the most severe threats.
+
+18
+00:01:23,000 --> 00:01:29,000
+These include implementing least privilege to limit user access, encrypting sensitive data, and securing
+
+19
+00:01:29,000 --> 00:01:31,000
+cached or temporary files.
+
+20
+00:01:31,000 --> 00:01:37,000
+Additionally, ensuring proper access controls and protecting server side source code from unauthorized
+
+21
+00:01:37,000 --> 00:01:43,000
+downloads are key defenses against potential data breaches and unauthorized system access.
+
+22
+00:01:44,000 --> 00:01:50,000
+These measures form the foundation of robust data protection strategies, focusing on safeguarding sensitive
+
+23
+00:01:50,000 --> 00:01:53,000
+information in the most vulnerable areas.
+
+24
+00:01:53,000 --> 00:01:59,000
+As we move down the list, we'll look at moderate relevance practices that address more common security
+
+25
+00:01:59,000 --> 00:02:05,000
+concerns, such as avoiding clear text, storage of sensitive information on the client side, disabling
+
+26
+00:02:05,000 --> 00:02:10,000
+client side caching, and removing comments from production code.
+
+27
+00:02:10,000 --> 00:02:18,000
+Finally, we'll cover low relevance practices which focus on edge cases like disabling autocomplete
+
+28
+00:02:18,000 --> 00:02:22,000
+on sensitive forms and removing outdated system documentation.
+
+29
+00:02:23,000 --> 00:02:29,000
+Each of these practices plays a role in creating a layered defense against both major and minor security
+
+30
+00:02:29,000 --> 00:02:35,000
+threats, and we will dive into the details of each to understand their importance.
+
+31
+00:02:36,000 --> 00:02:43,000
+In this second list, I have grouped data protection best practices based on their complexity, moving
+
+32
+00:02:43,000 --> 00:02:46,000
+from basic to advanced principles.
+
+33
+00:02:46,000 --> 00:02:53,000
+The basic practices focus on easily implemented security measures, such as ensuring sensitive information
+
+34
+00:02:53,000 --> 00:03:00,000
+isn't passed in URLs, removing unnecessary documentation, and disabling Autocomplete on sensitive
+
+35
+00:03:00,000 --> 00:03:01,000
+forms.
+
+36
+00:03:01,000 --> 00:03:08,000
+These are important first steps that can be quickly integrated into any system without requiring advanced
+
+37
+00:03:08,000 --> 00:03:10,000
+technical expertise.
+
+38
+00:03:10,000 --> 00:03:17,000
+As you move into the intermediate level, practices like disabling client side caching and securely
+
+39
+00:03:17,000 --> 00:03:24,000
+removing outdated sensitive data require a deeper understanding of web technologies and user data management.
+
+40
+00:03:24,000 --> 00:03:31,000
+However, this categorization by complexity is just one way to approach these best practices.
+
+41
+00:03:32,000 --> 00:03:39,000
+You can also group them based on relevance, frequency of use, or even specific areas of concern,
+
+42
+00:03:39,000 --> 00:03:42,000
+depending on what helps you learn most effectively.
+
+43
+00:03:43,000 --> 00:03:49,000
+The goal is to build your knowledge progressively, starting with the fundamentals and moving toward
+
+44
+00:03:49,000 --> 00:03:50,000
+more advanced techniques.
+
+45
+00:03:51,000 --> 00:03:57,000
+Feel free to adapt your learning strategy to focus on the areas that are most critical for your needs.
+
+46
+00:03:57,000 --> 00:04:03,000
+Whether it's mastering basic tasks first, or diving into advanced topics right away.
+
+47
+00:04:04,000 --> 00:04:08,000
+As I promised, let's provide a detailed overview of each technique.
+
+48
+00:04:08,000 --> 00:04:12,000
+As you saw, there are different ways to group these practices.
+
+49
+00:04:12,000 --> 00:04:17,000
+However, for the sake of this lesson, let's organize all the techniques by relevance and review them
+
+50
+00:04:17,000 --> 00:04:18,000
+in that order.
+
+51
+00:04:18,000 --> 00:04:23,000
+And in case you have any questions during the lesson, no need to wait till the end of the lesson.
+
+52
+00:04:23,000 --> 00:04:28,000
+Write them in the Q&A section below the video and I will be happy to answer.
+
+53
+00:04:29,000 --> 00:04:33,000
+First, let's dive deeper into the principle of least privilege.
+
+54
+00:04:34,000 --> 00:04:41,000
+This concept is foundational to any security strategy, because it ensures that users only have access
+
+55
+00:04:41,000 --> 00:04:46,000
+to the data, systems, and functionalities they need to perform their tasks.
+
+56
+00:04:47,000 --> 00:04:48,000
+Nothing more.
+
+57
+00:04:48,000 --> 00:04:54,000
+Implementing role based access control is a key step here, where users are assigned roles based on
+
+58
+00:04:54,000 --> 00:04:59,000
+their job functions, and each role has specific permissions.
+
+59
+00:04:59,000 --> 00:05:04,000
+by regularly auditing access rights, we ensure that as job roles change, permissions are adjusted
+
+60
+00:05:04,000 --> 00:05:07,000
+accordingly, minimising unnecessary exposure.
+
+61
+00:05:08,000 --> 00:05:11,000
+The reason this is so effective is that it limits the blast radius.
+
+62
+00:05:12,000 --> 00:05:17,000
+If a user's account is compromised, imagine a regular employee having access to sensitive financial
+
+63
+00:05:17,000 --> 00:05:19,000
+data they don't need for their job.
+
+64
+00:05:19,000 --> 00:05:23,000
+If their account gets hacked, that data is now exposed.
+
+65
+00:05:24,000 --> 00:05:28,000
+By limiting access from the start, we prevent such scenarios.
+
+66
+00:05:29,000 --> 00:05:36,000
+Next is the encryption of highly sensitive stored information, which is crucial in ensuring that even
+
+67
+00:05:36,000 --> 00:05:42,000
+if an attacker gains unauthorized access to your servers, the data remains unreadable.
+
+68
+00:05:43,000 --> 00:05:50,000
+Encryption acts as a last line of defense, scrambling the data in such a way that only authorized users
+
+69
+00:05:50,000 --> 00:05:59,000
+with the correct keys can decrypt it using strong, well vetted algorithms like AES 256 Ensures that
+
+70
+00:05:59,000 --> 00:06:05,000
+even if attackers get their hands on the encrypted data, it would take them an impractically long time
+
+71
+00:06:05,000 --> 00:06:06,000
+to break it.
+
+72
+00:06:07,000 --> 00:06:14,000
+This becomes especially important for sensitive information like passwords, API keys, and authentication
+
+73
+00:06:14,000 --> 00:06:15,000
+tokens.
+
+74
+00:06:15,000 --> 00:06:22,000
+Storing this data in plain text or using outdated encryption methods, makes it far easier for attackers
+
+75
+00:06:22,000 --> 00:06:24,000
+to exploit in case of a breach.
+
+76
+00:06:25,000 --> 00:06:31,000
+Proper encryption combined with secure key management ensures that sensitive information stays protected
+
+77
+00:06:31,000 --> 00:06:33,000
+even in worst case scenarios.
+
+78
+00:06:34,000 --> 00:06:40,000
+Let's now discuss the protection of cached or temporary sensitive data, which is often a weak spot
+
+79
+00:06:40,000 --> 00:06:42,000
+in many systems.
+
+80
+00:06:42,000 --> 00:06:49,000
+Temporary data, such as session information, cached files, or working data can contain sensitive
+
+81
+00:06:49,000 --> 00:06:53,000
+information that, if left unprotected, could be exposed.
+
+82
+00:06:53,000 --> 00:07:00,000
+Many systems create temporary files during operations and if these are not properly handled, they can
+
+83
+00:07:00,000 --> 00:07:02,000
+become a significant vulnerability.
+
+84
+00:07:03,000 --> 00:07:10,000
+Implementing strict controls around temporary data involves encrypting these files during their use
+
+85
+00:07:10,000 --> 00:07:14,000
+and ensuring they are securely deleted once they are no longer needed.
+
+86
+00:07:14,000 --> 00:07:21,000
+Imagine an attacker gaining access to temporary files that still contain sensitive user information,
+
+87
+00:07:21,000 --> 00:07:23,000
+because the system didn't clean them up.
+
+88
+00:07:24,000 --> 00:07:26,000
+This can lead to serious breaches.
+
+89
+00:07:27,000 --> 00:07:33,000
+Automating this process, where temporary files are encrypted and purged when no longer required, is
+
+90
+00:07:33,000 --> 00:07:34,000
+the best defence.
+
+91
+00:07:36,000 --> 00:07:41,000
+Now we move on to implementing access controls for sensitive data on the server.
+
+92
+00:07:41,000 --> 00:07:47,000
+It's not just about storing the data securely, it's also about ensuring that only the right people
+
+93
+00:07:48,000 --> 00:07:49,000
+can access it.
+
+94
+00:07:49,000 --> 00:07:54,000
+This includes temporary, cached and long term stored data.
+
+95
+00:07:55,000 --> 00:08:01,000
+Using multifactor authentication adds an extra layer of security beyond just passwords.
+
+96
+00:08:01,000 --> 00:08:07,000
+Even if a user's credentials are compromised, the additional factor, like a mobile authentication
+
+97
+00:08:07,000 --> 00:08:11,000
+app or hardware token, prevents unauthorized access.
+
+98
+00:08:11,000 --> 00:08:16,000
+Combining this with encryption of the data itself creates multiple layers of defense.
+
+99
+00:08:17,000 --> 00:08:22,000
+Without proper access controls, even non-critical users could access sensitive data.
+
+100
+00:08:22,000 --> 00:08:26,000
+Making it easier for internal threats or compromised accounts to cause damage.
+
+101
+00:08:26,000 --> 00:08:30,000
+Finally, there's the protection of server side source code.
+
+102
+00:08:30,000 --> 00:08:36,000
+Source code is the blueprint of your system, and if it falls into the wrong hands, attackers can study
+
+103
+00:08:36,000 --> 00:08:40,000
+it to find vulnerabilities or craft specific attacks.
+
+104
+00:08:40,000 --> 00:08:44,000
+Therefore, access to this code must be tightly controlled.
+
+105
+00:08:44,000 --> 00:08:50,000
+Limiting who can download or use the source code is essential to reducing exposure.
+
+106
+00:08:50,000 --> 00:08:57,000
+Implementing access control on repositories, especially for sensitive or production code, is a must.
+
+107
+00:08:57,000 --> 00:09:05,000
+Moreover, regular audits of who has access to the code base should be performed to ensure no unauthorized
+
+108
+00:09:05,000 --> 00:09:06,000
+personnel are involved.
+
+109
+00:09:06,000 --> 00:09:12,000
+Storing this code in private repositories with restricted access is the best practice, as opposed to
+
+110
+00:09:13,000 --> 00:09:16,000
+leaving it in public or poorly secured repositories.
+
+111
+00:09:17,000 --> 00:09:23,000
+When the source code is exposed, attackers can use it to launch highly targeted attacks, potentially
+
+112
+00:09:23,000 --> 00:09:27,000
+exploiting weaknesses that would be harder to find otherwise.
+
+113
+00:09:28,000 --> 00:09:34,000
+Now, let's review moderate relevance practices that address more common security concerns.
+
+114
+00:09:34,000 --> 00:09:40,000
+First, we have the avoidance of storing sensitive information in clear text on the client side.
+
+115
+00:09:41,000 --> 00:09:47,000
+This is crucial because sensitive data such as passwords, API keys, or database connection strings
+
+116
+00:09:47,000 --> 00:09:54,000
+should never be stored in a form that can easily be read or extracted by unauthorized users.
+
+117
+00:09:54,000 --> 00:10:01,000
+When you store such data in insecure formats like Viewstate or in technologies like Adobe Flash, which
+
+118
+00:10:01,000 --> 00:10:03,000
+is inherently vulnerable.
+
+119
+00:10:03,000 --> 00:10:07,000
+You are essentially leaving sensitive information exposed to attackers.
+
+120
+00:10:07,000 --> 00:10:13,000
+The goal here is to use encryption techniques that transform this data into an unreadable format.
+
+121
+00:10:13,000 --> 00:10:20,000
+For example, AES 256 encryption could be used to encrypt passwords before they are stored on the client
+
+122
+00:10:20,000 --> 00:10:20,000
+side.
+
+123
+00:10:21,000 --> 00:10:27,000
+This way, even if an attacker gains access to the stored data through a vulnerability or compromise,
+
+124
+00:10:27,000 --> 00:10:34,000
+they would only see encrypted content, which would take significant computational effort to break.
+
+125
+00:10:34,000 --> 00:10:41,000
+Storing data in plain text, on the other hand, leaves you vulnerable to attacks where the attacker
+
+126
+00:10:41,000 --> 00:10:47,000
+can directly access and misuse sensitive information, such as through browser vulnerabilities or compromised
+
+127
+00:10:47,000 --> 00:10:49,000
+client side storage.
+
+128
+00:10:50,000 --> 00:10:56,000
+Next, let's talk about disabling client side caching for pages that contain sensitive information.
+
+129
+00:10:57,000 --> 00:11:02,000
+Web browsers cache pages to enhance performance and reduce load times.
+
+130
+00:11:02,000 --> 00:11:10,000
+However, for pages that display sensitive data like banking portals, login screens, or medical records.
+
+131
+00:11:10,000 --> 00:11:16,000
+Caching introduces serious risks if these pages are cached on the user's device.
+
+132
+00:11:16,000 --> 00:11:22,000
+It's possible that sensitive information could be retrieved by anyone with access to the device, even
+
+133
+00:11:22,000 --> 00:11:24,000
+after the session ends.
+
+134
+00:11:24,000 --> 00:11:31,000
+Attackers could potentially access cached data through browser vulnerabilities or after gaining physical
+
+135
+00:11:31,000 --> 00:11:33,000
+access to the user's device.
+
+136
+00:11:33,000 --> 00:11:41,000
+To prevent this, we use HTTP headers like Cache-control no store and pragma no cache, which tells
+
+137
+00:11:41,000 --> 00:11:45,000
+the browser not to store these pages at all.
+
+138
+00:11:45,000 --> 00:11:52,000
+This ensures that sensitive data isn't left lingering in the browser's cache, where it could be accessed
+
+139
+00:11:52,000 --> 00:11:54,000
+later by unauthorized users.
+
+140
+00:11:55,000 --> 00:11:57,000
+If these headers are not used.
+
+141
+00:11:57,000 --> 00:12:03,000
+Sensitive information like financial data could remain accessible even after the user logs out, increasing
+
+142
+00:12:03,000 --> 00:12:05,000
+the risk of data leakage.
+
+143
+00:12:07,000 --> 00:12:12,000
+Next, we address the avoidance of passing sensitive information in HTTP.
+
+144
+00:12:12,000 --> 00:12:13,000
+Get requests.
+
+145
+00:12:14,000 --> 00:12:15,000
+Get requests by design.
+
+146
+00:12:15,000 --> 00:12:20,000
+Append parameters in the URL which makes them highly visible.
+
+147
+00:12:20,000 --> 00:12:29,000
+URLs can be logged in various places by web servers, proxy servers, or even within browser histories,
+
+148
+00:12:29,000 --> 00:12:34,000
+which makes them an unsafe channel for sending sensitive information.
+
+149
+00:12:34,000 --> 00:12:41,000
+For instance, sending authentication tokens or passwords through Get requests exposes them in plain
+
+150
+00:12:41,000 --> 00:12:46,000
+sight, which could be intercepted by login mechanisms or accidentally shared.
+
+151
+00:12:46,000 --> 00:12:50,000
+Instead, we should rely on Post requests for transferring sensitive information.
+
+152
+00:12:51,000 --> 00:12:56,000
+Post request keeps the parameters hidden in the request body, making them less susceptible to casual
+
+153
+00:12:56,000 --> 00:12:57,000
+interception.
+
+154
+00:12:58,000 --> 00:13:05,000
+Additionally, Post requests can also be combined with encryption or Https to further protect the data
+
+155
+00:13:05,000 --> 00:13:06,000
+in transit.
+
+156
+00:13:06,000 --> 00:13:13,000
+A common mistake is passing tokens, user credentials, or session data in Get requests, which could
+
+157
+00:13:13,000 --> 00:13:19,000
+be logged and inadvertently leaked through shared URLs or web server logs.
+
+158
+00:13:20,000 --> 00:13:24,000
+Finally, there is the removal of comments in user accessible production code.
+
+159
+00:13:25,000 --> 00:13:31,000
+When developers write code, they often include comments to explain functions or logic, which is useful
+
+160
+00:13:31,000 --> 00:13:35,000
+during development but potentially harmful in production environments.
+
+161
+00:13:35,000 --> 00:13:41,000
+Comments can disclose important details about system configurations, database queries, or debugging
+
+162
+00:13:41,000 --> 00:13:48,000
+information which attackers could use to better understand the backend architecture and exploit weaknesses.
+
+163
+00:13:49,000 --> 00:13:56,000
+For example, a comment in production code might reveal the structure of a database query or the specific
+
+164
+00:13:56,000 --> 00:13:58,000
+file path of a sensitive system file.
+
+165
+00:13:58,000 --> 00:14:06,000
+This information could be leveraged by an attacker to craft targeted attacks such as SQL injection or
+
+166
+00:14:06,000 --> 00:14:07,000
+file path traversal.
+
+167
+00:14:07,000 --> 00:14:14,000
+Before deploying code to production, it's critical to remove all comments that are not necessary for
+
+168
+00:14:14,000 --> 00:14:15,000
+the functioning of the system.
+
+169
+00:14:15,000 --> 00:14:22,000
+This ensures that no extraneous information about the system's internal workings is made available to
+
+170
+00:14:22,000 --> 00:14:24,000
+users or attackers.
+
+171
+00:14:25,000 --> 00:14:30,000
+Leaving these comments in place can inadvertently give attackers an understanding of how your system
+
+172
+00:14:30,000 --> 00:14:34,000
+works and what its potential weaknesses are.
+
+173
+00:14:35,000 --> 00:14:41,000
+Let's take a look at some low relevant security practices, which, while considered edge cases or lesser
+
+174
+00:14:41,000 --> 00:14:47,000
+known threats, are still important for ensuring the protection of sensitive information in certain
+
+175
+00:14:47,000 --> 00:14:48,000
+scenarios.
+
+176
+00:14:48,000 --> 00:14:55,000
+First, we focus on disabling autocomplete on forms that handle sensitive information.
+
+177
+00:14:55,000 --> 00:15:01,000
+An autocomplete can be convenient for users, but when it comes to forms containing sensitive data like
+
+178
+00:15:01,000 --> 00:15:07,000
+passwords or financial details, we must ensure that browsers don't store this information for future
+
+179
+00:15:07,000 --> 00:15:08,000
+use.
+
+180
+00:15:08,000 --> 00:15:14,000
+By setting the autocomplete equals to auth attribute on these forms, we prevent the browser from saving
+
+181
+00:15:14,000 --> 00:15:16,000
+and auto filling this sensitive data.
+
+182
+00:15:17,000 --> 00:15:23,000
+This step mitigates the risk of someone else accessing a shared computer or device and automatically
+
+183
+00:15:23,000 --> 00:15:28,000
+filling in confidential information, reducing the chance of accidental exposure.
+
+184
+00:15:28,000 --> 00:15:35,000
+For example, disabling autocomplete on login or payment forms ensures that sensitive data isn't inadvertently
+
+185
+00:15:35,000 --> 00:15:42,000
+stored or accessible later, allowing browsers to store passwords or credit card information without
+
+186
+00:15:42,000 --> 00:15:49,000
+disabling this feature could lead to serious privacy breaches if the device is shared or compromised.
+
+187
+00:15:50,000 --> 00:15:55,000
+Next, we have the removal of sensitive data when it is no longer required.
+
+188
+00:15:56,000 --> 00:16:02,000
+Data retention policies should ensure that personal or financial information is securely deleted or
+
+189
+00:16:02,000 --> 00:16:06,000
+purged from the system once it's no longer necessary.
+
+190
+00:16:06,000 --> 00:16:12,000
+Keeping unnecessary sensitive data increases the risk of exposure in the event of a breach.
+
+191
+00:16:12,000 --> 00:16:19,000
+By implementing automated processes that securely delete data or providing users the option to remove
+
+192
+00:16:19,000 --> 00:16:26,000
+their own data will limit the attack surface and ensure that outdated or unused information isn't accessible.
+
+193
+00:16:27,000 --> 00:16:32,000
+For example, automatically removing user data after it's no longer needed or allowing users to delete
+
+194
+00:16:32,000 --> 00:16:37,000
+their personal information reduces the potential for data theft.
+
+195
+00:16:37,000 --> 00:16:44,000
+In contrast, systems that keep sensitive information indefinitely without purging it increase the chances
+
+196
+00:16:44,000 --> 00:16:46,000
+of unauthorized access or data breaches.
+
+197
+00:16:47,000 --> 00:16:53,000
+Finally, we consider the removal of a necessary application or system documentation.
+
+198
+00:16:53,000 --> 00:16:58,000
+Documentation files can be extremely helpful during development, but once the system is live.
+
+199
+00:16:59,000 --> 00:17:06,000
+Leaving them accessible can inadvertently expose important technical details such as system architecture
+
+200
+00:17:06,000 --> 00:17:09,000
+or configuration settings, which attackers could exploit.
+
+201
+00:17:10,000 --> 00:17:16,000
+Regularly reviewing and removing outdated or unnecessary documentation from public or user accessible
+
+202
+00:17:16,000 --> 00:17:23,000
+directories reduces the risk of revealing too much information about how the system operates.
+
+203
+00:17:23,000 --> 00:17:29,000
+For instance, internal system documentation left on public directories can provide attackers with insights
+
+204
+00:17:29,000 --> 00:17:35,000
+into potential vulnerabilities, while removing these files from production environments eliminates
+
+205
+00:17:35,000 --> 00:17:36,000
+that risk.
+
+206
+00:17:37,000 --> 00:17:44,000
+In conclusion, data protection best practices are essential to creating a secure and resilient system,
+
+207
+00:17:44,000 --> 00:17:49,000
+and they can be effectively categorized by their relevance to threat mitigation.
+
+208
+00:17:50,000 --> 00:17:55,000
+At the high relevance level, we focus on measures that address the most critical threats.
+
+209
+00:17:55,000 --> 00:18:02,000
+This includes implementing least privilege, ensuring that users only have access to the minimum data
+
+210
+00:18:02,000 --> 00:18:05,000
+and functionality needed for their tasks.
+
+211
+00:18:05,000 --> 00:18:10,000
+Limiting access minimizes the risk of unauthorized access and potential data breaches.
+
+212
+00:18:10,000 --> 00:18:16,000
+Furthermore, encryption of sensitive data at rest ensures that even if unauthorized access occurs,
+
+213
+00:18:16,000 --> 00:18:18,000
+the data remains protected.
+
+214
+00:18:18,000 --> 00:18:23,000
+Equally important is the protection of cached and temporary data, ensuring that sensitive information
+
+215
+00:18:23,000 --> 00:18:28,000
+is securely stored, managed and removed once it's no longer needed.
+
+216
+00:18:29,000 --> 00:18:35,000
+Proper access controls for all types of stored data and safeguarding server side source code are also
+
+217
+00:18:35,000 --> 00:18:43,000
+crucial to prevent exploitation by attackers, who may try to access critical system files or user data.
+
+218
+00:18:43,000 --> 00:18:50,000
+These high relevance practices form the backbone of secure data management and help protect against
+
+219
+00:18:50,000 --> 00:18:51,000
+the most severe security risks.
+
+220
+00:18:52,000 --> 00:18:55,000
+Moving to the moderate relevance practices.
+
+221
+00:18:55,000 --> 00:19:01,000
+These address common security concerns that could still lead to breaches if overlooked.
+
+222
+00:19:01,000 --> 00:19:08,000
+For example, avoiding cleartext storage of sensitive information on the client side and ensuring that
+
+223
+00:19:08,000 --> 00:19:13,000
+sensitive data is never stored in insecure formats helps reduce exposure.
+
+224
+00:19:14,000 --> 00:19:21,000
+Additionally, disabling client side caching for sensitive pages prevents stored data from being accessed
+
+225
+00:19:21,000 --> 00:19:28,000
+through browser history or cache, ensuring that sensitive information is not included in HTTP get requests,
+
+226
+00:19:28,000 --> 00:19:35,000
+and removing unnecessary comments from production code further reduces the attack surface by preventing
+
+227
+00:19:35,000 --> 00:19:38,000
+accidental leakage of sensitive details.
+
+228
+00:19:39,000 --> 00:19:46,000
+Lastly, in low relevance edge cases, practices such as disabling autocomplete on sensitive forms and
+
+229
+00:19:46,000 --> 00:19:51,000
+ensuring the removal of outdated data further tighten the security posture.
+
+230
+00:19:51,000 --> 00:19:58,000
+This might not be immediately critical, but are essential to preventing attackers from exploiting minor
+
+231
+00:19:58,000 --> 00:20:00,000
+vulnerabilities.
+
+232
+00:20:00,000 --> 00:20:07,000
+Similarly, removing unnecessary documentation from production environments ensures that attackers don't
+
+233
+00:20:07,000 --> 00:20:14,000
+gain insights into system configurations or development nodes that could be used to plan attacks.
+
+234
+00:20:14,000 --> 00:20:19,000
+Overall, these practices was a high, moderate, or low relevance.
+
+235
+00:20:19,000 --> 00:20:23,000
+Work together to ensure that sensitive data is well protected.
+
+236
+00:20:23,000 --> 00:20:27,000
+While the high relevance strategies are vital for immediate protection against serious threats.
+
+237
+00:20:27,000 --> 00:20:33,000
+The moderate and low relevance practices address more common or subtle vulnerabilities, contributing
+
+238
+00:20:33,000 --> 00:20:37,000
+to a well-rounded and comprehensive approach to data security.
+
+239
+00:20:38,000 --> 00:20:41,000
+That's all what I plan to discuss with you in the lesson.
+
+240
+00:20:41,000 --> 00:20:44,000
+Let's recap what we have learned today.
+
+241
+00:20:44,000 --> 00:20:50,000
+We learned the importance of implementing least privilege and how it restricts access to only necessary
+
+242
+00:20:50,000 --> 00:20:51,000
+data and functionality.
+
+243
+00:20:51,000 --> 00:20:58,000
+We explored the encryption of sensitive data and why it is critical for protecting information stored
+
+244
+00:20:58,000 --> 00:20:59,000
+on the server.
+
+245
+00:20:59,000 --> 00:21:06,000
+Together, we discussed how to secure cached and temporary files and reviewed the access controls necessary
+
+246
+00:21:06,000 --> 00:21:08,000
+to protect sensitive data on the server.
+
+247
+00:21:09,000 --> 00:21:15,000
+We covered the risks associated with exposing server side source code and how to protect it from unauthorized
+
+248
+00:21:15,000 --> 00:21:16,000
+downloads.
+
+249
+00:21:16,000 --> 00:21:22,000
+You gained an understanding of why storing sensitive information in insecure formats is dangerous,
+
+250
+00:21:22,000 --> 00:21:23,000
+and learned how to prevent it.
+
+251
+00:21:24,000 --> 00:21:29,000
+We also reviewed the importance of removing unnecessary comments and documentation in production environments
+
+252
+00:21:29,000 --> 00:21:32,000
+to reduce security risks.
+
+253
+00:21:32,000 --> 00:21:39,000
+Lastly, we talked about disabling features that could expose sensitive data such as autocomplete and
+
+254
+00:21:39,000 --> 00:21:42,000
+how to securely manage data that is no longer needed.
+
+255
+00:21:43,000 --> 00:21:45,000
+That's all for this lesson.
+
+256
+00:21:45,000 --> 00:21:47,000
+Thanks a lot for your attention.
+
+257
+00:21:47,000 --> 00:21:50,000
+Have a great day and see you in the next lesson.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/008 Securing Databases Best Practices for Preventing SQL Injection_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/008 Securing Databases Best Practices for Preventing SQL Injection_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..f9281cd11b335e1d36de44ebf053618430d86cd2
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/008 Securing Databases Best Practices for Preventing SQL Injection_en.srt
@@ -0,0 +1,1036 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:13,000
+In this lesson, we will explore key strategies for securing databases with a focus on preventing unauthorized
+
+3
+00:00:13,000 --> 00:00:15,000
+access and common vulnerabilities.
+
+4
+00:00:15,000 --> 00:00:21,000
+These strategies are designed to ensure that databases are safeguarded from common vulnerabilities and
+
+5
+00:00:21,000 --> 00:00:24,000
+attacks, reducing the risk of data breaches.
+
+6
+00:00:25,000 --> 00:00:31,000
+The practices will explore cover a range of areas, from controlling how data is accessed and managed,
+
+7
+00:00:31,000 --> 00:00:35,000
+to ensuring the secure handling of credentials and connections.
+
+8
+00:00:35,000 --> 00:00:41,000
+Additionally, we'll look at ways to improve the overall security of the database by tightening system
+
+9
+00:00:41,000 --> 00:00:46,000
+configurations, managing user privileges effectively, and addressing potential vulnerabilities that
+
+10
+00:00:46,000 --> 00:00:49,000
+can arise from less common situations.
+
+11
+00:00:49,000 --> 00:00:55,000
+These combined efforts help to build a secure and resilient database infrastructure, protecting against
+
+12
+00:00:55,000 --> 00:00:59,000
+both common threats and more specialized attack vectors.
+
+13
+00:01:00,000 --> 00:01:07,000
+In this session, we will explore database security best practices that are organized by relevance,
+
+14
+00:01:07,000 --> 00:01:14,000
+starting from critical threat mitigation strategies to edge cases that help strengthen overall security.
+
+15
+00:01:15,000 --> 00:01:21,000
+We'll begin by looking at the high relevance practices, such as using parameterized queries to prevent
+
+16
+00:01:21,000 --> 00:01:29,000
+SQL injection, restricting database access through least privilege principles, and ensuring that credentials
+
+17
+00:01:29,000 --> 00:01:32,000
+and connection strings are securely managed.
+
+18
+00:01:32,000 --> 00:01:37,000
+These are essential steps in defending against the most severe vulnerabilities that could compromise
+
+19
+00:01:37,000 --> 00:01:38,000
+your database.
+
+20
+00:01:38,000 --> 00:01:45,000
+We will also cover moderate relevance practices, including input validation, the use of stored procedures,
+
+21
+00:01:45,000 --> 00:01:49,000
+and the disabling of default accounts and unnecessary features.
+
+22
+00:01:49,000 --> 00:01:54,000
+These are important for maintaining database security and day to day operations.
+
+23
+00:01:54,000 --> 00:02:01,000
+Lastly, we will touch on low relevance edge cases that address lesser known threats like ensuring proper
+
+24
+00:02:01,000 --> 00:02:07,000
+variable typing, closing database connections promptly, and removing default vendor content.
+
+25
+00:02:07,000 --> 00:02:13,000
+As we go through each item, we'll discuss its importance and how it contributes to creating a more
+
+26
+00:02:13,000 --> 00:02:15,000
+secure database environment.
+
+27
+00:02:16,000 --> 00:02:23,000
+In this second list, we have organized database security best practices by their complexity from basic
+
+28
+00:02:23,000 --> 00:02:24,000
+to advanced techniques.
+
+29
+00:02:24,000 --> 00:02:31,000
+The basic level includes fundamental practices such as using parameterized queries and ensuring variables
+
+30
+00:02:31,000 --> 00:02:33,000
+are strongly typed.
+
+31
+00:02:33,000 --> 00:02:40,000
+These are essential steps that provide a solid foundation for securing databases and protecting against
+
+32
+00:02:40,000 --> 00:02:41,000
+common threats.
+
+33
+00:02:41,000 --> 00:02:48,000
+Additionally, closing database connections promptly helps prevent unauthorized access and resource
+
+34
+00:02:48,000 --> 00:02:52,000
+exhaustion, making it another simple but effective practice.
+
+35
+00:02:52,000 --> 00:03:00,000
+Moving into intermediate and advanced levels, the techniques become more complex, addressing broader
+
+36
+00:03:00,000 --> 00:03:02,000
+security concerns.
+
+37
+00:03:02,000 --> 00:03:08,000
+The intermediate practices focus on enforcing least privileged access, ensuring secure credentials,
+
+38
+00:03:08,000 --> 00:03:12,000
+and using input validation to prevent attacks.
+
+39
+00:03:12,000 --> 00:03:18,000
+At the advanced level, we address more sophisticated techniques such as encrypting connection strings,
+
+40
+00:03:18,000 --> 00:03:25,000
+using stored procedures to control access, and managing distinct credentials for different trust levels.
+
+41
+00:03:26,000 --> 00:03:32,000
+While this is one way to categorize these practices, feel free to group them differently, perhaps
+
+42
+00:03:32,000 --> 00:03:39,000
+by risk or frequency of use, to better fit your learning style and focus on the areas that are most
+
+43
+00:03:39,000 --> 00:03:40,000
+relevant to you.
+
+44
+00:03:41,000 --> 00:03:46,000
+As I promised, let's provide a detailed overview of each technique.
+
+45
+00:03:46,000 --> 00:03:49,000
+As you saw, there are different ways to group these practices.
+
+46
+00:03:49,000 --> 00:03:55,000
+However, for the sake of this lesson, let's organize all the techniques by relevance and reuse them
+
+47
+00:03:55,000 --> 00:03:56,000
+in that order.
+
+48
+00:03:56,000 --> 00:04:01,000
+And in case you have any questions during the lesson, no need to wait till the end of the lesson.
+
+49
+00:04:01,000 --> 00:04:06,000
+Write them in the Q&A section below the video and I will be happy to answer.
+
+50
+00:04:07,000 --> 00:04:13,000
+Let's take a deeper look into each of these high relevance practices for securing databases, focusing
+
+51
+00:04:13,000 --> 00:04:19,000
+on preventing SQL injection and unauthorized access, which are two of the most common attack vectors
+
+52
+00:04:19,000 --> 00:04:21,000
+targeting sensitive data.
+
+53
+00:04:22,000 --> 00:04:29,000
+First, the use of strongly typed parameterized queries is fundamental in protecting against SQL injection
+
+54
+00:04:29,000 --> 00:04:29,000
+attacks.
+
+55
+00:04:30,000 --> 00:04:37,000
+SQL injection occurs when an attacker injects malicious SQL code into a query via user input, potentially
+
+56
+00:04:37,000 --> 00:04:41,000
+gaining unauthorized access to or control over the database.
+
+57
+00:04:42,000 --> 00:04:48,000
+By using parameterized queries, we isolate user inputs from the query structure, ensuring that inputs
+
+58
+00:04:48,000 --> 00:04:51,000
+are always treated as data, not executable code.
+
+59
+00:04:51,000 --> 00:04:57,000
+This technique forces the database to treat any input strictly as a value, which eliminates the possibility
+
+60
+00:04:57,000 --> 00:04:59,000
+of altering the SQL command.
+
+61
+00:04:59,000 --> 00:05:06,000
+For example, if we directly concatenate a user's input into a query, an attacker could manipulate
+
+62
+00:05:06,000 --> 00:05:09,000
+the input to execute destructive SQL commands.
+
+63
+00:05:09,000 --> 00:05:16,000
+In contrast, using parameterized queries ensures that such attacks are thwarted, protecting the integrity
+
+64
+00:05:16,000 --> 00:05:17,000
+of the database.
+
+65
+00:05:18,000 --> 00:05:24,000
+Next, we focus on accessing the database with the lowest possible level of privilege.
+
+66
+00:05:25,000 --> 00:05:31,000
+This practice is based on the principle of least privilege, which means that users and applications
+
+67
+00:05:31,000 --> 00:05:35,000
+should only be granted the permissions they absolutely need.
+
+68
+00:05:35,000 --> 00:05:42,000
+For instance, if an application only requires read access to specific data, it should not have write
+
+69
+00:05:42,000 --> 00:05:44,000
+or administrative permissions.
+
+70
+00:05:44,000 --> 00:05:51,000
+By enforcing these granular permissions, even if an attacker compromises the application, they will
+
+71
+00:05:51,000 --> 00:05:55,000
+have limited ability to manipulate or steal sensitive data.
+
+72
+00:05:55,000 --> 00:06:02,000
+It's a key security measure because it minimizes the potential damage caused by a compromised account,
+
+73
+00:06:02,000 --> 00:06:06,000
+reducing the attacker's range of action within the system.
+
+74
+00:06:06,000 --> 00:06:13,000
+An application operating with unnecessarily high privileges creates significant risk as attackers could
+
+75
+00:06:13,000 --> 00:06:19,000
+modify data, escalate their privileges, or access restricted information.
+
+76
+00:06:20,000 --> 00:06:25,000
+Equally important is ensuring the use of secure credentials for database access.
+
+77
+00:06:25,000 --> 00:06:31,000
+Weak, easily guessable or reuse passwords are common vulnerabilities that attackers can exploit through
+
+78
+00:06:31,000 --> 00:06:34,000
+brute force or credential stuffing attacks.
+
+79
+00:06:34,000 --> 00:06:41,000
+Secure credentials, including long, complex passwords combined with multi-factor authentication,
+
+80
+00:06:41,000 --> 00:06:44,000
+are essential in blocking unauthorized access.
+
+81
+00:06:44,000 --> 00:06:50,000
+Multi-factor authentication adds an additional layer of security by requiring not just a password,
+
+82
+00:06:50,000 --> 00:06:56,000
+but also a second factor, such as a mobile authentication code to access the database.
+
+83
+00:06:57,000 --> 00:07:02,000
+By using strong credentials and enabling multi-factor authentication where possible, we make it much
+
+84
+00:07:02,000 --> 00:07:07,000
+more difficult for attackers to gain access to the database, even if they obtain a password.
+
+85
+00:07:08,000 --> 00:07:11,000
+Now let's move on to the secure storage of connection strings.
+
+86
+00:07:11,000 --> 00:07:19,000
+Connection strings, which contain important details such as usernames, passwords, and database locations,
+
+87
+00:07:19,000 --> 00:07:21,000
+should be protected at all costs.
+
+88
+00:07:22,000 --> 00:07:28,000
+Hardcoding these strings into the application code is a risky practice, because anyone with access
+
+89
+00:07:28,000 --> 00:07:32,000
+to the code can see these sensitive details.
+
+90
+00:07:32,000 --> 00:07:39,000
+Instead, connection strings should be stored in encrypted configuration files that are isolated from
+
+91
+00:07:39,000 --> 00:07:40,000
+the main code base.
+
+92
+00:07:40,000 --> 00:07:47,000
+This way, even if the code is exposed, the database credentials remain protected.
+
+93
+00:07:47,000 --> 00:07:54,000
+Encryption adds an extra layer of security, ensuring that even if someone gains access to the configuration
+
+94
+00:07:54,000 --> 00:07:57,000
+file, they cannot easily read the sensitive information.
+
+95
+00:07:58,000 --> 00:08:03,000
+Finally, let's discuss the removal or modification of default database.
+
+96
+00:08:03,000 --> 00:08:05,000
+Administrative passwords.
+
+97
+00:08:05,000 --> 00:08:11,000
+When databases are first installed, they often come with default admin credentials, which are widely
+
+98
+00:08:11,000 --> 00:08:17,000
+known and easily accessible to anyone with basic knowledge of the database system.
+
+99
+00:08:17,000 --> 00:08:23,000
+Leaving these defaults unchanged is like leaving the front door of a house unlocked.
+
+100
+00:08:23,000 --> 00:08:26,000
+It's an invitation for attackers to walk right in.
+
+101
+00:08:27,000 --> 00:08:33,000
+By changing the default passwords immediately and enforcing strong password policies, we close this
+
+102
+00:08:33,000 --> 00:08:34,000
+easy entry point.
+
+103
+00:08:35,000 --> 00:08:40,000
+Additionally, implementing multi-factor authentication for administrative access further secures the
+
+104
+00:08:40,000 --> 00:08:46,000
+system, ensuring that even if an attacker knows the password, they would still need an additional
+
+105
+00:08:46,000 --> 00:08:49,000
+authentication factor to gain access.
+
+106
+00:08:50,000 --> 00:08:57,000
+Let's dive deeper into these moderate relevance practices for securing databases, and understand why
+
+107
+00:08:57,000 --> 00:09:03,000
+each of them plays a crucial role in defending against common security vulnerabilities like SQL injection
+
+108
+00:09:03,000 --> 00:09:05,000
+and unauthorized access.
+
+109
+00:09:06,000 --> 00:09:12,000
+First, let's discuss the utilization of input validation and output encoding.
+
+110
+00:09:12,000 --> 00:09:19,000
+These two methods work hand in hand to ensure that any data received from users is treated safely.
+
+111
+00:09:20,000 --> 00:09:26,000
+Input validation is about defining strict rules for what is acceptable input, for example, only allowing
+
+112
+00:09:26,000 --> 00:09:31,000
+numeric values where they are expected, or rejecting input with special characters that could be used
+
+113
+00:09:31,000 --> 00:09:33,000
+to manipulate database commands.
+
+114
+00:09:33,000 --> 00:09:39,000
+Output encoding ensures that any user input that gets displayed or processed is properly encoded, so
+
+115
+00:09:39,000 --> 00:09:46,000
+that special characters like less than character or single quote character don't get misinterpreted
+
+116
+00:09:46,000 --> 00:09:50,000
+as part of an SQL query or HTML code.
+
+117
+00:09:50,000 --> 00:09:55,000
+This is particularly crucial when handling dynamic content.
+
+118
+00:09:55,000 --> 00:10:02,000
+By applying both input validation and output encoding, we create a strong defense against SQL injection,
+
+119
+00:10:02,000 --> 00:10:09,000
+where attackers try to execute unauthorized SQL commands without proper validation and encoding.
+
+120
+00:10:09,000 --> 00:10:16,000
+Attackers can exploit loopholes in your application to inject malicious SQL, gaining access to sensitive
+
+121
+00:10:16,000 --> 00:10:20,000
+data, or even taking control of the database.
+
+122
+00:10:21,000 --> 00:10:26,000
+Next, we focus on the use of stored procedures to abstract data access.
+
+123
+00:10:27,000 --> 00:10:34,000
+Stored procedures offer an additional layer of security by encapsulating SQL queries and business logic
+
+124
+00:10:34,000 --> 00:10:36,000
+inside the database itself.
+
+125
+00:10:36,000 --> 00:10:41,000
+Instead of allowing users or applications to directly query the database.
+
+126
+00:10:41,000 --> 00:10:44,000
+Stored procedures act as an intermediary.
+
+127
+00:10:44,000 --> 00:10:51,000
+This abstraction limits what the user or application can do because they are interacting with pre-defined
+
+128
+00:10:51,000 --> 00:10:57,000
+controlled procedures, rather than having full control over the database tables.
+
+129
+00:10:57,000 --> 00:11:03,000
+A major advantage of stored procedures is that they prevent prevents users from crafting ad hoc SQL
+
+130
+00:11:03,000 --> 00:11:07,000
+statements, which can help mitigate the risk of SQL injection.
+
+131
+00:11:08,000 --> 00:11:15,000
+For instance, an attacker trying to manipulate a query would have no direct access to the base tables
+
+132
+00:11:15,000 --> 00:11:20,000
+as the logic and operations are embedded within the stored procedures themselves.
+
+133
+00:11:20,000 --> 00:11:26,000
+By centralizing data access and limiting permissions, you can drastically reduce the attack surface,
+
+134
+00:11:26,000 --> 00:11:31,000
+ensuring more controlled and secure interactions with the database.
+
+135
+00:11:33,000 --> 00:11:40,000
+Now let's examine the disabling of unnecessary default accounts when databases are initially installed.
+
+136
+00:11:40,000 --> 00:11:47,000
+They often come with several preconfigured accounts that are meant to provide administrative or maintenance
+
+137
+00:11:47,000 --> 00:11:48,000
+access.
+
+138
+00:11:48,000 --> 00:11:55,000
+These accounts, however, can be a significant risk if they are not used and are left active with default
+
+139
+00:11:55,000 --> 00:11:56,000
+credentials.
+
+140
+00:11:57,000 --> 00:12:03,000
+Attackers often know the default usernames and passwords for popular database systems, and leaving
+
+141
+00:12:03,000 --> 00:12:09,000
+these accounts enabled gives them an easy way in disabling or if possible, removing these accounts
+
+142
+00:12:09,000 --> 00:12:13,000
+reduces the number of potential entry points for unauthorized access.
+
+143
+00:12:13,000 --> 00:12:19,000
+For example, if an attacker gains access to an unused admin account, they can exploit it to steal
+
+144
+00:12:19,000 --> 00:12:22,000
+data or make unauthorized changes to the database.
+
+145
+00:12:22,000 --> 00:12:28,000
+Regular audits of all accounts and disabling those that are not required are essential steps to harden
+
+146
+00:12:28,000 --> 00:12:30,000
+the security of your system.
+
+147
+00:12:31,000 --> 00:12:36,000
+Finally, we turn to deactivating unnecessary database functionality.
+
+148
+00:12:36,000 --> 00:12:42,000
+Databases often come with a wide array of features, services, and utilities that may not be needed
+
+149
+00:12:42,000 --> 00:12:44,000
+for your specific application.
+
+150
+00:12:44,000 --> 00:12:51,000
+This might include unused stored procedures, services like remote access, or utility packages that
+
+151
+00:12:51,000 --> 00:12:54,000
+provide extra functionality.
+
+152
+00:12:54,000 --> 00:13:00,000
+While these features can be helpful in certain scenarios, leaving them active when they are not required,
+
+153
+00:13:00,000 --> 00:13:02,000
+only increases the attack surface.
+
+154
+00:13:02,000 --> 00:13:07,000
+Every feature enabled is another possible entry point for an attacker.
+
+155
+00:13:08,000 --> 00:13:14,000
+By disabling unnecessary functionalities, you follow a principle called surface area reduction, which
+
+156
+00:13:14,000 --> 00:13:19,000
+minimizes the opportunities for attackers to find and exploit vulnerabilities.
+
+157
+00:13:19,000 --> 00:13:26,000
+For example, if a rarely used feature like a remote database service is left active, it could be exploited
+
+158
+00:13:26,000 --> 00:13:33,000
+to gain unauthorized access by proactively turning off what's not needed, you create a more secure
+
+159
+00:13:33,000 --> 00:13:35,000
+and streamlined database environment.
+
+160
+00:13:36,000 --> 00:13:42,000
+Let's delve deeper into each of these low relevance practices, which are essential for addressing lesser
+
+161
+00:13:42,000 --> 00:13:47,000
+known threats and ensuring a more secure and resilient database environment.
+
+162
+00:13:48,000 --> 00:13:53,000
+First, we start with the importance of ensuring that variables are strongly typed.
+
+163
+00:13:53,000 --> 00:14:01,000
+This practice is about strictly defining the type of data a variable or input can accept, whether it's
+
+164
+00:14:01,000 --> 00:14:03,000
+an integer, a string, or a date.
+
+165
+00:14:04,000 --> 00:14:10,000
+By enforcing strong typing, we prevent attackers from manipulating inputs in unexpected ways.
+
+166
+00:14:10,000 --> 00:14:16,000
+For example, in the case of SQL injection, if an input is expected to be an integer, an attacker
+
+167
+00:14:16,000 --> 00:14:22,000
+would not be able to insert malicious SQL code as part of the input, because the type mismatch would
+
+168
+00:14:22,000 --> 00:14:23,000
+immediately reject the input.
+
+169
+00:14:23,000 --> 00:14:30,000
+Without strong typing, inputs are more flexible, which increases the risk of accepting dangerous data
+
+170
+00:14:30,000 --> 00:14:34,000
+that could be used to execute unauthorized commands.
+
+171
+00:14:34,000 --> 00:14:40,000
+Ensuring that all inputs and variables follow strict data types is a proactive measure to reduce the
+
+172
+00:14:40,000 --> 00:14:45,000
+likelihood of injection attacks and other forms of data manipulation.
+
+173
+00:14:46,000 --> 00:14:51,000
+Next, we focus on the closure of database connections as soon as possible.
+
+174
+00:14:51,000 --> 00:14:58,000
+Database connections that are left open longer than necessary can lead to two major problems resource
+
+175
+00:14:58,000 --> 00:15:01,000
+leakage and unauthorized access.
+
+176
+00:15:01,000 --> 00:15:08,000
+Resource leakage occurs when open connections continue to consume memory or processing power, slowing
+
+177
+00:15:08,000 --> 00:15:12,000
+down the system and potentially causing performance bottlenecks.
+
+178
+00:15:12,000 --> 00:15:19,000
+More critically, open connections can be exploited by attackers if left idle by keeping a database
+
+179
+00:15:19,000 --> 00:15:26,000
+connection open even briefly after its intended use, we create a window of opportunity for attackers
+
+180
+00:15:26,000 --> 00:15:29,000
+to intercept or manipulate the session.
+
+181
+00:15:30,000 --> 00:15:36,000
+The best practice is to close these connections immediately after the transaction or query is completed.
+
+182
+00:15:36,000 --> 00:15:42,000
+This can be achieved through the use of connection pooling, or by ensuring that your application's
+
+183
+00:15:42,000 --> 00:15:46,000
+code closes each connection as soon as it's no longer needed.
+
+184
+00:15:47,000 --> 00:15:54,000
+Properly managing connections not only optimizes performance, but also reduces the chance of exploitation.
+
+185
+00:15:55,000 --> 00:16:00,000
+Now let's talk about the removal of unnecessary default vendor content.
+
+186
+00:16:01,000 --> 00:16:08,000
+When a database is first installed, it often includes default schemas, sample data, or demo environments
+
+187
+00:16:08,000 --> 00:16:09,000
+provided by the vendor.
+
+188
+00:16:10,000 --> 00:16:16,000
+While these components can be useful during development or testing, leaving them in place in a production
+
+189
+00:16:16,000 --> 00:16:19,000
+environment creates a major security risk.
+
+190
+00:16:19,000 --> 00:16:25,000
+Default content is often publicly documented, meaning attackers may already know about the structure
+
+191
+00:16:25,000 --> 00:16:27,000
+of vulnerabilities of these components.
+
+192
+00:16:28,000 --> 00:16:31,000
+This gives attackers an easy entry point into the system.
+
+193
+00:16:32,000 --> 00:16:38,000
+For example, if a sample schema was default data or configuration is left exposed, an attacker could
+
+194
+00:16:38,000 --> 00:16:45,000
+use this information to craft specific exploits by removing or disabling any unnecessary default content,
+
+195
+00:16:45,000 --> 00:16:50,000
+such as vendor provided sample databases or unused utility functions.
+
+196
+00:16:50,000 --> 00:16:52,000
+You reduce the potential attack surface.
+
+197
+00:16:52,000 --> 00:16:57,000
+Ensuring that only the essential components of your database remain in production.
+
+198
+00:16:58,000 --> 00:17:03,000
+Lastly, we examine the importance of connecting to the database with distinct credentials for each
+
+199
+00:17:03,000 --> 00:17:04,000
+trust level.
+
+200
+00:17:05,000 --> 00:17:11,000
+Different users and applications interacting with the database often require varying levels of access.
+
+201
+00:17:11,000 --> 00:17:17,000
+For example, an administrator might need full access to modify and manage the database, whereas a
+
+202
+00:17:17,000 --> 00:17:25,000
+regular user might only need read permissions and a guest might have access to a limited subset of data.
+
+203
+00:17:25,000 --> 00:17:31,000
+By assigning unique credentials and permissions to each of these roles, you ensure that each user can
+
+204
+00:17:31,000 --> 00:17:34,000
+only perform actions relevant to their role.
+
+205
+00:17:34,000 --> 00:17:39,000
+This separation of privileges is a fundamental part of the least privilege principle.
+
+206
+00:17:40,000 --> 00:17:47,000
+If an attacker compromises a set of credentials, the damage they can inflict is limited to the level
+
+207
+00:17:47,000 --> 00:17:49,000
+of access granted to that role.
+
+208
+00:17:50,000 --> 00:17:58,000
+Conversely, using the same credentials for multiple trust levels, such as giving an admin and a regular
+
+209
+00:17:58,000 --> 00:18:03,000
+user the same database credentials exposes the system to overexposure.
+
+210
+00:18:03,000 --> 00:18:10,000
+An attacker who gains access to one set of credentials would suddenly have full control of the database,
+
+211
+00:18:10,000 --> 00:18:14,000
+far exceeding the original scope of the compromised account.
+
+212
+00:18:15,000 --> 00:18:22,000
+In conclusion, securing databases is about implementing a series of layered best practices that address
+
+213
+00:18:22,000 --> 00:18:29,000
+various levels of security risk, starting from the most critical to more specific edge case scenarios.
+
+214
+00:18:29,000 --> 00:18:36,000
+At the high relevance level, our primary focus is on mitigating critical threats such as SQL injection
+
+215
+00:18:36,000 --> 00:18:38,000
+and unauthorized access.
+
+216
+00:18:39,000 --> 00:18:46,000
+Using strongly typed, parameterized queries ensures that user inputs are treated as data and not executable
+
+217
+00:18:46,000 --> 00:18:50,000
+code, which is essential for preventing SQL injection attacks.
+
+218
+00:18:51,000 --> 00:18:57,000
+Similarly, restricting the privileges of database access ensures that applications and users only have
+
+219
+00:18:57,000 --> 00:19:03,000
+access to the minimum necessary data and functionality, thereby limiting potential damage in case of
+
+220
+00:19:03,000 --> 00:19:04,000
+a compromise.
+
+221
+00:19:04,000 --> 00:19:10,000
+Storing connection strings securely and using strong credentials are vital for ensuring that sensitive
+
+222
+00:19:10,000 --> 00:19:17,000
+information remains protected, and removing default admin passwords further reduces easy entry points
+
+223
+00:19:17,000 --> 00:19:18,000
+for attackers.
+
+224
+00:19:18,000 --> 00:19:24,000
+Moving down to moderate relevance practices, these are equally important, but address more general
+
+225
+00:19:24,000 --> 00:19:26,000
+security concerns.
+
+226
+00:19:26,000 --> 00:19:34,000
+Input validation and output encoding help ensure that any input received from users is safe, and won't
+
+227
+00:19:34,000 --> 00:19:36,000
+lead to malicious database commands.
+
+228
+00:19:37,000 --> 00:19:43,000
+The use of stored procedures abstracts data access, reducing the risk of direct manipulation of the
+
+229
+00:19:43,000 --> 00:19:45,000
+underlying tables.
+
+230
+00:19:45,000 --> 00:19:52,000
+Disabling unnecessary default accounts and deactivating unused features help reduce the attack surface,
+
+231
+00:19:52,000 --> 00:19:56,000
+ensuring that there are fewer entry points for attackers to exploit.
+
+232
+00:19:56,000 --> 00:20:03,000
+These measures may not directly prevent critical attacks, but they add crucial layers of security that
+
+233
+00:20:03,000 --> 00:20:06,000
+make your database more resilient.
+
+234
+00:20:06,000 --> 00:20:14,000
+Lastly, we have low relevance practices which address edge cases but are still important for maintaining
+
+235
+00:20:14,000 --> 00:20:18,000
+overall database hygiene, ensuring that variables are strongly typed.
+
+236
+00:20:18,000 --> 00:20:22,000
+Adds a layer of defense against unexpected inputs.
+
+237
+00:20:22,000 --> 00:20:29,000
+Closing database connections promptly ensures that no open connections remain vulnerable to exploitation.
+
+238
+00:20:30,000 --> 00:20:37,000
+Removing unnecessary vendor content like sample schemas further reduces unnecessary exposure, and using
+
+239
+00:20:37,000 --> 00:20:44,000
+distinct credentials for different trust levels ensures that even if one account is compromised, the
+
+240
+00:20:44,000 --> 00:20:46,000
+damage is limited to that row.
+
+241
+00:20:47,000 --> 00:20:53,000
+These practices may seem minor, but they add extra layers of security that can make a significant difference
+
+242
+00:20:53,000 --> 00:20:56,000
+in safeguarding your database.
+
+243
+00:20:57,000 --> 00:21:00,000
+That's all what I wanted to share with you in this lesson.
+
+244
+00:21:00,000 --> 00:21:08,000
+Let's recap what we've learned Today, we learned how to secure databases by using parameterized queries
+
+245
+00:21:08,000 --> 00:21:10,000
+to prevent SQL injection.
+
+246
+00:21:10,000 --> 00:21:17,000
+You explored the principle of least privilege understanding how to limit database access for applications
+
+247
+00:21:17,000 --> 00:21:18,000
+and users.
+
+248
+00:21:18,000 --> 00:21:24,000
+We discussed the importance of using secure credentials and storing connection strings in encrypted
+
+249
+00:21:24,000 --> 00:21:26,000
+configurations.
+
+250
+00:21:26,000 --> 00:21:31,000
+Together, we reviewed how to modify or remove default administrative passwords to enhance security.
+
+251
+00:21:32,000 --> 00:21:38,000
+We examined how input validation and stored procedures add additional layers of protection against common
+
+252
+00:21:38,000 --> 00:21:39,000
+vulnerabilities.
+
+253
+00:21:39,000 --> 00:21:44,000
+You learned how to disable unnecessary database accounts and features, reducing the overall attack
+
+254
+00:21:44,000 --> 00:21:45,000
+surface.
+
+255
+00:21:45,000 --> 00:21:51,000
+Lastly, we discussed how to properly manage database connections and the use of distinct credentials
+
+256
+00:21:51,000 --> 00:21:53,000
+for different trust levels.
+
+257
+00:21:54,000 --> 00:21:56,000
+That's all for this lesson.
+
+258
+00:21:56,000 --> 00:21:58,000
+Thanks a lot for your attention.
+
+259
+00:21:58,000 --> 00:22:01,000
+Have a great day and see you in the next lesson.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/009 Safe File Handling Preventing File-Based Vulnerabilities_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/009 Safe File Handling Preventing File-Based Vulnerabilities_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..a47c5c2c5134bea894a3acf56040b8a6245cbb1c
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/009 Safe File Handling Preventing File-Based Vulnerabilities_en.srt
@@ -0,0 +1,1148 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:12,000
+In this lesson, we will focus on essential strategies for securely handling files and managing system
+
+3
+00:00:12,000 --> 00:00:15,000
+resources to prevent vulnerabilities.
+
+4
+00:00:15,000 --> 00:00:22,000
+These practices are designed to protect your system from common threats by ensuring that files are properly
+
+5
+00:00:22,000 --> 00:00:28,000
+managed, that sensitive data is not exposed, and that potential security loopholes are closed.
+
+6
+00:00:29,000 --> 00:00:36,000
+Effective file handling ensures that only safe, authorized files are allowed into the system, while
+
+7
+00:00:36,000 --> 00:00:41,000
+proper memory management prevents issues like resource leaks or overflows, which could compromise system
+
+8
+00:00:41,000 --> 00:00:43,000
+stability or security.
+
+9
+00:00:43,000 --> 00:00:48,000
+The goal of these practices is to maintain control over how files are uploaded, stored, and accessed,
+
+10
+00:00:48,000 --> 00:00:53,000
+while also ensuring that system resources are efficiently used and protected.
+
+11
+00:00:53,000 --> 00:01:00,000
+By following these strategies, we can safeguard our systems against various forms of attacks and errors,
+
+12
+00:01:00,000 --> 00:01:07,000
+ensuring that they remain resilient and functional even in the face of unexpected challenges.
+
+13
+00:01:07,000 --> 00:01:14,000
+Through attention to detail in both file handling and resource management, we create a secure environment
+
+14
+00:01:14,000 --> 00:01:17,000
+that is resistant to exploitation and vulnerabilities.
+
+15
+00:01:18,000 --> 00:01:19,000
+Let's start our lesson.
+
+16
+00:01:20,000 --> 00:01:27,000
+In this lesson, we cover best practices for safe file handling and memory management organized by relevance.
+
+17
+00:01:27,000 --> 00:01:33,000
+We begin with high relevance practices which directly address critical threats like unauthorized file
+
+18
+00:01:33,000 --> 00:01:37,000
+uploads, malicious file execution, and system compromise.
+
+19
+00:01:37,000 --> 00:01:44,000
+Through dynamic includes or redirects, these practices focus on controlling who can upload files,
+
+20
+00:01:44,000 --> 00:01:50,000
+restricting file types, and ensuring that files cannot be executed or misused by the web server.
+
+21
+00:01:50,000 --> 00:01:56,000
+Measures like scanning files for malware and validating file headers add additional layers of protection,
+
+22
+00:01:56,000 --> 00:02:00,000
+ensuring that only safe, well validated files are accepted into the system.
+
+23
+00:02:01,000 --> 00:02:06,000
+Moving on to moderate and low relevance practices, we focus on enhancing file storage security and
+
+24
+00:02:06,000 --> 00:02:10,000
+preventing less common but still important vulnerabilities.
+
+25
+00:02:10,000 --> 00:02:17,000
+For instance, storing files outside the web context and using Whitelists to reference files helps minimize
+
+26
+00:02:17,000 --> 00:02:20,000
+risks from improper access.
+
+27
+00:02:20,000 --> 00:02:26,000
+We also cover technical considerations like buffer management, file paths, handling, and resource
+
+28
+00:02:26,000 --> 00:02:32,000
+management to ensure that even in edge cases, the system remains secure.
+
+29
+00:02:32,000 --> 00:02:38,000
+These practices collectively ensure comprehensive protection from both high impact threats and more
+
+30
+00:02:38,000 --> 00:02:40,000
+subtle vulnerabilities.
+
+31
+00:02:41,000 --> 00:02:48,000
+This second list organizes file and memory management best practices based on their complexity, helping
+
+32
+00:02:48,000 --> 00:02:51,000
+to guide you from basic to advanced concepts.
+
+33
+00:02:52,000 --> 00:02:58,000
+At the basic level, we cover fundamental practices like ensuring buffer sizes are correct, Avoiding
+
+34
+00:02:58,000 --> 00:03:04,000
+direct user input in dynamic includes and explicitly closing resources to prevent memory leaks.
+
+35
+00:03:05,000 --> 00:03:11,000
+This simple yet crucial steps create a foundation for secure file handling and prevent common programming
+
+36
+00:03:11,000 --> 00:03:13,000
+errors that can lead to vulnerabilities.
+
+37
+00:03:14,000 --> 00:03:21,000
+As we move into the intermediate and advanced levels, the focus shifts to more sophisticated techniques
+
+38
+00:03:21,000 --> 00:03:28,000
+such as limiting file uploads to authenticated users, preventing execution of dangerous files, and
+
+39
+00:03:28,000 --> 00:03:31,000
+separating file storage from web facing applications.
+
+40
+00:03:32,000 --> 00:03:39,000
+You can think of this categorization by complexity as just one way to approach learning these principles
+
+41
+00:03:40,000 --> 00:03:41,000
+for your own understanding.
+
+42
+00:03:41,000 --> 00:03:47,000
+Feel free to group them based on other criteria, such as the types of vulnerabilities they address
+
+43
+00:03:47,000 --> 00:03:53,000
+or how frequently they are used to speed up your learning process and focus on what's most important
+
+44
+00:03:53,000 --> 00:03:54,000
+for you.
+
+45
+00:03:55,000 --> 00:03:59,000
+As I promised, let's provide a detailed overview of each technique.
+
+46
+00:04:00,000 --> 00:04:03,000
+As you saw, there are different ways to group these practices.
+
+47
+00:04:03,000 --> 00:04:09,000
+However, for the sake of this lesson, let's organize all the techniques by relevance and review them
+
+48
+00:04:09,000 --> 00:04:10,000
+in that order.
+
+49
+00:04:10,000 --> 00:04:15,000
+And in case you have any questions during the lesson, no need to wait till the end of the lesson.
+
+50
+00:04:15,000 --> 00:04:19,000
+Write them in the Q&A section below the video and I will be happy to answer.
+
+51
+00:04:20,000 --> 00:04:26,000
+Let's explore these high relevance practices for securing file uploads in even more detail, as each
+
+52
+00:04:26,000 --> 00:04:32,000
+one plays a critical role in protecting systems from file based vulnerabilities.
+
+53
+00:04:32,000 --> 00:04:37,000
+First, we have the requirement for authentication before allowing file uploads.
+
+54
+00:04:37,000 --> 00:04:39,000
+This is your first line of defense.
+
+55
+00:04:39,000 --> 00:04:45,000
+By ensuring only authenticated users can upload files, you are preventing anonymous or unauthorized
+
+56
+00:04:45,000 --> 00:04:49,000
+users from submitting potentially harmful files without authentication.
+
+57
+00:04:50,000 --> 00:04:56,000
+Any attacker could upload malicious files with ease, exposing your system to significant risks by restricting
+
+58
+00:04:56,000 --> 00:05:02,000
+file uploads to trusted, authenticated users will add accountability and ensure that only legitimate
+
+59
+00:05:02,000 --> 00:05:05,000
+actors are accessing the upload functionality.
+
+60
+00:05:05,000 --> 00:05:09,000
+Next, we must limit the types of files that can be uploaded.
+
+61
+00:05:10,000 --> 00:05:14,000
+Not every file type is safe to handle in a web application.
+
+62
+00:05:14,000 --> 00:05:20,000
+Allowing executable files, for example, introduces the risk of harmful code being executed on the
+
+63
+00:05:20,000 --> 00:05:28,000
+server by enforcing a whitelist of acceptable file types such as images, PDFs, or certain document
+
+64
+00:05:28,000 --> 00:05:29,000
+formats.
+
+65
+00:05:29,000 --> 00:05:31,000
+We minimize this risk.
+
+66
+00:05:31,000 --> 00:05:38,000
+This practice ensures that only files relevant to the business process are accepted, preventing attackers
+
+67
+00:05:38,000 --> 00:05:45,000
+from exploiting less secure file types to inject malicious code or compromise the system.
+
+68
+00:05:45,000 --> 00:05:51,000
+Now, it's not enough to rely on file extensions to validate the uploaded content.
+
+69
+00:05:51,000 --> 00:05:58,000
+Attackers can easily rename a malicious file with a safe looking extension to bypass these checks.
+
+70
+00:05:58,000 --> 00:06:05,000
+Instead, we need to validate uploaded files by checking their file headers, which reveals the actual
+
+71
+00:06:05,000 --> 00:06:07,000
+content type of the file.
+
+72
+00:06:07,000 --> 00:06:13,000
+For example, a file named Image.jpg could actually be an executable or a script.
+
+73
+00:06:13,000 --> 00:06:21,000
+If only the extension is checked by inspecting the file headers, we verify that the file content matches
+
+74
+00:06:21,000 --> 00:06:23,000
+its intended purpose.
+
+75
+00:06:23,000 --> 00:06:27,000
+Adding a robust layer of protection against disguised malicious files.
+
+76
+00:06:28,000 --> 00:06:35,000
+Another crucial practice is the prevention of file uploads that can be interpreted by the web server.
+
+77
+00:06:36,000 --> 00:06:44,000
+Files like PHP or PHP scripts, if uploaded, can be executed by the server, potentially giving attackers
+
+78
+00:06:44,000 --> 00:06:47,000
+access to your system or sensitive data.
+
+79
+00:06:48,000 --> 00:06:55,000
+To counter this, we must block uploads of server executable file types and ensure the server does not
+
+80
+00:06:55,000 --> 00:06:57,000
+mistakenly execute these files.
+
+81
+00:06:58,000 --> 00:07:04,000
+Additionally, deactivating execution privileges and file upload directories ensures that even if a
+
+82
+00:07:04,000 --> 00:07:08,000
+harmful file sneaks through, it cannot run on the server.
+
+83
+00:07:08,000 --> 00:07:14,000
+For example, if an attacker manages to upload a script, disabling execution in that directory prevents
+
+84
+00:07:14,000 --> 00:07:17,000
+the server from running it, thereby neutralizing the threat.
+
+85
+00:07:18,000 --> 00:07:21,000
+Next, let's talk about dynamic redirects and includes.
+
+86
+00:07:21,000 --> 00:07:26,000
+Both of these can be dangerous if user supplied data is passed directly into them.
+
+87
+00:07:26,000 --> 00:07:33,000
+Allowing users to manipulate redirects can lead to open redirect attacks where users are unknowingly
+
+88
+00:07:33,000 --> 00:07:36,000
+sent to malicious websites.
+
+89
+00:07:36,000 --> 00:07:44,000
+Similarly, passing user input directly into dynamic include functions can lead to code injection attacks,
+
+90
+00:07:44,000 --> 00:07:52,000
+where attackers can force the server to execute unintended code by validating and sanitizing any inputs
+
+91
+00:07:52,000 --> 00:07:58,000
+that influences, redirects or includes, and by limiting redirects to validated relative paths.
+
+92
+00:07:58,000 --> 00:08:01,000
+We protect the system from these attack vectors.
+
+93
+00:08:02,000 --> 00:08:08,000
+Finally, we need to address the importance of scanning user uploaded files for viruses and malware.
+
+94
+00:08:08,000 --> 00:08:15,000
+Even after filtering and validating file types, malicious software can still be hidden in otherwise
+
+95
+00:08:15,000 --> 00:08:17,000
+harmless looking files.
+
+96
+00:08:17,000 --> 00:08:24,000
+Integrating antivirus software or using a malware detection API to scan every uploaded file provides
+
+97
+00:08:24,000 --> 00:08:26,000
+an additional safeguard.
+
+98
+00:08:26,000 --> 00:08:33,000
+This step ensures that even if a user uploads a file containing malware, it will be detected and removed
+
+99
+00:08:33,000 --> 00:08:35,000
+before it can cause any harm.
+
+100
+00:08:36,000 --> 00:08:42,000
+For example, scanning image files for embedded malicious payloads adds yet another protective layer
+
+101
+00:08:42,000 --> 00:08:45,000
+against sophisticated attacks.
+
+102
+00:08:46,000 --> 00:08:52,000
+Let's explore each of these moderate relevance file handling practices in greater detail as they address
+
+103
+00:08:52,000 --> 00:08:57,000
+common security concerns that can be exploited, if not properly managed.
+
+104
+00:08:58,000 --> 00:09:02,000
+First, we begin with a separation of file storage from the web context.
+
+105
+00:09:03,000 --> 00:09:09,000
+This is essential because when files are stored in the same directory as the web application, they
+
+106
+00:09:09,000 --> 00:09:14,000
+are at risk of being accessed directly via URLs.
+
+107
+00:09:14,000 --> 00:09:21,000
+For example, if an attacker knows a file path or file name, they could retrieve or manipulate sensitive
+
+108
+00:09:21,000 --> 00:09:26,000
+files by storing uploaded files on a separate content server or in a database, will create a physical
+
+109
+00:09:26,000 --> 00:09:31,000
+and logical barrier between the files and the web facing parts of the application.
+
+110
+00:09:31,000 --> 00:09:37,000
+This separation means that even if a user uploads a potentially dangerous file, it cannot be accessed
+
+111
+00:09:37,000 --> 00:09:43,000
+or executed through the web as the file's location is outside the reach of web browsers.
+
+112
+00:09:43,000 --> 00:09:49,000
+This prevents direct attacks on uploaded files, and mitigates the risk of exposing sensitive content
+
+113
+00:09:49,000 --> 00:09:52,000
+or allowing executable files to run.
+
+114
+00:09:53,000 --> 00:09:57,000
+Next, we focus on using a whitelist for referencing files.
+
+115
+00:09:57,000 --> 00:10:05,000
+This involves creating a list of allowed safe file types and file names that can be uploaded or served
+
+116
+00:10:06,000 --> 00:10:07,000
+without a whitelist.
+
+117
+00:10:07,000 --> 00:10:14,000
+Attackers could upload or serve malicious files by simply changing the file extension or file name to
+
+118
+00:10:14,000 --> 00:10:19,000
+make it appear harmless, when in reality it could be an executable or script.
+
+119
+00:10:20,000 --> 00:10:27,000
+For example, an attacker could upload a file named document dot pdf, but it might actually be an executable
+
+120
+00:10:27,000 --> 00:10:28,000
+file in disguise.
+
+121
+00:10:29,000 --> 00:10:35,000
+By checking against a predefined whitelist of valid file types and names, you ensure that only files
+
+122
+00:10:35,000 --> 00:10:39,000
+you expect and know to be safe are accepted.
+
+123
+00:10:39,000 --> 00:10:45,000
+This drastically reduces the risk of serving or executing unintended and harmful files.
+
+124
+00:10:47,000 --> 00:10:54,000
+Then there is the replacement of directory or file paths with index values, which is another protective
+
+125
+00:10:54,000 --> 00:10:56,000
+measure against path traversal attacks.
+
+126
+00:10:57,000 --> 00:11:04,000
+Path traversal occurs when an attacker manipulates the file paths input to access directories or files
+
+127
+00:11:04,000 --> 00:11:10,000
+outside of the intended location, potentially gaining access to sensitive system files.
+
+128
+00:11:10,000 --> 00:11:17,000
+Instead of exposing full directory paths in your application, we can use index values that correspond
+
+129
+00:11:17,000 --> 00:11:18,000
+to predefined file paths.
+
+130
+00:11:18,000 --> 00:11:24,000
+This abstraction hides the actual directory structure, making it impossible for users to know or manipulate
+
+131
+00:11:24,000 --> 00:11:25,000
+file paths.
+
+132
+00:11:25,000 --> 00:11:31,000
+For instance, instead of exposing slash user uploads slash private, you could use an index value such
+
+133
+00:11:31,000 --> 00:11:38,000
+as file add equal 12345, which maps to the actual file in a secure manner without revealing its true
+
+134
+00:11:38,000 --> 00:11:39,000
+location.
+
+135
+00:11:40,000 --> 00:11:46,000
+Additionally, ensuring that application files and resources are read only is critical for maintaining
+
+136
+00:11:46,000 --> 00:11:48,000
+the integrity of the system.
+
+137
+00:11:48,000 --> 00:11:54,000
+If files in your web application, such as configuration files or public resources, are writable.
+
+138
+00:11:54,000 --> 00:11:58,000
+Attackers could modify them to inject malicious code.
+
+139
+00:11:59,000 --> 00:12:06,000
+Setting these files as read only ensures that they cannot be modified even by authorized users without
+
+140
+00:12:06,000 --> 00:12:08,000
+proper administrative privileges.
+
+141
+00:12:08,000 --> 00:12:14,000
+For example, key files like digital access or other configuration scripts should have read only permissions
+
+142
+00:12:14,000 --> 00:12:16,000
+to prevent tampering.
+
+143
+00:12:16,000 --> 00:12:22,000
+This simple yet effective measure makes it significantly harder for attackers to compromise core parts
+
+144
+00:12:22,000 --> 00:12:24,000
+of your application.
+
+145
+00:12:24,000 --> 00:12:31,000
+Finally, in Unix environments, safe uploading is through the use of logical drives or recruited environment
+
+146
+00:12:31,000 --> 00:12:38,000
+provides an additional layer of security by isolating the upload directory from the rest of the system.
+
+147
+00:12:38,000 --> 00:12:44,000
+A chroot environment restricts the file system available to a process, effectively creating a sandbox
+
+148
+00:12:44,000 --> 00:12:47,000
+where the process and its files are confined.
+
+149
+00:12:47,000 --> 00:12:54,000
+Alternatively, mounting file directories as logical drives creates a similar isolation.
+
+150
+00:12:54,000 --> 00:13:01,000
+These techniques ensure that even if a malicious file is uploaded, it cannot affect or interact with
+
+151
+00:13:01,000 --> 00:13:02,000
+the core system files.
+
+152
+00:13:03,000 --> 00:13:10,000
+For example, if an attacker uploads a malicious script, the use of a crude or logical mount prevents
+
+153
+00:13:10,000 --> 00:13:15,000
+the file from accessing important system directories, limiting the damage it could cause.
+
+154
+00:13:17,000 --> 00:13:23,000
+Let's go into even more detail on this low relevance, but crucial file handling and memory management
+
+155
+00:13:23,000 --> 00:13:28,000
+practices, as they are essential for addressing rare but significant vulnerabilities.
+
+156
+00:13:29,000 --> 00:13:34,000
+First, we look at the importance of avoiding sending absolute file paths to clients.
+
+157
+00:13:35,000 --> 00:13:41,000
+Absolute paths expose the internal directory structure of your server, which could provide attackers
+
+158
+00:13:41,000 --> 00:13:46,000
+with information that helps them craft more targeted attacks, such as path fast traversal.
+
+159
+00:13:46,000 --> 00:13:52,000
+Fast traversal allows attackers to manipulate URLs to access directories and files outside the intended
+
+160
+00:13:52,000 --> 00:13:56,000
+scope, by sending relative paths or using aliases.
+
+161
+00:13:56,000 --> 00:14:02,000
+We ensure that clients only see the necessary file locations without gaining insight into how the system
+
+162
+00:14:02,000 --> 00:14:03,000
+is organized.
+
+163
+00:14:04,000 --> 00:14:10,000
+This makes it much harder for attackers to navigate or guess sensitive locations on the server.
+
+164
+00:14:10,000 --> 00:14:15,000
+Next, we need to use input and output control for untrusted data.
+
+165
+00:14:15,000 --> 00:14:22,000
+Untrusted data, especially from user inputs, is one of the most common sources of vulnerabilities.
+
+166
+00:14:22,000 --> 00:14:29,000
+Without proper validation and sanitization, untrusted data could introduce code injection attacks,
+
+167
+00:14:29,000 --> 00:14:32,000
+file corruption, or even security breaches.
+
+168
+00:14:32,000 --> 00:14:39,000
+For example, if a file upload feature allows unchecked inputs, an attacker could upload a malicious
+
+169
+00:14:39,000 --> 00:14:46,000
+script by validating the format, length, and content of user inputs and encoding any outputs.
+
+170
+00:14:46,000 --> 00:14:51,000
+We protect the system from executing harmful data or writing corrupted files.
+
+171
+00:14:52,000 --> 00:14:55,000
+Now let's discuss buffer verification.
+
+172
+00:14:55,000 --> 00:15:02,000
+When working with file data or user inputs, we must ensure that buffers are allocated with the correct
+
+173
+00:15:02,000 --> 00:15:02,000
+size.
+
+174
+00:15:03,000 --> 00:15:09,000
+A mismatch in buffer size could lead to buffer overflow, where data exceeds the allocated space and
+
+175
+00:15:09,000 --> 00:15:12,000
+overwrites adjacent memory.
+
+176
+00:15:12,000 --> 00:15:19,000
+This can cause system crashes or worse, allow attackers to execute arbitrary code.
+
+177
+00:15:19,000 --> 00:15:27,000
+Verifying buffer sizes ensures that memory is properly allocated, preventing these overflows and safeguarding
+
+178
+00:15:27,000 --> 00:15:29,000
+the system from unpredictable behavior.
+
+179
+00:15:31,000 --> 00:15:35,000
+Closely related to this is checking buffer boundaries and loops.
+
+180
+00:15:35,000 --> 00:15:41,000
+When processing data in a loop, it's critical to ensure that each iteration respects the allocated
+
+181
+00:15:41,000 --> 00:15:43,000
+memory space.
+
+182
+00:15:43,000 --> 00:15:49,000
+Failing to do so can result in writing beyond buffer limits, leading to memory corruption or system
+
+183
+00:15:49,000 --> 00:15:50,000
+instability.
+
+184
+00:15:51,000 --> 00:15:57,000
+By carefully checking buffer boundaries during each iteration, we can prevent out of bounds errors
+
+185
+00:15:57,000 --> 00:16:00,000
+and buffer overflow issues.
+
+186
+00:16:00,000 --> 00:16:06,000
+This measure ensures that data processing stays within safe memory limits and avoids inadvertently overwriting
+
+187
+00:16:06,000 --> 00:16:08,000
+important system data.
+
+188
+00:16:08,000 --> 00:16:14,000
+Another key step is truncating input strings to a reasonable length before using them in copy or concatenation
+
+189
+00:16:14,000 --> 00:16:16,000
+functions like strcpy or strcat.
+
+190
+00:16:16,000 --> 00:16:22,000
+These functions are notorious for causing buffer overflows when input strings exceed the buffer limits.
+
+191
+00:16:23,000 --> 00:16:30,000
+Truncating input strings ensures that they fit within the allocated memory, thus preventing overflows
+
+192
+00:16:30,000 --> 00:16:33,000
+and ensuring safe string handling.
+
+193
+00:16:33,000 --> 00:16:40,000
+For instance, if a user submits a long file name, truncating it before copying ensures that only a
+
+194
+00:16:40,000 --> 00:16:42,000
+portion of the input is handled.
+
+195
+00:16:42,000 --> 00:16:44,000
+Protecting the rest of the buffer.
+
+196
+00:16:44,000 --> 00:16:49,000
+We must also be aware of the nontermination of strings when using functions like strncpy.
+
+197
+00:16:49,000 --> 00:16:55,000
+They check if the destination buffer is the same size as the source.
+
+198
+00:16:55,000 --> 00:17:02,000
+It may not include the necessary null terminator, leading to unintended behavior such as string concatenation
+
+199
+00:17:02,000 --> 00:17:04,000
+failures or memory corruption.
+
+200
+00:17:05,000 --> 00:17:11,000
+To avoid this, we must ensure that strings are always properly null terminated by either allocating
+
+201
+00:17:11,000 --> 00:17:17,000
+extra space in the buffer or using functions that automatically handle null termination.
+
+202
+00:17:17,000 --> 00:17:23,000
+This prevents memory corruption and avoids unexpected results in string operations.
+
+203
+00:17:23,000 --> 00:17:30,000
+Another critical practice is explicit closure of resources such as file handles, connections, or other
+
+204
+00:17:30,000 --> 00:17:32,000
+system resources.
+
+205
+00:17:32,000 --> 00:17:38,000
+Relying on garbage collection to clean up resources can lead to resource leaks where open handles are
+
+206
+00:17:38,000 --> 00:17:45,000
+not properly released, causing system performance degradation over time by explicitly closing these
+
+207
+00:17:45,000 --> 00:17:51,000
+resources using functions like closed, flush, or equivalent, we ensure that resources are properly
+
+208
+00:17:51,000 --> 00:17:58,000
+released as soon as they are no longer needed, reducing the risk of leaks and preventing system slowdowns
+
+209
+00:17:58,000 --> 00:18:01,000
+or crashes caused by resource exhaustion.
+
+210
+00:18:02,000 --> 00:18:09,000
+It's also vital to avoid non-vulnerable functions such as strcpy, strcat, or printf.
+
+211
+00:18:10,000 --> 00:18:16,000
+These functions, if misused, are prone to buffer overflow attacks because they don't impose strict
+
+212
+00:18:16,000 --> 00:18:19,000
+size limits on input or output data.
+
+213
+00:18:19,000 --> 00:18:26,000
+Replacing them with safer alternatives like Snprintf or Strlcpy ensures that output is limited to the
+
+214
+00:18:26,000 --> 00:18:33,000
+allocated buffer size, preventing overflows and ensuring more robust handling of strings and inputs.
+
+215
+00:18:33,000 --> 00:18:39,000
+For example, Snprintf allows you to specify the maximum output size, reducing the risk of accidentally
+
+216
+00:18:39,000 --> 00:18:41,000
+writing too much data to a buffer.
+
+217
+00:18:42,000 --> 00:18:46,000
+Another key step is ensuring the proper freeing of allocated memory.
+
+218
+00:18:46,000 --> 00:18:51,000
+Dynamically allocated memory, if not freed after use, causes memory leaks.
+
+219
+00:18:51,000 --> 00:18:58,000
+These leaks accumulate over time, leading to performance degradation and in severe cases, system crashes
+
+220
+00:18:58,000 --> 00:18:59,000
+due to resource exhaustion.
+
+221
+00:19:00,000 --> 00:19:06,000
+Proper memory management includes using functions like free to release memory as soon as it's no longer
+
+222
+00:19:06,000 --> 00:19:09,000
+needed, especially at function exit points.
+
+223
+00:19:09,000 --> 00:19:16,000
+Failing to free memory not only wastes resources, but also risks slowing down or crashing the system
+
+224
+00:19:16,000 --> 00:19:18,000
+as memory use grows.
+
+225
+00:19:19,000 --> 00:19:26,000
+Lastly, the use of non-executable stacks is a fundamental defense against stack based buffer overflow
+
+226
+00:19:26,000 --> 00:19:26,000
+attacks.
+
+227
+00:19:27,000 --> 00:19:35,000
+In these attacks, an attacker overflows the stack with malicious code and then executes it by configuring
+
+228
+00:19:35,000 --> 00:19:38,000
+the system to have non-executable stacks.
+
+229
+00:19:38,000 --> 00:19:45,000
+We prevent any code placed on the stack from being executed, effectively neutralizing this class of
+
+230
+00:19:45,000 --> 00:19:45,000
+attack.
+
+231
+00:19:46,000 --> 00:19:54,000
+Many modern operating systems and compilers support this feature, and enabling it adds an extra layer
+
+232
+00:19:54,000 --> 00:20:01,000
+of protection against exploits that attempt to take advantage of buffer overflow vulnerabilities.
+
+233
+00:20:02,000 --> 00:20:08,000
+In conclusion, safe file handling and memory management are essential pillars for protecting systems
+
+234
+00:20:08,000 --> 00:20:13,000
+from a wide range of vulnerabilities, starting with high relevance practices.
+
+235
+00:20:13,000 --> 00:20:20,000
+These directly address the most critical threats, such as unauthorized file uploads and the execution
+
+236
+00:20:20,000 --> 00:20:21,000
+of malicious files.
+
+237
+00:20:22,000 --> 00:20:29,000
+Requiring authentication for file uploads ensures that only trusted users can interact with your system,
+
+238
+00:20:29,000 --> 00:20:34,000
+while limiting file types reduces the risk of harmful files being uploaded.
+
+239
+00:20:34,000 --> 00:20:40,000
+Moreover, validating files by their contents through file headers rather than simply relying on file
+
+240
+00:20:40,000 --> 00:20:43,000
+extensions, prevents attackers from disguising malicious files.
+
+241
+00:20:43,000 --> 00:20:49,000
+Disabling execution privileges in upload directories is equally crucial, as it prevents any uploaded
+
+242
+00:20:49,000 --> 00:20:52,000
+scripts or files from being executed by the server.
+
+243
+00:20:53,000 --> 00:20:59,000
+Additionally, dynamic functions like redirects and file includes must never directly use unvalidated
+
+244
+00:20:59,000 --> 00:21:07,000
+user inputs, as these can easily lead to serious attacks like code injection or redirection to malicious
+
+245
+00:21:07,000 --> 00:21:07,000
+websites.
+
+246
+00:21:08,000 --> 00:21:15,000
+Scanning files for viruses is the final line of defense catching harmful content before it affects the
+
+247
+00:21:15,000 --> 00:21:16,000
+system.
+
+248
+00:21:16,000 --> 00:21:22,000
+For moderate relevance practices, we shift the focus to refining system configurations to create safer
+
+249
+00:21:22,000 --> 00:21:23,000
+environments.
+
+250
+00:21:23,000 --> 00:21:29,000
+Storing files outside the web applications root directory ensures that even if a file is uploaded,
+
+251
+00:21:29,000 --> 00:21:32,000
+it cannot be accessed directly via the web.
+
+252
+00:21:33,000 --> 00:21:38,000
+Furthermore, using a whitelist for file types, along with replacing file paths with index indexed.
+
+253
+00:21:38,000 --> 00:21:44,000
+Values limits the scope of what can be accessed and served by the application, preventing unauthorized
+
+254
+00:21:44,000 --> 00:21:46,000
+access to sensitive files.
+
+255
+00:21:47,000 --> 00:21:53,000
+Making application files read only protects critical resources from being tampered with and in Unix
+
+256
+00:21:53,000 --> 00:22:00,000
+environments, isolating file upload directories using logical drives or a crude environment ensures
+
+257
+00:22:00,000 --> 00:22:06,000
+that even if an attack occurs, the damage is confined and does not affect the core system.
+
+258
+00:22:07,000 --> 00:22:14,000
+Lastly, low relevance practices address edge cases and subtle vulnerabilities that can still lead to
+
+259
+00:22:14,000 --> 00:22:17,000
+significant issues if left unchecked.
+
+260
+00:22:17,000 --> 00:22:22,000
+Avoiding absolute file paths prevents attackers from learning your servers.
+
+261
+00:22:22,000 --> 00:22:29,000
+Directory structure, while properly controlling untrusted data through validation mitigates the risk
+
+262
+00:22:29,000 --> 00:22:35,000
+of injection attacks, ensuring that buffer sizes are correct and that boundaries are respected in loops
+
+263
+00:22:35,000 --> 00:22:43,000
+helps prevent buffer overflow attacks, which can lead to memory corruption or unauthorized code execution.
+
+264
+00:22:43,000 --> 00:22:51,000
+Likewise, truncating input strings and ensuring proper string termination avoids potential memory related
+
+265
+00:22:51,000 --> 00:22:52,000
+errors.
+
+266
+00:22:52,000 --> 00:22:59,000
+Explicitly closing resources and freeing memory ensures ease of the system doesn't suffer from resource
+
+267
+00:22:59,000 --> 00:23:07,000
+leaks, while avoiding known vulnerable functions like stripe or strcat, and using non-executable stacks
+
+268
+00:23:07,000 --> 00:23:10,000
+further hardens the system against buffer overflow attacks.
+
+269
+00:23:12,000 --> 00:23:15,000
+That's all what I wanted to discuss with you in this lesson.
+
+270
+00:23:15,000 --> 00:23:18,000
+Let's recap what we have learned today.
+
+271
+00:23:19,000 --> 00:23:25,000
+We learned how to securely manage file uploads by requiring authentication and limiting file types to
+
+272
+00:23:25,000 --> 00:23:28,000
+only what's necessary for business purposes.
+
+273
+00:23:29,000 --> 00:23:35,000
+You now understand the importance of validating file headers instead of just file extensions, and how
+
+274
+00:23:35,000 --> 00:23:39,000
+this prevents attackers from bypassing file type restrictions.
+
+275
+00:23:40,000 --> 00:23:46,000
+Together, we explored how to disable execution privileges in file directories and how to prevent files
+
+276
+00:23:46,000 --> 00:23:48,000
+that could be interpreted by the web server.
+
+277
+00:23:49,000 --> 00:23:54,000
+We discussed the importance of separating file storage from the web application and ensuring that file
+
+278
+00:23:54,000 --> 00:23:57,000
+references are handled using a whitelist.
+
+279
+00:23:57,000 --> 00:24:03,000
+I showed you how to set application files as read only, and isolate file upload directories in Unix
+
+280
+00:24:03,000 --> 00:24:07,000
+environments using logical drives or chroot environments.
+
+281
+00:24:08,000 --> 00:24:14,000
+We reviewed edge case scenarios such as the need for truncating input strings and avoiding the use of
+
+282
+00:24:14,000 --> 00:24:16,000
+vulnerable functions.
+
+283
+00:24:16,000 --> 00:24:23,000
+Lastly, we highlighted the critical practice of scanning user uploaded files from malware to ensure
+
+284
+00:24:23,000 --> 00:24:25,000
+comprehensive protection.
+
+285
+00:24:26,000 --> 00:24:28,000
+That's all for this lesson.
+
+286
+00:24:28,000 --> 00:24:30,000
+Thanks a lot for your attention.
+
+287
+00:24:30,000 --> 00:24:33,000
+Have a great day and see you in the next lesson.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/010 Protecting Communication Channels Ensuring Secure Transmission of Data_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/010 Protecting Communication Channels Ensuring Secure Transmission of Data_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..fcce169ac91d50dc85cdde7ffeb4662cabbddfef
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/010 Protecting Communication Channels Ensuring Secure Transmission of Data_en.srt
@@ -0,0 +1,884 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:12,000
+In this lesson, we will learn how to ensure the secure transmission of data by protecting communication
+
+3
+00:00:12,000 --> 00:00:13,000
+channels.
+
+4
+00:00:13,000 --> 00:00:19,000
+We will focus on safeguarding sensitive information from unauthorized access and interception during
+
+5
+00:00:19,000 --> 00:00:26,000
+transmission, ensuring that data remains confidential and intact as it moves between systems and users.
+
+6
+00:00:26,000 --> 00:00:32,000
+We'll explore how to prevent vulnerabilities that could expose information, addressing both obvious
+
+7
+00:00:32,000 --> 00:00:35,000
+risks and smaller, often overlooked issues.
+
+8
+00:00:36,000 --> 00:00:41,000
+By the end of the lesson, you'll understand how to maintain secure and reliable communication channels
+
+9
+00:00:41,000 --> 00:00:45,000
+to protect data throughout its journey across networks.
+
+10
+00:00:46,000 --> 00:00:51,000
+In this session, we will focus on protecting communication channels to ensure the secure transmission
+
+11
+00:00:51,000 --> 00:00:52,000
+of data.
+
+12
+00:00:53,000 --> 00:00:59,000
+The list we're about to explore outlines key practices that help maintain confidentiality and integrity
+
+13
+00:00:59,000 --> 00:01:02,000
+when transmitting sensitive information.
+
+14
+00:01:02,000 --> 00:01:08,000
+These practices are categorized by relevance, beginning with critical threat mitigation techniques
+
+15
+00:01:08,000 --> 00:01:15,000
+such as the use of encryption through TLS Transport Layer Security to protect all data in transit.
+
+16
+00:01:15,000 --> 00:01:21,000
+Encryption ensures that sensitive information, including authentication credentials and personal data,
+
+17
+00:01:21,000 --> 00:01:23,000
+remains secure during transmission.
+
+18
+00:01:23,000 --> 00:01:29,000
+We'll also discuss how to prevent insecure fallback connections, which could compromise the integrity
+
+19
+00:01:29,000 --> 00:01:35,000
+of your communications and the importance of valid and correctly configured TLS certificates.
+
+20
+00:01:35,000 --> 00:01:42,000
+As we move through the list, we'll cover moderate relevance concerns, such as adopting a single TLS
+
+21
+00:01:42,000 --> 00:01:46,000
+implementation to reduce inconsistencies and vulnerabilities.
+
+22
+00:01:46,000 --> 00:01:54,000
+You'll also learn how specifying character encodings helps prevent encoding based vulnerabilities.
+
+23
+00:01:54,000 --> 00:02:02,000
+Lastly, we'll touch on low relevance edge cases such as filtering sensitive information from HTTP referrer
+
+24
+00:02:02,000 --> 00:02:08,000
+headers, which might seem minor but can still expose critical data if not handled correctly.
+
+25
+00:02:09,000 --> 00:02:14,000
+Throughout this session, we'll delve into each of these best practices, explaining how they work together
+
+26
+00:02:14,000 --> 00:02:18,000
+to provide a comprehensive defense for securing data transmission.
+
+27
+00:02:19,000 --> 00:02:25,000
+In this second list, we have grouped communication security best practices by complexity, starting
+
+28
+00:02:25,000 --> 00:02:29,000
+with basic concepts and progressing to more advanced techniques.
+
+29
+00:02:30,000 --> 00:02:35,000
+This approach helps to break down the learning process, ensuring a gradual understanding of security
+
+30
+00:02:35,000 --> 00:02:42,000
+principles, starting with simpler practices like filtering sensitive information from HTTP referrer
+
+31
+00:02:42,000 --> 00:02:45,000
+headers and specifying character encodings.
+
+32
+00:02:46,000 --> 00:02:52,000
+These fundamental steps help prevent data leaks and ensure consistent handling of transmitted data.
+
+33
+00:02:53,000 --> 00:03:00,000
+As we move to intermediate and advanced practices, the focus shifts to the implementation of more sophisticated
+
+34
+00:03:00,000 --> 00:03:07,000
+security measures, such as ensuring TLS is used for all sensitive communications and external connections,
+
+35
+00:03:07,000 --> 00:03:13,000
+and adopting a single well configured TLS implementation to avoid inconsistencies.
+
+36
+00:03:13,000 --> 00:03:19,000
+At the advanced level, practices like implementing full encryption for all data transmission and preventing
+
+37
+00:03:19,000 --> 00:03:25,000
+fallback to insecure connections are crucial for mitigating critical threats.
+
+38
+00:03:25,000 --> 00:03:32,000
+While this list is categorized by complexity, you are free to explore different grouping methods that
+
+39
+00:03:32,000 --> 00:03:38,000
+may suit your learning style better, such as categorizing by threat level or frequency of use.
+
+40
+00:03:39,000 --> 00:03:43,000
+This flexibility will help you grasp these principles more effectively.
+
+41
+00:03:44,000 --> 00:03:48,000
+As I promised, let's provide a detailed overview of each technique.
+
+42
+00:03:49,000 --> 00:03:52,000
+As you saw, there are different ways to group these practices.
+
+43
+00:03:52,000 --> 00:03:58,000
+However, for the sake of this lesson, let's organize all the techniques by relevance and review them
+
+44
+00:03:58,000 --> 00:03:59,000
+in that order.
+
+45
+00:03:59,000 --> 00:04:01,000
+And in case you have any questions during the lesson?
+
+46
+00:04:01,000 --> 00:04:04,000
+No need to wait till the end of the lesson.
+
+47
+00:04:04,000 --> 00:04:09,000
+Write them in the Q&A section below the video and I will be happy to answer.
+
+48
+00:04:10,000 --> 00:04:16,000
+Let's go deeper into each of these critical practices for protecting communication channels and ensuring
+
+49
+00:04:16,000 --> 00:04:18,000
+secure data transmission.
+
+50
+00:04:18,000 --> 00:04:25,000
+These practices are vital to maintaining the integrity, confidentiality and security of sensitive information
+
+51
+00:04:25,000 --> 00:04:27,000
+as it moves across networks.
+
+52
+00:04:28,000 --> 00:04:33,000
+First, the implementation of encryption is foundational for any secure communication.
+
+53
+00:04:33,000 --> 00:04:39,000
+Encryption ensures that sensitive data such as personal details, financial information, or passwords
+
+54
+00:04:39,000 --> 00:04:43,000
+is converted into unreadable ciphertext while in transit.
+
+55
+00:04:44,000 --> 00:04:49,000
+This way, even if an attacker intercepts the data, they cannot make sense of it without the decryption
+
+56
+00:04:49,000 --> 00:04:50,000
+key.
+
+57
+00:04:50,000 --> 00:04:56,000
+The most widely used protocol for this purpose is Transport Layer Security, which encrypts data in
+
+58
+00:04:56,000 --> 00:05:01,000
+transit between servers and clients, ensuring that confidential information is not exposed.
+
+59
+00:05:01,000 --> 00:05:08,000
+Encryption must cover all communication channels, not just the primary ones like login forms, but
+
+60
+00:05:08,000 --> 00:05:16,000
+also any file transfers, APIs, or other connections handling sensitive data without encryption.
+
+61
+00:05:16,000 --> 00:05:22,000
+Sensitive data is vulnerable to man in the middle attacks, where attackers intercept and potentially
+
+62
+00:05:22,000 --> 00:05:24,000
+manipulate the transmitted data.
+
+63
+00:05:25,000 --> 00:05:32,000
+Next, preventing fallback to insecure connections is critical in maintaining secure communication even
+
+64
+00:05:32,000 --> 00:05:35,000
+when something goes wrong with the TLS connection.
+
+65
+00:05:35,000 --> 00:05:41,000
+In the event that a TLS connection fails, some systems might default back to a less secure connection,
+
+66
+00:05:41,000 --> 00:05:43,000
+such as HTTP.
+
+67
+00:05:43,000 --> 00:05:50,000
+This opens up the system to downgrade attacks where attackers intentionally disrupt secure protocols,
+
+68
+00:05:50,000 --> 00:05:54,000
+forcing the communication to switch to an unencrypted state.
+
+69
+00:05:55,000 --> 00:06:01,000
+To mitigate this, systems should be configured to reject insecure protocols outright and retry the
+
+70
+00:06:01,000 --> 00:06:06,000
+TLS connection, rather than reverting to an unsafe fallback.
+
+71
+00:06:06,000 --> 00:06:12,000
+This practice ensures that data is always encrypted, and that attackers cannot exploit protocol weaknesses
+
+72
+00:06:12,000 --> 00:06:15,000
+to gain access to sensitive information.
+
+73
+00:06:16,000 --> 00:06:23,000
+We then move on to the importance of using TLS for all authenticated access and sensitive data exchanges.
+
+74
+00:06:23,000 --> 00:06:29,000
+Authentication and sensitive operations should never occur over an unencrypted connection.
+
+75
+00:06:29,000 --> 00:06:37,000
+For example, when users log in, their credentials must be encrypted or else an attacker could intercept
+
+76
+00:06:37,000 --> 00:06:42,000
+usernames and passwords in plain text, leading to account compromise.
+
+77
+00:06:43,000 --> 00:06:49,000
+Beyond login credentials, this applies to any sensitive data being transmitted during a session, such
+
+78
+00:06:49,000 --> 00:06:52,000
+as payment information or personal details.
+
+79
+00:06:52,000 --> 00:06:59,000
+Failing to use TLS in these cases exposes the system to session hijacking, where attackers can steal
+
+80
+00:06:59,000 --> 00:07:03,000
+session tokens and impersonate users by using TLS.
+
+81
+00:07:03,000 --> 00:07:10,000
+For all these operations, you protect not only the data, but the entire session from being compromised.
+
+82
+00:07:11,000 --> 00:07:17,000
+Additionally, applying TLS to external system connections is crucial when your system communicates
+
+83
+00:07:17,000 --> 00:07:21,000
+with third party services or external systems.
+
+84
+00:07:21,000 --> 00:07:28,000
+For example, many applications interact with external APIs, databases, or cloud services, which
+
+85
+00:07:28,000 --> 00:07:32,000
+often handle sensitive transactions without TLS.
+
+86
+00:07:32,000 --> 00:07:39,000
+These interactions are vulnerable to interception, leaving the sensitive information at risk by ensuring
+
+87
+00:07:39,000 --> 00:07:41,000
+that all external communication is encrypted.
+
+88
+00:07:41,000 --> 00:07:47,000
+We create a secure channel even when working with systems outside of our direct control.
+
+89
+00:07:47,000 --> 00:07:52,000
+This is especially important when exchanging sensitive data, such as when handling payments, processing
+
+90
+00:07:52,000 --> 00:07:56,000
+personal information, or interacting with healthcare systems.
+
+91
+00:07:57,000 --> 00:08:04,000
+Lastly, TLS certificate validation plays a key role in ensuring the trustworthiness of your encrypted
+
+92
+00:08:04,000 --> 00:08:05,000
+communication.
+
+93
+00:08:06,000 --> 00:08:13,000
+TLS certificates must be valid, properly associated with the correct domain and an expired.
+
+94
+00:08:13,000 --> 00:08:18,000
+They also need to include intermediate certificates to establish a chain of trust.
+
+95
+00:08:19,000 --> 00:08:25,000
+Using expired or mismatched certificates undermines the security of the entire connection, as browsers
+
+96
+00:08:25,000 --> 00:08:31,000
+or systems may reject the connection or display warnings, leaving users vulnerable to man in the middle
+
+97
+00:08:31,000 --> 00:08:35,000
+attacks where attackers present fraudulent certificates.
+
+98
+00:08:36,000 --> 00:08:43,000
+Proper certificate management using automated tools to monitor and renew certificates ensures that your
+
+99
+00:08:43,000 --> 00:08:47,000
+encrypted communications remain secure and trustworthy at all times.
+
+100
+00:08:49,000 --> 00:08:56,000
+Let's go into more detail about this moderate relevance practices, which, while not always front of
+
+101
+00:08:56,000 --> 00:09:02,000
+mind, are essential for maintaining secure communication channels and protecting data during transmission.
+
+102
+00:09:03,000 --> 00:09:08,000
+First, let's talk about the adoption of a single standardized TLS implementation.
+
+103
+00:09:09,000 --> 00:09:16,000
+When you rely on multiple TLS implementations across different systems or services, it introduces complexity
+
+104
+00:09:16,000 --> 00:09:21,000
+and increases the chance of inconsistent configurations or outdated versions being used.
+
+105
+00:09:21,000 --> 00:09:26,000
+Each implementation might have its own set of vulnerabilities, and managing security updates across
+
+106
+00:09:26,000 --> 00:09:31,000
+several libraries can be difficult, leaving certain parts of your system exposed.
+
+107
+00:09:32,000 --> 00:09:38,000
+By adopting a single TLS implementation, such as OpenSSL or another widely trusted library, and applying
+
+108
+00:09:38,000 --> 00:09:45,000
+a standardized configuration across all your services with a web server's APIs or internal systems,
+
+109
+00:09:45,000 --> 00:09:49,000
+you ensure that your encryption practices are uniform.
+
+110
+00:09:49,000 --> 00:09:56,000
+This reduces the risk of a man in the middle attack, where attackers exploit misconfigurations or weak
+
+111
+00:09:56,000 --> 00:09:59,000
+encryption protocols to intercept sensitive data.
+
+112
+00:09:59,000 --> 00:10:06,000
+Furthermore, with a single implementation, it's easier to manage updates and configuration changes,
+
+113
+00:10:06,000 --> 00:10:13,000
+making it less likely that one system will fall out of sync with the others, which could expose a vulnerability.
+
+114
+00:10:14,000 --> 00:10:20,000
+Another advantage of using a single TLS implementation is that it simplifies the audit process.
+
+115
+00:10:20,000 --> 00:10:27,000
+When all systems use the same configuration, security teams can more easily review, maintain, and
+
+116
+00:10:27,000 --> 00:10:32,000
+ensure that all aspects of the network adhere to the same security standards.
+
+117
+00:10:32,000 --> 00:10:38,000
+This way, you avoid inconsistencies that could result from using different libraries or methods of
+
+118
+00:10:38,000 --> 00:10:45,000
+encryption across various systems, ensuring a more unified and secure approach to data transmission.
+
+119
+00:10:46,000 --> 00:10:51,000
+Next, we look at the specification of character encodings for all connections.
+
+120
+00:10:52,000 --> 00:10:59,000
+It might not seem as immediately critical as encryption, but defining a clear character encoding standard
+
+121
+00:10:59,000 --> 00:11:06,000
+such as UTF eight, is essential to prevent security vulnerabilities related to how data is interpreted.
+
+122
+00:11:06,000 --> 00:11:13,000
+If character encodings are not consistently specified, systems might misinterpret or mishandle the
+
+123
+00:11:13,000 --> 00:11:18,000
+transmitted data, leading to potential security issues such as injection attacks.
+
+124
+00:11:19,000 --> 00:11:21,000
+For example, if data is not properly encoded.
+
+125
+00:11:21,000 --> 00:11:27,000
+Attackers can exploit encoding mismatches to inject malicious code or manipulate how data is displayed,
+
+126
+00:11:27,000 --> 00:11:32,000
+leading to vulnerabilities like cross-site scripting or SQL injection.
+
+127
+00:11:32,000 --> 00:11:38,000
+By explicitly defining a character encoding across all communication channels, you ensure that the
+
+128
+00:11:38,000 --> 00:11:45,000
+data being transmitted is always interpreted in the same way by both the sender and the receiver.
+
+129
+00:11:45,000 --> 00:11:52,000
+This not only prevents data corruption, but also protects against any ambiguity that attackers might
+
+130
+00:11:52,000 --> 00:11:56,000
+use to introduce harmful characters into the data stream.
+
+131
+00:11:57,000 --> 00:12:04,000
+In a security context, consistent character encoding is a fundamental step in preserving the integrity
+
+132
+00:12:04,000 --> 00:12:11,000
+of the transmitted data, preventing injection attacks, and ensuring that all data is treated securely
+
+133
+00:12:11,000 --> 00:12:12,000
+and consistently.
+
+134
+00:12:14,000 --> 00:12:21,000
+Let's delve a bit deeper into the concept of filtering sensitive information from HTTP referer headers,
+
+135
+00:12:21,000 --> 00:12:27,000
+and why it plays a key role in securing communication channels, even though it may seem like a small
+
+136
+00:12:27,000 --> 00:12:28,000
+edge case.
+
+137
+00:12:28,000 --> 00:12:35,000
+When a user navigates from your website to an external site, the HTTP referrer header contains the
+
+138
+00:12:35,000 --> 00:12:38,000
+URL of the originating page.
+
+139
+00:12:39,000 --> 00:12:46,000
+While this is typically harmless, if sensitive data like authentication tokens, session IDs, or personally
+
+140
+00:12:46,000 --> 00:12:51,000
+identifiable information is included in the URL, this data could be exposed to external websites.
+
+141
+00:12:52,000 --> 00:12:55,000
+This exposure is unintentional but can have severe consequences.
+
+142
+00:12:56,000 --> 00:13:02,000
+The HTTP referer header essentially tells the external site where the user came from, including any
+
+143
+00:13:02,000 --> 00:13:03,000
+parameters in the URL.
+
+144
+00:13:04,000 --> 00:13:10,000
+If sensitive information is present, it could be captured by the external site, which may not have
+
+145
+00:13:10,000 --> 00:13:12,000
+the same privacy protections in place.
+
+146
+00:13:12,000 --> 00:13:19,000
+For example, let's say a user logs into a secure area of your site and a session token is embedded
+
+147
+00:13:19,000 --> 00:13:20,000
+in the URL.
+
+148
+00:13:20,000 --> 00:13:27,000
+If they then click on a link to an external website and that token is passed along in the referrer header,
+
+149
+00:13:27,000 --> 00:13:34,000
+the external site now has access to the user's session information, which could potentially be used
+
+150
+00:13:34,000 --> 00:13:38,000
+to hijack the session or expose private user data.
+
+151
+00:13:38,000 --> 00:13:46,000
+To mitigate this risk, it is essential to filter or remove sensitive parameters from the referrer header.
+
+152
+00:13:47,000 --> 00:13:49,000
+There are several methods to achieve this.
+
+153
+00:13:49,000 --> 00:13:56,000
+One common approach is to configure your web server to strip sensitive data from the URL before passing
+
+154
+00:13:56,000 --> 00:13:59,000
+it to an external site.
+
+155
+00:13:59,000 --> 00:14:06,000
+For example, using a referrer policy header in your HTTP response can control how much information
+
+156
+00:14:06,000 --> 00:14:08,000
+is sent in the referrer header.
+
+157
+00:14:08,000 --> 00:14:16,000
+Setting it to no referrer ensures that no referrer information is sent at all, while strict origin
+
+158
+00:14:16,000 --> 00:14:22,000
+when cross-origin allows only the domain without URL parameters to be shared.
+
+159
+00:14:23,000 --> 00:14:29,000
+The risks associated with not filtering referrer headers are real sensitive.
+
+160
+00:14:29,000 --> 00:14:35,000
+Information that gets exposed could be used for malicious purposes, such as session hijacking, where
+
+161
+00:14:35,000 --> 00:14:39,000
+an attacker uses session tokens to impersonate the user.
+
+162
+00:14:40,000 --> 00:14:46,000
+Additionally, private data could be harvested by third parties for profiling or unauthorized access.
+
+163
+00:14:47,000 --> 00:14:53,000
+The result is a potential breach of user trust, which could have long term consequences for your organization's
+
+164
+00:14:53,000 --> 00:14:57,000
+reputation and legal standing if personal data is leaked.
+
+165
+00:14:57,000 --> 00:15:02,000
+A good example of implementing this practice is configuring your server to remove all sensitive query
+
+166
+00:15:02,000 --> 00:15:07,000
+parameters from URLs before sending users to external sites.
+
+167
+00:15:07,000 --> 00:15:14,000
+For instance, if a user clicks a link while logged in, the referrer header could be set to only include
+
+168
+00:15:14,000 --> 00:15:21,000
+the domain name of your website with no additional parameters like user IDs or session tokens.
+
+169
+00:15:21,000 --> 00:15:28,000
+On the other hand, a poor practice would be allowing full URLs with sensitive parameters to be sent
+
+170
+00:15:28,000 --> 00:15:34,000
+in the referrer header, as this opens up the possibility of exposing critical information to any external
+
+171
+00:15:34,000 --> 00:15:36,000
+site the user visits.
+
+172
+00:15:37,000 --> 00:15:43,000
+In conclusion, protecting communication channels is essential to ensuring the secure transmission of
+
+173
+00:15:43,000 --> 00:15:50,000
+data, particularly as data flows between systems, users and external services.
+
+174
+00:15:50,000 --> 00:15:56,000
+We have broken down the best practices into categories based on their relevance, starting with high
+
+175
+00:15:56,000 --> 00:16:03,000
+relevance measures that address critical threat mitigation At the core of these high priority practices
+
+176
+00:16:03,000 --> 00:16:07,000
+is the implementation of encryption, particularly through Transport Layer Security.
+
+177
+00:16:08,000 --> 00:16:13,000
+This ensures that all sensitive information, whether personal data, authentication credentials or
+
+178
+00:16:13,000 --> 00:16:16,000
+confidential transactions, is encrypted in transit.
+
+179
+00:16:17,000 --> 00:16:23,000
+Without encryption, data is vulnerable to interception, making it easy for attackers to read or manipulate.
+
+180
+00:16:23,000 --> 00:16:30,000
+It's important to use valid, correctly configured TLS certificates to maintain trust and ensure that
+
+181
+00:16:30,000 --> 00:16:33,000
+the data is encrypted between the correct parties.
+
+182
+00:16:34,000 --> 00:16:40,000
+Additionally, we must prevent fallback to insecure connections when TLS fails, we cannot afford to
+
+183
+00:16:40,000 --> 00:16:44,000
+allow unencrypted communication as this could be exploited by attackers.
+
+184
+00:16:45,000 --> 00:16:52,000
+Furthermore, TLS should be applied to all authenticated content and external system connections, ensuring
+
+185
+00:16:52,000 --> 00:16:59,000
+that data remains secure not just within our system, but also when interacting with third party services.
+
+186
+00:17:00,000 --> 00:17:07,000
+moving to moderate relevance practices, we see that standardization plays a key role in improving security.
+
+187
+00:17:08,000 --> 00:17:15,000
+Adopting a single standardized TLS implementation ensures consistency across all systems and minimizes
+
+188
+00:17:15,000 --> 00:17:21,000
+the risks associated with misconfiguration or using outdated or insecure libraries.
+
+189
+00:17:22,000 --> 00:17:28,000
+This also makes maintenance and security auditing much easier, as there is only one implementation
+
+190
+00:17:28,000 --> 00:17:29,000
+to manage and update.
+
+191
+00:17:30,000 --> 00:17:37,000
+Another crucial aspect is the specification of character encodings for all connections, ensuring that
+
+192
+00:17:37,000 --> 00:17:45,000
+a uniform character encoding such as UTF eight is used prevents encoding related vulnerabilities such
+
+193
+00:17:45,000 --> 00:17:52,000
+as injection attacks or data misinterpretation, which could lead to more significant security issues.
+
+194
+00:17:53,000 --> 00:17:59,000
+By applying a consistent encoding, we ensure data integrity across the entire communication process.
+
+195
+00:18:00,000 --> 00:18:07,000
+Lastly, we addressed some low relevance but still important edge cases, such as filtering sensitive
+
+196
+00:18:07,000 --> 00:18:11,000
+information from HTTP referer headers.
+
+197
+00:18:11,000 --> 00:18:18,000
+While this might seem like a minor detail, it's critical to ensure that no sensitive data, such as
+
+198
+00:18:18,000 --> 00:18:26,000
+session tokens or user IDs is accidentally leaked to external sites through Referer headers.
+
+199
+00:18:26,000 --> 00:18:32,000
+This protects user privacy and prevents unauthorized access or misuse of sensitive information by third
+
+200
+00:18:32,000 --> 00:18:33,000
+parties.
+
+201
+00:18:34,000 --> 00:18:40,000
+Even though this issue is less common, overlooking it could result in subtle security vulnerabilities
+
+202
+00:18:40,000 --> 00:18:44,000
+that undermine the overall safety of your system.
+
+203
+00:18:45,000 --> 00:18:48,000
+That's all what I wanted to discuss with you today.
+
+204
+00:18:48,000 --> 00:18:51,000
+Let's recap what we have learned in this lesson.
+
+205
+00:18:52,000 --> 00:18:58,000
+We explored how to secure data transmission by implementing encryption, focusing on the use of TLS
+
+206
+00:18:58,000 --> 00:19:00,000
+for protecting all sensitive information.
+
+207
+00:19:00,000 --> 00:19:07,000
+You learn the importance of preventing fallback to insecure connections, ensuring that data always
+
+208
+00:19:07,000 --> 00:19:09,000
+travels over secure channels.
+
+209
+00:19:09,000 --> 00:19:16,000
+We discussed the use of TLS for authenticated access and sensitive transactions, both within the system
+
+210
+00:19:16,000 --> 00:19:18,000
+and when connecting to external services.
+
+211
+00:19:18,000 --> 00:19:24,000
+We went over the value of adopting a single standardized TLS implementation across all services to avoid
+
+212
+00:19:24,000 --> 00:19:26,000
+inconsistencies and vulnerabilities.
+
+213
+00:19:27,000 --> 00:19:32,000
+You now understand how specifying character encoding helps prevent encoding based vulnerabilities during
+
+214
+00:19:32,000 --> 00:19:34,000
+data transmission.
+
+215
+00:19:34,000 --> 00:19:41,000
+I demonstrated how to filter sensitive information from HTTP referrer headers to prevent data leakage
+
+216
+00:19:41,000 --> 00:19:43,000
+when linking to external sites.
+
+217
+00:19:43,000 --> 00:19:49,000
+Lastly, we reviewed best practices for maintaining valid and correctly configured TLS certificates
+
+218
+00:19:49,000 --> 00:19:51,000
+to secure communication.
+
+219
+00:19:52,000 --> 00:19:54,000
+That's all for this lesson.
+
+220
+00:19:54,000 --> 00:19:56,000
+Thanks a lot for your attention.
+
+221
+00:19:56,000 --> 00:19:59,000
+Have a great day and see you in the next lesson.
+
diff --git a/76 - Cybersecurity Comprehensive Security Practices for Developers/011 Hardening System Configurations Reducing Attack Surface_en.srt b/76 - Cybersecurity Comprehensive Security Practices for Developers/011 Hardening System Configurations Reducing Attack Surface_en.srt
new file mode 100644
index 0000000000000000000000000000000000000000..43d98e0528eb025b39b2ddf7e50b84a78e1b4d37
--- /dev/null
+++ b/76 - Cybersecurity Comprehensive Security Practices for Developers/011 Hardening System Configurations Reducing Attack Surface_en.srt
@@ -0,0 +1,1064 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:13,000
+In this lesson, we will focus on the essential practices that help strengthen system security by minimizing
+
+3
+00:00:13,000 --> 00:00:15,000
+potential vulnerabilities.
+
+4
+00:00:15,000 --> 00:00:22,000
+These practices ensure that the system only runs the necessary components, limits access to critical
+
+5
+00:00:22,000 --> 00:00:28,000
+resources, and maintains a secure environment by regularly updating and monitoring configurations.
+
+6
+00:00:28,000 --> 00:00:35,000
+By implementing these strategies, we reduce the risk of unauthorized access, data breaches, and exposure
+
+7
+00:00:35,000 --> 00:00:36,000
+to known threats.
+
+8
+00:00:37,000 --> 00:00:42,000
+Additionally, we will explore how proper system management from maintaining strict controls over system
+
+9
+00:00:42,000 --> 00:00:48,000
+behavior to ensuring detailed monitoring and auditing contributes to overall security.
+
+10
+00:00:48,000 --> 00:00:54,000
+These practices, while sometimes addressing smaller details, help create a well protected and resilient
+
+11
+00:00:54,000 --> 00:00:57,000
+system that can better withstand potential attacks.
+
+12
+00:00:58,000 --> 00:01:04,000
+The goal is to create a robust framework where security is woven into every layer of system operations,
+
+13
+00:01:04,000 --> 00:01:07,000
+ensuring long term stability and protection.
+
+14
+00:01:07,000 --> 00:01:09,000
+Let's start our lesson.
+
+15
+00:01:10,000 --> 00:01:16,000
+In this lesson, we will explore the key system configuration best practices aimed at reducing the attack
+
+16
+00:01:16,000 --> 00:01:19,000
+surface and enhancing overall security.
+
+17
+00:01:20,000 --> 00:01:26,000
+The list is organized by relevance, starting with high relevance practices that focus on critical threat
+
+18
+00:01:26,000 --> 00:01:27,000
+mitigation.
+
+19
+00:01:28,000 --> 00:01:34,000
+These include restricting service and process accounts to the minimum necessary privileges, ensuring
+
+20
+00:01:34,000 --> 00:01:41,000
+that systems fail securely when errors occur, and removing unnecessary files and functionality that
+
+21
+00:01:41,000 --> 00:01:42,000
+could expose vulnerabilities.
+
+22
+00:01:43,000 --> 00:01:48,000
+Additionally, keeping all system components updated with the latest versions and applying patches is
+
+23
+00:01:48,000 --> 00:01:51,000
+crucial for preventing known exploits.
+
+24
+00:01:51,000 --> 00:01:57,000
+Isolating development environments from production systems also plays a vital role in reducing the risk
+
+25
+00:01:57,000 --> 00:01:58,000
+of unintentional exposure.
+
+26
+00:01:59,000 --> 00:02:05,000
+Will also cover moderate and low relevance practices that address common security concerns and lesser
+
+27
+00:02:05,000 --> 00:02:06,000
+known threats.
+
+28
+00:02:07,000 --> 00:02:14,000
+This includes disabling unnecessary HTTP methods, hiding directory structures from attackers, and
+
+29
+00:02:14,000 --> 00:02:20,000
+removing unnecessary details from HTTP response headers to limit the information that can be used against
+
+30
+00:02:20,000 --> 00:02:24,000
+your system for lower relevance, but still important edge cases.
+
+31
+00:02:24,000 --> 00:02:32,000
+We will look at how to handle different HTTP versions, manage asset tracking and control software changes
+
+32
+00:02:32,000 --> 00:02:37,000
+to ensure that every component is registered, secure and properly documented.
+
+33
+00:02:37,000 --> 00:02:43,000
+Together, these practices provide a comprehensive approach to minimizing vulnerabilities in system
+
+34
+00:02:43,000 --> 00:02:44,000
+configurations.
+
+35
+00:02:45,000 --> 00:02:53,000
+This second list organizes system configuration best practices based on complexity, starting with basic
+
+36
+00:02:53,000 --> 00:03:00,000
+practices that are foundational for security, such as removing unnecessary Functionality and files,
+
+37
+00:03:00,000 --> 00:03:06,000
+deactivating directory listings, and ensuring that test code is removed before deployment.
+
+38
+00:03:07,000 --> 00:03:13,000
+This simple yet effective steps help reduce the attack surface and prevent unintentional exposure.
+
+39
+00:03:13,000 --> 00:03:20,000
+Additionally, defining supported HTTP methods and removing unnecessary information from HTTP headers
+
+40
+00:03:20,000 --> 00:03:24,000
+are key to limiting what can be exploited by attackers.
+
+41
+00:03:24,000 --> 00:03:31,000
+As you get comfortable with these basic concepts, you can begin to move into more intermediate practices
+
+42
+00:03:31,000 --> 00:03:38,000
+such as restricting account privileges, ensuring secure failure, handling, and applying patches regularly
+
+43
+00:03:38,000 --> 00:03:40,000
+to maintain the security of your system.
+
+44
+00:03:41,000 --> 00:03:47,000
+Once you have mastered these fundamentals, you can progress to advanced practices which involve more
+
+45
+00:03:47,000 --> 00:03:54,000
+complex configurations like isolating development environments from production networks to prevent accidental
+
+46
+00:03:54,000 --> 00:03:55,000
+exposure.
+
+47
+00:03:55,000 --> 00:04:02,000
+Advanced strategies also include managing multiple versions of HTTP, ensuring configuration outputs
+
+48
+00:04:02,000 --> 00:04:09,000
+are human readable for auditing and implementing comprehensive asset management and change control systems.
+
+49
+00:04:09,000 --> 00:04:16,000
+While this list is organized by complexity to guide you step by step, feel free to explore other grouping
+
+50
+00:04:16,000 --> 00:04:22,000
+techniques that suit your learning style, whether by threat level or frequency of use.
+
+51
+00:04:22,000 --> 00:04:27,000
+Tailoring how you approach these principles will help you master them more effectively.
+
+52
+00:04:28,000 --> 00:04:32,000
+As I promised, let's provide a detailed overview of each technique.
+
+53
+00:04:32,000 --> 00:04:36,000
+As you saw, there are different ways to group these practices.
+
+54
+00:04:37,000 --> 00:04:42,000
+However, for the sake of this lesson, let's organize all the techniques by relevance and review them
+
+55
+00:04:42,000 --> 00:04:43,000
+in that order.
+
+56
+00:04:44,000 --> 00:04:48,000
+And in case you have any questions during the lesson, no need to wait till the end of the lesson.
+
+57
+00:04:48,000 --> 00:04:53,000
+Write them in the Q&A section below the video and I will be happy to answer.
+
+58
+00:04:54,000 --> 00:05:01,000
+Let's go deeper into these hardening practices to fully understand how each one plays a vital role in
+
+59
+00:05:01,000 --> 00:05:05,000
+reducing the attack surface and making the system more secure.
+
+60
+00:05:06,000 --> 00:05:12,000
+First, the restriction of web server process and service accounts to the least privileges necessary
+
+61
+00:05:12,000 --> 00:05:15,000
+is foundational in securing any system.
+
+62
+00:05:16,000 --> 00:05:22,000
+The principle of least privilege dictates that each user or service account should have only the permissions
+
+63
+00:05:22,000 --> 00:05:25,000
+required to perform its specific function.
+
+64
+00:05:25,000 --> 00:05:26,000
+Nothing more.
+
+65
+00:05:26,000 --> 00:05:32,000
+If an attacker gains control over a service account, the damage is limited because that account has
+
+66
+00:05:32,000 --> 00:05:34,000
+no access beyond what it needs.
+
+67
+00:05:34,000 --> 00:05:40,000
+For instance, a web server should not have write access to files unless absolutely required.
+
+68
+00:05:40,000 --> 00:05:45,000
+This way, even if the server is compromised, the attacker cannot alter critical files.
+
+69
+00:05:45,000 --> 00:05:52,000
+It's a simple but powerful way to contain potential damage and keep different areas of the system isolated
+
+70
+00:05:52,000 --> 00:05:54,000
+from unnecessary access.
+
+71
+00:05:54,000 --> 00:05:58,000
+Secure failure handling is another critical element.
+
+72
+00:05:58,000 --> 00:06:05,000
+When systems encounter errors, they often display error messages or log information for debugging purposes.
+
+73
+00:06:06,000 --> 00:06:13,000
+However, if those error messages expose internal details like file paths, stack traces, or database
+
+74
+00:06:13,000 --> 00:06:18,000
+queries, they can give attackers insight into the system's inner workings.
+
+75
+00:06:18,000 --> 00:06:22,000
+This knowledge can be used to craft more effective attacks.
+
+76
+00:06:23,000 --> 00:06:30,000
+Proper failure handling ensures that when exceptions occur, users only see generic messages while detailed
+
+77
+00:06:30,000 --> 00:06:35,000
+error information is securely logged on the back end for administrators.
+
+78
+00:06:35,000 --> 00:06:41,000
+This prevents attackers from gaining valuable information while allowing developers to troubleshoot
+
+79
+00:06:41,000 --> 00:06:42,000
+issues safely.
+
+80
+00:06:43,000 --> 00:06:50,000
+Next, removing unnecessary functionality and files significantly reduces the attack surface.
+
+81
+00:06:50,000 --> 00:06:57,000
+Every additional service, application, or file running on a system is a potential point of entry for
+
+82
+00:06:57,000 --> 00:06:58,000
+an attacker.
+
+83
+00:06:58,000 --> 00:07:05,000
+Systems often contain leftover files from installation, default configurations, or sample applications
+
+84
+00:07:05,000 --> 00:07:07,000
+that were never removed.
+
+85
+00:07:07,000 --> 00:07:12,000
+These can contain vulnerabilities that are well known and easily exploited.
+
+86
+00:07:13,000 --> 00:07:20,000
+Regularly auditing the system and removing these non-essential components ensures that only the necessary
+
+87
+00:07:20,000 --> 00:07:26,000
+elements are in production, effectively minimizing the opportunities for attackers to find and exploit
+
+88
+00:07:26,000 --> 00:07:27,000
+weaknesses.
+
+89
+00:07:29,000 --> 00:07:35,000
+Staying up to date is crucial, which is why ensuring servers, frameworks and components are running
+
+90
+00:07:35,000 --> 00:07:37,000
+the latest approved versions is a key practice.
+
+91
+00:07:38,000 --> 00:07:45,000
+Software vendors frequently release updates and patches to fix vulnerabilities as they are discovered.
+
+92
+00:07:45,000 --> 00:07:51,000
+If you are running outdated software, you are at risk from known vulnerabilities that attackers are
+
+93
+00:07:51,000 --> 00:07:53,000
+likely to target.
+
+94
+00:07:53,000 --> 00:07:58,000
+Implementing a process for regularly updating and patching components helps to close these security
+
+95
+00:07:58,000 --> 00:08:01,000
+gaps and protect against evolving threats.
+
+96
+00:08:01,000 --> 00:08:07,000
+Patching all versions in use consistently ensures that every part of your infrastructure is secure,
+
+97
+00:08:07,000 --> 00:08:09,000
+not just the main server or application.
+
+98
+00:08:09,000 --> 00:08:15,000
+Attackers often look for the weakest link, so leaving any part of the system unpatched could expose
+
+99
+00:08:15,000 --> 00:08:17,000
+the entire infrastructure.
+
+100
+00:08:18,000 --> 00:08:24,000
+The removal of test code and non-production functionality before deployment is another often overlooked
+
+101
+00:08:24,000 --> 00:08:26,000
+step in securing systems.
+
+102
+00:08:26,000 --> 00:08:32,000
+Developers use test code and debug features during the development process, but if these features are
+
+103
+00:08:32,000 --> 00:08:37,000
+left in the production environment, they can be exploited by attackers.
+
+104
+00:08:37,000 --> 00:08:43,000
+For example, debug modes may provide additional information or even administrative access that was
+
+105
+00:08:43,000 --> 00:08:45,000
+intended for testing purposes only.
+
+106
+00:08:46,000 --> 00:08:52,000
+Ensuring that test code is removed before the system goes live closes these loopholes, eliminating
+
+107
+00:08:52,000 --> 00:08:55,000
+tools that attackers could use.
+
+108
+00:08:56,000 --> 00:09:03,000
+Lastly, isolating development environments from production systems is crucial for maintaining security,
+
+109
+00:09:03,000 --> 00:09:04,000
+development and testing.
+
+110
+00:09:04,000 --> 00:09:11,000
+Environments often have more relaxed security controls, and it's common for developers to work with
+
+111
+00:09:11,000 --> 00:09:18,000
+real data if these environments are not isolated from production, attackers or even insiders with access
+
+112
+00:09:18,000 --> 00:09:26,000
+to development systems might inadvertently access production data or expose it to less secure testing
+
+113
+00:09:26,000 --> 00:09:26,000
+systems.
+
+114
+00:09:27,000 --> 00:09:33,000
+Proper isolation through network segmentation, restricted access controls and separate credentials
+
+115
+00:09:33,000 --> 00:09:39,000
+ensures that the production environment remains secure and that sensitive data is protected.
+
+116
+00:09:40,000 --> 00:09:47,000
+Let's take a more detailed look at each of these moderate relevance practices for hardening system configurations
+
+117
+00:09:47,000 --> 00:09:49,000
+to reduce the attack surface.
+
+118
+00:09:49,000 --> 00:09:56,000
+Each of these practices plays a vital role in minimizing potential entry points for attackers and improving
+
+119
+00:09:56,000 --> 00:09:59,000
+the overall security posture of your system.
+
+120
+00:10:00,000 --> 00:10:06,000
+First, disabling unnecessary HTTP methods is a crucial step in tightening security.
+
+121
+00:10:06,000 --> 00:10:14,000
+By default, web servers often enable a variety of HTTP methods such as put, delete, trace, or options.
+
+122
+00:10:15,000 --> 00:10:20,000
+These methods can be useful in certain environments, but are rarely needed for standard web applications.
+
+123
+00:10:21,000 --> 00:10:26,000
+Attackers can exploit these methods to modify or delete files, probe the system, or perform man in
+
+124
+00:10:26,000 --> 00:10:27,000
+the middle attacks.
+
+125
+00:10:28,000 --> 00:10:34,000
+For instance, an attacker could use the pop method to upload a malicious file or leverage trace to
+
+126
+00:10:34,000 --> 00:10:36,000
+steal session information.
+
+127
+00:10:36,000 --> 00:10:43,000
+Disabling these unnecessary methods or limiting them to only authenticated users greatly reduces these
+
+128
+00:10:43,000 --> 00:10:44,000
+risks.
+
+129
+00:10:44,000 --> 00:10:51,000
+Essentially, you are cutting off potential avenues for attackers to manipulate the server by reducing
+
+130
+00:10:51,000 --> 00:10:53,000
+the number of methods they can use.
+
+131
+00:10:54,000 --> 00:10:57,000
+Next is the deactivation of directory listings.
+
+132
+00:10:57,000 --> 00:11:05,000
+When a directory listing is enabled on a server, it allows anyone to see the entire contents of a directory.
+
+133
+00:11:05,000 --> 00:11:14,000
+If there is no default index file like index.html in that folder, this can unintentionally expose sensitive
+
+134
+00:11:14,000 --> 00:11:19,000
+files, configuration details, or scripts that shouldn't be publicly accessible.
+
+135
+00:11:20,000 --> 00:11:26,000
+For example, an attacker might find configuration files or backup scripts that could be leveraged in
+
+136
+00:11:26,000 --> 00:11:27,000
+an attack.
+
+137
+00:11:27,000 --> 00:11:34,000
+By deactivating directory listings, you prevent attackers from browsing through your directory structure
+
+138
+00:11:34,000 --> 00:11:37,000
+and gaining insights that could be used against you.
+
+139
+00:11:38,000 --> 00:11:44,000
+It's a simple but effective way to prevent information leakage and minimize unnecessary exposure.
+
+140
+00:11:45,000 --> 00:11:51,000
+Now let's talk about the prevention of directory structure disclosure through the robots.txt file.
+
+141
+00:11:52,000 --> 00:12:00,000
+While the robots.txt file is primarily used to control how search engines index your site, it can inadvertently
+
+142
+00:12:00,000 --> 00:12:03,000
+reveal too much to attackers.
+
+143
+00:12:03,000 --> 00:12:10,000
+Attackers often check this file to identify which directories are marked as disallowed or sensitive,
+
+144
+00:12:10,000 --> 00:12:13,000
+giving them an idea of what to target.
+
+145
+00:12:13,000 --> 00:12:19,000
+Instead of listing all disallowed directories individually, it's better to group sensitive directories
+
+146
+00:12:19,000 --> 00:12:26,000
+into a parent directory and disallow access to the entire parent directory in robots.txt.
+
+147
+00:12:27,000 --> 00:12:32,000
+This way, attackers can't easily map out your directory structure through this file.
+
+148
+00:12:33,000 --> 00:12:39,000
+By controlling what you reveal through robots.txt, you help protect sensitive areas of your system
+
+149
+00:12:39,000 --> 00:12:41,000
+from prying eyes.
+
+150
+00:12:42,000 --> 00:12:49,000
+Another important practice is the removal of unnecessary information from HTTP response headers.
+
+151
+00:12:49,000 --> 00:12:52,000
+When a server responds to an HTTP request.
+
+152
+00:12:52,000 --> 00:12:59,000
+The headers often include details such as the operating system, web server, version, and application
+
+153
+00:12:59,000 --> 00:13:00,000
+framework.
+
+154
+00:13:00,000 --> 00:13:06,000
+This information can be valuable to an attacker because it helps them identify which vulnerabilities
+
+155
+00:13:06,000 --> 00:13:08,000
+are relevant to your system.
+
+156
+00:13:09,000 --> 00:13:15,000
+For example, knowing the exact version of the web server could allow an attacker to exploit a known
+
+157
+00:13:15,000 --> 00:13:18,000
+vulnerability that exists in that version.
+
+158
+00:13:18,000 --> 00:13:23,000
+By stripping this information from the headers, you make it much harder for attackers to gather the
+
+159
+00:13:23,000 --> 00:13:26,000
+details they need to plan their attacks.
+
+160
+00:13:26,000 --> 00:13:32,000
+The less information you expose, the more difficult it is for attackers to find weak points in your
+
+161
+00:13:32,000 --> 00:13:33,000
+system.
+
+162
+00:13:34,000 --> 00:13:40,000
+Finally, defining and limiting supported HTTP methods is a key part of ensuring that your application
+
+163
+00:13:40,000 --> 00:13:45,000
+only responds to the methods that are absolutely necessary.
+
+164
+00:13:46,000 --> 00:13:54,000
+HTTP methods like Get and post are commonly used in web Applications, but others such as delete or
+
+165
+00:13:54,000 --> 00:13:57,000
+patch are only needed in specific cases.
+
+166
+00:13:57,000 --> 00:14:04,000
+If you don't explicitly define which methods are allowed, attackers can attempt to use unsafe methods
+
+167
+00:14:04,000 --> 00:14:08,000
+such as trace or connect to exploit your system.
+
+168
+00:14:09,000 --> 00:14:15,000
+For example, an attacker might use the delete method to remove crucial files or use trace to steal
+
+169
+00:14:15,000 --> 00:14:17,000
+cookies via cross-site scripting.
+
+170
+00:14:17,000 --> 00:14:25,000
+By clearly defining which HTTP methods are supported and limiting them to specific use cases, you minimize
+
+171
+00:14:25,000 --> 00:14:30,000
+the risk of attackers interacting with your system in unintended and harmful ways.
+
+172
+00:14:32,000 --> 00:14:38,000
+Let's dive deeper into each of these low relevance but essential practices for hardening system configurations,
+
+173
+00:14:38,000 --> 00:14:42,000
+which focus on addressing edge cases and refining system security.
+
+174
+00:14:43,000 --> 00:14:54,000
+First, consider the configuration of both HTTP 1.0 and 1.1, Even though HTTP 1.1 is widely used in
+
+175
+00:14:54,000 --> 00:15:02,000
+modern systems, some environments or legacy applications still rely on HTTP 1.0.
+
+176
+00:15:02,000 --> 00:15:08,000
+The difference between these versions, particularly in how they handle extended HTTP methods and caching,
+
+177
+00:15:08,000 --> 00:15:12,000
+can introduce inconsistencies or security risks if not properly managed.
+
+178
+00:15:13,000 --> 00:15:20,000
+For example, HTTP 1.0 lacks certain optimizations present in 1.1, such as persistent connections,
+
+179
+00:15:20,000 --> 00:15:24,000
+and handles caching differently without properly configuring both versions.
+
+180
+00:15:24,000 --> 00:15:31,000
+An attacker could exploit these differences to bypass security controls or access cached data that wasn't
+
+181
+00:15:31,000 --> 00:15:32,000
+intended to be accessible.
+
+182
+00:15:33,000 --> 00:15:39,000
+Ensuring that both protocols are aligned helps prevent these risks and maintains uniform security standards
+
+183
+00:15:39,000 --> 00:15:41,000
+across versions.
+
+184
+00:15:41,000 --> 00:15:49,000
+Next, let's talk about the importance of outputting security configurations in a human readable format.
+
+185
+00:15:49,000 --> 00:15:55,000
+Security configurations often become complex, especially in larger systems, and are typically stored
+
+186
+00:15:55,000 --> 00:15:59,000
+in formats that are difficult for humans to quickly parse and review.
+
+187
+00:16:00,000 --> 00:16:06,000
+This complexity can make it challenging for administrators to effectively audit and verify that security
+
+188
+00:16:06,000 --> 00:16:09,000
+settings are applied correctly.
+
+189
+00:16:09,000 --> 00:16:15,000
+By enabling the system to generate human readable security configuration outputs, you make it much
+
+190
+00:16:15,000 --> 00:16:19,000
+easier to spot inconsistencies or mistakes during audits.
+
+191
+00:16:20,000 --> 00:16:27,000
+For example, misconfigurations like leaving open ports or incorrect firewall rules are much easier
+
+192
+00:16:27,000 --> 00:16:31,000
+to catch when presented in a clear, organized manner.
+
+193
+00:16:32,000 --> 00:16:39,000
+This practice helps reduce human error and improves the ability to regularly review and update security
+
+194
+00:16:39,000 --> 00:16:40,000
+configurations.
+
+195
+00:16:41,000 --> 00:16:45,000
+Next is the implementation of an asset management system.
+
+196
+00:16:46,000 --> 00:16:51,000
+Tracking every piece of hardware and software in a the system is critical to maintaining security.
+
+197
+00:16:51,000 --> 00:16:57,000
+Without an asset management system, it becomes easy to lose track of outdated or unsupported software,
+
+198
+00:16:57,000 --> 00:17:00,000
+leading to potential vulnerabilities.
+
+199
+00:17:00,000 --> 00:17:06,000
+For example, an unregistered server might be running outdated software that has not been patched,
+
+200
+00:17:06,000 --> 00:17:10,000
+leaving the system exposed to known vulnerabilities.
+
+201
+00:17:10,000 --> 00:17:15,000
+An asset management system provides an organized and up to date inventory of all components, allowing
+
+202
+00:17:15,000 --> 00:17:19,000
+administrators to ensure everything is maintained and secure.
+
+203
+00:17:19,000 --> 00:17:25,000
+This visibility into the infrastructure helps prevent the use of unpatched or deprecated components,
+
+204
+00:17:25,000 --> 00:17:27,000
+thereby reducing the attack surface.
+
+205
+00:17:28,000 --> 00:17:34,000
+Finally, there is the software change control system, which is essential for managing and documenting
+
+206
+00:17:34,000 --> 00:17:37,000
+changes in both development and production environments.
+
+207
+00:17:38,000 --> 00:17:40,000
+In any system, changes are inevitable.
+
+208
+00:17:40,000 --> 00:17:45,000
+New features are added, bugs are fixed, and configurations are updated.
+
+209
+00:17:46,000 --> 00:17:49,000
+However, without a proper change control system.
+
+210
+00:17:49,000 --> 00:17:52,000
+Unauthorized or undocumented changes can.
+
+211
+00:17:52,000 --> 00:17:57,000
+Slip into production, introducing new vulnerabilities or causing misconfigurations.
+
+212
+00:17:58,000 --> 00:18:03,000
+For instance, a developer might make a configuration change in production without properly documenting
+
+213
+00:18:03,000 --> 00:18:11,000
+it, and that change could lead to a security weakness that goes unnoticed by using a version control
+
+214
+00:18:11,000 --> 00:18:13,000
+system or a formal change management process.
+
+215
+00:18:13,000 --> 00:18:18,000
+Every change is tracked, reviewed, and approved before being deployed.
+
+216
+00:18:18,000 --> 00:18:26,000
+This creates accountability, ensures that changes are thoroughly tested, and reduces the risk of unintentional
+
+217
+00:18:26,000 --> 00:18:27,000
+security gaps.
+
+218
+00:18:28,000 --> 00:18:35,000
+In conclusion, hardening system configurations is an essential practice for reducing the attack surface
+
+219
+00:18:35,000 --> 00:18:38,000
+and enhancing the security of any system.
+
+220
+00:18:39,000 --> 00:18:45,000
+Let's break down the key takeaways from this list, starting with high relevance practices that focus
+
+221
+00:18:45,000 --> 00:18:47,000
+on mitigating critical threats.
+
+222
+00:18:47,000 --> 00:18:55,000
+First, restricting access to the least privileges necessary ensures that users, services and processes
+
+223
+00:18:55,000 --> 00:19:02,000
+only have access to what they absolutely need, minimizing the risk of privilege escalation if an account
+
+224
+00:19:02,000 --> 00:19:03,000
+is compromised.
+
+225
+00:19:03,000 --> 00:19:09,000
+Secure failure handling is equally important because when exceptions occur, we must ensure that no
+
+226
+00:19:09,000 --> 00:19:13,000
+sensitive information is leaked and systems remain in a safe state.
+
+227
+00:19:13,000 --> 00:19:19,000
+Removing unnecessary functionality, applying all patches, and keeping systems up to date are core
+
+228
+00:19:19,000 --> 00:19:24,000
+defensive measures to close known vulnerabilities that attackers often exploit.
+
+229
+00:19:24,000 --> 00:19:32,000
+Additionally, the removal of test code and isolation of development environments from production systems
+
+230
+00:19:32,000 --> 00:19:39,000
+prevent exposure of non-production elements that could be exploited when we move to moderate relevance
+
+231
+00:19:39,000 --> 00:19:40,000
+practices.
+
+232
+00:19:40,000 --> 00:19:46,000
+These tackle common security concerns, disabling unnecessary HTTP methods.
+
+233
+00:19:46,000 --> 00:19:53,000
+Deactivating directory listings and removing sensitive information from HTTP headers are all practical
+
+234
+00:19:53,000 --> 00:20:00,000
+steps to reduce what attackers can see or use to map out potential vulnerabilities in your system.
+
+235
+00:20:00,000 --> 00:20:07,000
+These methods effectively limit the amount of information or functionality that attackers can manipulate.
+
+236
+00:20:08,000 --> 00:20:15,000
+Also, ensuring directory structure privacy through proper management of the robots.txt file is critical
+
+237
+00:20:15,000 --> 00:20:19,000
+to keeping sensitive parts of the system hidden from prying eyes.
+
+238
+00:20:20,000 --> 00:20:27,000
+By clearly defining which HTTP methods are allowed, such as get or post, and limiting them only to
+
+239
+00:20:27,000 --> 00:20:32,000
+what is required, we ensure a more controlled interaction with the application.
+
+240
+00:20:33,000 --> 00:20:40,000
+Finally, low relevance practices, though seemingly minor, still play a critical role in securing
+
+241
+00:20:40,000 --> 00:20:41,000
+the system's foundation.
+
+242
+00:20:42,000 --> 00:20:52,000
+Configuring HTTP 1.0 and 1.1 to handle methods similarly avoids inconsistencies that could lead to vulnerabilities.
+
+243
+00:20:52,000 --> 00:20:59,000
+Additionally, generating human readable security configuration outputs simplifies auditing and helps
+
+244
+00:20:59,000 --> 00:21:03,000
+administrators identify Misconfigurations more easily.
+
+245
+00:21:04,000 --> 00:21:11,000
+Implementing an asset management system ensures all system components are registered and tracked, reducing
+
+246
+00:21:11,000 --> 00:21:15,000
+the chance that outdated or vulnerable software is missed.
+
+247
+00:21:16,000 --> 00:21:23,000
+Similarly, a software change control system helps document and manage code changes, ensuring accountability
+
+248
+00:21:23,000 --> 00:21:28,000
+and that no undocumented changes are introduced into the production environment.
+
+249
+00:21:29,000 --> 00:21:32,000
+That's all what I wanted to discuss with you in this lesson.
+
+250
+00:21:32,000 --> 00:21:35,000
+Let's recap what we have learned from the lesson.
+
+251
+00:21:36,000 --> 00:21:42,000
+We learned how to limit system access by restricting service accounts and processes to the least privileges
+
+252
+00:21:42,000 --> 00:21:43,000
+necessary.
+
+253
+00:21:43,000 --> 00:21:51,000
+We discussed secure failure handling and how to ensure the system remains safe even when errors occur.
+
+254
+00:21:51,000 --> 00:21:57,000
+We explored the importance of removing unnecessary functionality files and test code from production
+
+255
+00:21:57,000 --> 00:22:00,000
+environments to reduce the attack surface.
+
+256
+00:22:00,000 --> 00:22:06,000
+You now understand the need for keeping servers, frameworks and components updated and how to ensure
+
+257
+00:22:06,000 --> 00:22:08,000
+patches are consistently applied.
+
+258
+00:22:09,000 --> 00:22:14,000
+We reviewed best practices for isolating development environments from production to protect sensitive
+
+259
+00:22:14,000 --> 00:22:14,000
+data.
+
+260
+00:22:14,000 --> 00:22:21,000
+I demonstrated how to disable unnecessary HTTP methods to hide sensitive information in HTTP headers,
+
+261
+00:22:21,000 --> 00:22:26,000
+and deactivate directory listings to prevent unwanted exposure.
+
+262
+00:22:26,000 --> 00:22:32,000
+Lastly, we covered the importance of asset management systems and change control processes for maintaining
+
+263
+00:22:32,000 --> 00:22:35,000
+a secure and well documented infrastructure.
+
+264
+00:22:36,000 --> 00:22:38,000
+That's all for this lesson.
+
+265
+00:22:38,000 --> 00:22:40,000
+Thanks a lot for your attention.
+
+266
+00:22:40,000 --> 00:22:43,000
+Have a great day and see you in the next lesson.
+