Which XSS OWASP Rule | 易学教程

问题

Using the OWASP checklist, which is the correct way protect this situation? This is url inside of a javascript string where a url parameter needs to have xss protection.

Problem:

<script>
    var u = 'xyz.html?x=<% url.baddata %>'  
    dosomeAjax(u);
</script>

Possible solution 1:

var u = 'xyz.html?x=<% encodeForURL(url.baddata) %>'

Possible solution 2:

var u = 'xyz.html?x=<% encodeForJavaScript(url.baddata) %>'

Possible solution 3:

var u = 'xyz.html?x=<% encodeForJavaScript(encodeForURL(url.baddata)) %>'

回答1:

Solution 3 should be used:

//solution 3:
var u = 'xyz.html?x=<% encodeForJavaScript(encodeForURL(url.baddata)) %>';

It is easier to see that this is correct if we rewrite the expression as:

var u = '<% encodeForJavaScript("xyz.html?x=" + encodeForURL(url.baddata)) %>';

First, we are creating a safe URL by appending baddata to a string constant, using the appropriate escape function. Then we are taking that safe URL and placing it in a JavaScript string, so we have to call the JavaScript escape function.

回答2:

I am going to answer my own question. After working with this scenario over and over again, the solution is very apparent and the reason is too.

First and foremost: Any string which is being inserted into javascript needs to be javascript safe. This always needs to happen no matter what:

<script>
  var x = "<% encodeForJavaScript(someCrazyString) %>";
</script>

The goal here is secure this statement. Since this is javascript code, treat it as javascript--this is not a url so url encoding is is incorrect.

Now if the x is going to be used in a url, it needs to be encoded as a url.

The only thing is x is now a javascript string. So server-side encoding is impossible because the string been pushed out of the middle tier and is now living and breathing in the browser.

The solution is to use javascript's url encoding function: encodeURIComponentz()

<script>
  var x = "<% encodeForJavaScript(someCrazyString) %>";
  x = x + '234'
  var url = 'http://localhost/abc.cfm?x=' + encodeURIComponent(x)
</script>

There is never a reason to use 2 server-side XXS encoding functions. Always use a single server-side encoding function and use the correct server-side function for the context:

Url:

<a href="xyz.jsp?x=<% encodeForURL(someString) %>" target="_blank" >click here</a>

js:

 <script>
   var x = "<% encodeForJavaScript(someCrazyString) %>";
 </script>

json:

 <script>
   var x = {"x"  : "<% encodeForJSONinJS(someCrazyString) %>"};
 </script>

Update (a few years later)

Performing 2 server-side encodings will achieve the same result as encoding once on the server and once in the client. So solution 3 is correct, if and only if var u stays in url scope.

The danger of doing 2 server-side encodings is that you may only use the snippet in the context in which it was first encoded.

Take the example above and add 1 more line:

 <script>
     var u = 'xyz.html?x=<% encodeForJavaScript(encodeForURL(url.baddata)) %>
     dosomeAjax(u);
     document.getElementById('someDivTag').innerHTML= u;
 </script>

Now there are problems because u is url encoded and not html encoded. (In this particular case, this does not present an xss variability as you cannot break out of an url encoded string into js scope--nonetheless there are lots of other cases where a string will need to be encoded 2x).

For flexibility, my preference is to encode once on the server and as needed in the client as:

 <script>
     var x = "<% encodeForJavaScript(someCrazyString) %>";
     var u = 'http://localhost/abc.cfm?x=' + encodeURIComponent(x)
     dosomeAjax(u);
     document.getElementById('someDivTag').innerHTML= u.toHtml();
 </script>

where toHtml() is:

    var __entityMap = {
            "&": "&amp;",
            "<": "&lt;",
            ">": "&gt;",
            '"': '&quot;',
            "'": '&#39;',
            "/": '&#x2F;'
    };

    String.prototype.toHtml = function() {
            return String(this).replace(/[&<>"'\/]/g, function (s) {  
                    return __entityMap[s];
            });
    }

I am checking Cheran Shunmugavel's answer as correct.

回答3:

var u = 'xyz.html?x=<% encodeForURL(encodeForJavaScript(url.baddata)) %>'

EncodeForURL should be last.

<insert obligatory 'eval is bad, what are you thinking ??'>

来源：https://stackoverflow.com/questions/10488992/which-xss-owasp-rule

标签

javascript

xss

owasp