-1

The security engineer is requesting that under certain conditions the application (MVC4 c#) should not send a response.

This way an attacker is unable to extract any information about the service (e.g. if we send the usual 401 unauthorized then the attacker knows their credentials did not work).

How can I achieve this?

UPDATE This is not a question to discuss the decision of 'do it vs not do it'. I need to know if it is technically possible to achieve this outcome with ASP.NET C# MVC.

zaitsman
  • 8,984
  • 6
  • 47
  • 79
  • 1
    Please tell me how the "engineer" expects you to send ***no response.*** HTTP is kind of a "request/response" protocol. – Mike Perrenoud Jul 08 '14 at 03:42
  • The attacker may know that the credentials don't work, but won't know whether it is the username or password (or both) that are the problem. – John Saunders Jul 08 '14 at 04:37
  • @MichaelPerrenoud think 'timeout' or firewall dropping traffic. – zaitsman Jul 08 '14 at 08:08
  • @JohnSaunders this is not necessarily for username/password auth, the scenario is around many different types (digest, Kerberos, cookie, client cert). – zaitsman Jul 08 '14 at 08:14
  • @zaitsman: i chose the weakest for my example. It's even less of a concern with other credentials. – John Saunders Jul 08 '14 at 08:57
  • @JohnSaunders I suppose it depends on the industry that you're in. – zaitsman Jul 08 '14 at 09:04
  • You're right. In some industries, decisions like this are called "security" and cannot be argued with, or even discussed, on pain of being considered dangerous for telling the Emperor about his wardrobe. – John Saunders Jul 08 '14 at 09:07

3 Answers3

4

From your action, either return null or EmptyResult().

...but this seems fishy. You are always in control over what you return to the client, and sending HTTP 401 is perfectly acceptable. There is no risk of brute-forcing over HTTP because it isn't practically possible. What you're describing sounds like cargo-cult security.

Dai
  • 141,631
  • 28
  • 261
  • 374
  • null as well as EmptyResult() produce an empty http 200 OK response. By sending 401 you're confirming existence of your service. The attacker knows there is something there to attack. By not sending anything back (timeout) you're creating an impression that potentially there is nothing there. – zaitsman Jul 08 '14 at 08:13
  • @zaitsman I don't buy that, nor do I subscribe to that school of thought. "Security through obscurity" is not a valid approach. Please return HTTP 401 when authentication fails and spend your time investigating actual potential weaknesses and known vulnerabilities rather than being afraid of hypotheticals with no basis in evidence. – Dai Jul 08 '14 at 10:32
  • the evidence for this question is under NDA unfortunately, and the question is purely technical - I want to know if it is possible or not with Microsoft's framework. – zaitsman Jul 09 '14 at 00:15
  • now that a few years have passed - consider the simple login pattern. Most trivial apps (e.g. the ones i wrote) would start by looking up the user via their username, then calculating the hash on the password material supplied. This means that the response time is some microseconds quicker for users that don't exist (e.g. in the db). This means that by recording average execution times I can use bruteforce to figure out whether certain users are likely to belong to a db. Now imagine that is a db of some X-rated or dating website, and e-mails you're using belong to politicians... – zaitsman Sep 17 '19 at 13:56
  • In more recent apps i actually mitigate the above by thread spinning to compensate for sensitive operations; however, being able to just leave the client hanging allows for a blanket approach to prevent accidental leaks of information like this. – zaitsman Sep 17 '19 at 13:57
2

Do this

public ActionResult IReturnNothing
{
    return new EmptyResult();
}

More here: ASP.Net MVC Controller Actions that return void

Community
  • 1
  • 1
TGH
  • 38,769
  • 12
  • 102
  • 135
  • This produces an Empty HTTP 200 response. I want the entire execution to stop and NO response to be returned (e.g. timeout). – zaitsman Jul 08 '14 at 08:12
0

Okay, after some time I did find a solution that, unfortunately, is not ideal. I am still investigating and won't accept this for now, but one way to do this would be:

    var wrapper = (HttpContextWrapper)this.HttpContext;
    FieldInfo ctx = typeof(HttpContextWrapper).GetField("_context", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.DeclaredOnly);
    var context = (HttpContext)ctx.GetValue(wrapper);

    FieldInfo response= typeof(HttpContext).GetField("_response", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.DeclaredOnly);
    response.SetValue(context, null);

This, however, causes the entire app pool to crash down in the System.Web.HttpRuntime.ProcessRequestNotificationPrivate and you need to set a very high tolerance for crashes in IIS to allow it to not shut down. but no response comes from your server, the client is just waiting.

zaitsman
  • 8,984
  • 6
  • 47
  • 79