This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Securing Cascading Style Sheets (CSS) Cheat Sheet"

From OWASP
Jump to: navigation, search
(editing for clarity)
(edits for clarity)
Line 46: Line 46:
 
= Defensive Mechanisms to Mitigate Attacker’s Motivation =
 
= Defensive Mechanisms to Mitigate Attacker’s Motivation =
  
==  Defense Mechanism #1 ==
+
==  Defense Mechanism ==
As a CSS Coder / Programmer, always keep the CSS isolated. By this, it means '''Student''' will have a different CSS file called as <code>StudentStyling.CSS</code> while '''Administrator''' has <code>AdministratorStyling.CSS</code> and so on.
+
As a CSS Coder / Programmer, always keep the CSS isolated by access control level. By this, it means '''Student''' will have a different CSS file called as <code>StudentStyling.CSS</code> while '''Administrator''' has <code>AdministratorStyling.CSS</code> and so on.  
  
Once you do this, make sure these <code>*.CSS</code> files are accessed only for an authenticated user while you keep the public pages like login (login.CSS) same for everyone.
+
Make sure these <code>*.CSS</code> files are accessed only for a user with the proper access control level.  Only users with the proper access control level should be able to access their <code>*.CSS</code> file. <code>*.CSS</code> files should not be loaded for users without proper access.
  
And also, only users with a specific role should be able to access only their <code>*.CSS</code> file and other <code>*.CSS</code> file should not be loaded and also should have authorisation to access it.
+
If an authenticated user with the '''Student''' Role tries to access <code>AdministratorStyling.CSS</code> through forced browsing, access should of course be denied and alert that an intrusion is occurring should be recorded.
 
 
For instance, if the role is student we need to have a logic similar to following.
 
 
 
 
 
'''Scenario #1''':
 
<syntaxhighlight lang=" JavaScript">
 
if Role(student):
 
  load(Student.CSS)
 
else:
 
  print(“Please login using your credentials”)
 
</syntaxhighlight>
 
 
 
 
 
'''Scenario #2''':
 
 
 
If '''Student''' Role (authenticated user) tries to access <code>AdministratorStyling.CSS</code> forcefully through the URL by replacing <code>StudentStyling.CSS</code> with <code>AdministratorStyling.CSS</code>, the permission should not be granted and the request should be forbidden because the '''Student''' Role doesn’t have access to any other <code>*.CSS</code> file except <code>StudentStyling.CSS</code>.
 
 
 
<syntaxhighlight lang=" JavaScript">
 
if Role(student)
 
  load(AdministratorStyling.CSS)
 
else:
 
  print(“Sorry, you are not authorized to access this file”)
 
</syntaxhighlight>
 
  
 
== Defense Mechanism #2 ==
 
== Defense Mechanism #2 ==

Revision as of 11:40, 25 November 2018

Cheatsheets-header.jpg

Last revision (mm/dd/yy): 11/25/2018

Introduction

The goal of this “CSS (Not XSS, but Cascading Style Sheet) Cheat Sheet is to inform Programmers, Testers, Security Analysts, Front-End Developers and anyone who is interested in Web Application Security to use these recommendations or requirements in order to achieve better security when authoring “Cascading Style Sheets.”

Let's demonstrate this risk with an example:

Santhosh is a programmer who works for a company called “X” and authors a Cascading Style Sheet to implement styling of the web application. The application for which he is writing CSS Code has various roles like “Student”, “Teacher”, “Super User” & “Administrator” and these roles have different permissions (PBAC - Permission Based Access Control) and Roles (RBAC - Role Based Access Control). Not only do these roles have different access controls, but these roles could also have different styling for webpages that might be specific to an individual or group of roles.

Santhosh thinks that it would a great optimized idea to create a “global styling” css file which has all the CSS styling/selectors for all of the roles. According to their role, a specific feature or user interface element will be rendered. For instance, Administrator will have different features compared to “Student” or “Teacher” or “SuperUser”. However, some permissions or features maybe common to some roles.

Example: Profile Settings will be applicable to all the users here while “Adding Users” or “Deleting Users” is only applicable for “Administrator”.

Example:

  • .login
  • .profileStudent
  • .changePassword
  • .addUsers
  • .deleteUsers
  • .addNewAdmin
  • .deleteAdmin
  • .exportUserData
  • .exportProfileData
  • ...

Now, let’s examine what are the risks associated with this style of coding.

Risk #1

Motivated Attackers always take a look at *.CSS files to learn the features of the application even without being logged in.

For instance: Jim is a motivated attacker and always tries to look into CSS files from the View-Source even before other attacks. When Jim looks into the CSS file, he sees that there are different features and different roles based on the CSS selectors like .profileSettings, .editUser, .addUser, .deleteUser and so on. Jim can use the CSS for intel gathering to help gain access to sensitive roles.This isa form of attacker due diligence even before trying to perform dangerous attacks to gain access to the web application.

In a nutshell, having global styling could reveal sensitive information that could be beneficial to the attacker.

Risk #2

Let’s say, Santhosh has this habit of writing the descriptive selector names like .profileSettings, exportUserData, .changePassword, .oldPassword, .newPassword, .confirmNewPassword etc. Good programmers like to keep code readable and usable by other Code Reviewers of the team. The risk is that attackers could map these selectors to actual features of a web application.

Defensive Mechanisms to Mitigate Attacker’s Motivation

Defense Mechanism

As a CSS Coder / Programmer, always keep the CSS isolated by access control level. By this, it means Student will have a different CSS file called as StudentStyling.CSS while Administrator has AdministratorStyling.CSS and so on.

Make sure these *.CSS files are accessed only for a user with the proper access control level. Only users with the proper access control level should be able to access their *.CSS file. *.CSS files should not be loaded for users without proper access.

If an authenticated user with the Student Role tries to access AdministratorStyling.CSS through forced browsing, access should of course be denied and alert that an intrusion is occurring should be recorded.

Defense Mechanism #2

Being a programmer or a tester, take care of the naming conventions of your CSS (Cascading Style Sheet) Selectors. Obfuscate the selector names in such a fashion that hackers don’t get a hint of what a specific selector is linking to. Of course, your customers or users who have access to their roles can always use Web Developer Tools to perform reverse-engineering in order to know the features using those selectors as they are authorised to use your application. However, they are not under Threat Actor category based on the context.

Example: CSS Selectors for addUser, addAdmin, profileSettings, changePassword can be something like aHj879JK, bHjsU, ahkrrE, lOiksn respectively.

This is just an example and you can use your own custom obfuscation, but watch out for “Rogue Insiders” who leave the company or who share the information about this specific obfuscation that you use in your code. Also, there have to be guidelines in terms of who should do this obfuscation activity and what happens when they leave the company? Of course, someone in the company need to change this obfuscation because someone out there in the web world knows what keys are you using?

Note that the usage of online obfuscators or some tools maybe deobfuscated very quickly and attacker can use the online de-obfuscators if you are using prefabricated tools.

This NPM package can be used to perform the renaming of the CSS selector.

Defense Mechanism #3

If your web application sends some styling via JSON request in specific features for various reasons, then make sure that the properties and values are not tampered with and also reject anything that appears to be suspicious or anything that is out of your whitelist. This attack may work even when you have escaped characters, or done input encoding and output encoding.

Example: Someone may just tamper with the request body of a specific feature and edit the styling to create an attack where height or width can be changed to make it look like fullpage & also every part of the webpage is clickable which will redirect the users to malicious websites which will inturn have multitude of attacks.

You can read about how LinkedIn had a vulnerability through Cascading Style Sheet which was fixed once reported.

Authors and Primary Editors

Santhosh Tuppad - https://www.linkedin.com/in/santhosh-tuppad-338b7412/

Other Cheatsheets