1
00:00:10,150 --> 00:00:17,050
Let us conclude our Web application section by having a look on the Web application countermeasures

2
00:00:17,050 --> 00:00:20,080
that how you should prevent such attacks.

3
00:00:21,100 --> 00:00:29,350
Let us see the force that is broken authentication and session management for this use SSL that is sigatoka

4
00:00:29,410 --> 00:00:35,980
clear for authenticated, a part of the application verify whether all the user's identities and credentials

5
00:00:35,980 --> 00:00:39,550
are stored in hashed form that is used hashing and cryptography.

6
00:00:39,930 --> 00:00:45,150
I never submit session data is a part of it or both requests never do that.

7
00:00:45,610 --> 00:00:52,420
The next is XML entity that is a word processing XML input containing a reference to the external entity.

8
00:00:52,870 --> 00:01:00,190
Then XML unmarred should be configured securely past the document with the securely configured parser.

9
00:01:00,760 --> 00:01:08,170
Next, sensitive data exposure do not create or use weak cryptographic algorithms as they may result

10
00:01:08,170 --> 00:01:15,280
in sensitive data exposure, then generate encryption keys off-line and store them securely and ensure

11
00:01:15,280 --> 00:01:21,730
that the encrypted data are stored on the disk is not easy to decrypt and therefore brute force attacks

12
00:01:21,730 --> 00:01:23,500
won't work in this case.

13
00:01:24,110 --> 00:01:31,510
The next is broken access control that is busy now perform access control checks before redirecting

14
00:01:31,510 --> 00:01:37,480
the authorized user to request a resource check whether it is only legitimate user who is trying to

15
00:01:37,480 --> 00:01:44,890
access the user requested resource avoid using insecure items to prevent a tiger from getting it, then

16
00:01:44,890 --> 00:01:46,900
provides session timeout mechanism.

17
00:01:46,900 --> 00:01:55,180
If a user is not active for, let's say, 30 to 40 seconds, you can adjust a timeout decision and log

18
00:01:55,180 --> 00:02:01,960
out the user forcefully and then limit the permissions to authorized users from misuse.

19
00:02:04,050 --> 00:02:09,720
The next is how you can prevent a scale injection attacks limit the length of the user input, as we

20
00:02:09,720 --> 00:02:18,660
have seen, that if you change the input from 10 to 15 or 100 and then only user can input a string

21
00:02:18,660 --> 00:02:25,080
or a big function, but if you limit that only or as attacks can be prevented, then use custom error

22
00:02:25,080 --> 00:02:31,980
messages, do not disclose any information through errors, just give an error that that's a error that

23
00:02:32,400 --> 00:02:38,820
you do not have to display anything else, then monitor database traffic using ideas, firewalls and

24
00:02:39,150 --> 00:02:43,500
other application firewalls, disable commands like expectation.

25
00:02:43,920 --> 00:02:49,490
If you want to read more about this, you can always go to the books that you have attached for Web

26
00:02:49,500 --> 00:02:54,780
application resources, then isolate a database server and a web server also.

27
00:02:55,110 --> 00:03:01,380
And the next is filing a tax that is file upload, strongly worded user input.

28
00:03:01,650 --> 00:03:06,060
Consider implementing a jail route, then disable a love.

29
00:03:06,060 --> 00:03:10,680
You are left open and allow your URL in BHP, not Ironi.

30
00:03:10,680 --> 00:03:16,110
We have seen this while installing the Linux in time when the of application.

31
00:03:16,110 --> 00:03:21,810
If you do not recall, please go to that lecture in Section two, setting up the penetration testing

32
00:03:21,810 --> 00:03:26,760
lab, then ensure that all files and streams functions are carefully vetted.

33
00:03:27,270 --> 00:03:30,960
Do not allow any random file to be inputted.

34
00:03:31,560 --> 00:03:38,250
The next is command injection flows, perform again input validation, escape dangerous characters.

35
00:03:40,130 --> 00:03:46,190
Use language specific libraries that avoid problems due to shell commands, perform input and output

36
00:03:46,190 --> 00:03:51,740
encoding, and use a safe API which avoids the use of interpretor entirely.

37
00:03:52,370 --> 00:03:56,060
Then the next is using components with known vulnerabilities.

38
00:03:56,060 --> 00:04:03,250
How you can avoid that you can avoid by regularly checking the versions of both client side and so rules

39
00:04:03,260 --> 00:04:09,710
or components and their dependencies then continuously monitor sources like National Vulnerability Database

40
00:04:09,950 --> 00:04:16,430
for vulnerabilities in your components, apply security patches, regularly scan the components with

41
00:04:16,430 --> 00:04:23,660
security scanners, frequently enforce security policies and best practices for component use.

42
00:04:24,590 --> 00:04:32,390
And the second last is cross site request forgery attack here log of immediately after using our application

43
00:04:32,390 --> 00:04:33,650
and clear the history.

44
00:04:33,950 --> 00:04:39,800
We have seen that if you log off and if you delete all the data after the user has created the browser,

45
00:04:40,220 --> 00:04:43,310
attackers cannot use the site of attack.

46
00:04:43,620 --> 00:04:49,430
Then do not allow your browser and websites to save login details, which is a bad practice, and also

47
00:04:49,430 --> 00:04:53,690
check the header of processing a post.

48
00:04:53,840 --> 00:04:55,190
Another type of request.

49
00:04:55,190 --> 00:05:02,300
And the last and important is kookier parameter time, putting the not stored plaintext or weakly encrypted

50
00:05:02,300 --> 00:05:06,260
passwords in a cookie that is not allowed and that is always a bad practice.

51
00:05:06,620 --> 00:05:07,700
Implement cookies.

52
00:05:07,700 --> 00:05:08,390
Timeout.

53
00:05:08,780 --> 00:05:09,170
Let's see.

54
00:05:09,170 --> 00:05:15,150
After four to five days, if a user hasn't visited the website, you can delete the cookie and whenever

55
00:05:15,150 --> 00:05:21,140
a user tries to log in again, you can ask for more security questions to ensure that the same user

56
00:05:21,140 --> 00:05:25,010
is logging and finally make logged functions available.

57
00:05:25,820 --> 00:05:33,450
Insist the user to log out before closing a browser and using all this with the application attacks

58
00:05:33,590 --> 00:05:34,670
can be prevented.

59
00:05:34,970 --> 00:05:42,560
Uh, so in the next section onwards we are going to start the DENIAL-OF-SERVICE section that is the

60
00:05:42,560 --> 00:05:43,070
DOS.