How Security Relates to Your Brand

This is primarily intended as a technical blog, however, every now and then there are issues that arise which require us sun-deprived tech people to grudgingly think outside of the tech-box. We sometimes act like our tech world is less like a box and more like one of those underwater shark-proof cages — we use tech to keep the business people out. Well, time to head out there into the scary business waters where all those suits swim for a minute.

Check your tanks and let’s go… 🙂

Swim With The Fish! (Credit: TANAKA Juuyoh (田中十洋) - Wikicomons)

Seeing Security From Within The Business Waters

One issue that I often see coming up over and over again is a misunderstanding of how a very small security issue can affect the business, specifically in the area of trust. I’m not talking about larger issues like a SQL injection vulnerability, or improperly configured servers, which are always understood by technical people as things that must be solved ASAP, but I’m talking about the really simple things such as URL forwards (sometimes called Open Redirects or Open Forwards.)

Let’s look at an example to see how that relates.

What I mean by URL forwards are situations where — in the web world — we would use a URL parameter to keep track of where we want to send a user next. Sometimes, for example, we may have a content page such as the following for what we will pretend is a site at our company, called “example.com.”

http://www.example.com/content/article100

Now let’s pretend this site is a content site, and let’s also imagine this page might say “this page is available for subscribers only, so please login!” However, we probably want to send the user to a common login page, but at the same time we also need to get the user back to where they were so that they can enjoy the article they paid for. How do we remember where we should send them back to such that the user can finish reading her content?

Well, a common technique is to save the current URL in a parameter, and get back to the page once the user is authenticated:

http://www.example.com/content/login?return_to_url=www.example.com/content/article100

What a Hacker Sees

The problem with URL parameters is that they are not read only. I could just as easily type this on the command line, and if the parameters are not checked properly to ensure they cannot be over used to get to other sites, this might forward the user somewhere else besides our site. For example, this might forward one to Google immediately after login:

http://www.example.com/content/login?return_to_url=www.google.com

Well, there’s no apparent harm from this for a couple reasons, and that’s usually what is heard when discussing this sort of issue:

1. Someone would (apparently) have to have access to your browser to type that stuff up there.
2. Even if someone did forward you to another site, what’s the harm in that?

Now, the first point is only sort of true: This is a “browser side” problem, however, there are numerous ways to get a link in an unsuspecting user’s browser. Let us imagine for a moment that we are Mary, one of mysite.com’s clients. As a manager at an important company, she is alert and astute. But busy. Really busy.

If, like many content sites, you send occasional mailout’s reminding people that you’re alive, a Bad Guy could send a professional looking email to Mary (among millions of other people) in an attempt to convince them to click on a link like this one:

http://www.example.com/content/login?return_to_url=http://hackorheavenmysite.com/login

As a subscriber, she might think these are new articles to a product she knows she subscribes to. She might be interested in clicking on one of the links.

If you look at the above link, especially on the left side as we all do, it looks pretty much harmless. This is the important part: Because the link really originates from our real site, it is not obviously a problem. And this is why this is a real problem for those business aware suits I mentioned off the top: This Bad Guy has hijacked Mary’s trust of our brand. More on this later.

Mary clicks. She goes to the login page, and she logs in.

From that, an alert hacker could maybe convince Mary that her login actually didn’t work, so please try again — but on a page that looks exactly like the last one (which was real) but now is actually a Bad Site — resulting in her credentials being stolen.

As an aside, there are lots of tricks to hide the data on the URL, so it’s harder to see what it’s doing. Thus URL is actually identical to the more obviously bad one, above:

http://www.example.com/content/login?return_to_url=http%3A%5C%5C%68%61%63%6B%6F%72%68%65%61%76%65%6Emysite.com/login

Why Mitigation isn’t the Only Point

Technically speaking, there are things that can be done to fix this. We may do a blog post on scrubbing techniques for this sort of a situation, but fundamentally it just needs to be valid data when it comes in from URLs. This isn’t what I wanted us to learn, out here among the business sharks.

As I said off the top, the technical solution isn’t really all that difficult, however, convincing technical people why something which is this “laterally risky to the website” can be important enough to solve as a high priority, is: Sure, there are security risks, but in this day and age, that’s only part of the problem. The more serious issue, as I see it anyway, is that Mary will no longer trust our company once her credit card has been used, or once her personal data has been skimmed.

Fundamentally, the problem you need to beware of isn’t just what can be done. It’s also about how bad someone can make your brand look with a post to a website after they have found issues. Depending on your business — it’s what people can tell the world to make your business look insecure in an age where competition is fierce, and trust in your brand is very, very valuable.

Okay, you can get back in the shark cage now. 🙂

Ron Matuschek ( @RonEm on Twitter) is a software developer who has been swimming outside of the shark cage for more years than he’d care to admit. 🙂