Cross-Site Forgeries (CSRF) and Public Application Interface

Question

Looking to tightening up security and prevent Cross-Site Request Forgery attacks. Understand tokenization for forms but less clear on object instances.

According to OWASP The exploit criteria includes 1. web user needs to be authenticated and 2. CSRF attacks specifically target state-changing requests.

At Issue: I have a public facing photo gallery with database driven content. The application is authenticated with the database, but NOT the web user.

On initial page load (initial state), the viewer(HTML) request a lightbox of thumbnail images from the application. The web user clicks on a thumbnail to load images associated with the gallery. The click event reloads the page passing a GET variable (gallery id) to the controller script. The controller creates a new instance of the params array.

The application starts a session, but not the viewer html.

Here is the public interface for the application, everything else is protected or private.

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?

Answer 1

You don't need to worry about CSRF if it the request does only trivial updates (more on definition of "trivial updates" below). In a typical CSRF attack you have:

1. User logged into website A with cookies for website.
2. In same browser session, user accesses website B.
3. Website B causes browser to access some URL on website A.
4. Website A responds to the request thinking it came from the user.

Because of the same origin policy, website B can't see the response of the access; it can only cause the access to occur. So if the request only does trivial updates, the user's browser will display the content from site A when they are accessing site B, but we know that the user is entitled to see that data anyway because site A would have rejected the request otherwise.

The user may freak out a bit, call support of website A, whatever, but there was no data breach.

If the requests does more than trivial updates, then website B has caused the user to take an action on site A without that being their intent. Very bad for user and site A.

So trivial updates only is safe without CSRF protection. Everything else needs protection.

"Trivial updates" will mean different things for different sites. For example, updating someone's bank balance is clearly not trivial. But is logging a get balance request in a database a trivial update? How about performing a time-consuming query? Your site's technical and business model will determine what you consider trivial updates and acceptable to leave unprotected from CSRF and what you feel must be protected.

In your model of app-authentication but not user authentication, you don't need to worry about CSRF as all accesses are public.

One final note, it is frequently a good idea to add no CSRF protection on the logout functionality. This helps to ensure that the user can always logout, even if a bug happens in CSRF validation. That said, the risk of this is that site B can force a logout of the user from site A. You have to pick what makes the most sense for you.