Re: New html security tag

Hi Carlos,

I remember this issue coming up some time ago, and I too agree that
something like this would be superb. Webmail, bulletin boards, etc. are
particular situations that come to mind.

You've already noted that you'd like to discuss the validity of your
example at another time, but in a way I think it's important to introduce
that discussion as soon as possible. I recall that the same suggestion did
come up last time (a unique identifier, listed in the start and close
tags) leading to the same problem - attributes aren't allowed in closing
tags.

One solution I did consider was to use the Object tag - I'm not
particuarly up to speed on the latest X/HTML developments but I remember
that in 4.0 somewhen you could use external sources (if it isn't object,
apologies, but I distinctly remember some ability to do so). It seems
inherently more feasible, practical and secure to work this way - to embed
an external document and apply settings to that - the main difference
being that CGI scripts would need to be amended to supply a second file.

- Sven Latham

On Fri, 16 Aug 2002, Carlos Paz wrote:

>
> Hello,
>
> I'm posting this message here by suggestion of a mozilla team member...
>
> 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 today 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 common 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).
>
> This seems like a web server application problem, but clients are involved
> on this issue, since the set of dangerous tags depends/is defined/is
> extended/ by the client's browsers.
>
> Since browsers perform the document parsing and the lexical/semantic
> analysis of the page, and they know which html tags are dangerous on their
> case; adding some extra logic to deal with the problem above shouldn't be
> too difficult, and seems the "natural" place to implement security
> restrictions.
>
> 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 and other not known/implemented dangerous tags)
> 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), or "only allow this
> tags: <b>,<br> and <em>".
>
> 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 and 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 type of violation attempted could
> be provided.
>
> This is just a first attempt to define this feature, I believe this tag is
> far from completion, but it would greatly simplify web development.
>
> Further development, suggestions and corrections are greatly appreciated.
>
>

Received on Friday, 16 August 2002 10:21:08 UTC