My team recently upgraded our web application to Asp.Net 2.0 from Asp.Net 1.1. Yesterday was the first deployment since the upgrade. Overall, the conversion went well. But an odd thing happened during the mandated Vulnerability Assessment that is required before the application go live. I received an email that said "A high risk 'Blind SQL Injection' is showing up on the http://<domain> /<virtdir>/common/error.aspx URL on the aspxerrorpath object." I looked at the page, but it literally did nothing in the database (read or write). Not a thing. I thought maybe a Cross Site Scripting vulnerability, but certainly not a SQL injection problem. But, anybody who has worked in a large organization knows, the path of least resistance is the best.
I decided to address the perceived issue by overriding the OnError event in a common base class for all the pages in the site. I made sure I didn't pass the aspxerrorpath param and voila: We passed today.
I use Subversion (1.4.5.25188) via Apache (2.2.6.0). I use CruiseControl.Net (1.0.1.1277) as our build server. I setup Subversion in a non-standard manner. And, it could account for the problem. All the users who access Subversion, do so via a domain login. That is except for the build user. I setup the build user as a local account on both the Subversion server and the Build server with the same password. I then setup a second location alias in Apache to also use SSPI authentication, but I set the "SSPIDomain" to Off. This allowed the user base to only have to put in their username without a domain and the allowed the local accounts to work via the second location.
All was fine until I started getting a build Exception that said "authorization failed." I was able to reproduce this and I tried all I could think of to fix it. Yesterday, I had an epiphany (understand I am paranoid): I setup the account to use SSL, and then to use basic authentication. I had avoided this in the past because I didn't want any passwords embedded in any scripts.
…The problem occurred only occasionally, but seemed to be occurring more often...
I also added another directive:
Order Deny, Allow
Deny from all
Allow from 192.168.xxx.xxx
I believe with this added, I have now effectively locked access down to only the build server.