Author: doylestowncoder

This blog post is intended to help lay the groundwork to eventually setup and configure Mutual Authentication (Two Way TLS/Client Cert). For now, I will demonstrate how to just setup and configure basic SSL in IIS Express. For this exercise, I will be using a self-signed certificate that Visual Studio automatically generates and installs for us.

In the next blog, I will then show how to setup and configure a Client Cert for Mutual Authentication for your Web API. Finally, I will demonstrate how to deploy this to an Azure App Service and test using Chrome and Postman.

Prerequisites: Visual Studio 2017 Community Edition on Windows 10 Home Edition or similar development environment.

Assumption: You know C#, WebApi and do not need every exact step for creating a Web API project.

Creating a Sample Project

First, let’s start by creating an Empty WebApi project.

After clicking the “Ok” button, then check MVC and WebApi.

Then click “Ok” again. Now we are ready to add a new API endpoint. Right click on the Controllers folder and add a new Controller. Since this is a WebApi, make sure your controller inherits from ApiController.

Note: Your URL may be different. Check the properties of your project for the URL your project is configured for. It will usually very by port number.

Now we know we have a working API. Let’s configure SSL.

Configuring SSL

This is really, really difficult so make sure your read carefully (note the sarcasm). Microsoft has really overly simplified this process compared to 10 years ago. First, right click on the project and click “Properties”.

In the “Properties” section, enable SSL.

Now, run the WebApi. The first time when your run the WebApi project, you will need to trust the IIS Express SSL Certificate.

Then another dialog will pop-up asking you to install the certificate.

Once this is up and running, let’s test the endpoint using HTTPS. Obviously, make sure your are using the appropriate URL when testing HTTPS.

Notice that both HTTP and HTTPS URLs will work. It is up to you to decide if you need to block access to your endpoints for HTTP. There are several ways to do that.

Conclusion

This blog has demonstrated how simple it is now to develop and run Web API in IIS Express using SSL. Ten years ago doing this was very convoluted and error prone. Now it is overly simplified so any developer can easily setup their dev environment to run SSL. Next, I will dive into Mutual Authentication for IIS Express.

On a recent app I worked on, we needed to internationalize the App Name. Currently, Cordova does not allow you to easily handle this via configuration. One alternative is to open the Android project and modify it to include the internationalization. However, if a developer removes the platform, the process has to be repeated. This article explains how to accomplish this in a repeatable process that works when the developer removes and adds the Android App. I will be using the Ionic Framework to build this sample app; however, this should work for any Cordova project.

Why do I want this repeatable? Great, question. Maybe I have an App that is used by multiple clients so I need a configurable build process for each client where one client supports English but another supports English and Spanish. If so, this builds the basic foundation necessary to create such a dynamic build environment.

Assumptions: I am assuming you have some experience writing Mobile Hybrid Apps with Cordova and Ionic Framwork.

Cordova Hooks

Cordova allows developers to create hooks that run to customize Cordova commans like adding/removing platforms, running a build, etc. Hooks can be written in any language according to their documentation but I personally have only used Node.js for writing hooks.

This hook has a dependency for the the fs.extra NPM Package. It can be found in the following location. Dependencies

For this project, our hook will run when the Android app is prepared. Therefore, we will create a js file named 020_i18n_app_name.js in the “hooks/after_prepare” folder.

Unlike iOS, this is rather simple. We just need to copy the necessary resources files into the Android project. Therefore, this hook checks to see if the Cordova Project is configured for the Android platform and the copies predefined Android Resource files to the appropriate Android platform folder.

You need to create a values folder for each language. The default language will have a folder called values; while each other language will use the following syntax: values-{{language code}}. IE. values-fr for French, values-es for Spanish, etc…

I placed these folders and files under a folder called resources/android in my root folder for my project. The hook will then copy the files to the appropriate location in the Android project.

Check it out

Since I am using Ionic, I’ll run the following command:

ionic run android

That command is basically a wrapper for the Cordova command. Notice the output and you will see the hook running and adding the files to the Android project before building and installing the app.

Conclusion

At this time, this process certainly meets my needs. But this obviously could be considered immature and easily improved on by adding configuration to config.xml that contains the languages and resource locations. Certainly a project for another day!

Other Resources:

Android has a ton of tools. This is a quick introduction to a couple commands I use in AAPT.

What is AAPT?

AAPT (Anroid Asset Packaging Tool) is a great tool to help you view, create and update your APKs (as well as zip and jar files).

Where is it?

On Windows, check you Android/tools folder. For my Windows 8, it is located here:

C:\Program Files (x86)\Android\android-sdk\build-tools\23.0.2

Just add it to your path Environment Variable.

Getting your VersionCode, etc…

By running the following commands, you will see lots of important information from App Id, Version Code, Version Number, SDK Info, Permissions, etc…

aapt dump badging my.apk

This is really helpful when delivering the APK to a client. If a client questions the VersionCode or other information, you can easily verify the app and also explain how the client can verify it.

When running this tool the output will look similar to this:

Check your permissions:

It also helps verify what permissions are set in the app. We recently failed a security audit for our App. The customer said the Third Party failed our app for too many permissions. This tool was very helpful in determining the exact permissions our App had and provided the information to our customer. Turned out the Third Party was wrong and accidentally got the permissions of another app. Opps!

aapt dump permissions my.apk

Other Resources

By now, developers should really understand how to build a form and properly secure it. But this still seems to allude some. It’s rather embarrassing to fail security assessments for certain secuirty flaws that can be easily avoided.

In this blog, a refresher on the basics will be covered for securing your post as well as writing an extension to add to your MVC Infrastrucutre to be used by all of your team members.

It does not cover data validation. I am really focusing on the form and the action of that form. In addition, this is also from the perspective of a business web application that is only accessed via an authenticated user.

Let’s get started…

Poorly Secured Form and Action

Let’s take a simple Edit many developers write everyday and show the numerous flaws with this. Here is the Razor View:

When a user navigates to the Edit page for from a link, double clicking a row in a grid, or by any other means, that action should be called via a HTTPGet; therefore the first Action is called due to the HTTPGet attribute on that method. Once on that page, the user then modifies the data and clicks a submit button in a form performing a POST thus calling the second Action decorated with HTTPPost.

When do you want to use an ActionMethodSelectorAttribute? In my opinion, pretty much on every Action in your controller.

Rules to live by:

1. If you are selecting data to display in your Action method, then your Action should be decorated with the HTTPGet Attribute.

2. If you are creating, updating or deleting data via your Action method, then your Action should be decorated with the HTTPPost Attribute.

Oh, and by the way, using HTTPPost helps prevent some attacks via CSRF (see next section). Without that ActionMethodSelectorAttribute, it’s easy for a hacker to create links that a user can click and unknowingly modify their data.

Without the HTTPPost a well crafted link (obviously depending on your model and your action etc…) can be used to update sensitive info. Even worse, if your id is just an identity column in SQL Server and if you did not properly secure your form, a hacker could call this link over and over again for each identity id in your database, thus updating your data to what ever he wants.

Pretty scary if your site really contains sensitive information like account information, employee data or critical business processes that if disrupted by a hacker causes serious damage to your company’s reputation.

So use HTTPPost and you will prevent the above hacks via get from working.

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is the #8 security flaw on the OWASP Top 10 for 2013. Follow the link for great information about CSRF. For nitty grittey detail, read “Part 5: Cross-Site Request Forgery (CSRF), 1 Nov 2010 in Troy Hunt’s OWASP Top 10 book. It’s free. This will explain in great detail how an attacker can take advantage of your site. Luckily for us, we don’t have to implement the “Synchronizer Token Pattern” as Tony explains. Instead, we just need to add the following in our form:

@Html.AntiForgeryToken()

Then on the Controller’s Action, the following ActionFilter must be added.

Note: The user must accept cookies. This only works with POST Requests. It does not work with GET Requests.

Without a valideAntiForgeryToken, the server will threw exceptions like the following:

Can this be circumvented? Why, yes…. But, a hacker has to actually get the AntiForgeryToken, then craft a POST using the correct form values. Gettign the AntiForgeryToken is possible if your site is vulnerable to XSS or your users are on older browser’s that allow cross-domain access. Therefore, dropping support for older browsers in web applications is critical when the data is sensitve. But that might be easier said than done.

The next step is to check the referrer.

Checking the Referrer

The next issue that I see with the above code is that the post could originate from another site. There are expections, but for most business web application, a post originates from your site.

In order to check the referrer, you need to write a Attribute that inherits from AuthorizeAttribute:

Checking the Origin

Authenticated or Authorized

Next check the user to see if the user is authenticated and authorized to perform the action.

Finally

Build an HTML Extension to make this even easier to follow in your Business Application. It is so easy to do…

Conclusion

These techniques help tremendously when securing your site, protecting your data and for passing security assessments. So don’t forget to use them in all your forms and protect your reputation, your companies reputation and your bottom line.

What really? My security assessment failed because of my cookies. But I only use a couple of cookies to store certain user preferences. Those cookies are there only for user convince. Guess what? That third-party that ran the security assessment doesn’t care. All they care about is that you have cookies and that you are not securing your cookies properly.

You can easily pass your security assessment by opening Web.Config and setting the http Only setting to true and also turning on SSL for your cookies (assuming you only have SSL);

<httpCookies httpOnlyCookies=”true” requireSSL=”true” />

But you do need to understand the ramifications of these settings.

If your JavaScript is accessing your cookies then setting httpOnlyCookies to true will break your code. HttpOnly cookies help mitigate XSS and prevents cookies from being accessed vias client-side scripting. Therefore, depending on how your code is implemented may mean you have some refactoring to do.

Finally, my sites normally run using SSL only. Therefore, I set requireSSL to true. This only allows the cookie to be sent back over a connection using SSL/TLS. This is especially important with the Session Id cookie. You certainly do not want that to be passed over HTTP since that could be stolen and used to hack your site.

Wait a second? Really, I can’t tell my user that they locked out the account. Yep!!! For sites containing highly sensitive information like employee information, financial information, etc… you will fail a security assessment because you are telling a hacker the account is locked out.

Why is that?

The concern is a hacker attempted to login with an account many times. The hacker gets the “The account is locked out due to 5 failed attempts”. Now the hacker knows he has a good account name. One more piece of information that can help that hacker figure out how to get in. Once the hacker gets a good user name, he can keep trying to hack the account each time it is reset. Or, he might just use a little social engineering and call your help desk. Using the URL and account name, the hacker might be able to convince your help desk to change the password without even verifying other information on the account. Then the hacker has a good account with a good password. Now your hacked but don’t even know it until it is way too late. It could be weeks before the real user tries to login and figures out he can’t and then calls the help desk. By then the hacker could have downloaded anything that user has access to, created another user account, etc…

It is best to avoid showing messages like these to the user:

The password is invalid.

The account is locked out.

Best Practice

Always show the same response for a failed login:

The username and password is invalid. Please try again.

When a user calls the help desk for a password reset:

The help desk must verify information about the user.

The help desk should be able to see past history and be able to ask the user when they successfully logged in last time.

The help desk should be able to see as much information about any failed login attempts like IP Address, number of failed attempts, etc… If the failed attempts are out of China but your users are only in a few locations in the United States, well you might have a problem…

The help desk should reset the password and send a password reset email to the email account on file.

So solving this problem is not just about coding a secure login page but also letting your help desk understand social engineering and hacking.