Tag: Security

Trust no one! Most security issues comes from assuming that no bad person is going to tamper with your input data. We usually pay more attention to it when processing the most common inputs, such as an HTTP request or some argument that’s going into an SQL query. But we usually don’t pay much attention to other types of resources that are also vulnerable to malicious thinking – such as an file.

are an XML feature which allow you to embedded an external source into your document. For example, let’s suppose that your application responds to queries using an XML schema, which contains a disclaimer footer. Your legal department is prone to changing the wording on it so it probably makes sense to take it from an external file, so that your templates (which are part of your deployed source code) are not modified. Such templates could look like this:

Last month the massive Heartbleed security vulnerability was exposed. Three weeks later a security flaw in Microsoft Internet Explorer was revealed. It seems as though every few months there is news of a security breach or vulnerability. As more and more business is done online, in the cloud and through SaaS providers, how can you be sure the applications you and your business use are safe? Using the Heartbleed vulnerability as a case study, this article will examine what went wrong, as well as what you should expect from a SaaS provider, before, during and after a security event.

What is Heartbleed?

Heartbleed is the commonly recognized name of an exposure identified in a critical Internet security software package called OpenSSL, the most common transmission encryption software package used by Internet servers worldwide. This vulnerability allows an attacker to craft keepalive messages in such a way as to force a server disclose its short-term memory space. Since a server’s memory often contains personal, confidential information, such as user passwords or credit card numbers, the attacker could obtain that information. More severely, the server may also inadvertently disclose to the attacker its own private encryption key, which then allows the attacker to subsequently listen to all communications with that server, even without using the Heartbleed vulnerability. The nature of this attack is such that it leaves no traces, and is practically invisible to common detection mechanisms (although now that it has been exposed, signatures for it are becoming available for popular intrusion detection software).

The “Man-in-the-Middle” attack is such a well-recognized security risk, with established solutions and preventative measures in place that when I first heard about the recent ruckus around the Apple security flaw, I thought Apple’s trouble was more legal in natural, maybe some sort of royalties dispute between iTunes and the Michael Jackson estate. Only later did I found out what all the fuss was about “in the middle”, not “in the mirror”, and why I had to upgrade the iOS on my iPhone on a beautiful Saturday afternoon.

Regarding the specifics to Apple’s security flaw, there is already plenty of press coverage out there.  For example, David Auerbach wrote a great analysis over at Slate.com.

In this post, I’d like to illustrate how automated unit testing with appropriate code coverage could have detected that particular kind of error, the one caused by grammatically correct code that inadvertently invalidated the whole logic of the program. We will build the unit tests using the MUnit module, an open source testing framework that significantly streamline and simplify the process of writing unit tests.

It sounds like the title for a fantasy movie, but Google, OAuth and the “” is a very common issue. Wikipedia defines a as “a computer program that is innocently fooled by some other party into misusing its authority. It is a specific type of privilege escalation” (complete article here).

The Wikipedia article shares an example of a compiler exposed as a paid service. This compiler receives an input source code file and the path where the compiled binary is to be stored. This compiler also keeps a file called BILLING where billing information is updated each time a compilation is requested. If a user were to request a compilation setting the output path to “BILLING”, then the file would be overwritten and the billing information lost. In this case, the compiler is a “confused deputy” because although the client doesn’t have access to the file, it’s tricked the compiler (who does have access) into altering the file.

You may have already heard that on December 31st, 2013, Snapchat was hacked and  4.6MM records were subsequently compromised. According to the official blog, “an attacker released a database of partially redacted phone numbers and usernames.” It turns out the hacker(s) had exploited the “Find Friends” API to try to return the username of automatically generated phone number combinations.

In this case, only phone numbers and usernames were released. Pretty harmless, right? Not quite. The most substantial loss that Snapchat faces in this situation is the loss of trust. Snapchat, along with other organizations that have faced similar challenges, will ultimately recover and fix flaws to become stronger than ever before.

The dreaded user table. Think about it: whenever you start working on a new end-user application, you’ll have to create a table to store emails, user information and passwords. And then you’ll need to add support for the password reset workflow. And so on and so forth. The wheel gets re-invented time and again. Of course, you may go sophisticated and decide to manage users in LDAP or even – gasp – ActiveDirectory. Now you would have a whole different range of problems to deal with, starting with interacting with this external directory in a graceful manner.

Enter Stormpath, the SaaS API whose sole mission is to make authentication and user management awesome and developer friendly! And thanks a new connector for (available here), you can now benefit from Stormpath’s extensive features, which include all of the aforementioned ones, and many more.

In this post, we will look at a Mule application that integrates with the Stormpath API via this new connector. This application exposes a web user interface that uses AJAX to interact with the Mule application. This application allows a user to create an account, log-in and trigger the password forgotten procedure. Enough ado, let’s start digging!

On my previous 3-part blog, I showed how Mule ESB can be used to service-enable and orchestrate traditional on-premise technologies like an Oracle database and IBM Websphere MQ. Using Mule ESB, we created a service that accessed employee information from an Oracle database table and transmitted this to IBM WebSphere MQ. An observant customer I was showing this to noticed a security flaw with how sensitive employee information was being transmitted in plain text and also asked how the employee record can be sent to SalesForce.com. This blog will show how these can be easily addressed using MuleSoft’s AnyPoint Platform. We’ll make use of the PGP encryption features from AnyPoint Enterprise Security to encrypt the data before sending it to WebSphere MQ. Then, we’ll create another message flow to retrieve this message, decrypt it and send it to SalesForce.com using the AnyPoint Connector for SalesForce.com.

is an ever-present concern for IT. It can be a rather daunting area when one considers all of the different possible dangers and the large variety of solutions to address them. But, the aim of Enterprise Security really just boils down to establishing and maintaining various levels of access control itself has always facilitated secure message processing both at the level of the transport, the service layer and of the message . Mule configurations can include all that Spring Security has to offer giving, for example, easy access to an LDAP server for authentication and authorisation. On top of that Mule Applications can apply WS-Security thus facilitating, for example, the validation of  incoming SAML messages. But in this post, rather than delve into all the details of the very extensive security feature set , I would rather approach the subject by considering the primary concerns that drive the need for security in a Service Oriented Architecture, how the industry as a whole has addressed those concerns, the consequent emergence of popular technologies based on this Industrial best practice and finally, the implementation of these technologies in Mule. 

Enterprise integrations running across trust boundaries demand robust security solutions. Enterprise Security enables end-to-end protection of your integration ecosystem. Join Reza Shafii, Director of Product Management at MuleSoft, to better understand how our enterprise-grade security solution can help you.

 

 

In this webinar, you will learn how to:

  • Block unauthorized access to your systems
  • Eliminate exposure of sensitive data and information
  • Prevent attacks through proactive threat management

Presenter: Reza Shafii,  Director of Product Management, MuleSoft, Inc.
Date: Thursday, January 10, 2013
Time: 8 AM PST / 11 PM EST

Register now >>

reza.shafii on Thursday, January 3, 2013

How to Protect Your APIs with OAuth

0

On this 10th ‘Day of Christmas’ Mule blog post, we tackle an increasingly important question in the world of APIs: Presume that you would like to create a remote API (which perhaps exposes some legacy business logic) for access by internal and/or external clients. How can you make sure that access to your API is protected in such a way that:

A) Only clients that you trust can access them;
B) Those clients can access your API through the explicit authorization of their end-users; and
C) The end-users can be authenticated with a central entity, *withouth* having to share their credentials with your API’s clients.