Sometimes you find yourself poking around. Sometimes simply viewing a web page's source reveals a lot. And sometimes both of those intersect. This is a documentation of my first real foray into web application security with CSRF, in May of 2016.
At one of my prior work places, I looked into the web page source for a lesser known web app, developed at the organization for internal use, and accessible across the organization. The immediate part that stood out was the lack of a token anywhere in the source, pointing to a CSRF vulnerability. All other web apps that I checked too lacked a token.
Initial disclosure was to the IT group of the division I worked in, The issue was reviewed, and response was essentially as follows:
The web app isn't vulnerable since it's intranet and not externally accessible. We're aware of the problem but a new version is in the works.
I wanted to confirm a vulnerability would be fixed, so I sought the new version's developers and was redirected to the org's web app security team. Not only did they confirm the new version would resolve the CSRF vulnerability, they also confirmed the applications were indeed vulnerable.
In short, CSRF is exploited with a form precrafted by an attacker who gets a user to unknowingly submit it. The form exploits the user's active session to submit under the user's identity.
This is prevented by having a token generated server side and included with the form when it's sent to the user. Submitting the form will also submit the token, validating the form originated from the server.
CSRF tokens can be a string of random characters, preventing the token from being guessed, and unique to each user, preventing it being leaked. Other methods of token generation include using encrypted data as a token.
Note that a hidden field containing random characters doesn't mean the form is immune to CSRF. The server has to verify the token, and the token entropy may be too low or guessable in other ways.
Somewhat similarly, paper currency has markings and colors that are producible only by the mint, verifying the origin. Also similarly, markings that aren't unique enough can be replicated, still impersonating the origin.
With this is mind, regarding the response I received, it's important to note that the form submitted in a CSRF attack originates from the attacker, but submission itself originates from the user's machine. Thus, web apps originally protected within a corporate intranet are not necessarily safe from CSRF.