XSRF attack

[Superman]

First read:Cross-site request forgery and Preventing CSRF and XSRF Attacks

It is possible to perform XSRF-attack onto SugarCRM. But it is up to you to decide whether it is defect or not. As for me, it is not defect, but there could be some companies which are highly secure addicted.
My argument is that it is quite hard to determine record id or user id to perform delete/update action, it is 36-char unique string.

However, if you still need to perform defense, then let me describe the way you may do it.

In SugarCRM we need to attach token to "Save", "MassUpdate" and "Delete" actions (there can be some extended Save function, like SaveSignature, SavePassword etc, they should be included as well).
Everything other doesn't matter: attacker will not get results (html data) of action "ListView", "Export", "Edit", "Detail".
Quoting: "the attack is blind; i.e., the attacker can't see what the target website sends back to the victim in response to the forged requests, unless he exploits a cross-site scripting or other bug at the target website." (source: Cross-site request forgery - Wikipedia, the free encyclopedia).
Attacker cannot exploit "cross-site scripting" since he cannot be inside SugarCRM instance, this is kind of intranet, and not guestbook/forum/etc.

We need to define some function which would generate token, and developer will be able to use it in any module developed.
And put token-check function inside SugarCRM: include/MVC/SugarApplication.php guess somewhere near $this->checkHTTPReferer().

put following function inside security_utils.php (include/utils folder)

 /**
 *
 * Return 36-char token and save it in user session for further check
 * @param object current user object
 * @return string 36-length token
 */
function get_token() {
  // one token per whole page
  static $token = '';
  if (empty($token)) {
    global $current_user;
    $token = create_guid();
    $current_user->setPreference('sugar_token', $token);
  }
  return $token;
} 
  

then put following function inside include/Smarty/plugins/function.sugar_token.php:

 function smarty_function_sugar_token($params, &$smarty) {
  require_once 'include/utils/security_utils.php';
  $input = "<input type='hidden' id='sugar_token' name='sugar_token' value='" . get_token() . "' />";
  return $input;
} 
  

Let's now put token inside form: put

{{sugar_token}}
</form>

in include/ [EditView / DetailView] /footer.tpl or header.tpl or whereelse before </form> tag.
In same manner you can put {{sugar_token}} on other smarty templates.

Now, create token-check function inside security_utils.php:

 /**
 *
 * Perform token validation for selected actions
 * @return bool token valid?
 */
function isTokenValid() {
  // lowercase only!
  $affectedActions = array(
    'save' => 1,
    'delete' => 1,
  );
  //
  // See more detailed function SugarApplication::protected function isModifyAction()
  //
  if (isset($affectedActions[strtolower($_REQUEST['action'])])) {
    global $current_user;
    if (!empty($current_user) && !empty($_REQUEST['sugar_token'])) {
      $userToken = $current_user->getPreference('sugar_token');
      if (strcmp($userToken, $_REQUEST['sugar_token']) == 0) {
        // tokens are valid
        // destroy current token and create a new one
        $new_token = get_token();
        return true;
      }
    }
    return false;
  }
  return true;
} 
  

then i put in SugarApplication.php:

 ...
$this->loadUser();
$this->ACLFilter();
$this->preProcess();
$this->controller->preProcess();
$this->checkHTTPReferer();
if(!isTokenValid()) {
 $GLOBALS['log']->fatal("Possible XSRF-attack detected.");
 die;
 
}
... 
  

[rogerSerieA]

I implemented a quite good upgrade save solution. Only file you need to touch is SugarApplication.
Sugar offers already some protection versus outside attacks and async calls, but you are restircted to use the special features (only working with JSON).
IF you have a more complex use, you will easly face the limits.

Further the ID with 36 chars is not really save. Dont forget you can get user informaion by its user_name. Also you dont need to have an ID. It is also possible to forge Sugar creating a new user or other beans. Thus you can easy add admin users and you have a huge problem...
As we talked yesterday, if there is no anti frame spoofing, it is also possible, to fake easy POST calls.

Guess Sugar needs to do sth. here, moreover for their enterprise solutions. Guess the clients won't be amused, if they have a significant leak or security =)

cya,
Roger