If you are into threat modeling (and you should be) then you should check out the latest version of the product formerly code named “Torpedo”. I think this is the first product to make real strides (bad pun intended) toward making threat modeling more approachable for the average developer.
Get it at:
http://msdn.microsoft.com/security/securecode/threatmodeling/acetm/
At Code Camp 5 in Waltham this past Sunday I was delivering my session entitled “All you need to know about Membership”, when I learned that I didn’t know everything I need to know about membership.
Someone asked if the scripts were available that aspnet_regsql.exe uses to create the membership table. My answer was that I hadn’t seen them so I assumed they were baked into the exe. WRONG! Our good buddy and fellow Code Camp presenter, Dan Krhla, pointed out that in the same directory that you find the aspnet_regsql.exe (namely C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727) you also find the scripts that the tool users including InstallMembership.sql. There are a bunch of them and you have to install them in order (installcommon.sql first, etc.). They offer some good insights and I have already spent a bit of time on them myself.
Thanks again Dan and I am happy that the question came up so I could learn something too. This is why I really love the Code Camp.
MS has committed, at some level, to support VB6 on Vista. In an article from February there are some details, but we now know that if you have a VB6 application that you cannot live without, you will probably be OK for years to come.
This is both good news and bad news. While I feel the pain of people who depend on these legacy tools for their products to work, I can’t help wincing when I see this because old tools support old techniques and technologies that are often just not up to the task of building secure applications. Everything from cryptography to SQL Injection have evolved as have the tools to combat them.
If you are using / depending on VB6 then congratulations, but my advice is to get off of it (from a seasoned VB developer) unless you can really and truly convince yourself that it poses no weaknesses in security based on your use of it. Eventually you will have to jump.
A friend of ours, Phil, sent Duane and I a link to an article about web attacks (Phil does this alot). He commented that he hadn’t heard of CRLF Injection before and while I had heard of it, I realized that I wasn’t comfortable explaining it on the spot with examples so I read the link.
While I think the writeup is good and felt refreshed of information on the topic (as esoteric as it is given how often we still find SQL Injection), I was struck by one badly worded comment in the text. Namely the section that says, “The best way to defend against CRLF attacks it to filter extensively any input that a user can give. One should “remove everything but the known good data” and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server”. The premise is well intended, but did you see the flaw? Why would you remove anything from a submission that has anything bad in it? OK, maybe there are innocent times when a user will insert something that doesn’t belong. However if you are doing the filter thing and you find something bad, overtly bad then you shouldn’t remove it, you should end the user’s session and redirect them to an error page (or some other circle of hell).
If a criminal came to your house and tried to open a window only to find it locked would you then allow them to keep trying? If you can determine that the input was actually harmful (the opposite of good data) then you should think hard about maybe dumping the user and not going any further in their processing.
If you make your applications work more like the way the real world works then they are more likely to survive in the real world.
</rant> 
Scott Guthrie pointed me at a link to the source code for the ASP.Net 2.0 providers including the Membership and Role Management providers. While I think the Profiles, Web Parts and Site Navigation providers are important and cool, I expect to do much more with the Membership provider. Expect to see some customizations in presentations I give in the future.
I think this is a great step and am not surprised to see Scott doing something this cool.
Check it out!
I was recently asked by a very technical and very sharp friend of mine about the symantics of permissions on copy.
I figured if he needed some guidance on how this works then there must be a ton of other developers who could use a refresher so here goes:
There are alot of reasons that a developer or QA engineer must use copy or move to get their applications running for test or even for production. The problem is that the same old processes that worked so many times before can often mask a misconception or two that arise as “bugs” when the moons do not align to make the old process function as expected. Case in point. You want to deploy a web application which has notoriously particular permissions requirements. If copy has always worked in the past, but on the new server you are getting strange permissions then you might be forgetting some of the rules.
The first thing to take into account is whether this is this a move within the same volume (nothing fancy) or a move across volumes (maybe obscured by DFS) or even just a plain old copy (often the case).
A move within volumes would mean you should have the permissions preserved. A move across volumes is actually a copy and a delete combined and means you are just getting the permissions of the target folder which is by design and this is also the behavior of a copy unless you use something like scopy which preserves permissions.
If a copy in the past has preserved permissions and you didn’t use scopy (very handy by the way) then either there is a setting in Windows that I am unaware of (please enlighten me) or you got lucky in the past and the target folder permissions were what you expected.
Usually file permissions and especially the semantics of permissions on copy vs. move are the domain of network types. In many cases it helps alot to be a mongrel from both worlds.
As promised, but fashionably late as always, here are the slides from this Saturday’s Mini Code Camp Security Edition.
I want to thank everyone that attended and the feedback has been great (no death treats so far)!
Membership.ppt (752 KB)
Security Best Practices.ppt (579 KB)
Check Duane’s blog at www.cyberspacesamurai.com for his slides.
See you at the next Code Camp!
Thanks
Patrick
In dealing with our teams of developers and engineers I find myself preaching some basic rules that make life easier for me when I try to deal with the legion of emails I get every day. I thought to document them and in doing so realized that they have a decidedly security slant to them (big surprise).
Here are some rules of etiquette that will allow you to survive my spam filter (outlook junk mail) and not get deleted for cause:
I could go on and on about all caps being like yelling, but that isn’t my intention. I had figured that everyone already knew about these and yet I still get these things sent to me times per day and often by very technical people.
Be safe…
Microsoft has chimed in on the questions about ClickOnce security raised by Dominick Baier and basically is asserting that this is a non-issue.
I am not buying. I think that using the excuse that older technologies do something a certain way undermines the principle of secure by default.
What do you think?
If you are at all into security or even if you just think technology is cool then you have to watch the latest episode of the The Code Room. In this latest episode you will see our own Duane Laflotte, our resident top hacker as part of the team of evil doers that hack a casino in vegas.
I think it is really well done and makes some good fundamental points about security in a very entertaining way.