1

After a virus attack on a shared server added 180 links to a client's website and I spent hours manually removing them, I would like to thwart any similar future attacks by including a generalized 410 Handler. I began by modifying global.asax.cs to issue a 410 error whenever a query string existed since this application does not use them:

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        string queryParms = Request.Url.Query;
        if (queryParms.Length > 0)
        {
            Response.StatusCode = 410;
            Response.End();
        }
    }

This worked fine (default error page was displayed) for IE11 and Chrome on my local test machine as well as with IE11 on the shared server; but Chrome displayed a blank page.

My ISP infformed me that a custom error page would resolve this issue and supplied a link to the SO post entitled 410 a bunch of html pages in IIS.

As per the SO post instructions, I created a custom 410Error.aspx page in the root folder and set Response.StatusCode = 410 in the code behind, I modified web.config as the SO example illustrated as follows:

<system.webServer> 
    <httpErrors errorMode="Custom" defaultResponseMode="ExecuteURL">
       <remove statusCode="410" subStatusCode="-1" />
       <error statusCode="410" path="/Error410.aspx" responseMode="ExecuteURL" />
    </httpErrors>
</system.webServer>

I also set Custom Errors to true:

<system.web>
    <customErrors mode="On"  />
    <compilation debug="true" targetFramework="4.0"/>
    ...
</system.web>

Unfortunately, Chrome still displayed a blank page on the loccal macine and shared server, and IE11 showed the default 410 error page. It seems that IIS could not find the Error410.aspx, so I tried using several different paths, including the absolute path with no luck. What am I missing?

Community
  • 1
  • 1
ron tornambe
  • 10,452
  • 7
  • 33
  • 60
  • On a slight tangent here but it might be better to fix the underlying problem with query strings rather than to just disallow them completely. Even if your site doesn't explicitly use them, there are cases where they may be needed, things like google paid adds for example. – DGibbs Jun 16 '14 at 11:25
  • Good point. This was just a quick and dirty solution, even though this client does not want any advertising on his site, I would like to know about alternate solutions. I did not quite understand how the example's "listOf410urls.Contains(Request.RawUrl)" worked. – ron tornambe Jun 16 '14 at 12:26
  • Out of curiosity, what is the problem you're having with query strings? The `listOf410urls.Contains()` code is basically the same as what you have now except it's doing it over a collection of urls that they what to return a 410 for. You mentioned that chrome isn't showing your custom error page? Go into chrome and open up dev tool (press F12) and go to the network tab. Refresh the page and check the response status code. If it's a 410 then that's probably good enough, it's unlikely that users are going to be randomly adding query string params to your Urls if your site doesn't need them. – DGibbs Jun 16 '14 at 12:40
  • It is not the users that concern me, it is the hackers that may strike again in the future. With one of the hacked query strings attached, the Network tab shows the the query string (?louisvuitton=245) with Staus Code 410 - Gone; other info too, but the page is blank on the shared server. – ron tornambe Jun 16 '14 at 12:59
  • But if your overall goal is to return a 410 response code when someone requests a url with query string parameters in it, then doesn't that satisfy the condition? Can you provide the full query string that the hackers used (omit the domain name)? Sounds like an XSS issue which are relatively easy to fix. – DGibbs Jun 16 '14 at 15:57
  • Yes, it does satisfy the condition. Here's a real hacked query string: /?louisvuitton=21407 XSS? Would the XXS fix obviate the need for a custom error handler? – ron tornambe Jun 16 '14 at 16:09
  • XSS = [Cross site scripting attack](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)). A hacker would be able to inject malicious code into your site via a query string. That's an already hacked query string, we want the one that the attacker used to inject whatever they injected into your site. Look for pages where you take user input, make sure it's sanitized before you do anything with it. Are you querying a database? Make sure that the input is sanitized/validated against a whitelist and ensure that you use parametrized queries to prevent SQL injection. – DGibbs Jun 16 '14 at 16:32
  • I wouldn't have that query string since this is a shared server at an ISP. I have sent support your last comment and asked if they could supply it. There is no database for this site and the only input is a Contact Us form that sends an email using SMTP (aspx) to some recipients. It does validation and emailing server side. You can find it under Office Information at madisonpscom. Thanks so much for your savvy comments. Perhaps they should be made into an answer so others can benefit. – ron tornambe Jun 16 '14 at 17:46
  • If it's a shared hosting environment it may be that one of the other sites on the server or the server itself was compromised and that's how you were hacked. The site doesn't have a great deal of functionality so that seems like the most likely scenario to me. No problem, happy to help! P.S you need to re-enable custom error pages ;) http://www.madisonps.com/ – DGibbs Jun 17 '14 at 08:14

0 Answers0