Add csrf token protection to API calls.

[drgrice1]

Anytime a page is rendered a csrf token is added to the webworkConfig variable. This is then retrieved in JavaScript anytime an API call is going to be performed and is attached to the request. The API will now refuse any request that does not have this token or if the token does not match the token in the session. This utilizes the Mojolicious csrf_token helper method.

The point of this is that a user that has properly logged into webwork in the browser may be tricked into doing something in another tab or window by an attacker that would cause a request to be sent to the API. That request would automatically have the valid WeBWorK session cookie attached to it by the browser, and so the request would succeed and could do whatever the user has permission to do via the API. Adding the csrf token prevents that because the other tab or window would not have access to the csrf_token in the webworkConfig JavaScript variable.

This was one of the vulnerabilities that @Alex-Jordan found with Claude before.

This does mean that using the API via a script will not work as easily. You would have to extract the csrf_token either from the cookies in the response or by parsing the HTML to find the csrf_token in the webworkConfig variable. But it can still be done. If we really want a proper API for usage in scripts we could make it possible for users to generate an API token in the UI (those with sufficient permissions at least), and the API token added as an Authorization: Bearer header could be used as an alternative to the csrf_token. At this point I don't think this is needed though. I doubt anyone really uses the API in this way.

Note that this does not apply to the render_rpc endpoint. It probably should, but that would cause issues for PreTeXt an others using this endpoint in the same way (although this could be worked around in much the same way that cookie disabling is done if the allow_unsecured_rpc option is set). At this point I think this is also not necessary as this endpoint generally can't do anything destructive. It just renders problems.