AntiCSRF Protection Measures In Chariot Command

 

About CSRF

CSRF stands for Cross Site Request Forgery,   With it, the attacker tricks an unsuspecting user with a malicious web page.  The malicious page then steals the credentials of the user, and then uses those credentials to perform bad things against your website.

There is a ton of information on the Internet about CSRF.  Here are a few to help you learn about it:

• https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
• http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
• http://en.wikipedia.org/wiki/Cross-site_request_forgery

 

Chariot Command CSRF Protection Mechanisms

Chariot Command provides a “reverse-proxy” that modifies html code on the fly to insert CSRF protection mechanisms.  We use the “double-submit-cookie” protection mechanism as described on Coding Horror. 

CSRF protection takes place in two steps:

1. Modify the pages calling the protected commands to insert a token to check against the cookie.
2. On submission of the form (or click of a protected link), check that both the cookie and the token on the form match up.

Our reverse proxy modifies the generated html code with the following rules:

1. If the user loading the page is not logged in, then nothing is done.  (CSRF relies on credential stealing, of nothing is there to steal, modification of forms is pointless)
2. If the user loading the page is logged in then the defaults are:
   1. Modify forms to add a hidden value that must match the hidden cookie.
   2. Leave Links alone.

Token Generation

Changing The Default Logged Token Generation In Behavior

1. Anchors (“a”) tags, will have a security token generated in the link if you add “nocsrf” to its ‘class’ attribute.
2. Forms can be forced to not have the security token generated by adding “allowcsrf” to its ‘class’ attirbute.

Forcing Creation of Security Token

Under normal conditions, whenever a user logs in, a CSRF token is created. However, if no session is created and you need a CSRFToken, how do we know when to create one? Tag either a command object or method with this annotation, and it'll ensure that a Session is being created along with the appropriate CSRFToken.

Example 1:

The following class will have Security tokens generated no matter what method is invoked:

	import org.chfw.command.annotations.WebCommand;
	import org.chfw.command.annotations.SecurityTokenProvider;

	@SecurityTokenProvider
	@WebCommand
	public class Example1 {
		public methodOne() {

		}
	
		public methodTwo() {

		}	
	}

Example 2

The following class will generate a security token when methodOne is invoked, but not methodTwo

	import org.chfw.command.annotations.WebCommand;
	import org.chfw.command.annotations.SecurityTokenProvider;

	@WebCommand
	public class Example1 {
		@SecurityTokenProvider
		public methodOne() {

		}
	
		public methodTwo() {

		}	
	}

 

When to use CSRF protection mechanisms

Not everything has to be protected from CSRF vulnerabilities.  For example, a list of public documents doesn’t necessarily have to be protected.  Updating or deleting a publically available document should be protected. 

The basic rule of thumb would be:  GET methods are typically not protected, POST, PUT, or DELETE operations should be guarded against.

But as you should well know if you’ve done much software development, rules of thumb don’t always hold.  For example, a GET operation that exposes your address book should be protected against CSRF since the information being divulged is sensitive.  (That’s why we have to allow for Anchor tags to have nocsrf in their ‘class’ attribute)

Enable CSRF Token Checking on Various Command Methods

Use the “SecurityTokenRequired” annotation to tag methods to be protected against CSRF.

Example:

The following example protects methodTwo() against CSRF protection. Like the previous set of examples, you may also tag the entire command class with SecurityTokenRequired to protect access to all methods.

	
	import org.chfw.command.annotations.WebCommand;
	import org.chfw.command.annotations.SecurityTokenRequired;

	@WebCommand
	public class Example1 {
		
		public methodOne() {

		}
	
		@SecurityTokenRequired
		public methodTwo() {

		}	
	}

The CSRF protection mechanisms in Chariot Command are not difficult to use, and since  CSRF-based hacks are making the headlines nearly every day, we cannot stress the need for you to employ these methods (or at least roll your own anti-CSRF protection measures.)