Places To Go
News and Reviews....
People To See
Places To Go
Thursday, May 25, 2006
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:
Monday, May 08, 2006
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.
Wednesday, May 03, 2006
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.
Thursday, April 27, 2006
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.
Thursday, April 20, 2006
Sharing a web server between development teams is always fun (not). We had a problem surface today (or resurface) where if a developer creates a web application on IIS that uses .Net 1.1 for example (not an uncommon occurance) and some other developer creates a web application on that same server but this second one uses .Net 2.0 (something becoming more common every day). Odds are that the developers and even sometimes the network engineer or web master will allow the defaults to lull them into the false sense that it was an easy and straightforward task.
The problem is that they both allowed the "Default Application Pool" to remain selected and now the second of these sites to load will crash IIS.
You can't have two different versions of .Net loaded into the same process and Application Pool often (though not always) means the same process.
Scott Forsyth has an article about this very issue that will help describe the error that occurs when you have this problem (the "Server Application Unavailable" error).
If you haven't seen this yet, then you will.
Friday, April 14, 2006
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!
Wednesday, April 12, 2006
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.
Wednesday, April 05, 2006
Like the Code Camps another good idea is coming out of the Microsoft Developer Evangelists. This time it is a web site with an interesting concept. If you go to http://www.community-credit.com/DevCommunity.aspx you will see it in action and also be able to see the people who are working hard to build their technical communities. Think of it as an ongoing public resume where people who contribute to the community get credit for their efforts.
I think this is a good step in building a nice feedback system so the dev community keeps going.
Check it out.
Monday, March 27, 2006
Wednesday, March 22, 2006
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:
- Always put a subject on the message (the more specific the better). I am noticing a ton of no subject emails in my junk mail folder and I don't scan the addresses before I delete them. Not putting in a subject is a technique used by spammers to make you view the message. For me and a growing number of people it backfires. Call it a pet peeve, but if you can't be bothered to put a subject on a message then I can't be bothered to read it.
- Never send an attachment unless I expect it (you told me in a previous message that you are sending it) or you explain what and why you are sending it in a way that lets me know that you had to have written it. Remember that anyone can send a message as you if they really want to do it.
- If you send me a link then tell me what is at the other end. There are many sites that lure you in and do something amusing. Why would you assume that they aren't being used to infect or subvert your computer. There are many "drive-by" exploits that only need the page to be viewed from a vulnerable machine to do their work.
- If I know a password or other secret then you can refer to the password or secret, but avoid sending it in an email. It just isn't a secure medium.
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.