Cross-Site Forgery (CSRF) and Public API
Looking at hardening security and preventing spoofed request attacks. Understand tokenization for forms, but less understandable for object instances.
According to OWASP, the exploit criteria include 1. the web user must be authenticated and 2. CSRF attacks are specifically designed for state-changing requests.
In issue: I have a public photo gallery with database-driven content. The application is authenticated against the database, but is NOT a web user.
On initial page load (initial state), the viewer (HTML) requests a thumbnail lightbox from the application. A netizen clicks on a thumbnail to download images associated with the gallery. The click event reloads the page passing the GET (gallery id) variable to the script controller. The controller creates a new instance of the params array.
The app starts a session but not view the html.
Here is the public interface for the application, everything else is protected or closed.
viewer.php
/*
* class params
*/
if( isset($gid) && $gid!=null ) {
/* show project gallery images */
$params['ticket'] = "gallery";
$params['active'] = "Y";
$params['gid'] = $gid;
} else {
/* show lightbox thumbnails */
$params['ticket'] = "lightbox";
$params['active'] = "Y";
}
/* later in html body, instance object */
$cObj = accesswrapper::factory($params);
$cObj->jobrequest();
unset($params);
unset($cObj);
factory.php
/**
* @api
* @return void
* instantiates the sub class passed from viewer
*
* @param array $params, [ticket] subclass name
* pforeman, object interface
*/
class accesswrapper {
public static function factory($params) {
$ticket = $params['ticket'];
switch($ticket) { //route to appropriate sub class
case $ticket=="lightbox":
$inst = new lightbox($params);
break;
case $ticket=="gallery";
$inst = new gallery($params);
break;
}
if ($inst instanceof pforeman) {
return $inst;
} else {
return void;
}
}
}
Questions: Does this process need a token? And will that be enough to stop CSRF?
source to share
You don't need to worry about CSRF if it only requests trivial updates (more on the definition of "trivial updates" below). With a normal CSRF attack, you have:
- User registered on website A with website cookies.
- In the same browser session, the user accesses website B.
- Website B forces the browser to access some URL on website A.
- Website A responds to the request, thinking it came from a user.
Due to the same origin policy, website B cannot see the access response; this can lead to access. So if the request only has trivial updates, the user's browser will display the content from Site A when they visit Site B, but we know that the user has the right to see this data anyway, because Site A would have rejected the request otherwise.
The user may bother a little, keep website A maintained, no matter there was no data breach.
If the requests perform more than trivial updates, then website B forced the user to take action on site A without their intention. Very bad for user and site A.
So trivial updates are only safe without CSRF protection. Everything else needs protection.
"Trivial updates" mean different things to different sites. For example, updating any bank balance sheet is clearly not trivial. But does the balance query log the trivial update to the database? How about a time consuming query? The technical and business model of your site will determine what you consider to be trivial updates and acceptable to leave CSRF unprotected and what you think should be protected.
In your application authentication model, but not user authentication, you don't need to worry about CSRF since all hits are public.
Finally, note that it is not recommended to add CSRF protection to logout functions. This helps to ensure that the user can always log out, even if an error occurs while checking the CSRF. However, the risk of this is that Site B might force the user to log out of Site A. You must choose what is most important to you.
source to share