{% set baseFontFamily = "Open Sans" %} /* Add the font family you wish to use. You may need to import it above. */

{% set headerFontFamily = "Open Sans" %} /* This affects only headers on the site. Add the font family you wish to use. You may need to import it above. */

{% set textColor = "#565656" %} /* This sets the universal color of dark text on the site */

{% set pageCenter = "1400px" %} /* This sets the width of the website */

{% set headerType = "fixed" %} /* To make this a fixed header, change the value to "fixed" - otherwise, set it to "static" */

{% set lightGreyColor = "#f7f7f7" %} /* This affects all grey background sections */

{% set baseFontWeight = "normal" %} /* More than likely, you will use one of these values (higher = bolder): 300, 400, 700, 900 */

{% set headerFontWeight = "normal" %} /* For Headers; More than likely, you will use one of these values (higher = bolder): 300, 400, 700, 900 */

{% set buttonRadius = '40px' %} /* "0" for square edges, "10px" for rounded edges, "40px" for pill shape; This will change all buttons */

After you have updated your stylesheet, make sure you turn this module off

Validating Trust Boundaries Through a  Centralized Input &  Data Validation Architecture

by Jason Taylor on September 28, 2011

I’m a software developer at heart, but my real passion for secure design is the result of my experience conducting penetration tests and code reviews on our customer’s applications.  I routinely find dozens of vulnerabilities that are the result of bad design, and these are often the most difficult to fix. If a vulnerability is a result of a design problem, a painful redesign may be the only way to make a fix. Lack of data validation on trust boundaries is often a major culprit. We recommend a centralized input and data validation architecture, so that trust boundaries can clearly be validated and a data validation is all done in the same set of routines. This approach is easier to implement correctly and much easier to maintain than a more scattershot approach. It also makes it easy for static analysis tools to validate your validation approach, they can check tainted input to ensure it passes through a validation routine as it makes its way from source to sink.

Here is a summary of some best practices:

  1. Identify Trust Boundaries.
    Ensure that entry points between trust boundaries validate all input data explicitly. Make no assumptions about the data. The only exception is inside a routine that you know can only be called by other routines within the same trust boundary.
  2. Constrain, reject, and sanitize input.
    Examine the validation functions to make sure they constrain known valid input first, then reject known bad input, and sanitize the resulting data. Constrain what you allow from the beginning. It is much easier to validate data for known valid types, patterns, and ranges (using a white list) than it is to validate data by looking for known bad characters (using a black list). The range of valid data is generally a more finite set than the range of potentially malicious input. However, for added defense you might want to reject known bad input and then sanitize the input. Constrain input for type, length, format, and range. Use regular expressions to help constrain text input. Use strong data typing where possible.
  3. Centralize validation.
    Develop a dedicated class or library for input and data validation functions in all but the smallest of applications.  A good library includes routines for all of the different types of validation you need to apply, and these can be used in combination if necessary. Trace data from entry point to exit point to know how it should be validated. For instance you will treat input that is used in a SQL query differently than input that will echoed back to the user in an HTML page.

This approach requires great care, however. A bug in a centralized data validation routine will manifest itself in hundreds of ways throughout your application. The fix may be easier, since you can make it in one place, but the consequences of failure are greater as well.

Topics: application security

Most Recent

What's Trending

Featured Resource