From Episode 3 – Securing .NET Applications | February 1, 2012

Security experts Joël Hébert and Steve Syfuhs talk all about security – principles, documentation, attack vectors, testing tools, and more.

Key Points

  • [03:14] Security as part of standard design documentation and why security is not part of day-to-day practices
    ”For me, herein lies one intrinsic problem with some of our business processes or the SDLCs we use. The penetration testers or the security officers or the threat-risk agents – the people who do the analysis – always come in at the end of the project. Reasoning being, it’s quite expensive to do a pen [penetration] test on your website and this goes on due to the fact that if you want to be a pen tester, it’s takes quite a bit of time depending on the risks involved. If you take the software architecture document and model out the security vulnerabilities from the start, you’ll be able to educate your developers right from the start and as they’re coding, you can mitigate against, let’s say anti-cross site scripting or cross-site request forward, you can do that from the start and you do it on multiple levels. You don’t just rely on one thing. What happens is that at the end of the project, you’re not scrambling or worried about your release. You have other things to worry about two weeks before the release, fixing the last few bugs that your clients want. It’s not time to start worrying about the security …”
  • [05:09] Making the business case building in code to handle security (that doesn’t have a direct business function)
    ”I think there are a few different ways of doing so. One of them, if I had to try to convince someone, I usually just go on Twitter and show them the antisec feed and show them how many things are compromised. If you take a look at some of the big agencies in the US, and we won’t name any of them, they’ve all been hacked last year. We’ve had an emergence of new terms – hacktivists, privacy by design – last year. So you see – nothing is really secure so sometimes you have to tell the customer that whatever you have in your database and expose that to the web, you have to be almost ready to share that with others because there’s no such thing as a secure website. It’s very nice, everybody likes to say that they are secure, they have these nice little things on their website saying that they are hacker proof and what not. This is not exactly the case, so you have to be very realistic with the client and explain to them ‘well, let’s put these mitigations into place, let’s get your clients to have some confidence in you and that will help you in your business practices.’”
  • [07:17] Do security principles and preparations go away for applications that are purely for internal use?
    ”I don’t think so… for an internal application you probably won’t have to do as much, but you still have to put in the basics. That’s my take on it. Protecting against a distributed denial of service attack on an internal site is ridiculous, but there’s definitely cross-site scripting and SQL injection and all of the basics should be handled.”
  • [08:51] Keeping passwords secret
    ”I’ve seen someone go as far as there is no password written down at any time. There’s only one person that actually knows the password. The database person puts it in, does the deploy, and that’s it – it’s forgotten. The least people that have these secrets the better it is. I have to agree with him [MrJames on the chat]. Sometimes it could be a disgruntled employee, sometimes it could be a client, and sometimes it could be somebody who handles the deployment.”
  • [10:10] Securing and testing any .NET applications (phone apps, cloud apps, etc)
    [Assuming that all of these security principles stay the same, just implementations might be slightly different] That’s correct. Usually if you have a vulnerability, it’s common across all vectors. If you’re utilizing a phone, and I decide to put in a SQL injection attack in there, if you have an SQL backend, and you’re not mitigating against it, it will probably go through the web service and go to the data store at some point. So whatever affects your .NET forms application, whatever affects your web service, whatever affects your Windows Phone, they’re approximately the same. You have to mitigate at all levels.”
  • [11:15] Built in Visual Studio tools to help with getting started with security
    The Web Protection Library that has the Microsoft anti-cross site scripting integrated into it. I like that one because it comes to augment. If you take a look at ASP.NET, the request validators, personally, since I know a few things that I can bypass them (I know about 7 techniques to bypass those request validators), what I like to do is take the Microsoft anti-XSS, I add it, and it comes to augment. It also whitelists and does quite a few nice things. … So now you have two levels of security – you have the request validators, you have the anti-XSS. I like to add an HTTP module that verifies cookies, form values, anything that’s posted and that sanitizes also, so it has to go through all three levels. This way you know whatever is being entered on your website is almost – not full proof – but quite a bit safe. … There’s also a scanner now that you can scan and tells you what’s wrong with the code.” (See part 3 of Steve Syfuhs’ Basics of Securing Applications blog series.)
  • [12:50] Other tools you can use
    ”[On Metasploit] That’s the tool here that you want if you want to test your web applications. Metasploit, and I would say BackTrack 5 (it’s a Linux tool). Those two things will incorporate everything that you need – all integrated.”
  • [18:10] Security in the Cloud
    ”About 10 years ago, someone coined the term ‘the 10 immutable laws of security’. As a developer, we know that immutable means essentially that it cannot change … Security really doesn’t change at a principle level. When we say, when we look at different types of attacks, conceptually, they never change. It is just a question of how are they implemented, how do we protect against them. The Cloud is really no different. By deploying to the Cloud, you get some benefits. For instance, you get automatic patching, so the attack vector of a ‘zero day’ or a flaw in a design that just got patched, we don’t really have to worry about things like that just because we’re not managing … we hope that the people who we’re giving money to are actually doing their job. We have trust in them. At the same time, there are a couple of new security problems we have to worry about. For instance, everything is now running in virtual machines, so there are new attack vectors that crop up. Because everything is, sort of, co-existing, on the same machines, you could potentially have an attacker who is sitting on the same physical hardware as you, just in a different virtual machine, so how do you protect against them breaching the underlying hardware and going across the hypervisor into your system.” [Same concept as before – by not managing the infrastructure, you’re deferring to your provider and trusting that they are protecting you from such attacks."]

For a deeper look at ASP.NET security

Joël Hébert

Joël Hébert is the Director and Chief Architect at Opulent ASP Development Inc. where he works as a consultant specializing in ASP.NET Enterprise Architecture/Development. He has developed large-scale web applications and Computer Aided Audit Tools for CaseWare-IDEA and is currently working on federal government projects. He is passionate about web application security and enterprise applications patterns.

Steve Syfuhs

Steve Syfuhs is a bit of a Renaissance Kid when it comes to technology. Part developer, part IT Pro, part Security Consultant working for ObjectSharp. Steve spends most of his time in the security stack with special interests in Identity and Federation. He recently received a Microsoft MVP award in Developer Security.

In case you haven't heard about the show, Developers, Developers, Developers: LIVE & INTERACTIVE (D³) is a monthly show hosted by Jonathan Rozenblit. The show airs live every first Wednesday of the month at 12:00 PM ET and features the latest updates on what's new and exciting in the world of development; featured presentations; and guests. LIVE and INTERACTIVE means that you'll be part of the show – You're invited to interact with us; ask questions and get them answered; and share your thoughts and opinions.

 Join the Canadian Developer Connection LinkedIn group
 Follow @devsdevdevs
 Like D³ on Facebook
Subscribe to podcasts via iTunes, Zune, or RSS