This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Periodic Table of Vulnerabilities - Remote File Inclusion"

From OWASP
Jump to: navigation, search
m
 
Line 34: Line 34:
  
 
=== Discussion / Controversy ===
 
=== Discussion / Controversy ===
This issue is closely related to [[OWASP Periodic Table of Vulnerabilities - Weak Authentication Methods | Weak Authentication Methods]], which allows malicious third parties to trick users into giving away login credentials. The standards solution is also closely related to [[OWASP Periodic Table of Vulnerabilities - Cross-Site Scripting (XSS) | Cross-Site Scripting]].
+
This issue is closely related to [[OWASP Periodic Table of Vulnerabilities - Weak Authentication Methods | Weak Authentication Methods]], which allows malicious third parties to trick users into giving away login credentials. The standards solution is also closely related to [[OWASP Periodic Table of Vulnerabilities - Cross-Site Scripting (XSS) | Cross-Site Scripting]]. Most use cases may be already solved by <code>seamless</code> and <code>sandbox</code> attributes of <code>IFRAME</code> elements.
  
 
=== References ===
 
=== References ===
Line 43: Line 43:
 
[https://developer.chrome.com/extensions/contentSecurityPolicy.html Content Security Policy]<BR>
 
[https://developer.chrome.com/extensions/contentSecurityPolicy.html Content Security Policy]<BR>
 
[https://developers.google.com/caja/ Google Caja]<BR>
 
[https://developers.google.com/caja/ Google Caja]<BR>
 +
[http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html IFRAME HTML Element Living Standard]

Latest revision as of 00:30, 16 November 2013

Return to Periodic Table Working View

Remote File Inclusion

Root Cause Summary

The application loads data from an attacker-controlled resource at runtime, enabling a variety of malicious activities. Either the source address or the resource itself (or both) may be under the attacker's control.

Browser / Standards Solution

Define a standard for safe inclusion of 3rd-party code and content which enforces namespace separation and mediates namespace/DOM access.

The standard should provide support for the following content types:

  • 3rd-party images
  • Active content such as Flash, Applets, ActiveX or other OBJECT content
  • IFRAMEd content
  • 3rd-party SCRIPT

The standard should allow for the content to be safely rendered in both of the following scenarios:

  1. The content is loaded by the browser after the containing page is fully constructed by the web server.
  2. The content is embedded in the containing page by the web server before it is served to the browser.

Perimeter Solution

None

Generic Framework Solution

Provide a configurable white list of 3rd-party domains which are allowed to serve inline content, and block file inclusion from all other domains.

Provide a proxy library to sanitize/sandbox third-party code and content for safe inclusion (e.g. Caja).

Custom Framework Solution

None

Custom Code Solution

None

Discussion / Controversy

This issue is closely related to Weak Authentication Methods, which allows malicious third parties to trick users into giving away login credentials. The standards solution is also closely related to Cross-Site Scripting. Most use cases may be already solved by seamless and sandbox attributes of IFRAME elements.

References

Top 10 2007-Malicious File Execution
PHP File Inclusion
Remote File Inclusion (WASC)
PHP Remote File Include (CWE)
Content Security Policy
Google Caja
IFRAME HTML Element Living Standard