Those of us who accept credit cards are familiar with PCI (Payment Card Industry) compliance. In addition to protecting credit card numbers and so forth, your web sites need to tested for vulnerability to attacks and hackers. As part of compliance, your web sites are automatically scanned for vulnerabilities. Our site has always passed, but the report would show various weird vulnerabilities that I put down to being on a shared hosting service (DiscountASP.Net). But this most recent scan failed repeatedly with messages like this:
News database accessible over web (news.mdb) Impact: Attackers may access (read or destroy) application information, and in worst cases may take administrative control of the application. Data Sent: GET /help/trainingstudio/TrainingStudioContentEditor/news.mdb
When I went to help/trainingstudio/TrainingStudioContentEditor, there was no file named news.mdb or anything similar. I contacted the scan vendor (Security Metrics) and Emily evaluated the situation and came up with this explanation:
I have looked into these issues and I believe that each one is flagging because we are receiving affirmative (200 OK) responses for non-existent pages. Our scanner is sending a GET request for a specific page or file that is associated with a vulnerable program (ie. Guppy). The response to that GET request is a custom error page that you have created – but that customer error page’s status code is a 200 OK. The scanner sees the 200 OK and it flags the issue.
Sure enough, we had set up our site through DiscountASP.Net’s IIS tools (shown below) to show a custom error page (error.htm) if there was a missing page. So if the user put in a bogus link like http://www.plattecayon.com/cool.htm, that page would display. But unfortunately that page returned the standard 200 status code. I found this nice tool that shows you the actual status code: http://gsitecrawler.com/tools/Server-Status.aspx. When the scan looked for various rogue files, the 200 response put up red flags.
So what to do?
My first thought was to edit the error.htm page to set the status code to 404 (missing page). I had no luck finding a way to do that though. The next best thing was to use an ASP.NET page as that had the power to change the status code programmatically. Here is the code for missingPage.aspx.
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load If IsPostBack = False Then Response.StatusCode = 404 Me.UpdateRepeaters(linksRepeater, 41) End If End Sub
The important part is Response.StatusCode = 404. The last step was to make this the custom error page for missing pages. This is done in IIS (Internet Information Services) for non-ASP.NET pages and in web.config for extensions handled by ASP.NET. Here is the DiscountASP.Net interface for the IIS setting.
For the web.config, we used this entry:
<customerrors mode="RemoteOnly" defaultredirect="errorpage.aspx"> <error statuscode="404" redirect="missingPage.aspx"></error> </customerrors>
After making the changes, the site passed on the first try.
I hope this is helpful if any of you run into a similar situation. Note that returning the correct status code is helpful for search engines as well.
About Jeff Rhodes