Woo Hoo!

If you are a web developer using VS 2005 then this is a must read!

Scott Guthrie (one of the nicest and brightest guys you will ever meet) has posted that his team has released the final version of the VS 2005 Web Application Project Model option.  This is the add on that allows you to run your VS 2005 web application projects like the good old days of VS 2003.  Project files, single DLLs and all the other things that make things easier are there.  But wait!  There's more! 

infomercial mode = off

OK, I know I am getting carried away, but this is very good news.  This release also contains Edit and Continue for VB.Net and C# web apps.  We haven't had this since early Beta of the original ASP.Net (for those that don't remember, it got yanked before the product shipped).

Check out Scott's post along with lots of screenshots on how to configure and use Edit and Continue here.

Yet another step has been taken by the bad guys in the arms race that is phishing attacks.

I expect that everyone knows that phishing is when you get an email or some other communication that looks like it is offical from someplace like paypal.  The communication is trying to get you to go to a link that is designed to make you think it is legit, but in fact takes you to a bogus site that is stealing your information.  Whether for identity theft or so the bad guys can use your paypal to buy stuff the result is the same, theft.

Fast forward to the latest version which doesn't even require the user to be fooled into clicking on a link.  Instead of using the old technique, full fledged hackers are getting in on the game.  Phishing is more of a social engineering play, but with the new model hackers take over the ISP that hosts the site in question, most often a smaller, regional bank.  Once they have exploited the server they redirect traffic from the real web sites to their fake version that will include screens to ask for the information of interest.

This is a really bad development.  This means that if my bank or other site I use that handles money is hacked in this way, then when I open my browser and type in the address myself (formerly the tried and true way to ensure you were going where you expected) then I still end up on the bad guy's server.

There aren't alot of ways for the average user to detect this attack.  A pro can sometimes notice subtle mistakes in the copy site or might even notice a redirect flash, but my parents are not prepared to open up logs and do pings and other kinds of things to know they are truly at the right place.

It is up to our financial institutions to take some very important steps that they seem to be very slow in taking:
 -  Do actual and real security audits to ensure their servers are not vulnerable
 - Implement some kind of image selection when setting up an account for the user and always displaying the image when that user is logged in. If done well then this helps even novice users detect this kind of scam.
 - Reconsider shared hosting and look into either self hosting or dedicated server hosting if you must go with an ISP

There is an article that talks about specific examples of this exploit if you look here.

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> ;)