Concerto Security
From Harmoni
Concerto (as well as Segue version 2) are designed to enable their safe use on a publicly available web-server. Some of the design features listed below are provided by the Harmoni Application framework, while others are implemented in the applications themselves. See the Security Best Practices page for additional details.
Contents |
Single Entry Point
Concerto (and other applications that use the Harmoni Architecture) has a single php script, index.php, through which all requests get passed. Individual actions are accessed by specifying an action parameter in the request (http://concerto.example.edu/index.php?action=xxxxx), rather than accessing the action script directly (http://concerto.example.edu/xxxxx.php).
Executing the application in this way provides several advantages:
- All PHP code can be placed in a non-web-accessible directory, with only the index.php script (and some CSS, javascript, and image files) exposed in a web-accessible directory. With this configuration the following advantages come into play.
- The execution sequence is well defined.
- Action scripts can remain lightweight as they have a very specific role in the execution cycle.
- It is impossible to execute scripts out of order, and/or without configuration files being included.
- The action specified can be validated and authorizations checked before it is executed.
RequestContext
Rather than access the $_REQUEST, $_GET, or $_POST superglobals directly, all access to user input is done through the RequestContext class. The primary goal of the RequestContext class is to allow namespacing of input variables. A secondary goal is to provide a centralized place for user-input to flow through, at which hooks can be placed to validate inputs.
Database Storage of Files
Files uploaded to Concerto are stored as Assets in the HarmoniRepository. This Repository implementation in turn stores file data as BLOBs in the database rather than as files on the filesystem.
Advantages:
- Only one data source to back up - the database.
- Uploaded files can not be executed in a shell or browser as they only live as rows in the database. When accessed, the data is queried from the database and printed directly to the browser.
- Any file-type can be uploaded safely, even PHP files.
- Every file access can have authorization checks applied as it is impossible to directly access files.
Disadvantages:
- Database input-size limits.
- Possible [slight] performance degradation over direct access to the files.
- Streaming likely precluded.
Service-Oriented Architecture
Concerto uses Harmoni's Category:Services for the vast majority of its logic. Concerto can be accurately thought of as a set of user interfaces and a few [very small] libraries which interact with the Harmoni Services. A consequence of this is that Concerto makes few, if any, direct data-storage or data-modification calls. Instead, with these calls going through the various Harmoni Services, user inputs are validated once by the Concerto UI code, a second time at the Service API boundary, and possibly a third time in the database access layer.
All services do input validity checking and throw Exceptions when inputs are not valid. As well, since the same services have consistent APIs and are shared by many applications and used in many contexts, it is comparatively easy to audit the services layer and provide robust validation and error handling that helps all Harmoni-based applications.
Unified Database Abstraction Layer
The Harmoni Database Manager provides object-oriented query generation with methods that allow for automatic escaping of input values and identifiers, preventing SQL injection attacks.
