Pattern 9: Do Not Trust External Sources That You Do Not Control Yourself

vPierre Sicherheit / Security, Software Development, WWW Leave a Comment

Web applications often include content from other sources, especially content providers. The content is mostly referenced in the source code and is dynamically loaded by the user’s web browser. When integrating content from third-party sources, we should classify the trustworthiness of the source and, if necessary, check or filter the contents delivered by third parties.

9.1      What are the threats facing us and our customers?

Infected by Malicious Code from External Files

Files from external servers may be infected with malicious code that, by incorporating them into our applications, can infect our users‘ computer systems. In the past, such cases have been recognized mainly by malware in online advertising (malvertising), which has been integrated into a large number of websites and applications, which could infect a high number of computer systems.

Reputation Damage

If externally integrated files pose a threat to our users, this can also lead to reputational damage for the customer. Thus, the origin of malicious code is not directly traceable to many users and can easily be linked to the customer applications. We should therefore take all possible safeguards and carefully examine externally integrated content and files and include only trusted sources.

9.2      What should we consider during development?

Check Reliability and Trustworthiness of External Sources

Before integrating external content into our applications, the reliability and trustworthiness of the source should be checked:

·      Are the contents of a well-known provider (content provider)?

·      Has the content provider been active in the market for a long time?

·      Were there any security incidents associated with the content provider in the past?

Isolate External Content from the Rest of the Application

External content, if possible, should be isolated from the rest of the application and equipped with as few privileges as possible.

This may be achieved e.g. by using IFrames in connection with the sandbox attribute (HTML5). This allows external content to be included in the view, without the content provider running JavaScript, calling URLs, or reading cookies.

Also, it may be useful to explicitly name trustworthy sources for executable JavaScript code (so-called Content Security Policy). JavaScript code from other sources is then no longer executed in the user’s web browser and cannot pose a threat.

9.3      Further Information

Introduction to HTML5 Sandbox:
http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/Introduction to Content Security Policy (CSP):
http://www.html5rocks.com/en/tutorials/security/content-security-policy/Best Practices (=pattern) for applying the Content Security Policy (CSP):
https://www.owasp.org/index.php/Content_Security_Policy_Cheat_SheetDetailed background article on malvertising:
http://www.wired.com/2015/12/hacker-lexicon-malvertising-the-hack-that-infects-computers-without-a-click/

https://www.gronau-it-cloud-computing.de/10-pattern-for-secure-software-development/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.