Cross-Site Request Forgery (CSRF)

Description

See CWE-352
Also see this description
Essentially, when an HTTP GET request makes a persistent modification, then you can get users to make changes to other websites they are already authenticated into.

As a rule, don’t allow GET actions to perform persistent modifications to the website. GET requests are much easier to forge than POST requests.
If a GET does still need to make a modification, then require authentication within that HTTP request (see DVWA as an example).
Session tokens should not be allowed in URLs, only in cookies.
Consider why you are allowing clients to create GET requests for other clients anyway (e.g. email clients hiding img tags from users initially).

The ubiquitous bug tracker Bugzilla had one of these in how it deals with XML-RPC. See the CVE-2012-0453, the release notes, the bug (note the detailed discussion) and the fix revision

Web application frameworks will mitigate this by providing a random token with every form, and only accepting submissions with that token. This is not foolproof, but it’s a good step. The Ruby on Rails Security Documentation has a great discussion on this.
Technically, this is not cross-site scripting as no script is being executed on user’s browser. However, CSRFs allow attackers to fool victims into sending GET requests to malicious sites or by modifying something in the app itself.
CSRF is one reason that many email clients don’t show images upon initially showing an email.

Use the DVWA demo from your instructor. An example exploit would be to load a separate html page with the following tag:

<img src="http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=12345&password_conf=12345&Change=Change#">