Export (0) Print
Expand All
Expand Minimize

Be Secure When Interoping

Published: October 10, 2007

By Mitch Ruebush, Microsoft MVP – C#

See other Security MVP Article of the Month columns.

Planning Is Key

Writing secure code can be hard enough when you are working on one platform, but it can become quite difficult when you have to think about communicating between two or more frameworks like Java and .NET. You can mitigate many of the issues if you spend some time to plan your approach. Nothing is worse than having an application close to completion and then find you need to redesign the security approach, especially because security cuts across your application. Careful planning is required around what data can and cannot be trusted, where your trust boundaries are, and what technologies would be the most appropriate to support interoperation between the frameworks.

You would not blindly open e-mail messages from people you do not know without validating the message by scanning it for viruses and checking the header to verify that the sender is legitimate. Don’t do the programming equivalent of blindly opening an email message by using data from sources that have not validated. During the design process you need to think about the data your application is using and ask yourself: What data and code do I trust and what don’t I trust? I found that using the concept of a trust boundary to be a useful tool to visualize what is and is not trusted. A trust boundary is as simple as putting a box around parts of your architecture. Everything within the box trusts each other and can use information without validating it. Any data or call across the trust boundary must be validated at the very least and may need to be authenticated and encrypted. I like to color-code the different trust boundaries in my application architecture drawings so they stand out.

Figure 1

I also like to create a list of resources that are in my application and define what level of access my application needs to each of these resources. Resources can include the following:

  • Configuration files.

  • Database objects (tables, stored procedures). I like to think in terms of granular objects when defining what permissions are needed, always keeping in mind the least-privilege principle.

  • Files and directories used by the programs (including Web pages).

  • Error and audit logs.

  • Registry keys.

  • XML messages.

  • Data objects (lists, hash tables, arrays).

  • Caches.

  • Session objects.

  • Dynamic Data Types

Remember that only validated data should be allowed to cross the trust boundary. You should also avoid combining trusted and untrusted data in the same data structures to prevent using untrusted data. Defining trust boundaries and understanding your data will help you choose the technologies that will work best for your application. You can find a template on MSDN that will help you design a secure application.

Choose Your Technology Wisely

If you have never worked with any of the standards, and you know you are going to need to write .NET code that talks to a custom or purchased application that is running on J2EE application platform, give yourself some time to understand and experiment with the nuances of the technologies. You may need to dig deeper into the technology than you planned in order to get the applications to work 100% of the time. Also, you will need to consider what technologies you will use based on the requirements of your application and the maturity of the technology. Note: If you can’t change the code in the application, you will need to include it in a trust boundary and wrap it with something that you can control and then set up a trust boundary between the two components. For example, you may have a legacy application written in COBOL that you would like to integrate in your application. You could use a façade pattern to create a Web service that authenticates on behalf of the application using WS-Security and SAML. This will bring your COBOL application into the trust boundary.

Security technologies break down into three categories:

  • Authentication
    Authentication is a form of validation that verifies people or programs are who or what they claim to be. This can be accomplished by a simple user ID and password validation or more complex like exchanging public keys and verifying that the keys do match through mutual authentication of certificates.

  • Confidentiality
    Encryption technologies make information unreadable to everyone in any location (memory, file, network) except for those that have the security keys and algorithms to decrypt the information.

  • Integrity/Validation
    This may entail everything from validating the user or verifying that the data does not contain any illegal characters to verifying that the data has not been changed in transit.

Use Technology Standards

Popular standards exist on most all platforms that will allow you to ensure authentication, confidentiality, and integrity in your applications. You need to decide during design what technology meets the requirements; what is the simplest/most mature available; and what is supported by the various frameworks involved. There have been a number of security standards in the IT industry to make secure interoperation possible. You need to be thinking about the technologies supported by the application and use the simplest and most mature. Of course, everybody wants to try using a Web service and the WS-Security standard with a SAML token, but a simple digest authentication with SSL may suffice and will most likely be better supported by the applications. Also remember that even if a vendor states it supports a standard, the vendor may not fully support it and may be missing one of the features you need—so you will need to do your homework. Here are the security standards that you should consider:

Authentication Standards

  • Basic Authentication (typically over HTTP)

  • Digest Authentication (typically over HTTP)

  • Lightweight Directory Access Protocol (LDAP)

  • X.509 Certificates issued from a trusted Certificate Authority

  • Kerberos

  • WS-Security (the same as above except in a SOAP envelope)

Note: WCF uses SAML tokens by default for its federated security scenarios.

Authorization Standards

Confidentiality Standards

  • SSL\TLS Security (Transport layer security: everything is encrypted between the end points, most likely proxy server to proxy server)

  • Data Encryption Standard (DES and 3DES) (symmetric key encryption algorithms superseded by AES)

  • Advanced Encryption Standard (AES) (also known as Rijndael)

  • WS—SecurityXML Encryption (Xenc)
    http://www.w3.org/TR/xmlenc-core/

Integrity Standards

Database Providers

One of the more common ways of providing interoperation is through the database. Connecting to databases is well-documented from any platform regardless of whether you use .NET, Java, or even PHP or PERL. ODBC is universal to all platforms, Java provides you with JDBC drivers and, .NET with .NET Data Providers, OLEDB, and Data Adapters all with the purpose of talking to common databases. You should investigate the options on your driver to see what is supported in terms of authentication, confidentiality, and integrity. If one of these is not supported, you may need to look at finding a different driver or wrapping the database code in a trust boundary that provides the missing security service.

Additional Resources for Designing Secure Applications

Application Threat Modeling

Threat Modeling Resources from ACE

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft