Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
0
1
00:00:01,030 --> 00:00:02,060
Hello everyone.
1
2
00:00:02,080 --> 00:00:09,780
So let's continue to the third vulnerability of OWASP that is sensitive data exposure.
2
3
00:00:09,910 --> 00:00:18,760
So what is SDE when any application or API do not protect sensitive data properly like for example
3
4
00:00:18,820 --> 00:00:27,410
user Account details, Credit card details or Passwords etc. Then SDE Vulnerability arises.
4
5
00:00:27,640 --> 00:00:36,630
Also if an attacker can view this sensitive data and get access to the internal network also git hub
5
6
00:00:36,630 --> 00:00:46,050
tokens and API keys which had been leaked on to the Internet can also lead to sensitive data exposure.
6
7
00:00:46,050 --> 00:00:53,580
A very good example to this is a Snapchat report which was submitted by a security researcher on Hackerone
7
8
00:00:53,580 --> 00:01:01,800
wherein he was able to find out a token which was indexed by Google and that token was into GitHub.
8
9
00:01:02,370 --> 00:01:11,640
So he reported that token and he got 15,000$ of bounty basically reward for that specific
9
10
00:01:11,640 --> 00:01:12,380
bug.
10
11
00:01:12,390 --> 00:01:20,980
So SDE can be very critical and dangerous also sensitive invoices which are indexed by Google.
11
12
00:01:20,980 --> 00:01:30,010
There was again a vulnerability by paypal in which the users invoices were indexed by the Google crawlers
12
13
00:01:30,310 --> 00:01:34,960
and by hitting a right Google dork onto the Internet.
13
14
00:01:35,380 --> 00:01:41,150
Attackers or security researchers were able to identify those invoices.
14
15
00:01:41,170 --> 00:01:43,990
This was also reported to people and it was fixed
15
16
00:01:46,610 --> 00:01:54,170
and insecure storage of data also leads to sensitive data exposure which means if any website or owner
16
17
00:01:54,560 --> 00:02:02,780
is storing some of the important critical files for example db.conf which contains database credentials
17
18
00:02:03,200 --> 00:02:12,680
or login passwords.txt which contains the credentials into its server any user can try to get those
18
19
00:02:12,680 --> 00:02:23,860
files using a directory brute force so why SDE happens?
No proper access control over when exchange
19
20
00:02:24,490 --> 00:02:26,310
of sensitive data occurs.
20
21
00:02:26,350 --> 00:02:34,330
There should be proper access controls. Second APIs are not properly protected unauthenticated API which
21
22
00:02:34,390 --> 00:02:42,910
anyone can call for any user also lead to SDE lack of robots.txt file which is very
22
23
00:02:42,910 --> 00:02:51,490
important as I gave the example of paypal wherein the crawler of Google(Google crawler) was able to crawl
23
24
00:02:51,790 --> 00:02:53,100
the invoices.
24
25
00:02:53,100 --> 00:02:53,460
Okay.
25
26
00:02:53,680 --> 00:03:00,520
So robots.txt is a file in which we can write a set of rules which will tell those crawlers
26
27
00:03:00,670 --> 00:03:08,800
what can be crawled from the website website and what cannot be called so lack of data strip when
27
28
00:03:08,800 --> 00:03:15,680
saving at sever is also what can happen because of SDE
28
29
00:03:19,300 --> 00:03:26,560
what can be achieved by sensitivity exposure sensitive information of user as we all know which can
29
30
00:03:26,560 --> 00:03:37,660
also be transaction details passwords etc. APAC api keys which can also be achieved by sensitive data
30
31
00:03:37,670 --> 00:03:38,540
exposure.
31
32
00:03:38,660 --> 00:03:39,920
These types of keys.
32
33
00:03:39,920 --> 00:03:49,330
Generally developers make mistakes and leave these types of keys and tokens into their github repositories.
33
34
00:03:49,610 --> 00:03:58,280
Attackers can also get the tokens of internal portals which are only accessible to domain admins sensitive
34
35
00:03:58,280 --> 00:04:04,360
information like passwords SSL keys a key anything that is sensitive.
35
36
00:04:04,380 --> 00:04:11,220
If you get it falls under the category of sensitivity to exposure which can be misused further by an
36
37
00:04:11,310 --> 00:04:13,650
attacker.
37
38
00:04:13,650 --> 00:04:17,740
So how do we fix sensitive data exposure issues.
38
39
00:04:17,760 --> 00:04:24,070
The first step is don't store sensitive data unnecessary next.
39
40
00:04:24,120 --> 00:04:27,150
Make sure to encrypt all the sensitive data at rest.
40
41
00:04:27,780 --> 00:04:34,950
If you are having any sensitive data at your server just make sure you encrypt everything with a strong
41
42
00:04:34,950 --> 00:04:43,260
corruption and a private key disable caching responses that have sensitive data so disable any application
42
43
00:04:43,260 --> 00:04:51,840
caching any types of responses into their browsers do not put any keys tokens in GitHub or anywhere
43
44
00:04:51,900 --> 00:05:01,400
in the server implement access control for users so a functionality known as make the checker.
44
45
00:05:01,400 --> 00:05:09,830
This is a functionality which is generally used in banks where the maker is the person with low privileges
45
46
00:05:10,130 --> 00:05:13,650
and checker is the person with high privileges.
46
47
00:05:13,790 --> 00:05:20,600
So if the maker is able to bypass those privileges and is able to get the privileges of the checker
47
48
00:05:20,960 --> 00:05:28,400
which means the higher privileges bypassing this access control can also lead to sensitive data exposure
48
49
00:05:28,610 --> 00:05:29,810
issues.
49
50
00:05:29,810 --> 00:05:30,320
Thank you.
5828
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.