Welcome back, everyone, to this lecture on get some post requests as well as the SRF.
We've already seen that HTP that is hypertext transfer protocol, is the foundation for the method of
sending and receiving data over the worldwide web.
You can also recall the HTP tips is simply an encrypted or secured version of HTTP.
HDP itself defines a variety of methods for interactions over its protocol.
And the key methods we need to understand are the get and post methods which you've already seen use
in HTML forms, but we haven't really talked about the difference between the.
Get is going to request data from a specified resource post, is going to request to send data to a
server to create or update a resource.
Now, you should note the tricky terminology that can sometimes be confusing.
Technically speaking, both gets and post are HTP request methods, even though you commonly see written
as an explanation of the difference between get and post as get requesting information and post as sending
information.
Technically speaking, they're both HDP requests, but we do typically think of get as asking for information
and post as giving information to be saved or used by the actual website.
So again, to clarify, we have get which is going to request data from a specified resource and post,
which is going to also technically request.
But it's really requesting to send data to a server essentially.
Where are you going to get information or are you going to post information?
So how does an HDP request work?
Well, essentially, we need a way to communicate between the client and browser side and our back end
website or web application.
So this way is to send the request and then you get back some sort of response.
And let's think of what a get request does it get is going to request data from a resource.
So you send a get request and you should note this is the default form method.
Once you create an HTML form, by default, it's going to send gets request.
And this is going to request data from a resource.
And this is actually done inside the URL, so you've actually seen this before back in HTML forms where
we saw there was a key value pair that was attached to the URL.
We saw a question mark and then we saw the key that is the name attached to that forms input.
And then the value provided by the user.
And then what happens is the website is going to give a response back.
Maybe it redirects to a different web page.
Just notice how, again, the get request is sent in the URL.
This means a few things the get requested can actually be bookmarked and saved in history.
It's essentially just a URL.
So if I sent a get requests to reform, I could actually save that result as a URL in my history, which
also means it can be cached.
And it also means that it has length restrictions or limits, so the get requests can really only request
data.
It's not meant to modify or update anything on the website.
But what if we want to send information for the specific purpose of updating some backend information
in that case?
We probably don't want that information inside a URL.
And really, our main concern is no receiving of information back, but instead sending that information.
So a post request is really similar, except this time, remember, the main purpose is to actually
use the information inside the post request for an update that is, I want to post this information
and probably change something on the back end.
And because that's the case, I don't want to just send this information inside the URL.
So this is actually sent inside the body message of the HTP.
It looks a lot like a Python dictionary, and when you send a post request, you're no longer actually
going to see that information inside the URL.
Instead, it's within the actual message or body of the HDP request.
It's not inside the URL, and you will get a response back.
So essentially, what this says is when you send the post's request, you're actually passing on HTP
message inside a body and says, Hey, use this key value, pair an update or post this information
to the website.
And we can see that HTML forms are actually quite readable by the browser.
So we want to make sure that the HTML form on the page is being correctly used by the appropriate user.
So now that we understand get versus a post request, we want to be able to think about the question
could a malicious actor actually try to fake an HTML form?
And what kind of issues is that present to us?
Well, let's imagine this forgery attempt in step one, let's imagine that your bank has a website,
and when you actually want to transfer information, you fill out a form on the website, such as who
you are and who you want to send money to.
So this is just a form.
After you log into the website, it shows this estima form inside the browser, and anybody actually
who has an account at the bank would be able to see that HTML form inside the browser by just inspecting
that form.
So what would happen if a hacker attempts to actually create a forgery of that form?
Maybe they also have an account at that bank and they can actually see what the form looks like so they
can create a copy of that form.
For example, if the form is a post request where some of the key information is something like send
money to Tom, they could make a forgery and then actually begin to edit that form.
Maybe they can say, Hey, actually send the money to me, the hackers account.
So this is known as a forgery of an HTML form.
They're taking a legitimate form on the bank website, and then they begin to create a forgery and edit
key components such as whoever hit submit on this button will actually be the sending money to the hackers
account.
So that's essentially step two.
They're able to create a forgery of the form, and they've done some editing there.
Next, they need to perform some sort of phishing scam to actually send the form to somebody, such
as sending an email to an unsuspecting user to go ahead and click on a button, which would accidentally
submit the form.
So the president's pants, some sort of user, they send them the form.
It doesn't look like a form.
It typically would be like, Hey, click here to see the latest results, but really, by clicking here,
maybe they're clicking a submit button within that form.
And if everything went well for the hacker upon hitting that phishing link, the actual unsuspecting
user would end up sending a form request.
And unfortunately, that form request would go to the bank and the bank would think, OK, this is a
legitimate form, and that user wanted to send money to the hacker account.
This entire process is known as CSI Ref or cross site request forgery, where a hacker has created a
forgery of a form and then is using someone else as essentially a potential target in order to perform
this across the site.
So how can we actually prevent this attack?
What we could do is generate a random cryptographic token with every form during each individual session.
The server could then confirm at the token matches with the current session.
So every time someone's logging in and using that website, we end up creating a unique token that's
only valid for that exact session.
Since each session has a unique token, only the true original form would be accepted as authentic.
You really wouldn't be able to copy it because a token would expire by the time the session is over.
So for example, if we think back to the key actors here you have the bank who now is using a CC rf
token.
And so we represent this token.
If that little golden medallion there and what they do is they have a token that they know on their
website, and they've also attached it to the form and technically it's hidden in the form.
It's not like you can go ahead and edit the token within filling out the forms inputs, but you can
inspect the actual form and see that token.
But more importantly for the bank, there's a session attached to this token.
So essentially what they're saying is when someone's logging in and filling out this form in the bank,
this particular token is only valid and authentic for this exact session when they're logged in.
So if the hacker was logged into the bank and they created a form, unfortunately for the hacker, that
particular CSR token would only be valid for the exact session when the hacker is logged in.
So that means even if the hacker decided to create a forgery of the form and end up editing it and still
have that CSR token from the bank's perspective, that token was only valid for that particular session.
Essentially, it's almost like it has an expiration date that once the user is ending up either going
to a different page or logging off or just ending their session somehow, then that token is no longer
valid.
Which means even if the hacker was able to send this illegitimate form, then what would happen is the
bank would say, Hey, sorry to the prey or victim, but hey, your CSR token is illegitimate.
This is from some older session, and it doesn't match what I have here currently.
It's no longer valid.
So this is one way where we could use tokens that are again generated per individual session each time
you create that form in order to make sure that the form is actually meant for that particular session.
Now, what's really nice about jingo is it automatically creates these CSR tokens for us with a simple
tag call.
Essentially, we need to do it every time you create a form, you just remember to provide CSR if underscore
token as a Django template tag.
And this will all be automatically done for you.
And this is important for a post request inside a form.
We really want to make sure that whoever is actually posting or updating information to the website
is legitimately logged in just at that particular session that way.
The hacker can actually just duplicate the form because that token would be invalid by the time they
were able to forgeries or make a forgery of the actual form.
For more information on Django's Bill 10cc, our protection system, you can check out this link in
the documentation.
OK.
With that being said, let's go ahead and begin to explore how Django forms with the form class model
actually works.
I'll see you at the next lecture.