RE: New security tag

I thought this post was familiar as well... :)

> -----Original Message-----
> From: www-html-request@w3.org [mailto:www-html-request@w3.org]On Behalf
> Of Rowland Shaw
> Sent: Wednesday, September 11, 2002 3:18 AM
> To: 'Carlos Paz'; www-html@w3.org
> Subject: RE: New security tag
>
>
>
> Isn't this what you suggested on 16th August 2002?
>
> -----Original Message-----
> From: Carlos Paz [mailto:capaz@iote.net]
> Sent: 10 September 2002 19:58
> To: www-html@w3.org
> Subject: New security tag
>
>
> I'm posting this message here by suggestion of a mozilla development team
> member (I got kicked out when I posted this as a desired feature
> in mozilla
> ;-)...
>
> Sorry about the lengthy post, and please don't get picky on the xhtml
> validity of this proposal, that can be issued later.
>
> A problem that most web developers must face sometime is the security risk
> involved with the publication of user contributed data on their website
> that allows some html formatting tags, since there is a chance that a
> malicious user adds some java/javascript code that, when the page is
> displayed, steals session information or performs other actions on behalf
> of other users browsing the page.
>
> There isn't yet (AFAIK) a universal solution to this problem: not all web
> development languages provide a way to block some tags and let others on a
> page, and many web developers currently strip out the <javascript> tag on
> user's data but fail to check for less known but equally dangerous tags
> (like onClick, onMouseOver, etc).
>
> Even though this seems like a server side problem, I think that clients
> are involved on this issue too, since some code enabling tags are specific
> to some browsers (IE's activex, for example) and since they do all the
> document parsing and the lexical/semantic analysis of the page; adding
> some extra logic to deal with the problem above shouldn't be too
> difficult.
>
> I propose a new tag like this:
>  ------------------------------
> <html>
> ...
> web app's html
> ...
> <p>A user's comment:</p>
> <security block="action_tags" id="SECURITY_TAG_ID"
> report_to="/security.php">
>
> Here goes the user's data, comments, hmtl, etc.
> All harmless html code is rendered, but code enabling tags
> (java/script,activex, etc) stuff is ignored.
>
> </security id="SECURITY_TAG_ID">
> ...
> The rest of the app's html.
> ...
> </html>
>  ------------------------------
>
> The <security> tag explicitly tells the browser to block all code enabling
> tags on the enclosed block, this could be refined to something like
> "enable only a safe subset of the javascript engine" (enable alert windows
> and status bar handling, disable access to cookies, fetching other
> documents or altering the form's action attribute)
>
> The "SECURITY_TAG_ID" value on the id attribute is a random and hard to
> guess string generated by the web app stored safely in the browser parsing
> engine, used to "authenticate" the closing </security> tag. This would
> avoid that a malicious user could close prematurely the security enhanced
> block.
>
> The report_to attribute would be used by the browser to report a page
> (uri) when there is an attempt to use unauthorized code or an invalid
> </security> tag on the corresponding security block. Additional
> information like the session's data or kind of violation attempted could
> be provided.
>
> This is just a first attempt to define this feature, further development,
> suggestions and corrections are greatly appreciated.
>

Received on Wednesday, 11 September 2002 09:35:24 UTC