How "secure" is the ASP .NET Controller

Question

I am still very new to the concepts and design of ASP .NET's MVC and AJAX and I was wondering how secure the Controller is to unwanted user's when webdeployed.

I ask because for fun I made a little admin panel that requires a user name and password. Once input is entered the information is AJAX submitted to a ActionResult method in the Controller that just compares the strings to see if they match, then returns the response back to the AJAX.

My question is, how easy is it for someone to get into my Controller and see the hard-coded password?

No professional-type person will ever try to break into this, as it is a free site for a university club, but I want to make sure that the average Computer Science student couldn't just "break in" if they happen to "rage" or get mad about something (you never know! haha).

Question: Is having a password validation within the Controller "decently" secure on a ASP .NET MVC web-deployed application? Why or why not?

Here is the actual code in case the use of it matters for the answer (domain is omitted for privacy)

Note: I understand this use of Javascript might be bad, but I am looking for an answer relative to AJAX and Controller security of the password check.

View (Admin/)

//runs preloadFunc immediately
window.onpaint = preloadFunc();

function preloadFunc() {
    var prompting = prompt("Please enter the password", "****");
    if (prompting != null) {
        $.ajax({
            url: "/Admin/magicCheck",
            type: "POST",
            data: "magic=" + prompting,
            success: function (resp) {
                if (resp.Success) {
                  //continue loading page
                }
                else {
                    //wrong password, re-ask
                    preloadFunc();
                }
            },
            error: function () {
                  //re-ask
                  preloadFunc();
            }
        });
    }
    else {
       // Hitting cancel
        window.stop();
        window.location.replace("google.com");
    }
}

Controller (ActionResult Snippet)

[HttpPost]
public ActionResult magicCheck(string magic)
    {
        bool success = false;
        if (magic == "pass")
        {
            success = true;
        }
        else
        {
            success = false;
        }
        return Json(new { Success = success });
    }

Again I am new to MVC and AJAX, let alone anything dealing with security so I am just wondering how secure the Controller is, specifically on webdeploy for this simple password setup.

Answer 1

As has already been pointed out if you can get a hold of the binaries for an app (or for that matter ANY .NET application not just MVC) then it's definately game over.

Just sat in front of me here and now I have 3 applications that make it child's play to see what's inside.

• Telerick - Just Decompile
• IL-Spy

Are both freely downloadable in seconds, and the former of the two will take an entire compiled assembly, and actually not just reverse engineer the code, but will create me a solution file and other project assets too, allowing me to load it immediately back into Visual Studio.

Visual Studio meanwhile, will allow me to reference the binaries in another project, then let me browse into them to find out their calling structure using nothing more than the simple object browser.

You can obfuscate your assemblies, and there are plenty of apps to do this, but they still stop short of stopping you from de-compiling the code, and instead just make the reverse engineered code hard to read.

on the flip side

Even if you don't employ anything mentioned above, you can still use command line tools such as "Strings" or editors such as "Ultra Edit 32" and "Notepad++" that can display hex bytes and readable ASCII, to visually pick out interesting text strings (This approach also works well on natively compiled code too)

If your just worried about casual drive by / accidental intrusions, then the first thing you'll want to do is to make sure you DON'T keep your source code in the server folder.

It's amazing just how many production MVC sites Iv'e come accross where the developer has the active project files and development configuration actually on the server that's serving live to the internet.

Thankfully, in most cases, IIS7 is set with sensible defaults, which means that things like '*.CS' files, or 'web.config' files are refused when an attempt is made to download them.

It's by no means however an exact science, just try the following link to see what I mean!!

filetype:config inurl:web.config inurl:ftp

(Don't worry it's safe, it's just a regular Google Search link)

So, to avoid this kind of scenario of leaking documents, a few rules to follow:

• Use the web publishing wizard, that will ensure that ONLY the files needed to run end up on the server
• Don't point your live web based FTP root at your project root, in fact if you can don't use FTP at all
• DO double check everything, and if possible get a couple of trusted friends to try and download things they shouldn't, even with a head start they should struggle

Moving on from the server config, you have a huge mountain of choices for security.

One thing I definitely don't advocate doing though, is rolling your own.

For years now .NET has had a number of very good security based systems baked into it's core, with the mainstay being "ASP.NET Membership" and the current new comer being "ASP.NET simple membership"

Each product has it's own strengths and weaknesses, but every one of them has something that the method your using doesn't and that's global protection

As your existing code stands, it's a simple password on that controller only.

However, what if I don't give it a password.

What happens if I instead, decide to try a few random url's and happen to get lucky.

eg: http://example.com/admin/banned/

and, oh look I have the banned users page up.

This is EXACTLY the type of low hanging entry point that unskilled script kiddies and web-vandals look for. They wander around from site to site, trying random and pseudo random URL's like this, and often times they do get lucky, and find an unprotected page that allows them to get just far enough in, to run an automated script to do the rest.

The scary part is, small college club sites like yours are exactly the type of thing they look for too, a lot of them do this kind of thing for the bragging rights, which they then parade in front of friends with even less skill than themselves, who then look upon them as "Hacking Heroes" because they broke into a "College Site"

If however, you employ something like ASP.NET membership, then not only are you using security that's been tried and tested, but your also placing this protection on every page in your site without having to add boiler plate code to each and every controller you write.

Instead you use simple data annotations to say "This controller is Unprotected" and "This one lets in users without admin status" letting ASP.NET apply site wide security that says "NO" to everything you don't otherwise set rules for.

Finally, if you want the last word in ASP.NET security, MVC or otherwise, then go visit Troyhunt.com I guarantee, if you weren't scared before hand, you will be afterwards.

Answer 2

During normal operation, there is no concern as your code is compiled, the DLL prevented from being served, and there is no way for the browser to request the controller to divulge its own code.

However, it is not impossible (but quite rare) that unforeseen bugs, vulnerabilities, or misconfigurations of the server could lead to the server divulging compiled code, web.config, etc., whereby someone could disassemble the code (IL is easily decompiled) and reveal your secret.

More worrisome would be someone having physical access to the server just grabbing the binaries directly and disassembling to find your secret.

Another thing to consider is who, during normal situations, might see that secret and whether or not they should know it. A developer, tester, or reviewer may be allowed to write or inspect code, but you may not want them to know the secret.

One way to handle this is not store secrets in plain text. Instead, create a hash of the valid value, then update your application to hash the user's input in the same manner, and compare the results. That way if the user ever gets your source code, they can't read the original plain text value or even copy/paste it into your UI. You can roll your own code to do the hashing, use the FormsAuthentication API, or something else.

Finally, do not rely on client-side enforcement of security. You can check security on the client side to have the UI react appropriately, but all server-side requests should be doing checks to make sure the user's security claims are valid.

The question really goes out of scope from here, regarding how to manage identities, passwords, and make security assertions. Spend a little time looking through the myriad articles on the subject. Also, the Visual Studio ASP.NET project templates include a lot of the security infrastructure already stubbed out for you to give you a head start.

Never leaving things to chance is an important policy. Learning about ASP.NET and MVC's various facilities for authentication and authorization is a worthwhile effort. Plus, there are numerous APIs you can plug in to do a lot of the heavy lifting for you.

Answer 3

This code is not secure at all. Your JavaScript code can be replaced with EVERYTHING user wants. So someone can just get rid of your preloadFunc. Average computer sience student will execute this code directly from console:

if (resp.Success) {
    //continue loading page
    //this code can be executed by hand, from console
}

And that will be all when it comes to your security.

Authentication and authorization info should go to server with every request. As a simple solution, you could use FormsAuthentication, by calling

FormsAuthentication.SetAuthCookie("admin")

in /Admin/magicCheck, only if password is correct.

Then you should decorate data retrieval methods with [Authorize] attribute to check if cookie is present.

Using SSL to secure communication between browser and server would be wise too, otherwise password travels in clear text.

Answer 4

It looks like you are sending a password via AJAX POST. To your question, my answer would be that you should consider using SSL or encrypt the password prior to sending it via POST. See this answer for an example and explanation SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt

As HackedByChinese said, the actual code being stored in your compiled files (DLL) wouldn't be too big of a deal. If you want to be extra paranoid, you can also store the password in your web.config and encrypt it there. Here's an example and explanation of that How to encrypt username and password in Web.config in C# 2.0