Archives For Security

What are Prepared Statements?

Prepared Statements, also known as parameterized statements, is a database feature that allows the same or similar queries to be executed with more efficiency and greater security. It has also been a common Sugar platform feature request for some time.

A prepared statement looks something like this:

SELECT * FROM table WHERE id = ?

As you can see, a prepared statement is basically a SQL template that allows you to identify parameters that can be bound later. The database engine can parse, optimize, and cache this statement without executing it.

This reduces the overhead associated with parsing complex queries that are used frequently by applications like Sugar. For example, you can imagine that List View queries would benefit from prepared statements since they are often complex and executed each time a list is displayed, searched, filtered, or paginated. With prepared statements, the database will do less work each time one of these actions is repeated.

Continue Reading…

Many customers want to configure Sugar for Single Sign On (SSO). Well Sugar supports Security Assertion Markup Language (SAML) so this must be easy, right? But the devil is always in the details.

Each SAML identity provider behaves a little differently. Each of these systems has different terminology and methods for configuration and may use different default settings. Some of these important configuration settings can make the difference between a successful SSO implementation and a tire fire. For example, are users provisioned Just-In-Time or will they be provisioned manually? Did you know that Sugar uses the e-mail address as the SAML application username format?

Below are instructions for configuring SAML SSO with a couple of common identity providers.

Okta

One of our Solution Architects, Enrico Simonetti, wrote a good summary of how to configure SAML authentication for Sugar using Okta as the identity provider. Okta is convenient for trying out SSO because they have a developer program you can join. Enrico also covers a few tips and details that can trip up any SAML implementation.

Please visit Enrico’s post called SSO Authentication on SugarCRM with SAML for more details including screen shots and even code examples.

Active Directory Federation Service

The most common system that we get questions about is Microsoft’s Active Directory Federation Service (ADFS). ADFS is pretty complicated so there are several steps that you need to follow to get it done right.

We recently publish a SugarCRM Knowledge Base article called Configuring SSO With Active Directory’s ADFS. It was written by Lars Blockken, one of our Senior Technical Account Managers, and in it he walks you through each of these steps in detail along with screenshots. It will have you up and running on ADFS in no time!

Sugar Developers now have a new tool for building upgrade safe mobile customizations that address most branding, theming, and mobile security requirements.

Introducing Sugar MACS

Introducing the Sugar Mobile Application Configurator Service (Sugar MACS)! This tool allows Sugar Developers building solutions for Sugar Enterprise customers to create and distribute custom-branded versions of the SugarCRM Mobile app.

Many of you have seen earlier previews of Sugar MACS at SugarCon and UnCon.

Continue Reading…

Here is another guest post from Emmanuel Dyan from the Elite SugarCRM Partner iNET Process. In it he addresses a common Sugar project requirement using an open source tool developed by iNET Process.

The problem that we will try to solve with this post is:

How do we make sure that we are never developing using actual customer data but, at the same time, work with data that reflects reality?

Data Anonymization

Usually, when we work on a customization project for a customer you have a minimum of 3 different environments: Development,  User Acceptance Testing (UAT), and Production. To make sure that we work in optimal and consistent conditions, we usually copy the database from one environment to another (preferably from production to other environments). Doing this type of manipulation has multiple drawbacks, including:

  • We have to collect a Database Dump which means that it contains unencrypted raw data. What would happen if we mistakenly expose this dump to someone who is unauthorized?
  • We have to test some functionality to make sure that it works. What would happen if we test a Campaign that sends thousand of e-mails … to the … actual customers of our customer?

Anonymizing the data is the best practice to avoid “playing” with customer data and to keep their trust in us.

The challenge with anonymizing data is figuring out how to overwrite the data with something that is completely unrecognizable. For example: “John Doe” will become “voluptatem accusantium“. His job title becomes “doloremque” and his country “magnam“. His phone number will become “569898520114457878744778” instead of “+123456789“.

Continue Reading…

The Sugar application requires that a number of directories be writable in order to properly function.  The precise directories and minimum permissions needed are covered in the Sugar Install Guide.

A common practice for Sugar Developers to work around file permission issues is to make everything writable to the web user.  In practice, this does not cause any functional issues and is an easy way to avoid problems. But this is not desirable in production or sensitive environments from a security point of view because it violates the principle of least privilege. So Developers should really familiarize themselves with setting up secure file permissions for their web servers since this will be more in line with real production environments.

Here are some tips for working with extended file system permissions on your Sugar deployments from Jelle Vink our Security Architect.

Continue Reading…

CSRF Tokens in Sugar 7.7

Matthew Marum —  December 1, 2015 — 2 Comments

What is a Cross Site Request Forgery (CSRF)?

A CSRF is a type of exploit that a malicious website or attacker could employ to have a user send unauthorized commands to a website or application.  It is a type of confused deputy attack against a user’s web browser that tricks it to send malicious HTTP requests to a target website.

Some CSRF techniques are trivial to employ.  For example, it is possible to place an arbitrary URL within an HTML IMG tag which will convince your browser to run an HTTP GET against that URL.

Try out this example that uses RequestBin.  I added an image tag to a page in my local web setup.

<img src="http://requestb.in/vzwvagvz">

When I checked RequestBin then I could see what the request from my browser looked like to the external service.

Screen Shot 2015-11-25 at 11.13.23 AM

CSRF exploit example

A malicious HTTP GET can potentially expose sensitive information.  For HTTP GET requests, the state of the system rarely changes meaning that lasting damage can be limited.  What can be more troubling is when a browser is tricked into performing an HTTP POST using a maliciously designed HTML form.

Continue Reading…