php - Cross-Site Forgeries (CSRF) and Public Application Interface -
looking tightening security , prevent cross-site request forgery attacks. understand tokenization forms less clear on object instances.
according owasp exploit criteria includes 1. web user needs authenticated , 2. csrf attacks target state-changing requests.
at issue: have public facing photo gallery database driven content. application authenticated database, not web user.
on initial page load (initial state), viewer(html) request lightbox of thumbnail images application. web user clicks on thumbnail load images associated gallery. click event reloads page passing variable (gallery id) controller script. controller creates new instance of params array.
the application starts session, not viewer html.
here public interface application, else 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 sub class passed viewer * * @param array $params, [ticket] subclass name * pforeman, object interface */ class accesswrapper { public static function factory($params) { $ticket = $params['ticket']; switch($ticket) { //route 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: process need token? , enough stop csrf?
you don't need worry csrf if request trivial updates (more on definition of "trivial updates" below). in typical csrf attack have:
- user logged website cookies website.
- in same browser session, user accesses website b.
- website b causes browser access url on website a.
- website responds request thinking came user.
because of same origin policy, website b can't see response of access; can cause access occur. if request trivial updates, user's browser display content site when accessing site b, know user entitled see data anyway because site have rejected request otherwise.
the user may freak out bit, call support of website a, whatever, there no data breach.
if requests more trivial updates, website b has caused user take action on site without being intent. bad user , site a.
so trivial updates safe without csrf protection. else needs protection.
"trivial updates" mean different things different sites. example, updating someone's bank balance not trivial. logging balance request in database trivial update? how performing time-consuming query? site's technical , business model determine consider trivial updates , acceptable leave unprotected csrf , feel must protected.
in model of app-authentication not user authentication, don't need worry csrf accesses public.
one final note, idea add no csrf protection on logout functionality. helps ensure user can logout, if bug happens in csrf validation. said, risk of site b can force logout of user site a. have pick makes sense you.
Comments
Post a Comment