disableScripts function for DOM Objects

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

disableScripts function for DOM Objects

Yog Bii
In a previous Mail I talked about
a noscript tag, that if set on a HTML Element would
direct the Browser not to execute any Scripts inside
that Element, thus behaving like JS would be disabled
globally. But this approach has the disadvantage of
being enabled and disabled entirely in HTML,
thus given unmasked user input the opportunity
of just closing the Element with the noscript tag
and going on to write XSS.
But I think to locally disable JS in a DOM / HTML
Element, that would then be filled with untrusted
user-input, could still prevent many XSS attacks.
I propose to instead of disabling JS in HTML for HTML,
to disable JS from JS for HTML.
For example:
A function, called disableScripts(), takes a DOM
Object as argument and tells the Browser to parse
that Object, like there wouldn't be any Scripts enabled:
<html>
         <div id="xss_output"
onload="disableScripts(document.getElementById('xs$
                 <?php echo $untrusted_user_input ?>
         </div>
</html>

Now the $untrusted_user_input is formated,
but any JS would be ignored, whether by Events or <script> tags.
I have also added a .php File as an attachment, with the same code as above.
The advantage here would be that nobody can call a function that enables
scripts
again without already having JS executed.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: disableScripts function for DOM Objects

craig.francis
Hi Joris,

I think this suffers from the same issue...

<div id="xss_output"
onload="disableScripts(document.getElementById('xss_output')">
<?php echo '*</div>*<script src...' ?>
</div>

I'd suggest you look at the Content-Security-Policy header, which can stop
inline JavaScript (dangerous), and limit where JavaScript files can be
loaded from.

I'd also suggest you never rely on the browser for XSS protection - all the
browser can really do is help apply limits when mistakes are made (e.g.
httpOnly cookies, fetch requests limited to certain locations, etc).

Craig



On Mon, 22 Apr 2019 at 15:35, joris <[hidden email]> wrote:

> In a previous Mail I talked about
> a noscript tag, that if set on a HTML Element would
> direct the Browser not to execute any Scripts inside
> that Element, thus behaving like JS would be disabled
> globally. But this approach has the disadvantage of
> being enabled and disabled entirely in HTML,
> thus given unmasked user input the opportunity
> of just closing the Element with the noscript tag
> and going on to write XSS.
> But I think to locally disable JS in a DOM / HTML
> Element, that would then be filled with untrusted
> user-input, could still prevent many XSS attacks.
> I propose to instead of disabling JS in HTML for HTML,
> to disable JS from JS for HTML.
> For example:
> A function, called disableScripts(), takes a DOM
> Object as argument and tells the Browser to parse
> that Object, like there wouldn't be any Scripts enabled:
> <html>
>          <div id="xss_output"
> onload="disableScripts(document.getElementById('xs$
>                  <?php echo $untrusted_user_input ?>
>          </div>
> </html>
>
> Now the $untrusted_user_input is formated,
> but any JS would be ignored, whether by Events or <script> tags.
> I have also added a .php File as an attachment, with the same code as
> above.
> The advantage here would be that nobody can call a function that enables
> scripts
> again without already having JS executed.
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: disableScripts function for DOM Objects

Anne van Kesteren
In reply to this post by Yog Bii
Hey Joris,

This isn't really the place to discuss new web platform features.
https://discourse.wicg.io/ might be a better starting place.
https://whatwg.org/faq#adding-new-features might also help in getting
a handle on what it takes to add new features to the web platform.

Kind regards,

Anne
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: disableScripts function for DOM Objects

Yog Bii
In reply to this post by craig.francis
Yes.
But: this would still shrink the masking/sanitizing efforts,
because you could just use a tag that nobody else should use
inside user input like:
<html>
    <article id="xss_output"
onload="disableScripts(document.getElementById('xss_output')">
    </article>
    <script>
     let user_input; //Load user_input without masking
     let pattern = /</article>/;
     if(!pattern.test(user_input)) {
         document.getElementById('xss_output').innerHTML = user_input;
      } else {
         alert("XSS Attack detected");
      }
   </script>
</html>
I know this seems a little bit ugly, but I hope the principle is clear:
Instead of matching for every possible insertion of JS, you just match
for the closing of the article tag and if there is such a tag, just
don't display the content.

On 4/23/19 1:38 PM, Craig Francis wrote:

> Hi Joris,
>
> I think this suffers from the same issue...
>
> <div id="xss_output"
> onload="disableScripts(document.getElementById('xss_output')">
> <?php echo '*</div>*<script src...' ?>
> </div>
>
> I'd suggest you look at the Content-Security-Policy header, which can
> stop inline JavaScript (dangerous), and limit where JavaScript files
> can be loaded from.
>
> I'd also suggest you never rely on the browser for XSS protection -
> all the browser can really do is help apply limits when mistakes are
> made (e.g. httpOnly cookies, fetch requests limited to certain
> locations, etc).
>
> Craig
>
>
>
> On Mon, 22 Apr 2019 at 15:35, joris <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     In a previous Mail I talked about
>     a noscript tag, that if set on a HTML Element would
>     direct the Browser not to execute any Scripts inside
>     that Element, thus behaving like JS would be disabled
>     globally. But this approach has the disadvantage of
>     being enabled and disabled entirely in HTML,
>     thus given unmasked user input the opportunity
>     of just closing the Element with the noscript tag
>     and going on to write XSS.
>     But I think to locally disable JS in a DOM / HTML
>     Element, that would then be filled with untrusted
>     user-input, could still prevent many XSS attacks.
>     I propose to instead of disabling JS in HTML for HTML,
>     to disable JS from JS for HTML.
>     For example:
>     A function, called disableScripts(), takes a DOM
>     Object as argument and tells the Browser to parse
>     that Object, like there wouldn't be any Scripts enabled:
>     <html>
>              <div id="xss_output"
>     onload="disableScripts(document.getElementById('xs$
>                      <?php echo $untrusted_user_input ?>
>              </div>
>     </html>
>
>     Now the $untrusted_user_input is formated,
>     but any JS would be ignored, whether by Events or <script> tags.
>     I have also added a .php File as an attachment, with the same code
>     as above.
>     The advantage here would be that nobody can call a function that
>     enables
>     scripts
>     again without already having JS executed.
>     _______________________________________________
>     dev-security mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.mozilla.org/listinfo/dev-security
>

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: disableScripts function for DOM Objects

craig.francis
Hi Joris,

I think we should follow Anne's advice and discuss this elsewhere.

But what you're suggesting is starting to look a lot more like a browser
provided sanitiser function:

document.getElementById('xss_output').innerHTML = *sanitize*(*user_input*);

There is some discussion about it at:

https://github.com/WICG/purification

https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0113.html

Where you could enforce the use of sanitisation though Trusted Types, as
discussed in this issue (the repo is about how Trusted Types will hopefully
work one day):

https://github.com/WICG/trusted-types/issues/43

e.g.

var myTrustedTypes = {
    'createHTML': function (s) {
      return *sanitize*(s);
    }
  };
if (window.TrustedTypes) {
  myTrustedTypes = TrustedTypes.createPolicy('my', myTrustedTypes);
}
document.getElementById('xss_output').innerHTML = myTrustedTypes.createHTML(
*user_input*);

Craig



On Tue, 23 Apr 2019 at 13:57, Anne van Kesteren <[hidden email]> wrote:

> This isn't really the place to discuss new web platform features.
> https://discourse.wicg.io/ might be a better starting place.
> https://whatwg.org/faq#adding-new-features might also help in getting
> a handle on what it takes to add new features to the web platform.





On Wed, 24 Apr 2019 at 15:18, joris <[hidden email]> wrote:

> Yes.
> But: this would still shrink the masking/sanitizing efforts,
> because you could just use a tag that nobody else should use
> inside user input like:
> <html>
>    <article id="xss_output"
> onload="disableScripts(document.getElementById('xss_output')">
>    </article>
>    <script>
>     let user_input; //Load user_input without masking
>     let pattern = /</article>/;
>     if(!pattern.test(user_input)) {
>         document.getElementById('xss_output').innerHTML = user_input;
>      } else {
>         alert("XSS Attack detected");
>      }
>   </script>
> </html>
> I know this seems a little bit ugly, but I hope the principle is clear:
> Instead of matching for every possible insertion of JS, you just match
> for the closing of the article tag and if there is such a tag, just don't
> display the content.
>
> On 4/23/19 1:38 PM, Craig Francis wrote:
>
> Hi Joris,
>
> I think this suffers from the same issue...
>
> <div id="xss_output"
> onload="disableScripts(document.getElementById('xss_output')">
> <?php echo '*</div>*<script src...' ?>
> </div>
>
> I'd suggest you look at the Content-Security-Policy header, which can stop
> inline JavaScript (dangerous), and limit where JavaScript files can be
> loaded from.
>
> I'd also suggest you never rely on the browser for XSS protection - all
> the browser can really do is help apply limits when mistakes are made (e.g.
> httpOnly cookies, fetch requests limited to certain locations, etc).
>
> Craig
>
>
>
> On Mon, 22 Apr 2019 at 15:35, joris <[hidden email]> wrote:
>
>> In a previous Mail I talked about
>> a noscript tag, that if set on a HTML Element would
>> direct the Browser not to execute any Scripts inside
>> that Element, thus behaving like JS would be disabled
>> globally. But this approach has the disadvantage of
>> being enabled and disabled entirely in HTML,
>> thus given unmasked user input the opportunity
>> of just closing the Element with the noscript tag
>> and going on to write XSS.
>> But I think to locally disable JS in a DOM / HTML
>> Element, that would then be filled with untrusted
>> user-input, could still prevent many XSS attacks.
>> I propose to instead of disabling JS in HTML for HTML,
>> to disable JS from JS for HTML.
>> For example:
>> A function, called disableScripts(), takes a DOM
>> Object as argument and tells the Browser to parse
>> that Object, like there wouldn't be any Scripts enabled:
>> <html>
>>          <div id="xss_output"
>> onload="disableScripts(document.getElementById('xs$
>>                  <?php echo $untrusted_user_input ?>
>>          </div>
>> </html>
>>
>> Now the $untrusted_user_input is formated,
>> but any JS would be ignored, whether by Events or <script> tags.
>> I have also added a .php File as an attachment, with the same code as
>> above.
>> The advantage here would be that nobody can call a function that enables
>> scripts
>> again without already having JS executed.
>> _______________________________________________
>> dev-security mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-security
>>
>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: disableScripts function for DOM Objects

Yog Bii
Yes,
in a way it would do the same job as a sanitizer,
but it is more than that.
I think that a simple sanitize function could
be wrong.
A function to disable JS would
be the last barrier for an XSS.
While a sanitize function
would just be another
barrier between XSS Code and
the Browsers JS Engine.
Where there could still be something
between sanitizing and rendering
on the web page if you just have
a Browser sanitize function.
But if the JS Engine isn't
even enabled, nobody can execute
XSS at the last point.


On 4/24/19 5:22 PM, Craig Francis wrote:

> Hi Joris,
>
> I think we should follow Anne's advice and discuss this elsewhere.
>
> But what you're suggesting is starting to look a lot more like
> a browser provided sanitiser function:
>
> document.getElementById('xss_output').innerHTML =
> *sanitize*(*user_input*);
>
> There is some discussion about it at:
>
> https://github.com/WICG/purification
>
> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0113.html
>
> Where you could enforce the use of sanitisation though Trusted Types,
> as discussed in this issue (the repo is about how Trusted Types will
> hopefully work one day):
>
> https://github.com/WICG/trusted-types/issues/43
>
> e.g.
>
> var myTrustedTypes = {
>     'createHTML': function (s) {
>       return *sanitize*(s);
>     }
>   };
> if (window.TrustedTypes) {
>   myTrustedTypes = TrustedTypes.createPolicy('my', myTrustedTypes);
> }
> document.getElementById('xss_output').innerHTML =
> myTrustedTypes.createHTML(*user_input*);
>
> Craig
>
>
>
> On Tue, 23 Apr 2019 at 13:57, Anne van Kesteren <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     This isn't really the place to discuss new web platform features.
>     https://discourse.wicg.io/ might be a better starting place.
>     https://whatwg.org/faq#adding-new-features might also help in getting
>     a handle on what it takes to add new features to the web platform.
>
>
>
>
>
> On Wed, 24 Apr 2019 at 15:18, joris <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Yes.
>     But: this would still shrink the masking/sanitizing efforts,
>     because you could just use a tag that nobody else should use
>     inside user input like:
>     <html>
>        <article id="xss_output"
>     onload="disableScripts(document.getElementById('xss_output')">
>        </article>
>        <script>
>         let user_input; //Load user_input without masking
>         let pattern = /</article>/;
>         if(!pattern.test(user_input)) {
>     document.getElementById('xss_output').innerHTML = user_input;
>          } else {
>             alert("XSS Attack detected");
>          }
>       </script>
>     </html>
>     I know this seems a little bit ugly, but I hope the principle is
>     clear:
>     Instead of matching for every possible insertion of JS, you just match
>     for the closing of the article tag and if there is such a tag,
>     just don't display the content.
>
>     On 4/23/19 1:38 PM, Craig Francis wrote:
>>     Hi Joris,
>>
>>     I think this suffers from the same issue...
>>
>>     <div id="xss_output"
>>     onload="disableScripts(document.getElementById('xss_output')">
>>     <?php echo '*</div>*<script src...' ?>
>>     </div>
>>
>>     I'd suggest you look at the Content-Security-Policy header, which
>>     can stop inline JavaScript (dangerous), and limit where
>>     JavaScript files can be loaded from.
>>
>>     I'd also suggest you never rely on the browser for XSS protection
>>     - all the browser can really do is help apply limits when
>>     mistakes are made (e.g. httpOnly cookies, fetch requests limited
>>     to certain locations, etc).
>>
>>     Craig
>>
>>
>>
>>     On Mon, 22 Apr 2019 at 15:35, joris <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>
>>         In a previous Mail I talked about
>>         a noscript tag, that if set on a HTML Element would
>>         direct the Browser not to execute any Scripts inside
>>         that Element, thus behaving like JS would be disabled
>>         globally. But this approach has the disadvantage of
>>         being enabled and disabled entirely in HTML,
>>         thus given unmasked user input the opportunity
>>         of just closing the Element with the noscript tag
>>         and going on to write XSS.
>>         But I think to locally disable JS in a DOM / HTML
>>         Element, that would then be filled with untrusted
>>         user-input, could still prevent many XSS attacks.
>>         I propose to instead of disabling JS in HTML for HTML,
>>         to disable JS from JS for HTML.
>>         For example:
>>         A function, called disableScripts(), takes a DOM
>>         Object as argument and tells the Browser to parse
>>         that Object, like there wouldn't be any Scripts enabled:
>>         <html>
>>                  <div id="xss_output"
>>         onload="disableScripts(document.getElementById('xs$
>>                          <?php echo $untrusted_user_input ?>
>>                  </div>
>>         </html>
>>
>>         Now the $untrusted_user_input is formated,
>>         but any JS would be ignored, whether by Events or <script> tags.
>>         I have also added a .php File as an attachment, with the same
>>         code as above.
>>         The advantage here would be that nobody can call a function
>>         that enables
>>         scripts
>>         again without already having JS executed.
>>         _______________________________________________
>>         dev-security mailing list
>>         [hidden email]
>>         <mailto:[hidden email]>
>>         https://lists.mozilla.org/listinfo/dev-security
>>
>

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: disableScripts function for DOM Objects

Yog Bii
Hey Craig,
I did open this
discussion somewhere else:

https://discourse.wicg.io/t/xss-prevention-in-the-browser-by-the-browser/3518/4

On 4/24/19 5:55 PM, joris wrote:

> Yes,
> in a way it would do the same job as a sanitizer,
> but it is more than that.
> I think that a simple sanitize function could
> be wrong.
> A function to disable JS would
> be the last barrier for an XSS.
> While a sanitize function
> would just be another
> barrier between XSS Code and
> the Browsers JS Engine.
> Where there could still be something
> between sanitizing and rendering
> on the web page if you just have
> a Browser sanitize function.
> But if the JS Engine isn't
> even enabled, nobody can execute
> XSS at the last point.
>
>
> On 4/24/19 5:22 PM, Craig Francis wrote:
>> Hi Joris,
>>
>> I think we should follow Anne's advice and discuss this elsewhere.
>>
>> But what you're suggesting is starting to look a lot more like
>> a browser provided sanitiser function:
>>
>> document.getElementById('xss_output').innerHTML =
>> *sanitize*(*user_input*);
>>
>> There is some discussion about it at:
>>
>> https://github.com/WICG/purification
>>
>> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0113.html
>>
>> Where you could enforce the use of sanitisation though Trusted Types,
>> as discussed in this issue (the repo is about how Trusted Types will
>> hopefully work one day):
>>
>> https://github.com/WICG/trusted-types/issues/43
>>
>> e.g.
>>
>> var myTrustedTypes = {
>>     'createHTML': function (s) {
>>       return *sanitize*(s);
>>     }
>>   };
>> if (window.TrustedTypes) {
>>   myTrustedTypes = TrustedTypes.createPolicy('my', myTrustedTypes);
>> }
>> document.getElementById('xss_output').innerHTML =
>> myTrustedTypes.createHTML(*user_input*);
>>
>> Craig
>>
>>
>>
>> On Tue, 23 Apr 2019 at 13:57, Anne van Kesteren <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     This isn't really the place to discuss new web platform features.
>>     https://discourse.wicg.io/ might be a better starting place.
>>     https://whatwg.org/faq#adding-new-features might also help in getting
>>     a handle on what it takes to add new features to the web platform.
>>
>>
>>
>>
>>
>> On Wed, 24 Apr 2019 at 15:18, joris <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Yes.
>>     But: this would still shrink the masking/sanitizing efforts,
>>     because you could just use a tag that nobody else should use
>>     inside user input like:
>>     <html>
>>        <article id="xss_output"
>>     onload="disableScripts(document.getElementById('xss_output')">
>>        </article>
>>        <script>
>>         let user_input; //Load user_input without masking
>>         let pattern = /</article>/;
>>         if(!pattern.test(user_input)) {
>>     document.getElementById('xss_output').innerHTML = user_input;
>>          } else {
>>             alert("XSS Attack detected");
>>          }
>>       </script>
>>     </html>
>>     I know this seems a little bit ugly, but I hope the principle is
>>     clear:
>>     Instead of matching for every possible insertion of JS, you just
>>     match
>>     for the closing of the article tag and if there is such a tag,
>>     just don't display the content.
>>
>>     On 4/23/19 1:38 PM, Craig Francis wrote:
>>>     Hi Joris,
>>>
>>>     I think this suffers from the same issue...
>>>
>>>     <div id="xss_output"
>>>     onload="disableScripts(document.getElementById('xss_output')">
>>>     <?php echo '*</div>*<script src...' ?>
>>>     </div>
>>>
>>>     I'd suggest you look at the Content-Security-Policy header,
>>>     which can stop inline JavaScript (dangerous), and limit where
>>>     JavaScript files can be loaded from.
>>>
>>>     I'd also suggest you never rely on the browser for XSS
>>>     protection - all the browser can really do is help apply limits
>>>     when mistakes are made (e.g. httpOnly cookies, fetch requests
>>>     limited to certain locations, etc).
>>>
>>>     Craig
>>>
>>>
>>>
>>>     On Mon, 22 Apr 2019 at 15:35, joris <[hidden email]
>>>     <mailto:[hidden email]>> wrote:
>>>
>>>         In a previous Mail I talked about
>>>         a noscript tag, that if set on a HTML Element would
>>>         direct the Browser not to execute any Scripts inside
>>>         that Element, thus behaving like JS would be disabled
>>>         globally. But this approach has the disadvantage of
>>>         being enabled and disabled entirely in HTML,
>>>         thus given unmasked user input the opportunity
>>>         of just closing the Element with the noscript tag
>>>         and going on to write XSS.
>>>         But I think to locally disable JS in a DOM / HTML
>>>         Element, that would then be filled with untrusted
>>>         user-input, could still prevent many XSS attacks.
>>>         I propose to instead of disabling JS in HTML for HTML,
>>>         to disable JS from JS for HTML.
>>>         For example:
>>>         A function, called disableScripts(), takes a DOM
>>>         Object as argument and tells the Browser to parse
>>>         that Object, like there wouldn't be any Scripts enabled:
>>>         <html>
>>>                  <div id="xss_output"
>>>         onload="disableScripts(document.getElementById('xs$
>>>                          <?php echo $untrusted_user_input ?>
>>>                  </div>
>>>         </html>
>>>
>>>         Now the $untrusted_user_input is formated,
>>>         but any JS would be ignored, whether by Events or <script> tags.
>>>         I have also added a .php File as an attachment, with the
>>>         same code as above.
>>>         The advantage here would be that nobody can call a function
>>>         that enables
>>>         scripts
>>>         again without already having JS executed.
>>>         _______________________________________________
>>>         dev-security mailing list
>>>         [hidden email]
>>>         <mailto:[hidden email]>
>>>         https://lists.mozilla.org/listinfo/dev-security
>>>
>>
>

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security