Recently I’ve been updating the configuration of a bunch of personal servers to match the 2016 PCI requirements. One of the 2016 PCI requirements requires you to disable TLS 1.0 as it is now considered insecure. One of the problems with doing this of course is the fact that WebDeploy uses SSL and by default won’t allow connections and deployments to occur with TLS disabled. Luckily the fix is rather simple.

When writing forms for your ASP.Net MVC websites the common approach to ensuring only real people use them site is to simply add an Html.AntiForgeryToken() to your form’s view mark-up and controller and be on your way. I've recently found out this approach while simple, can actually have pretty serious affects on both how your visitors use of your site as well as their view of it’s professionalism and stability – two things you really don’t want any trouble with.

Web application security's had a lot of coverage in recent times with a lot of attention paid to approaches to dealing with user generated content or exposing form or query string data to users. Thanks to a number of big hacks over the years you commonly hear about the risks of not properly encoding user data and the risk it poses to your visitors. One thing you don't hear often is how user entered CSS can have just as much risk attached to it – thanks to accidental support for HTML Components (HTC's).

Today starts this year's Microsoft TechEd conference up on the sunny Queensland Gold Coast and I'm lucky enough to be up here for the week watching many top Australian and international developers and IT professionals working on  the Microsoft stack, hacking on new frameworks and tooling, and perusing product wares. This is my second year at TechEd and I'm looking forward to more of the same awesome everything that we saw last year.

Continuous Deployment is an time-saving, team-loving, kudos-earning, stress-reducing capability that any team is wise to implement. OnCheckin is definitely aiming to bring this awesome’ness to as many ASP.Net developers as possible by making it fast and easy to setup. Once you’ve started out automating deployment though iteration is the key. Deploying your website early and often is great but with OnCheckin this goes further – Add-ons. And where better to start than helping developers out than with an often overlooked part of web development: Application Security.

These days we’re lucky. SSL is becoming pretty pervasive. Facebook uses it. Twitter uses it. Most modern start ups now use it. Sadly there are still other sites or services that you may be accessing on the internet that are still insecure allowing others to listen in on your internet usage, and for these your want an encrypted VPN link to route your traffic through. VPN’s can be expensive though if all you have is a home PC and a laptop on the road – lucky for us this can be a magic combination that is all you need and saves the day.

When it comes to reviewing visitor site usage, server bandwidth usage, or forensic security investigations; IIS log files often hold the answers. Although as I'm sure you’re more than aware, gigantic text files can be hard to view let alone pull intelligence from. Investigating a website attack can be really daunting when looking at log files as an information source. In my previous post I covered a tool to help with Windows Security Logs. Lucky for us it’s just as awesome when dealing with huge IIS logs.

When bad things happen to either your website or your server you’re usually faced with a situation that either makes or breaks you. Much like having a good backup and restore plan, being able to filter and scan log files for what you need to help draw conclusions on how a situation occurred or by whom it was conducted, is an important part of your security plan. However if you have a heavily traffic’d website, network share or part of your file system and you’re doing a lot of logging, you probably have files the size of the moon to wade through, so making sense of them can be a nightmare.

Over the last week a few stories have moved through the Ruby On Rails and wider development community as one of their shining stars, GitHub was hacked to draw attention to some of the weaknesses that can come about from ROR’s convention-based model binding. The interesting thing about the security hole found at GitHub is that it is not necessarily limited to Ruby On Rails, but often comes from using a framework that supports model binding out of the box without understanding the security limitations up front. It also brings a question to the fore: Is it the role of framework developers to force any security configuration to be the default instead of being explicitly applied?