![]() ![]() To disable it, add/edit the Registry key detailed in this Microsoft KB article. RC4 ciphers are also considered to be cryptographically broken, and again are enabled by default on many Windows servers. SSL V2 is considered to be cryptographically broken, however it's enabled by default on many Windows servers. Here's the output from a cURL request to my website for example: This is to protect against main-in-the-middle and Strip HTTPS attacks.įor example if a user browses to they will receive an HTTP 301 Moved Permanently and be redirected to instead. This ensures your IIS server returns a HTTP 301 Moved Permanently or 302 Found HTTP code and redirects to the HTTPS version of your site. This is an IIS setting, and it's pretty easy to enable. With no further ado, the things to make sure you do. If that's true, that's your call - after all, it's your website. Also, some may not be appropriate for your website. I believe they do, but I don't have the full resources to exhaustively test every single one. Also, these fixes may not solve a particular vulnerability fully. ![]() While these changes worked for me, make sure you test them yourself to ensure they solve the issue for you. In the spirit of Scott Hanselman I'd just like to point out: any changes you make are at your own risk. After that there's some links to resources you can use to help test your site to check for a number of vulnerabilities you want to be protected against. Some fixes are code, some are Web.config settings, and others require digging around in the Registry. I've arranged them by flaw/requirement, with a quick explanation for each and then the steps to fix. So, Dear Reader, why have I written this? Well, I thought it would be a good idea to collate all the stuff that's best practice into a single blog post, and then include for each one the instructions of how to fix it. ![]() Some required some creative Googling to find, others were right there (if you knew what you were looking for). There were a lot of resources where just one problem would be described (and sometimes a fix for it described), but a lot of the time there'd be a page about a problem, but you'd need to go to a completely different one for the fix. However, after three rounds of realisation, fixing and testing, there was one common theme I found with all of this - there was no central resource detailing how to fix all of the issues that came up. It was very useful as it was quite eye-opening to discover what seemingly innocent "oh that's not important" small niggly things could, in the hands of a skilled "hacker", actually lead to your machine being completely owned by an attacker. The title was a bit of a misnomer, as it wasn't so much "how to code securely" as "how to find security problems". Then there was the security testing course. ![]() This meant yet further reading to find out how to fix the software issues, as well as reading further afield to find out how to fix the server and network configuration issues as well. However, a secure app is a secure app, meaning that you just can't ignore it because it's not controllable by the code. They also did some tests which were more of the server and network configuration, which in some cases fell out of my personal work remit. This was slightly more work, as they were very good at saying "X is an issue", but almost useless at saying how to fix it. The same was true of the results from the dedicated security testers. Fixing these was a mix of "Oh yeah" realisations or a quick Google leading to MSDN or Stack Overflow, leading to some simple one-line changes here and there. These were exclusively application/coding changes. This has been from a mix of hands-on testing of them myself, dealing with feedback from dedicated security testers testing the applications, and this week attending an "ASP.NET Secure Coding" training course.įrom my own testing I found the odd thing here and there during development based on what I've read in the past is best-practice. So recently I've been doing some work ensuring some websites I work on are secure. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |