dasBlog has a pretty large user base, and while browsing some dasBlog sites I occassionally check if they're set up securely. It's not that dasBlog is inherently insecure, but some installations allow for information leakage and most users aren't even aware of this.
There are a couple of locations where you can set up security for any ASP.NET application:
<authentication>
HttpForbiddenHandler
Note that web.config settings only apply to file extensions mapped to ASP.NET on Windows Server 2003 and before. I am working on IIS 6 here and while I like my security settings in (mostly) one place I usually go with a generic read access configuration in IIS and set the more fine-grained settings using NTFS.
When deploying dasBlog to your web server you will likely enable read access to the dasBlog folder for the IUSR and NETWORK SERVICE accounts on the NTFS Security tab. This gives the IIS and ASP.NET runtimes the rights they need to work. On the /logs, /content and /SiteConfig directories you will also need to enable change access for the NETWORK SERVICE account since this is where dasBlog stores its working data. (dasBlog is represented by the IIS worker process identity, which is NETWORK SERVICE on Windows Server 2003 and ASPNET on Windows 2000 and XP.) If anything is set up incorrectly you'll see the configuration error page when you're trying configure your blog or post a blog entry.
Sometimes when I visit a random dasBlog site I try to download one of dasBlog's log files which are located in the /logs folder. Since IUSR's read access is most likely inherited (RI) in this folder, anonymous users can download log files. The log file name format is publicy available so, for example, the /logs/2007-06-08-referrer.log.zip file contains the referrers for today. This information leakage could be easily mitigated by denying IUSR read access to the /logs folder. However, I've found at least three high-traffic blogs where this was not the case (I e-mailed the owners, things are fixed now).
Another problem that came up recently on the developer mailing list was how to keep blog templates private. Since we already incorporate the HttpForbiddenHandler for *.blogtemplate files and IIS doesn't serve files when there's no MIME type available this is really a non-issue. The template's manifest file, however, will be served but that should not bother you since there's no valuable information in it.
One rather interesting place is the /content folder. Your posts, comments and blogged binary content like images are stored there. The /content/binary subfolder holds images and enclosures, i.e. basically everything you attach to a certain post. The /content/profiles folder serves as a container for user profiles stored in <Username>.format.html files. Please note that *.format.html files are always templated and served through FormatPage.aspx, that is, are never accessed by IUSR directly.
With the basic setup above, read access for anonymous users is enabled in the /content folder and its subfolders. Thus, anonymous users are able to get the raw post data by requesting the *.dayentry.xml and *.dayfeedback.xml files for a certain date, i.e. /content/2007-06-08.dayentry.xml. Again, the file name pattern is no secret.
This last piece of public information should only be served through certain channels like the templated font page or RSS. Because of dasBlog's folder structure securing the /content folder it is kind of tricky:
In the end the NTFS security settings that work best for me look like this: (Changes red)
Please note that on Windows Deny ACLs have always preference over Allow ACLs.
If you're a dasBlog developer or user, please feel free to leave a comment if you (dis)like this solution, have a question or suggestions for a better solution.
Now Playing [?]: Robert Mechs – The OGD Sessions Vol. 2
a@href@title, blockquote@cite, em, strike, strong, sub, sup, u