SameSite Cookies – What are they?

SameSite cookies is a new cookie attribute proposed by the folks over at Google and Mozilla to allow cookies to be declared as “same-site” and therefore shouldn’t be attached to cross site requests; essentially mitigating Cross Site Forgery Requests (CSFRs). This feature is currently present in Chrome 51 and Opera 39.

If you have a website that uses cookies then you can start supporting SameSite cookies straight away, by simply adding the SameSite attribute in the Set-Cookie field. Now the SameSite attribute requires a value (else it will be ignored) – the choices are: Lax or Strict.

You’d implement them by using either:

  • SameSite=Lax
  • SameSite=Strict

So what’s the difference between Lax and Strict?

Strict

Strict, as you will have probably guess is the more rigorous and robust option for protection, it would more than likely protect against all CSFR attacks, however this comes at a cost – the cookie is not sent with ANY type of request, including GET requests.

For example: If you click [GET request] on a tweet with a link to a Facebook album hosted on facebook.com – and facebook.com is using strict mode then the user wouldn’t be taken to the facebook page and already be logged into facebook.com, even if they were already logged in.

This is because the browser will not be allowed to send cookies from twitter.com to facebook.com

Lax

Lax is the less severe of the two options, by only stopping cookies being sent cross domains if it’s using HTTP methods that we’d call unsafe such as DELETE or POST.

This means that in the strict example above the user would be logged into facebook, however if: A user submits a form [POST request] on a website where the target is facebook.com then if facebook.com is using lax mode then the request would not go through.

So in conclusion, strict mode provides much better security, though breaks some functionality. Linking to a resource on a website such as private facebook album wouldn’t work from external sites, even if you were logged into facebook and would have access to the album normally. In lax mode this scenario would work, however you would be better protected from cross site post or delete requests such as auto-posting an advert on your facebook wall, which I think we’d all be happier without.

Access Umbraco back office user from the front end

If you need to access the current user logged into the Umbraco Backoffice from the Front End (to show a link to administrator area for example) you may have tried:

umbraco.BusinessLogic.User.GetCurrent()
UmbracoContext.UmbracoUser
UmbracoContext.Security.CurrentUser
umbraco.helper.GetCurrentUmbracoUser()

None of which seem to work, then you should user the following code:

@using Umbraco.Core.Security;
var userTicket = new System.Web.HttpContextWrapper(System.Web.HttpContext.Current).GetUmbracoAuthTicket();
if (userTicket != null) {     
 var currentUser = ApplicationContext.Services.UserService.GetByUsername(userTicket.Name);
}

As Andrew Wilson mentions in the comments, remember to include Umbraco.Core.Security – though if you forget hopefully Visual Studio will tell you to add it.

Find source property name from automapped object

So if you find yourself wanting to find the source property of a view model that caused an entity validation error in the destination when you’re using AutoMapper to map one field to
another then here you go:

First create a TypeMap to perform a lookup against:

var map = Mapper.FindTypeMapFor<YourViewModelClass, YourEntityClass>();

Then for each of the error in the EntityValidationErrors lookup the Destination Property using the Validation Error’s Property name

ex.EntityValidationErrors.SelectMany(e => e.ValidationErrors).ForEach(e =>
{
var errorItem = map.GetPropertyMaps().FirstOrDefault(x => x.DestinationProperty.Name == e.PropertyName);
});

Now the errorItem variable has a property called SourceMember.Name which is the name of the property in the View Model.

So then you can add a error to the ModelState in the loop:

ex.EntityValidationErrors.SelectMany(e => e.ValidationErrors).ForEach(e =>
{
var errorItem = map.GetPropertyMaps().FirstOrDefault(x => x.DestinationProperty.Name == e.PropertyName);
this.ModelState.AddModelError(errorItem.SourceMember.Name, e.ErrorMessage);
});

Then when you return the ViewModel back to the page it will highlight the affected field and display the entity validation error.

Subresource integrity

A new feature in Google Chrome 45 is the ability to add meta data inline to <script> and <link rel=”stylesheet”> elements which will allow the browser to determine if the resource which has been downloaded is the same as the author intended.

This is done by adding integrity  metadata to the element inline such as:

<link rel=”stylesheet” href=”this_is_verified.css” integrity=”sha256-qvuZLpjL9TNV6yI1kNdGCPnSTrWM6Y0ILEzzyvA9hGY=”>

You would generate the base64 encoded version of the SHA256 hash with the following command:

cat this_is_verified.css| openssl dgst -sha256 -binary | openssl enc -base64 -A

If the hash doesn’t match the file and the integrity is compromised the browser will not load the resource.

This is currently in development for Firefox as well, though no news on Edge or Safari for implementation.

.NET MVC model null on POST

I came across a problem whilst building my latest application, when I was sending a model from a create view the model was showing up null on post.

The code that wasn’t working:

public class FileNote
{
public int CaseID { get; set; }
public string Title { get; set; }
public string Note { get; set; }
}

[HttpPost]
public ActionResult CreateFileNote(FileNote note)
{
bool fileNoteAdded = FileAccess.Create(note);
//etc etc...

};

Now when the model arrives the object is null, this is because I’ve named the parameter note which is also the same name as one of properties of FileNote. The model binder gets confused trying to bind the property of the model rather than the model itself. Changing the code to the below fixes the issue.

[HttpPost]
public ActionResult CreateFileNote(FileNote newNote)
{
bool fileNoteAdded = FileAccess.Create(newNote);
//etc etc...

};

jQuery.hashIdentity

Identify hashes using javascript.

This plugin allows you to identify hashes using regular expressions.

$(this).hashIdentity(hash); Returns: Array of hash types it may be.

Description

By passing a string of the hash to the plugin it will return a list of possible hash types it could be.

Example

var listOfHashes = $(this).hashIdentity(“35d715dbd2b390af1f5596b2118f7216”);

Demo

Visit: http://ryanmcdonough.co.uk/hashidentity/index.html

Extending CurrentPrincipal

If you are wanting to use the built in ASP Identity but you are also wanting to store extra data against that user whilst they use the website then you can extend the CurrentPrincipal easily.

So in this case I’m going to use it in the sense of it being for a company called Company, here’s my extended code:


public class CompanyPrincipal : IPrincipal
{
private _Company_Employee_Access employeeAccess = new _Company_Employee_Access();
public _Company_Employee_Detail Information { get; set; }
public IIdentity Identity { get; private set; }
public CompanyPrincipal(IIdentity identity)
{
Information = employeeAccess.getEmployeeByName(identity.Name);
this.Identity = identity;
}
public bool IsInRole(string role)
{
throw new NotImplementedException();
}
}

So the extra information we want to store is an instance of: _Company_Employee_Detail called Information.

We fill it using employeeAccess.getEmployeeByName(identity.Name); so that would be your code to return _Company_Employee_Detail with the correct information.

In MVC you can then access it like so:

@{
ViewBag.Title = "Home Page";
var User = (CompanyPrincipal)Context.User;
}

Sup @User.Information.FirstName ?