<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 18, 2012, at 1:47 PM, Fletcher Penney &lt;<a href="mailto:fletcher@fletcherpenney.net">fletcher@fletcherpenney.net</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Not to mention everyone will want to make sure to do some input "sanitization" on the text input to try to filter mischievous input.<br></blockquote><br></div><div>1) Consider <i>*only*</i> 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 &amp; the individual dingus hosts. (Checking HTTP REFERER wouldn’t allow the maintainer to test locally, and is easy to fake, anyway)</div><div><br></div><div>2) If we are only showing raw HTML, then <i>no one </i>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.</div><div><br></div><div>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 <i>if</i>&nbsp;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.</div><div><br></div><div>4) In general, shouldn’t it be the multi-dingus’ job to protect against malicious code, instead of individual implementors? This&nbsp;would reduce the "attack surface."</div><br><div>Alan</div></body></html>