1 00:00:05,410 --> 00:00:10,230 Welcome back, everyone, to this lecture on get some post requests as well as the SRF. 2 00:00:11,690 --> 00:00:17,060 We've already seen that HTP that is hypertext transfer protocol, is the foundation for the method of 3 00:00:17,060 --> 00:00:19,760 sending and receiving data over the worldwide web. 4 00:00:20,120 --> 00:00:26,060 You can also recall the HTP tips is simply an encrypted or secured version of HTTP. 5 00:00:27,380 --> 00:00:32,180 HDP itself defines a variety of methods for interactions over its protocol. 6 00:00:32,689 --> 00:00:38,060 And the key methods we need to understand are the get and post methods which you've already seen use 7 00:00:38,060 --> 00:00:41,540 in HTML forms, but we haven't really talked about the difference between the. 8 00:00:43,330 --> 00:00:50,260 Get is going to request data from a specified resource post, is going to request to send data to a 9 00:00:50,260 --> 00:00:52,750 server to create or update a resource. 10 00:00:54,020 --> 00:00:57,530 Now, you should note the tricky terminology that can sometimes be confusing. 11 00:00:57,950 --> 00:01:05,930 Technically speaking, both gets and post are HTP request methods, even though you commonly see written 12 00:01:05,930 --> 00:01:12,260 as an explanation of the difference between get and post as get requesting information and post as sending 13 00:01:12,260 --> 00:01:12,950 information. 14 00:01:13,400 --> 00:01:19,940 Technically speaking, they're both HDP requests, but we do typically think of get as asking for information 15 00:01:20,240 --> 00:01:25,190 and post as giving information to be saved or used by the actual website. 16 00:01:25,880 --> 00:01:31,340 So again, to clarify, we have get which is going to request data from a specified resource and post, 17 00:01:31,340 --> 00:01:33,920 which is going to also technically request. 18 00:01:34,190 --> 00:01:37,820 But it's really requesting to send data to a server essentially. 19 00:01:37,820 --> 00:01:41,870 Where are you going to get information or are you going to post information? 20 00:01:44,100 --> 00:01:46,200 So how does an HDP request work? 21 00:01:47,280 --> 00:01:53,130 Well, essentially, we need a way to communicate between the client and browser side and our back end 22 00:01:53,130 --> 00:01:54,750 website or web application. 23 00:01:56,030 --> 00:02:01,160 So this way is to send the request and then you get back some sort of response. 24 00:02:01,310 --> 00:02:06,530 And let's think of what a get request does it get is going to request data from a resource. 25 00:02:07,010 --> 00:02:11,990 So you send a get request and you should note this is the default form method. 26 00:02:12,350 --> 00:02:15,980 Once you create an HTML form, by default, it's going to send gets request. 27 00:02:17,020 --> 00:02:19,360 And this is going to request data from a resource. 28 00:02:19,570 --> 00:02:25,450 And this is actually done inside the URL, so you've actually seen this before back in HTML forms where 29 00:02:25,450 --> 00:02:29,200 we saw there was a key value pair that was attached to the URL. 30 00:02:29,410 --> 00:02:34,510 We saw a question mark and then we saw the key that is the name attached to that forms input. 31 00:02:34,840 --> 00:02:36,910 And then the value provided by the user. 32 00:02:38,380 --> 00:02:41,530 And then what happens is the website is going to give a response back. 33 00:02:41,770 --> 00:02:44,140 Maybe it redirects to a different web page. 34 00:02:45,980 --> 00:02:48,880 Just notice how, again, the get request is sent in the URL. 35 00:02:48,900 --> 00:02:53,670 This means a few things the get requested can actually be bookmarked and saved in history. 36 00:02:53,700 --> 00:02:55,170 It's essentially just a URL. 37 00:02:55,500 --> 00:03:01,890 So if I sent a get requests to reform, I could actually save that result as a URL in my history, which 38 00:03:01,890 --> 00:03:03,270 also means it can be cached. 39 00:03:03,540 --> 00:03:09,750 And it also means that it has length restrictions or limits, so the get requests can really only request 40 00:03:09,750 --> 00:03:10,110 data. 41 00:03:10,350 --> 00:03:13,650 It's not meant to modify or update anything on the website. 42 00:03:15,470 --> 00:03:20,570 But what if we want to send information for the specific purpose of updating some backend information 43 00:03:21,110 --> 00:03:21,960 in that case? 44 00:03:21,980 --> 00:03:25,130 We probably don't want that information inside a URL. 45 00:03:25,520 --> 00:03:31,370 And really, our main concern is no receiving of information back, but instead sending that information. 46 00:03:33,280 --> 00:03:39,340 So a post request is really similar, except this time, remember, the main purpose is to actually 47 00:03:39,550 --> 00:03:45,100 use the information inside the post request for an update that is, I want to post this information 48 00:03:45,340 --> 00:03:47,530 and probably change something on the back end. 49 00:03:47,890 --> 00:03:51,700 And because that's the case, I don't want to just send this information inside the URL. 50 00:03:52,150 --> 00:03:55,840 So this is actually sent inside the body message of the HTP. 51 00:03:56,170 --> 00:04:02,260 It looks a lot like a Python dictionary, and when you send a post request, you're no longer actually 52 00:04:02,260 --> 00:04:05,140 going to see that information inside the URL. 53 00:04:05,230 --> 00:04:10,690 Instead, it's within the actual message or body of the HDP request. 54 00:04:10,870 --> 00:04:14,290 It's not inside the URL, and you will get a response back. 55 00:04:15,890 --> 00:04:20,690 So essentially, what this says is when you send the post's request, you're actually passing on HTP 56 00:04:20,690 --> 00:04:25,880 message inside a body and says, Hey, use this key value, pair an update or post this information 57 00:04:25,880 --> 00:04:26,690 to the website. 58 00:04:28,390 --> 00:04:31,840 And we can see that HTML forms are actually quite readable by the browser. 59 00:04:32,110 --> 00:04:37,630 So we want to make sure that the HTML form on the page is being correctly used by the appropriate user. 60 00:04:38,200 --> 00:04:44,380 So now that we understand get versus a post request, we want to be able to think about the question 61 00:04:44,650 --> 00:04:48,460 could a malicious actor actually try to fake an HTML form? 62 00:04:48,730 --> 00:04:50,770 And what kind of issues is that present to us? 63 00:04:52,450 --> 00:04:59,380 Well, let's imagine this forgery attempt in step one, let's imagine that your bank has a website, 64 00:04:59,650 --> 00:05:04,600 and when you actually want to transfer information, you fill out a form on the website, such as who 65 00:05:04,600 --> 00:05:06,760 you are and who you want to send money to. 66 00:05:07,030 --> 00:05:08,560 So this is just a form. 67 00:05:08,560 --> 00:05:14,050 After you log into the website, it shows this estima form inside the browser, and anybody actually 68 00:05:14,170 --> 00:05:19,660 who has an account at the bank would be able to see that HTML form inside the browser by just inspecting 69 00:05:19,660 --> 00:05:20,290 that form. 70 00:05:22,070 --> 00:05:26,420 So what would happen if a hacker attempts to actually create a forgery of that form? 71 00:05:26,660 --> 00:05:33,170 Maybe they also have an account at that bank and they can actually see what the form looks like so they 72 00:05:33,170 --> 00:05:35,420 can create a copy of that form. 73 00:05:36,320 --> 00:05:41,060 For example, if the form is a post request where some of the key information is something like send 74 00:05:41,060 --> 00:05:46,610 money to Tom, they could make a forgery and then actually begin to edit that form. 75 00:05:46,970 --> 00:05:51,270 Maybe they can say, Hey, actually send the money to me, the hackers account. 76 00:05:51,770 --> 00:05:55,400 So this is known as a forgery of an HTML form. 77 00:05:55,670 --> 00:06:01,190 They're taking a legitimate form on the bank website, and then they begin to create a forgery and edit 78 00:06:01,190 --> 00:06:07,400 key components such as whoever hit submit on this button will actually be the sending money to the hackers 79 00:06:07,400 --> 00:06:07,730 account. 80 00:06:07,970 --> 00:06:09,590 So that's essentially step two. 81 00:06:09,920 --> 00:06:13,880 They're able to create a forgery of the form, and they've done some editing there. 82 00:06:15,140 --> 00:06:20,030 Next, they need to perform some sort of phishing scam to actually send the form to somebody, such 83 00:06:20,030 --> 00:06:24,620 as sending an email to an unsuspecting user to go ahead and click on a button, which would accidentally 84 00:06:24,620 --> 00:06:25,370 submit the form. 85 00:06:26,300 --> 00:06:30,580 So the president's pants, some sort of user, they send them the form. 86 00:06:30,590 --> 00:06:32,000 It doesn't look like a form. 87 00:06:32,000 --> 00:06:36,920 It typically would be like, Hey, click here to see the latest results, but really, by clicking here, 88 00:06:36,920 --> 00:06:39,230 maybe they're clicking a submit button within that form. 89 00:06:39,620 --> 00:06:46,220 And if everything went well for the hacker upon hitting that phishing link, the actual unsuspecting 90 00:06:46,220 --> 00:06:48,380 user would end up sending a form request. 91 00:06:48,560 --> 00:06:53,630 And unfortunately, that form request would go to the bank and the bank would think, OK, this is a 92 00:06:53,630 --> 00:06:57,080 legitimate form, and that user wanted to send money to the hacker account. 93 00:06:58,890 --> 00:07:05,250 This entire process is known as CSI Ref or cross site request forgery, where a hacker has created a 94 00:07:05,250 --> 00:07:12,870 forgery of a form and then is using someone else as essentially a potential target in order to perform 95 00:07:12,870 --> 00:07:13,900 this across the site. 96 00:07:15,840 --> 00:07:17,640 So how can we actually prevent this attack? 97 00:07:18,060 --> 00:07:24,900 What we could do is generate a random cryptographic token with every form during each individual session. 98 00:07:25,410 --> 00:07:29,010 The server could then confirm at the token matches with the current session. 99 00:07:29,460 --> 00:07:34,680 So every time someone's logging in and using that website, we end up creating a unique token that's 100 00:07:34,800 --> 00:07:37,320 only valid for that exact session. 101 00:07:38,890 --> 00:07:44,500 Since each session has a unique token, only the true original form would be accepted as authentic. 102 00:07:44,710 --> 00:07:49,240 You really wouldn't be able to copy it because a token would expire by the time the session is over. 103 00:07:50,410 --> 00:07:56,650 So for example, if we think back to the key actors here you have the bank who now is using a CC rf 104 00:07:56,800 --> 00:07:57,250 token. 105 00:07:57,670 --> 00:07:58,930 And so we represent this token. 106 00:07:58,930 --> 00:08:04,270 If that little golden medallion there and what they do is they have a token that they know on their 107 00:08:04,270 --> 00:08:08,620 website, and they've also attached it to the form and technically it's hidden in the form. 108 00:08:08,800 --> 00:08:14,080 It's not like you can go ahead and edit the token within filling out the forms inputs, but you can 109 00:08:14,080 --> 00:08:16,690 inspect the actual form and see that token. 110 00:08:17,050 --> 00:08:20,980 But more importantly for the bank, there's a session attached to this token. 111 00:08:21,610 --> 00:08:26,020 So essentially what they're saying is when someone's logging in and filling out this form in the bank, 112 00:08:26,320 --> 00:08:32,919 this particular token is only valid and authentic for this exact session when they're logged in. 113 00:08:33,340 --> 00:08:38,830 So if the hacker was logged into the bank and they created a form, unfortunately for the hacker, that 114 00:08:38,830 --> 00:08:44,590 particular CSR token would only be valid for the exact session when the hacker is logged in. 115 00:08:45,610 --> 00:08:51,460 So that means even if the hacker decided to create a forgery of the form and end up editing it and still 116 00:08:51,460 --> 00:08:57,490 have that CSR token from the bank's perspective, that token was only valid for that particular session. 117 00:08:57,700 --> 00:09:04,030 Essentially, it's almost like it has an expiration date that once the user is ending up either going 118 00:09:04,030 --> 00:09:09,190 to a different page or logging off or just ending their session somehow, then that token is no longer 119 00:09:09,190 --> 00:09:09,580 valid. 120 00:09:10,360 --> 00:09:17,680 Which means even if the hacker was able to send this illegitimate form, then what would happen is the 121 00:09:17,680 --> 00:09:25,090 bank would say, Hey, sorry to the prey or victim, but hey, your CSR token is illegitimate. 122 00:09:25,360 --> 00:09:28,960 This is from some older session, and it doesn't match what I have here currently. 123 00:09:29,170 --> 00:09:30,610 It's no longer valid. 124 00:09:31,090 --> 00:09:37,210 So this is one way where we could use tokens that are again generated per individual session each time 125 00:09:37,210 --> 00:09:42,430 you create that form in order to make sure that the form is actually meant for that particular session. 126 00:09:44,190 --> 00:09:49,380 Now, what's really nice about jingo is it automatically creates these CSR tokens for us with a simple 127 00:09:49,380 --> 00:09:49,990 tag call. 128 00:09:50,070 --> 00:09:55,710 Essentially, we need to do it every time you create a form, you just remember to provide CSR if underscore 129 00:09:55,740 --> 00:09:57,720 token as a Django template tag. 130 00:09:57,990 --> 00:10:00,420 And this will all be automatically done for you. 131 00:10:00,660 --> 00:10:04,530 And this is important for a post request inside a form. 132 00:10:04,770 --> 00:10:08,970 We really want to make sure that whoever is actually posting or updating information to the website 133 00:10:09,270 --> 00:10:13,230 is legitimately logged in just at that particular session that way. 134 00:10:13,590 --> 00:10:18,360 The hacker can actually just duplicate the form because that token would be invalid by the time they 135 00:10:18,360 --> 00:10:22,290 were able to forgeries or make a forgery of the actual form. 136 00:10:23,930 --> 00:10:28,670 For more information on Django's Bill 10cc, our protection system, you can check out this link in 137 00:10:28,670 --> 00:10:29,510 the documentation. 138 00:10:30,350 --> 00:10:30,680 OK. 139 00:10:30,950 --> 00:10:36,080 With that being said, let's go ahead and begin to explore how Django forms with the form class model 140 00:10:36,320 --> 00:10:37,130 actually works. 141 00:10:37,430 --> 00:10:38,510 I'll see you at the next lecture.