Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The safearea HTML tag and attribute #7164

Closed
doctoresam1 opened this issue Oct 6, 2021 · 5 comments
Closed

The safearea HTML tag and attribute #7164

doctoresam1 opened this issue Oct 6, 2021 · 5 comments

Comments

@doctoresam1
Copy link

The problem: preventing code injection in web pages.

proposed solution: the safearea html attribute and tag. it mark part of the page as 'not supposed to have any code inside'.

here is an example...

<body safearea="39hjf978fgewsd9fewq9fghqwe9dhfq9hfj39e7uh893rwe">

</body>

the long alfa-numenric code is :

  • pseudo random.
  • generated by the backend.each time a user request a page he get a new code.
  • the length is determined by the backend , minimum length should be suggested by us (lets make it min 20 characters for now).
    -the browser will accept safearea body code only from the first tag in the page, that to prevent maliciously inserting a second body tag with new safearea code in order to override the main page safearea code. thus safearea does NOT work in iframe.

how to use?

<ul safearea="39hjf978fgewsd9fewq9fghqwe9dhfq9hfj39e7uh893rwe">
    <li> ubsanitized raw user input goes here </li>
    <li> ubsanitized raw user input goes here </li>
    <li> ubsanitized raw user input goes here </li>
    <li> ubsanitized raw user input goes here </li>
</ul safearea="39hjf978fgewsd9fewq9fghqwe9dhfq9hfj39e7uh893rwe">

basically once the browser see the safearea attribute with a code matching that in the body tag it turn on "no execution allowed mode" which will turn off interpreting anything as javascript or wasm . once the browser see a matching closing tag with the correct code it turn off "no execution allowed mode".

a closing tag with no code or with incorrect code will NOT turn off the safearea.

you can mark a whole area of the page as safearea by using the tag:

<safearea code="39hjf978fgewsd9fewq9fghqwe9dhfq9hfj39e7uh893rwe">
    // any amount of html can go here
</safearea code="39hjf978fgewsd9fewq9fghqwe9dhfq9hfj39e7uh893rwe">

the safearea tag has no visual representation in the page what so ever,it is merely there in order to provide a signal to the browser. i.e. it is not even an inline or block element.

you want to hydrate the page via ajax? no problem:

<div class="myclass" safearea="39hjf978fgewsd9fewq9fghqwe9dhfq9hfj39e7uh893rwe">
<div>

<script>
     // javascript to hydrate the div above
</script>

i am lazy and "safearea" seem to be long, but for now i am more interested in the idea.

@annevk
Copy link
Member

annevk commented Oct 6, 2021

This is what srcdoc and sandbox are for. This kind of design was also considered and you can find discussion of it in the mailing list archives: https://lists.whatwg.org/.

If we were to reconsider this it would benefit from being iterated over by the WICG community first: https://wicg.io/.

Hope that helps.

@annevk annevk closed this as completed Oct 6, 2021
@tabatkins
Copy link
Collaborator

Specifically, this exact idea (a random nonce value placed on the opening and matching closing tag of an element) was considered and rejected back during the srcdoc/sandbox design.

@doctoresam1
Copy link
Author

doctoresam1 commented Oct 6, 2021

1- srcdoc and sandbox apply to iframes only.
2- was there such design considered before? you are mistaken because searching the mailing list there is nothing like that.

question : is there any letter agency ( WICG community) preventing this from happening because they want such security vulnerabilities to continue happening?

of course it was rejected because from what i can tell , such solution is secure and it should have been in the HTML spec tight from the beginning. closing this security gap will close so many 3 letter agency gaps.

and of course they didn't suggest any alternative and left the door open. also any future similar suggestions will be quickly closed.

@doctoresam1
Copy link
Author

doctoresam1 commented Oct 6, 2021

nonce

Specifically, this exact idea (a random nonce value placed on the opening and matching closing tag of an element) was considered and rejected back during the srcdoc/sandbox design.

1-those are for iframe only.
2- there was no such suggestion, you know why? because they just can't reasonably justify rejecting it.

@bathos
Copy link

bathos commented Oct 7, 2021

If pursuing this in WICG, it may help to avoid framing the premise as a "safe" area given many folks will have different expectations about the kinds of guarantees suggested by this word. In itself (if I'm understanding right) it doesn't appear to provide a persistent "safe area" but rather would act like a (one-time) parsing directive? Too bad <noscript> is already taken :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants