Multidingus

[Alan Hogan]

On Oct 18, 2012, at 1:47 PM, Fletcher Penney <fletcher at fletcherpenney.net> wrote:


> Not to mention everyone will want to make sure to do some input "sanitization" on the text input to try to filter mischievous input.


1) Consider *only* accepting requests from the multi-dingus. Perhaps it could be as simple as a shared secret: a GET param (called "token") with a value known only to the multi-dingus operator & the individual dingus hosts. (Checking HTTP REFERER wouldn’t allow the maintainer to test locally, and is easy to fake, anyway)

2) If we are only showing raw HTML, then no one needs to worry about scrubbing against XSS/JS/HTML weirdness; merely the multi-dingus host must make sure to properly escape HTML when displaying the result.

3) If we show not just raw HTML but HTML previews as well, then yes, an XSS scrubber should be used. However, it isn’t probably huge deal if the multi-dingus (a) only accepts POST, not GET, requests for conversion, and (b) protects against CSRF attacks (many frameworks have built-in CSRF protection). Given those assumptions, essentially the only people who could suffer from bad output are the same people who gave us bad input.

4) In general, shouldn’t it be the multi-dingus’ job to protect against malicious code, instead of individual implementors? This would reduce the "attack surface."

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20121018/f678ad49/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4887 bytes
Desc: not available
Url : <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20121018/f678ad49/attachment-0001.bin>