Security
There are 16 entries for the tag
Security
This is the third in a three part series related to HTML encoding blocks, aka the <%: ... %> syntax.
Html Encoding Code Blocks With ASP.NET 4
Html Encoding Nuggets With ASP.NET MVC 2
Using AntiXss as the default encoder for ASP.NET
Scott Guthrie recently wrote about the new <%: %> syntax for HTML encoding output in ASP.NET 4. I also covered the topic of HTML encoding code nuggets in the past as well providing some insight into our design choices for the approach we took. A commenter to Scott’s blog post asked, ...
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...
A Cross-site request forgery attack, also known as CSRF or XSRF (pronounced sea-surf) is the less well known, but equally dangerous, cousin of the Cross Site Scripting (XSS) attack. Yeah, they come from a rough family. CSRF is a form of confused deputy attack. Imagine you’re a malcontent who wants to harm another person in a maximum security jail. You’re probably going to have a tough time reaching that person due to your lack of proper credentials. A potentially easier approach to accomplish your misdeed is to confuse a deputy to misuse his authority to commit the dastardly act...
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,...
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...
UPDATE: I have a followup to this post that works for down-level browsers. 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...
I recently learned about a very subtle potential security flaw when using JSON. While subtle, it was successfully demonstrated against GMail a while back. The post, JSON is not as safe as people think it is, covers it well, but I thought I’d provide step-by-step coverage to help make it clear how the exploit works. The exploit combines Cross Site Request Forgery (CSRF) with a JSON Array hack allowing an evil site to grab sensitive user data from an unsuspecting user. The hack involves redefining the Array constructor, which is totally legal in Javascript. Let’s walk through the attack step...
As Scott wrote last week, using a punny title I have to admire, he and I (among many others) were both the subject of a DoS (Denial of Service) attack. Looking through my logs, it looks to actually be a DDoS (Distributed Denial of Service) attack coming from multiple IP addresses. The attack appears to actually be an attempt at a SQL Injection attack, but for his blog, which stores its data in XML files, that is entirely pointless. For my blog, which doesn’t do any inline SQL, it’s also mostly pointless. So far, the SQL injection part of...
We all know that it is bad bad bad to trust user input. I don’t care if your users are all ascetic monks in a remote monastery, do not trust their input. However, user input often likes to put on sheep’s clothing and disguise itself as something else entirely, such as the case with ViewState. Another example of this is highlighted in the latest entry of his excellent series of ASP.NET MVC tips. In this post, Stephen Walther writes about how cookie values and server variables can be passed as parameters to action methods. Immediately, commenters understably asked...
When you create a new ASP.NET MVC project using our default templates, one of the things you might notice is that there is a web.config file within the Views directory. This file is there specifically to block direct access to a view. Let’s look at the relevant sections. For IIS 6 (and Cassini) <add path="*.aspx" verb="*"
type="System.Web.HttpNotFoundHandler"/>
For IIS 7
<add name="BlockViewHandler" path="*.aspx" verb="*"
preCondition="integratedMode" type="System.Web.HttpNotFoundHandler"/>
What these sections do is block all access to any file with the .aspx extension...
This is a quick follow-up to my last post. That seemed like such a common test situation I figured I’d write a quick generic method for encapsulating those two tests. I’ll start with usage. [Test]
public void FileBrowserSecureCreationTests()
{
AssertSecureCreation<FileBrowserConnector>(new string[] {"Admins"});
}
And here’s the method.
/// <summary>
/// Helper method. Makes sure you can create an instance
/// of a type if you have the correct role.</summary>
/// <typeparam name="T"></typeparam>
/// <param name="allowedRoles"></param>
public static void AssertSecureCreation<T>(string[] allowedRoles
, params object[] constructorArguments)
{
try
{
Activator.CreateInstance(typeof (T),...
This is a simple little demonstration of how to write unit tests to test out a specific role based permission issue using NUnit/MbUnit and Rhino Mocks.
In Subtext, we have a class named FileBrowserConnector that really should only ever be constructed by a member of the Admins role. Because this class can write to the file system, we want to take extra precautions other than simply restricting access to the URL in which this object is created.
Here are two tests I wrote to begin with.
[Test]
[ExpectedException(typeof(SecurityException))]
public void NonAdminCannotCreateFileConnector()
{
new FileBrowserConnector();
}
[Test]
public void AdminCanCreateFileConnector()
{
MockRepository mocks = new MockRepository();
IPrincipal principal;
using (mocks.Record())
...
In his book, Producing Open Source Software, Karl Fogel gives sage advice on running an open source project. The section on how to deal with a security vulnerability was particularly interesting to me last night.
Upon learning of a potential security hole, Karl recommends the following:
Don’t talk about the bug publicly until a fix is available.
Make sure to have a private mailing list setup with a small group of trusted committers where users can send security reports.
Fix the patch quickly. Time is of the essence....
UPDATE: We released Subtext 2.0 which also includes the fix for this vulnerability among many other bug fixes.
A Subtext user reported a security vulnerability due to a flaw in our integration with the FCKEditor control which allows someone to upload files into the images directory without being authenticated.
As far as we know, nobody has been seriously affected, but please update your installation as soon as possible. Our apologies for the inconvenience.
The fix should be relatively quick and painless to apply.
The Fix
If you’re running Subtext 1.9.* we have a fix available consisting of a single assembly, Subtext.Providers.BlogEntryEditor.FCKeditor.dll. After you download it...
In a recent post I ranted about how ASP.NET denies WebPermission in Medium Trust. I also mentioned that there may be some legitimate reasons to deny this permission based on this hosting guide. Then Cathal (thanks!) emailed me and pointed out that the originUrl does not take wildcards, it takes a regular expression. So I updated the <trust /> element of web.config like so: <trust level="Medium" originUrl=".*" />
Lo and Behold, it works! Akismet works. Trackbacks work. All in Medium Trust.
Of course, a hosting provider can easily override this as Scott Guthrie points out in my comments. I need to stop...
This is a bit of rant born out of some frustrations I have with ASP.NET. When setting the trust level of an ASP.NET site, you have the following options:Full, High, Medium, Low, Minimal It turns out that many web hosting companies have chosen to congregate around Medium trust as a sweet spot in terms of tightened security while still allowing decent functionality. Only natural as it is the one in the middle. For the most part, I am sure there are very good reasons for which permissions make it into Medium trust and which ones are not allowed. But...