CSRF Token
CSRF stands for Cross Site Request Forgery.
Today web serves mostly dynamic content rather than static ones.
The websites are mostly authenticated via cookies. The browser stores cookies and moves it back and forth between server and client. The browser identifies the site that it needs to send cookie to, any only sends cookie to that site. Say for example a banking site, the browser chrome knows to send the authentication cookie related to the bank to the same site only.
What an attacker can do is hand your computer some javascript. And since your computer is already logged in, it will use that authenticated cookie to make request on the bank website.
The banking sites have APIs exposed for login, logout, email change etc. All these APIs are wide opened. If the authentication cookie is sent, they will honor the request. So we need some way to ensure that the request was sent from our page or someone who has read access to our page.
In this scenario because you are just browsing the attacker's website, they can't access the content of the cookie and while they can tell your browser to make the request, it's your browser making the request, it' your browser that gets the response. The attacker's website can't get the response. SO they are really just shooting in the dark.
So the easiest way to do this is just put a token in the page, and this token will be in the form of a hidden field in the form, or just some hidden field in the page at which javascript has access to, so that when you make an AJAX request, it can include this token with the AJAX request. This token lets the webserver know that your browser is on or in your webapp.
Most of the times, this token is some encrypted value and it's encrypted with a key that only the webserver knows. So the client, the user, the browser none of them actually know what little cookie says underneath the encryption. They can just see the encrypted data. And if they mess with it, it won't decrypt properly.
This is also not enough. If every thing has the same encrypted value then the attacker has to just browse you website, get that encrypted value and send the same value with the request. And so to fix that, the encrypted value on that page is specific to the user somehow. Even better if its specific to the user's current session. This means that every user and session has a different token. The token doesn't even have to be stored on the website because the server side has decryption key and can decrypt and verify the token.
One way to do this is to just say encrypt the session id with some random salt value, and this will help prevent reversing of the key, which should be impractical anyways as long as you are using an aes key of large enough size.
Many frameworks and technology stacksLike MVC, Microsoft's MVC or Ruby on Rails had these mechanism built in. Most of the frameworks has something built in for these handling.
Since the attacker can't get at the content of the page but your local Javascript can, it can put this token in every request, and there is something on the server that can decipher it down.
GET requests - As per specification get is what's considered to be a safe method, and should not have any significant side effects, or take any significant actions besides retrieval of data.
Cross site request forgery only applies to things regarding to changing stuff.