1 00:00:00,300 --> 00:00:07,260 In the previous video, we looked into an error which is resulted from Crosseyed request for the issue, 2 00:00:07,530 --> 00:00:10,940 which is famously called as Casares in the industry. 3 00:00:11,220 --> 00:00:20,400 So CSR will come in any Web application whenever someone tries to make a board or delete such kind of 4 00:00:20,400 --> 00:00:28,770 operations, which will result in data change on the database by default, CSR issue will block your 5 00:00:28,770 --> 00:00:29,600 operations. 6 00:00:29,880 --> 00:00:37,140 It's nothing related to the cross origin, even if you are trying to perform the operations like your 7 00:00:37,150 --> 00:00:45,540 UI and back in the stay on the same post on board and domain still will get in to CSR issues. 8 00:00:45,690 --> 00:00:53,010 The reason is a typical cross site request forgery, which is CSR of attack, aims to perform an operation 9 00:00:53,010 --> 00:01:01,890 in a Web application on behalf of Lobban user without the explicit consent that many with the hackers 10 00:01:01,890 --> 00:01:04,000 can attack other users. 11 00:01:04,319 --> 00:01:13,260 Maybe you have taken enough measures not to steal their credentials, but CSR is one of the smartest 12 00:01:13,260 --> 00:01:17,030 approach where the attackers can exploit. 13 00:01:17,370 --> 00:01:19,160 If you don't handle it properly. 14 00:01:19,320 --> 00:01:27,210 So consider the scenario where we have it to website Netflix dot com and attack US websites and travel 15 00:01:27,210 --> 00:01:28,130 black dot com. 16 00:01:28,290 --> 00:01:33,210 So as a Netflix user, I can turn my credentials and I logged in. 17 00:01:33,660 --> 00:01:41,310 Now, in a hypothetical scenario, let's think about a scenario where Netflix is maintaining a cookie 18 00:01:41,310 --> 00:01:42,570 inside my browser. 19 00:01:42,810 --> 00:01:49,350 So as long as I'm inside the same browser and making any request for the request to the Netflix, it 20 00:01:49,350 --> 00:01:50,940 won't ask my credentials. 21 00:01:51,150 --> 00:01:55,230 It will just rely on the cookie to perform any operations on the back. 22 00:01:55,500 --> 00:02:02,820 So now I have a valid cookie present on the browser and now I'm navigating to the travel black dot com 23 00:02:03,010 --> 00:02:09,830 where attackers have a link which will change my password on Netflix dot com. 24 00:02:09,930 --> 00:02:12,840 So when attack attempt to click on the link. 25 00:02:12,990 --> 00:02:20,370 As soon as you click on the link, it will send a legal request to Netflix dot com to change the password. 26 00:02:20,550 --> 00:02:27,870 And since you already have a cookie inside your browser, Netflix dot com will accept and treat it as 27 00:02:27,870 --> 00:02:35,970 a valid cookie and change the password, which is a security exploit here to avoid the sort of attacks. 28 00:02:36,240 --> 00:02:41,370 There are many ways, but first of all, you can see here in the diagram, firstly, the user logged 29 00:02:41,370 --> 00:02:46,470 on into a proper website like Netflix dot com, and he has an active social networking site. 30 00:02:46,470 --> 00:02:52,980 His browser, not the same user, clicked on some malicious link, which is built by Hacker. 31 00:02:53,160 --> 00:03:01,320 And as soon as users click on the link, it will take the cookie inside your browser related to Netflix 32 00:03:01,320 --> 00:03:07,200 dot com and send a request to Netflix dot com to change the password and Netflix dot com. 33 00:03:07,200 --> 00:03:12,570 Treat it as a genuine request because the cookie value, the water token that you stored inside the 34 00:03:12,720 --> 00:03:16,540 cookie is given by Netflix itself during the first login. 35 00:03:16,860 --> 00:03:23,670 That's why even Netflix dot com also cannot identify whether the request is coming really from a valid 36 00:03:23,670 --> 00:03:25,020 user or from attack. 37 00:03:25,230 --> 00:03:32,510 You may say this may not be a possible if the user will not click on the link, but we can't control 38 00:03:32,700 --> 00:03:34,590 all those user activities. 39 00:03:34,770 --> 00:03:42,240 But what we can do to avoid this sort of attack inside our application is by maintaining its CSR. 40 00:03:42,960 --> 00:03:51,540 So CSR is a token which is issued by your backend application when the first communication happens from 41 00:03:51,540 --> 00:03:56,820 the user to Netflix dot com, like during the login of the user. 42 00:03:57,060 --> 00:04:01,050 So that token will never be stored into the browser. 43 00:04:01,060 --> 00:04:09,720 Share our browser cookies, but it will be given to the WHO are calling us application or browser. 44 00:04:10,080 --> 00:04:17,970 They have to make sure that they are passing the same token value whenever they try to want a communication 45 00:04:18,149 --> 00:04:18,870 with the back. 46 00:04:19,140 --> 00:04:27,570 So now my back end, though, I'm passing a valid security token letter to my login mechanism. 47 00:04:27,780 --> 00:04:31,080 But still it will expect me to pass it CSIR. 48 00:04:31,680 --> 00:04:39,600 If I don't have a sort of token valid one which pass, then it will block the communication using it 49 00:04:39,600 --> 00:04:42,210 for zero three for an error. 50 00:04:42,420 --> 00:04:49,020 So that means on top of your authentication token, which you are maintaining inside your cookie, we 51 00:04:49,020 --> 00:04:56,850 are also maintaining a sort of token that is tied to user session, but it is not submitted automatically 52 00:04:56,850 --> 00:04:57,900 like cookies. 53 00:04:57,900 --> 00:04:59,850 And you have to make major. 54 00:05:00,420 --> 00:05:06,570 To send that token every time when we are making a request to them back and so so now we have a clear 55 00:05:06,570 --> 00:05:14,850 idea of what sort of attack, let's try to see different ways of handling this or resolve this error 56 00:05:15,060 --> 00:05:16,290 in spring security. 57 00:05:16,560 --> 00:05:17,370 Thank you by.