SAML for your application is not enough !

If you have implemented authentication in your application using SAML, this will interest you. Although you might have not made the same mistake I did, but believe me, I thought this is out of the box functionality of ADFS or any other technology which issues SAML tokens.

Let me come to the point straight away. The SAML token issued by ADFS to my application was in plain readable XML format in my browser. I was astounded finding that I can read the entire SAML response in web debugging tool and there it was, all the information about me & my IDP. Pants!!! How the hell that happened? It took me around half an hour to recover and then I started digging.

First let’s just quickly understand how SAML works. I found this image online which is detailed enough to understand this protocol.

In steps:-

• Step 1: You try to access a secured website on your browser. In this case, saleforce.com.
• Step 2 & 3: Saleforce.com says, you are not authenticated and redirects you to let’s say your company’s active directory login page. This is a 302 Get redirect which you can see in your browser.
• Step 4 & 5: You provide your credentials at SAML identity provider and if valid, it redirects you back to salesforce.com with SAML token. This is now a 302 post redirect as it has the SAML token data.

And here lies my problem. I saw this step 4 & 5 302 post redirect in HTTPFox and there it was, my SAML token in plain XML in post data. See below:-

So today's new learning, by default, your SAML tokens are not encrypted between the identity provider & service provider.  You need to perform few more steps to make sure your tokens are encrypted and no one can see the assertions/attributes of your SAML token.

Now obviously, this only happens after successful login and people might argue that if some can login into your system then they already sort of bypassed the security but no. I blogged sometime back about how if you can fake claims then you can get into the application without IDP ever knowing about it. This SAML token contains assertions/attributes not only about the logged in user but also about your IDP and the type of trust your IDP & SP has. If hacker gets his hands on this token then your system is open to a logged in Bruteforce attack.

As I said, after I found this I started digging and here is the official documentation of OASIS on this. It clearly explains the type of SAML assertions, protocol and possible hacks which can be tried against them. The best practice of SAML communication is to encrypt the token. Even that is not going to save you from all sorts of hack but something is better than nothing.

After I found this, fixing the issue was not really a rocket science. All you have to do is upload the public key of your certificate (.cer) on your identity provider and install the certificate with the private key on service provider to make sure the SAML token can be decrypted when received here.

Now nothing is straight forward in IT and here also I have to do bit of RnD to make this working and below are the findings & best practices to do this:-

• First the certificate you will use for this must either be self-signed, or signed and chained directly to a public certification authority.
• Certificate files that contain only a public key (.cer file) must be DER-encoded. Base64-encoded certificate files will result in a validation error.

And finally, this is more of ADFS specific issue. I managed to get the assertions encrypted in the token but not the metadata and after bit more digging, I found, in active directory the default is to encrypt the assertions only and not the full message. You can change this if you have access to your AD which unfortunately not applicable in my case. If you wish to change this, use below command in powershell.

Set-ADFSRelyingParty -TargetName MyRP -SamlResponseSignature "MessageAndAssertion"

Once you do this, your SAML token will be completely encrypted and only readable by your SP & IDP. There would a slight impact on performance on your overall communication but I think when it comes to security, this is acceptable.

Remember, most of the things which are running and not being hacked so far is not because people can’t do it but because no one is trying J so always keep your application security at the max level you can.

Application security - 5 things you don't waana do

Let me start by saying and I quote it, “in today’s world everything which is necessary is not secure”.

Now-a-days, everyone knows the significance of application security but very few take it seriously and try to implement safe guards to avoid any breach. For rest, it is more desirable than imperative.

Let’s face it; we have stories in backlog not security. We accept a reduced security or vulnerable flow just because we know a proper secured communication will take more time & money either of which are usually in shortfall. But what we can do at least is not to make things to easy for a hacker by leaving backdoors open which are mere programming errors and not a security flawed design.

When it comes to security, there are too many things to worry about.  Input validation, broken authentication, lack of authorization, misconfiguration of security, insecure direct object reference, improper error handling leaving sensitive information exposed, open redirects anywhere and the list goes on. Almost all hacking techniques are designed to exploit these loopholes and gain access in your application/servers/communication.

I am not targeting any specific programming language because the 5 things I have mentioned below are implemented in all. So let’s start.

Input validation

By very nature of this business or technical requirements, I believe the code should always be defensive. It helps you to deal with both kinds of people, extreme stupid and very clever ones. You really don’t want anyone breaking your application by just entering something in the input fields which nowhere in the world belongs there. You can’t help it; common sense is not really common anymore. But this category is also not our main problem. The problem is the ones who are very clever and know from where the validation is missing and how it can be exploited.

Common input validation hacks include SQL injection, HTML injection, Cross Site Scripting (XSS), buffer overflows, application content identification, phishing etc. A hacker can inject html, JavaScript or unlimited data into your application’s input fields until either it breaks or does something on the server which it never suppose to do.

This all can be avoided by taking few simple measures. First, always expect the unexpected and put validations on everything. Second, implement validation both on client & server side. The web browser is an untrusted, uncontrolled environment because all data coming from and going to the web browser can be modified in transit regardless of input validation routines.

Authentication & Authorization

Well, nothing to say here. These are the bouncers or gate keepers of your application. Any flaw here will results in unwanted guests inside your application.  Just implementing the login in the application doesn’t make it secure. There are more security hacks then security solutions available now-a-days. You have to implement the security in a way that no one can guess and mimic it.

Common issues with authentication implementations are:-

1. Transmitting credentials in header over HTTP
2. Passing tokens, sessionIds as url parameters
3. No session management, timeout implemented
4. Unsecured/open form submission without Captcha
5. Open redirects post authentication without validation
6. Permissions not checked before execution

Above are just few things but if not implemented properly can lead to things like Denial of Service (DDos) attack, Man in middle attack, Session hijacking etc.

It is really easy to implement above properly. Most of the programming languages come with an out of the box functionality to implement above correctly. All you have to do is use them and make sure you are not leaving something which someone can exploit.

Error Handling

A good quality error handling not only ensures security but a better application and enhanced end user experience. Who likes an application which gives you a yellow screen of death (at least developers will understand what yellow screen of death is).

For now let’s just see how an improper error handling can lead to security flaws. See below and tell me how many things this error exposes of this application.

You might think, this is just an error. Not really exposing much details but for a 

hacker even this much information is enough to fire much closer hits to your application. And remember, you need the luck always but hackers only need it once.

So always make sure that you handle all errors inside your application and even if something is unhandled, user should only see an unknown error message and not a broken screen as above. 

Security Misconfiguration

This is another area where you don’t even require coding to screw it up. Application configurations are critical aspect of security and if something is deployed in production with local environment’s configuration is as good as giving you application to a hacker in silver plate with ribbon on it.

Below are some examples which can lead a leakage of your application information:-

1. Deploying application with default username/passwords of third party components
2. Deploying application in debug mode
3. Keeping directory listing enabled
4. Deploying application with security disabled for certain areas of application. 
5.  Running outdated software or operating system

The best solution to overcome above issues is to automate the entire build process. Most of the deployment errors happen because the process is manual. Remember the quote “If there is an error, it’s human” perfectly fits here.

An automated process will keep the environments consistent and reduce the number of human/manual errors.

Understand the technology & understand the business

And finally, understand before you implement. I have seen people (majority in big organizations) where they only care about the module they are developing without the understanding of the entire end to end flow and the organization rules.  Developers are too removed from the business, especially if they do not work for the company whose website they are creating.  A developer will not be able to accurately model threats unless the developer is keenly aware of what the business objectives are and which critical information assets have to be protected by the application.

Same goes for technology. Web applications are changing rapidly and the tools to build those are changing even more quickly. Everybody involved in the web development process has to live up to the challenge to understand the security aspects of particular frameworks and development environments. This process is made harder if organizations try to chase the latest fad in web technology just to keep up with the industry.

Technology owners are trying hard to keep their products upto date with all latest threats and various programming languages are updating their modules to fight against these threats as well. If you understand the threat and the technology then all you have to do is to implement an out of the box solution to deal with those threats. Believe me, it require much less time than it sounds. All you need to know is what you are up against and what you have to fight it. 

Summary

Hopefully I gave you some idea about how implementing even small things in your application can save you from major hacks. Also, just to set the expectation right, we have't even scratched the surface of application security here. If you really wish to build a secure application then I am afraid there are no shortcuts. You will always have to be top of your game, stay up to date with various security threats and mitigations.