WEBVTT - This file was automatically generated by VIMEO 1 00:00:08.300 --> 00:00:11.700 Hello, everyone. Welcome back. We have expressed as 2 00:00:11.700 --> 00:00:14.500 for how do we secure certain positions across web 3 00:00:14.900 --> 00:00:18.100 and visits of network security. Now, 4 00:00:17.100 --> 00:00:20.700 let's take a look at additional best practices 5 00:00:20.900 --> 00:00:23.600 that can be incorporated in order to strengthen the 6 00:00:23.600 --> 00:00:26.000 security posture. First thing that I 7 00:00:26.100 --> 00:00:29.400 would like to talk about is segregating the authentication and 8 00:00:29.400 --> 00:00:29.900 authorization. 9 00:00:30.200 --> 00:00:33.800 And application. Typically the way of application behaves 10 00:00:33.800 --> 00:00:36.400 is that once a user logs in, 11 00:00:36.800 --> 00:00:39.700 we generate a session ID that is being passport application for 12 00:00:39.700 --> 00:00:40.600 all the actions. 13 00:00:41.900 --> 00:00:44.700 The approach would be to create a nuanced token 14 00:00:44.900 --> 00:00:47.500 that is generated using all 15 00:00:47.500 --> 00:00:50.000 the security requirements, the way we 16 00:00:50.300 --> 00:00:53.600 generate a session ID and that whatever token is 17 00:00:53.600 --> 00:00:56.500 used for all sensitive actions. For example, may 18 00:00:56.500 --> 00:00:59.600 be updating a profile password or 19 00:00:59.700 --> 00:01:02.200 maybe transferring money depending on 20 00:01:02.200 --> 00:01:05.300 the application requirement. If we can segregate the 21 00:01:05.300 --> 00:01:08.100 sensitive actions performed by the user and we 22 00:01:08.100 --> 00:01:11.500 use the oauth token to actually authorize 23 00:01:12.200 --> 00:01:16.000 And see if that is being generated in a timely fashion and 24 00:01:15.400 --> 00:01:19.100 meeting all the access requirements. That 25 00:01:18.100 --> 00:01:21.200 way we can add an additional layer 26 00:01:21.200 --> 00:01:24.800 of security. We have seen a crack such as brute 27 00:01:24.800 --> 00:01:27.300 force or session fixation, which 28 00:01:27.300 --> 00:01:30.200 lack session management reason being, 29 00:01:30.200 --> 00:01:33.400 is that the way the session management was 30 00:01:33.400 --> 00:01:36.500 implemented is from the developer point 31 00:01:36.500 --> 00:01:36.900 of view. 32 00:01:38.100 --> 00:01:41.600 They themselves to the ownership of creating the session 33 00:01:41.400 --> 00:01:44.300 maintaining the session and purging the 34 00:01:44.300 --> 00:01:44.800 session. 35 00:01:46.100 --> 00:01:50.400 It would be a smart way to develop an application using 36 00:01:49.400 --> 00:01:53.400 their own inbuilt session management. For 37 00:01:53.400 --> 00:01:56.900 example, all the big Frameworks such as Java 38 00:01:56.900 --> 00:01:59.200 PHP and dotnet Technologies. They 39 00:01:59.200 --> 00:02:02.100 have their own built-in session Management in 40 00:02:02.100 --> 00:02:05.700 that way. We don't need to worry about how 41 00:02:05.700 --> 00:02:08.200 do we create a session ID if the 42 00:02:08.200 --> 00:02:11.300 secure enough or not? All these Technologies do 43 00:02:11.300 --> 00:02:14.600 for industry standards, for example, the to generate 44 00:02:14.600 --> 00:02:15.000 along. 45 00:02:15.200 --> 00:02:18.400 A string for a session ID that are quite random in 46 00:02:18.400 --> 00:02:22.400 nature at the same time. They also ensure 47 00:02:21.400 --> 00:02:25.400 how the data is being transmitted and 48 00:02:24.700 --> 00:02:27.800 a daring to all the such as management principles. 49 00:02:27.400 --> 00:02:30.500 The next thing that I want to talk about is 50 00:02:30.500 --> 00:02:33.400 the US forces accepted mechanism. All 51 00:02:33.400 --> 00:02:36.700 example, if we do understand that a 52 00:02:36.700 --> 00:02:39.400 session ID has to be passed to 53 00:02:39.400 --> 00:02:43.200 the application, which is consumed by the server is 54 00:02:43.200 --> 00:02:45.000 through a for certain way. 55 00:02:45.200 --> 00:02:48.400 Example, either to the cookie. So, 56 00:02:48.400 --> 00:02:51.400 in that way, if an attacker is trying to inject the 57 00:02:51.400 --> 00:02:55.000 same session ID. So other variations 58 00:02:54.300 --> 00:02:57.300 such as through the URL or any other form 59 00:02:57.300 --> 00:03:00.200 factor, I should not be accepted. So 60 00:03:00.200 --> 00:03:03.400 ask a developer. They need to ensure that how 61 00:03:03.400 --> 00:03:06.300 are they actually in cop between these 62 00:03:06.300 --> 00:03:09.100 sensory information such as such an ID in terms 63 00:03:09.100 --> 00:03:12.300 of consuming Roth indication and authorization. 64 00:03:13.300 --> 00:03:16.400 One of the thing which is quite important on all other 65 00:03:16.400 --> 00:03:19.600 application is that to ensure that we 66 00:03:19.600 --> 00:03:22.600 encourage our users log out. Reason 67 00:03:22.600 --> 00:03:25.800 being is that as long as a session is 68 00:03:25.800 --> 00:03:29.000 active, that's where it creates in value. The 69 00:03:28.500 --> 00:03:31.600 example that we spoke about where 70 00:03:31.600 --> 00:03:34.700 social media applications do require session 71 00:03:34.700 --> 00:03:36.700 to be maintained or longer period of time. 72 00:03:37.900 --> 00:03:40.800 Those scenarios. Most of the users would 73 00:03:40.800 --> 00:03:43.800 actually just terminate the browser and 74 00:03:43.800 --> 00:03:46.500 actually just access application. The next time 75 00:03:46.900 --> 00:03:48.400 and the session will be persisted. 76 00:03:49.500 --> 00:03:52.700 But in case, if the u.s. I encouraged log 77 00:03:52.700 --> 00:03:55.700 out, it would not really matter because 78 00:03:55.900 --> 00:03:58.600 the session would be pushed. We 79 00:03:58.600 --> 00:04:01.300 don't need to take additional precaution that an 80 00:04:01.300 --> 00:04:05.300 additional layer of validation happens on the server side stating 81 00:04:04.500 --> 00:04:07.000 that since the user performed, a 82 00:04:07.100 --> 00:04:10.600 law, Court action, that particular session, ID value no 83 00:04:10.600 --> 00:04:12.100 longer persist. 84 00:04:13.200 --> 00:04:16.100 This is one other common security perspective is 85 00:04:16.100 --> 00:04:18.700 that we should encourage the users to do so. 86 00:04:20.100 --> 00:04:23.400 One of the recent Technologies is HTML5 and 87 00:04:23.400 --> 00:04:26.600 these particular technology actually store 88 00:04:26.600 --> 00:04:27.900 the information. 89 00:04:29.400 --> 00:04:32.200 So there are certain apis that are 90 00:04:32.200 --> 00:04:35.300 capable enough from the HTML technology point 91 00:04:35.300 --> 00:04:39.300 of view which actually store information 92 00:04:38.200 --> 00:04:42.300 in the local storage and 93 00:04:41.400 --> 00:04:45.000 that could be either information leakage or 94 00:04:44.400 --> 00:04:47.400 other applications accessing 95 00:04:47.400 --> 00:04:50.600 the shared system. So we need to ensure 96 00:04:50.600 --> 00:04:53.600 that proper security mechanisms are implemented while 97 00:04:53.600 --> 00:04:54.800 using HTML5. 98 00:04:55.900 --> 00:04:58.300 The next thing would be when shot that is 99 00:04:58.300 --> 00:05:01.200 such an IDs are also treated as user input. 100 00:05:02.300 --> 00:05:05.600 What you mean by that? Is that unlike any user 101 00:05:05.600 --> 00:05:08.300 input that is being fed to the system, either through 102 00:05:08.300 --> 00:05:11.700 of form or to DPI. We do ensure that 103 00:05:11.700 --> 00:05:15.300 all the common web attacks are terminated either 104 00:05:14.500 --> 00:05:17.400 for cross-site scripting or SQL 105 00:05:17.400 --> 00:05:20.800 injection or in is impeccable attack. So, 106 00:05:20.800 --> 00:05:23.400 similarly, you also need to ensure that even 107 00:05:23.400 --> 00:05:26.500 the session ID value also doesn't 108 00:05:26.500 --> 00:05:30.000 contain any invalid character that 109 00:05:29.200 --> 00:05:31.200 can break the application. 110 00:05:32.300 --> 00:05:35.600 Maybe give away to a new one ability. 111 00:05:35.300 --> 00:05:38.900 So just to reiterate, 112 00:05:38.400 --> 00:05:41.200 this is it to sanitize all 113 00:05:41.200 --> 00:05:45.000 the values that are being consumed by the application, starting 114 00:05:44.100 --> 00:05:47.200 from the user input through the 115 00:05:47.200 --> 00:05:49.300 session IDs that can be tampered. 116 00:05:50.300 --> 00:05:53.300 One of the use case you want to talk about is 117 00:05:53.500 --> 00:05:54.900 the complex applications. 118 00:05:55.800 --> 00:05:59.600 For example, in an ecosystem, a person 119 00:05:59.600 --> 00:06:02.200 is trying to perform a single 120 00:06:02.200 --> 00:06:05.900 sign-on and that particular user is also capable 121 00:06:05.900 --> 00:06:08.600 enough to access multiple 122 00:06:08.600 --> 00:06:13.000 applications under the same industry. So 123 00:06:11.500 --> 00:06:14.900 we need to be cognizant 124 00:06:14.900 --> 00:06:17.900 of the fact that while generating individual cookies 125 00:06:17.900 --> 00:06:21.300 for each application. How do 126 00:06:20.300 --> 00:06:23.600 we actually maintain the persistent 127 00:06:23.600 --> 00:06:25.300 for each one of those in terms of 128 00:06:25.800 --> 00:06:29.100 Jan and authentication, for example, the 129 00:06:29.100 --> 00:06:32.700 basics would be to ensure that both the cookies that 130 00:06:32.700 --> 00:06:35.900 are being used, should have a different nomenclature such 131 00:06:35.900 --> 00:06:38.500 that it doesn't happen where 132 00:06:38.200 --> 00:06:41.500 one of the application whose expiry 133 00:06:41.500 --> 00:06:44.600 time was in standard industry format 134 00:06:44.700 --> 00:06:47.700 and the second application being a social media, which 135 00:06:47.700 --> 00:06:50.500 had a long expiry date, but just because 136 00:06:50.500 --> 00:06:53.800 of the fact that both use the safety name and 137 00:06:53.800 --> 00:06:55.600 there were no additional cookie flag. 138 00:06:55.700 --> 00:06:58.400 That was set in terms to 139 00:06:58.400 --> 00:07:01.900 validate who can access then, that 140 00:07:01.900 --> 00:07:04.500 becomes a new thread where that particular key 141 00:07:04.500 --> 00:07:07.400 value is applicable throughout the 142 00:07:07.900 --> 00:07:10.100 multiple browser sessions. 143 00:07:11.400 --> 00:07:14.500 The next thing is something that we already spoke about saying 144 00:07:14.500 --> 00:07:17.500 that if we can segregate the 145 00:07:17.200 --> 00:07:20.300 authorization and authentication out of 146 00:07:20.300 --> 00:07:24.000 the application, we can add an additional layer of 147 00:07:23.200 --> 00:07:26.200 the authentication for 148 00:07:26.200 --> 00:07:29.100 critical actions. This could happen in terms of 149 00:07:29.100 --> 00:07:33.100 a multi-factor or it can happen where 150 00:07:32.100 --> 00:07:35.800 we actually. I was the user to 151 00:07:35.800 --> 00:07:38.600 re-login so that we can validate and 152 00:07:38.600 --> 00:07:39.900 provide one usage and ID. 153 00:07:41.200 --> 00:07:45.200 So while genetic session ID, we can also add additional factors 154 00:07:44.200 --> 00:07:48.100 such as Source IP or username agent 155 00:07:47.300 --> 00:07:50.700 to bind in such a way that 156 00:07:50.700 --> 00:07:53.700 we can uniquely identify from where a person is 157 00:07:53.700 --> 00:07:56.200 logging from. In that way. If 158 00:07:56.200 --> 00:07:59.600 that's a requirement, where we want to avoid multiple 159 00:07:59.600 --> 00:08:03.100 session ID is being generated the other parameter and 160 00:08:02.100 --> 00:08:05.500 of actually always help to 161 00:08:05.500 --> 00:08:07.800 differentiate between simultaneous access. 162 00:08:09.200 --> 00:08:11.100 Results for this video. Thank you.