How to decline malicious requests

Question

I recently took over an application and we recently did an appscan and I got a item marked as vulnerable. The remediation task the report suggested was to Decline malicious requests. The report said appscan tried:

The following changes were applied to the original request: Set HTTP header to 'http://bogus.referer.ibm.com'

I had this flagged the 1st time we ran appscan, and put code to check if the urlreferer is provided, if so then make sure it's the same as the host in the url, otherwise kill the user's session and redirect to the login page. We ran appscan again and it got flagged again, I'm not sure how to handle this.

When I look at the report, it shows it put in bogus referrer, the server responded with a 302 status, redirect, and then a request was put in for the login which the server responded with a 202, giving it. Appscan reasoning says:

The same request was sent twice in different sessions and the same response was received. This shows that none of the parameters are dynamic (session identifiers are sent only in cookies) and therefore that the application is vulnerable to this issue.

But wouldn't the response always be the same? If the check fails a 302 followed by a 202, a redirect and login page comes up, regardless of the user. Does anyone know how to handle this? I'm guessing I could put the user's session id into the redirect url so appscan will see if as different, but I thought there must be another way.

This is a .net 4 application. Users are tracked with the Session object, if that matters, Forms Authentication was not used.

Answer 1

Set the viewstate user key, ref: https://security.stackexchange.com/questions/19152/how-does-viewstate-protect-against-csrf This makes it harder to send a query without having access to both the most recent page & your cookies.

Use the HttpException to return 403 (you may need to do some extra work too keep it from turning into a 500)

Throwing an HttpException always sends back HTTP 500 error?

And app scans have a highly recognizable signature-- they throw 100s of exceptions in the same minute. As part of your error logging infrastructure, you might want to present a captcha after say 5 exceptions in the same minute, or present a captcha on errors that the app scan throws that your app never throws (like very long URLs, queries for .jsp files in a .aspx application). Once an appscanner has been ID'd you'd want to poison their session by always redirecting to an error page until they solve a capcha. The down side of this is that there is a low chance that a user will be presented with a capcha after an exception thrown by the application, say a security error when the user puts a > in a textbox. You may or may not want to implement this feature for all app scanners, maybe just the malicious ones, depends on the incentive in your organization.