{% 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

Cross-Site Scripting:  Why is it Still So Prevalent?

by Joe Basirico on September 16, 2011

As a security researcher, I regularly come across software applications that are susceptible to a few basic types of attacks – and I struggle to understand how these can continue to slip through each phase of development and into production. There are a handful of vulnerabilities that fit into this group; cross-site scripting (XSS) being one of them – and we find them in just about every application we test.

A Cross Site Scripting vulnerability allows an attacker to modify a web page however they see fit, sometimes by injecting JavaScript, flash objects, HTML or anything else the browser can render. Because the payload is delivered by a vulnerable site, XSS will prey on a user’s trust relationship with the website they are visiting – and the browser has no way of discerning if the code was created by the original developer or a malicious attacker.

Anything that can render HTML or includes a web interface is potentially vulnerable including mobile devices and desktop applications.  When the script is stored in a database it becomes persistent, which is far worse because the same attack can be used for any user that browses to the site.

Below are common mistakes that organizations make that leave their applications vulnerable to attack. Be sure they don’t exist in yours.

  • Failure to use whitelist validation before it is processed by the application.
  • Trusting data retrieved from any database or other data source
  • Failing to encode any remotely provided data, including reverse DNS lookup, cookie contents, uploaded files, etc.
  • Improperly converting "safe" tags to HTML.
  • Displaying user input directly without encoding it appropriately for the context in which it is used.
  • Checking user submitted data against a blacklist instead of a whitelist.

In my next blog entry, I’ll talk about how to properly use Input validation to prevent XSS flaws.

Topics: developer guidance, application security

Most Recent

What's Trending

Featured Resource