Latest Microsoft Blogs

Now that we presented the scenario & the requirements , let’s take a look at the solution. What is conceptual solution we propose? Fabrikam Shipping in the pre-Claims era: This diagram shows Fabrikam Shipping today if used by Adatum (no claims, no federation): You will see the usual suspects for a typical .NET web application. Furthermore, Fabrikam is using standard providers for authentication, authorization and profile. In this configuration, everyone in Adatum must use, of course, user name & passwords. The username is the handle associated with a role in the roles database, which drives application behavior (what you can do). In the example, John from sales, can only Order New Shipments, but Peter from Customer Service, can Manage...

Once again, thanks everybody that wrote us with reviews, feedback and suggestions! Please keep it coming! Also: we hope to have soon a CodePlex site where we can start sharing more. We are still working out some details. As usual, the Disclaimer: this post and the next ones are early drafts to share with you the direction we are taking. They might (and I hope they will) change quite a bit in the actual Guide ! We might end up not covering one of these scenarios in the book. An additional disclaimer for this post: I wrote the whole scenario following the same template of the previous posts and it resulted in a very loooong article. So I divided it into two parts. This is Part I –> the scenario, the challenges and the requirements. Part II...

I open several PDF files every day ! Check out these latest attack statistics from CNet Microsoft has always been the Hack Attacker’s favorite victim, but in recent years we’ve made it harder and harder to successfully attack Microsoft products. And so, the bad guys are diversifying their efforts – and Adobe seems to now be in their cross hairs. [ Click HERE to tread the article on CNet News ]   Technorati Tags: Microsoft , Adobe , Security , Hacker , Attack Read More...

A member of the Subtext team discovered a security vulnerability due to our integration with the FCKEditor control as well as the FreeTextBox control. This vulnerability would potentially allow unauthenticated users to upload files using the file upload tools included with these editors. The Fix If you’re running the latest version of Subtext (Subtext 2.1.1) , the quickest way to patch your installation is to copy the following web.config file… < configuration > < system.web > < authorization > < allow roles ="Admins" /> < deny roles ="HostAdmins" /> < deny users ="*" /> </ authorization > </ system.web > </ configuration > …to the following directories within...

In my last post, I wrote about the hijacking of JSON arrays . Near the end of the post, I mentioned a comment whereby someone suggests that what really should happen is that browsers should be more strict about honoring content types and not execute code with the content type of application/json . I totally agree! But then again, browsers haven’t had a good track record with being strict with such standards and it’s probably too much to expect browsers to suddenly start tightening ship, not to mention potentially breaking the web in the process. Another potential solution that came to mind was this: Can we simply change JSON? Is it too late to do that or has that boat left the harbor? Let me run an idea by you. What if everyone got together...

In my last blog post , I walked step by step through a Cross-site request forgery (CSRF) attack against an ASP.NET MVC web application. This attack is the result of how browsers handle cookies and cross domain form posts and is not specific to any one web platform. Many web platforms thus include their own mitigations to the problem. It might seem that if you’re using Web Forms, you’re automatically safe from this attack. While Web Forms has many mitigations turned on by default, it turns out that it does not automatically protect your site against this specific form of attack. In the same sample bank transfer application I provided in the last post, I also included an example written using Web Forms which demonstrates the CSRF attack. After...

Today I read something where someone was comparing Web Forms to ASP.NET MVC and suggested that Web Forms does a lot more than ASP.NET MVC to protect your site from malicious attacks. One example cited was that Server controls automatically handled HTML encoding so you don’t have to really think about it. The idea here is that Web Forms automatically protects you from XSS attacks. My friends, I’m afraid this is just not true. Take a look at the following page code. <%@ Page Language="C#" Inherits="System.Web.UI.Page" %> <% //For demo purposes, we have inline code here. // Pretend the following userInput came from the database string userInput = "<script>alert('You’ve been Haacked!');</script>"...

Earlier this morning, I posted on making a simple jQuery delete link which makes it easy to create a delete link that does a form post to a delete action. Commenters pointed out that my solution won’t work for down-level browsers such as some mobile phones, and they were right. I wasn’t really concerned about down-level browsers. One solution for down-level browsers is to render a proper form with a submit button, and then hide the form with JavaScript. Of course this takes a bit more work. Here’s what I did. I made sure I had the following script in my master template. < script type ="text/javascript" > $( "form.delete-link" ).css( "display" , "none" ); $( "a.delete-link" ).show(); $(...

In a recent post, Stephen Walther pointed out the dangers of using a link to delete data . Go read it as it provides very good coverage of the issues. The problem is not restricted to delete operations. Any time you allow a GET request to modify data, you’re asking for trouble . Read this story about something that happened to BackPack way back in the day to see what I mean. The reason that delete operations deserve special attention is that it’s the most common case where you would use a link to change information. If you were editing a product record, for example, you would use a form. But a delete operation typically only needs one piece of information (the id) which is easy to encode in the URL of a GET request. If you are using jQuery,...

Every time I talk with customers in meetings or at conferences I’m struck by how many cool amazing new capabilities IIS7 has.  I can go on for literally hours talking about the new features and benefits, and showing demos.  And with each new IIS7 Extension , the list of new features just gets bigger and bigger.  A few months ago I realized we didn’t have the top list of features written up anywhere, and so we started the process of distilling down the list to the top 10.  We almost made it!  We ended up with the top 12 reasons you should get IIS7 today.  Check them out here: http://www.iis.net/getstarted Over the next few weeks we’ll be adding a cool demo for each of the reasons to show the features in action. ...