Geek Answers Handbook

Would this be a good idea against XSS?

since it is actually not very popular to use the Origin / X-Frame-Options HTTP header, and I don’t think the new CSP in Firefox would be better (overhead, complexity, etc.). I want to make an offer for a new version of JavaScript / ECMA.

But first, I publish this idea so that you can say it is bad. I call it simple jsPolicy :

Everyone who uses JavaScript has placed scripts in their html header. So why don't we use them to add our policies to control all subsequent scenarios. Example:

<html> <head> <title>Example</title> <script> window.policy.inner = ["\nfunction foo(bar) {\n return bar;\n}\n", "foo(this);"]; </script> </head> <body> <script> function foo(bar) { return bar; } </script> <a href="#" onclick="foo(this);">Click Me</a> <script> alert('XSS'); </script> </body> </html>

Now the browser compares <scripts> .innerHTML and onclick.value with those specified in the policy, and therefore the last script element is not executed (ignored).

Of course, it won't be useful to double all the embedded code, so instead we will use checksums. Example:

 crc32("\nfunction foo(bar) {\n return bar;\n}\n");

Results for "1077388790"

And now a complete example:

 if (typeof window.policy != 'undefined') { window.policy.inner = ["1077388790", "2501246156"]; window.policy.url = ["http://code.jquery.com/jquery*.js","http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"]; window.policy.relative = ["js/*.js"]; window.policy.report = ["api/xssreport.php"]; }

The browser only needs to be compared if the checksum of the built-in script is set to policy.inner or if the URL script.src is suitable for policy.url.

Note. The idea of ​​politics. Relative - allow only local scripts:

 window.policy.url = false; window.policy.relative = ["js/*.js"];

Note. policy.report should be almost the same as with CSP (sends blocked scripts and URLs in api):
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-unofficial-draft-20110315.html#violation-report-syntax

Important:

  • A policy cannot be set twice (otherwise it will issue a warning) = constant
  • To think about it: a policy can only be set in the head (otherwise it issues a warning)
  • This policy is only used to test scripts that are part of the html source, and not those that are hosted on the fly. example:
    document.write ('<script src = "http://code.jquery.com/jquery-1.5.2.min.js"> </ scr' + 'ipt>');
    You do not need the definition of policy.url for "http: //code.jquery.com ..." as the checksum of policy.inner checked the full source of the script. This means that the source is loaded, even if the policy.url parameter is set to false (yes, it is still protected!). This ensures easy use of the policy.
  • If one of the policies is missing, there are no restrictions. This means an empty policy. The result resolves all local files. This ensures backward compatibility.
  • If one of the policies is set to false, use is not allowed (by default, this is true). example:
    policy.inner = false;
    This prohibits any inline scripts.
  • The policy ignores only prohibited scripts and issues a console warning (an error stops the execution of permitted scripts, and this is not required).

I think this would make XSS impossible, and instead of CSP, it would also avoid permanent XSS (since no one ever overwrites the Policy), and it would be much easier to update.

What do you think?

EDIT:
Here is an example made in Javascript:
http://www.programmierer-forum.de/php/js-policy-against-xss.php

Of course, we cannot control the execution of the script, but it shows how it can work if there is a browser compatible with jsPolicy.

EDIT2:
I don’t think I'm talking about coding a small javascript function to detect xss! My jsPolicy idea should be part of the new JavaScript engine. You can compare it with the php installation placed in the .htaccess file. You cannot change this parameter at runtime. The same requirements apply to jsPolicy. You can call it global setting .

jsPolicy in a nutshell:
HTML parser -> send scripts in JavaScript Engine -> compare with jsPolicy -> allowed?
A) yes, execution using the JavaScript Engine
B) no, ignored and sends a report to the webmaster

EDIT3 :
Referring to Mike's comment , this is also possible:

 window.policy.eval = false;
+4
source share
4 answers

Crossite scripting occurs on the client side. Policies are defined on the client side. See the problem?

I like the Content Security Policy, and I use it in all my projects. In fact, I'm working on a JavaScript framework that has one of its requirements: "CSP-friendly."

CSP> crossdomain.xml> your policy.

+4
source

The vast majority of XSS attacks come from "trusted" sources, at least with respect to the browser. They are usually the result of a user echo input, for example. in the forum, not escape from input. You will never get XSS from a jquery link, and it is extremely that you will be from any other related source.

In case you are trying to execute cross-domain scripts, you cannot get the checksum on the remote script.

So, although your idea seems great, I really don't see the point.

+1
source

This idea continues to swim and swim so often ... and each time, security experts have debunked it.
This does not mean that it sounds harsh, but it is not a development problem, it is a security problem. In particular, most developers do not understand how many options, vectors, exploits, and evasion methods exist.

As mentioned in other answers, the problem is that your solution does not solve the problem, trust or not trust what comes in the browser, because on the client side you do not know what the code is and what the data is. Even your decision does not interfere with this.

See this question on ITsec.SE for some practical questions on implementing this. (your question is a kind of duplicate of this, more or less ...)

Btw, re CSP - check out this other question on ITsec.SE .

+1
source

This policy is only used to test scripts that are part of the html source, and not those that are hosted on the fly. example: document.write (''); You do not need the definition of policy.url for "http: //code.jquery.com ..." as the checksum of policy.inner checked the full source of the script. This means that the source is loaded, even if the policy.url parameter is set to false (yes, it is still protected!). This ensures easy use of the policy.

You seem to have left the whole game here.

If I have a code like

 // Pull parameters out of query string. var match = location.search.match(/[&?]([^&=]+)=([^&]*)/); window[decodeURIComponent(match[1])](decodeURIComponent(match[2]));

and someone tricks the user into visiting my site using the query string ?eval=alert%28%22pwned%22%29 , then they were XSSed, and your policy did nothing to stop it.

0
source

More articles:


All Articles