|distributed.net Faq-O-Matic : Statistics, Graphs, and other Statsbox things : Why is arbitrary HTML no longer allowed in team or participant mottos?|
|In January 2002, we had to instate a new policy that prohibited the use of arbitrary HTML in the customized team and participant "motto" sections of our website. http://cgi.distributed.net/cgi/planarc.cgi?user=bovine&plan=2002-01-22.20:52
Attempting to filtering general HTML is what a number of web-mail providers (like Hotmail, YahooMail, and others) attempt to do today, but if you've kept up on monitoring security vulnerabilities mailing lists (such as BugTraq or Vuln-Dev), you're probably aware of incident after incident of new tags being discovered that needed to also be filtered. These new discoveries have continued to occur every few months for the last several years, ever since the popularity of web-based mail took off. E-Bay also attempts to allow auctioneers to utilize HTML for their product descriptions, but they also need to filter malicious techniques that can be used to automatically submit bids and such. There are many other instances of websites that need to employ similar tactics.
Two well-written security advisories on this type of exploit are available from CERT:
Within the last month alone, there have been numerous cross-site scripting issues exposed throughout the web on extremely popular websites. Here are just a few of the articles on BugTraq within the last month that succinctly summarize the variety of the problems:
In summary, it is an ongoing job to maintain filters that attempt to explicitly exclude "known unsafe" activities, and we do not have the resources or desire to maintain such filtering technologies. It's far easier to do the opposite and create a filter that only allows "known safe" activities. Although it would be possible to try to construct a filter that allows good-HTML to be entered (but be very aggressive and only allow "known safe" forms), it's a little easier to create your own variant that does not have any of the operational expectations that HTML has. Attempting to filter HTML also has the problem of inadvertantly breaking "safe" HTML that simply does not conform to the strict filtering rules that would need to be used (after all, there are innumerable ways of expressing the same effect).
By creating our own markup language that is extremely limited and extremely strict in its allowances, there is far less ambiguity over why something isn't working or what is allowed. In actuality, the markup language that was chosen to be implemented is intentionally similar to the markup language used by UBB/phpBB/vBulletin and a number of other bulletin-board packages available today, so as to reduce the "non-standardness" of our technique. The available tags are shown on the team and participant configuration pages.
© Copyright distributed.net 1997-2013 - All rights reserved