Multidingus

[John MacFarlane]

+++ Alan Hogan [Oct 18 12 14:34 ]:

>    On Oct 18, 2012, at 1:47 PM, Fletcher Penney

>    <[1]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)


I could store a secret token along with the URL of each dingus server.
(It would be best to use a different token for each server.)  The
multidingus would send this along with the request, and the servers
could check for it.

I'm not sure how much additional security that really gives you,
though.


>    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.


Right.  The multidingus gets the data back as JSON.  Right now I just
use the jquery text() function to insert it into the "pre"; this
automatically escapes everything.  Other fields (name, author,
description, etc.) will also be treated as text and escaped.


>    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.


I don't see any problems with using GET.  And it's certainly useful to be
able to pass data to the script in the url; this way you can link to
results in discussions, etc.

Writers of individual dingus servers would still need to take steps to
avoid malicious attacks.  In general, this shouldn't be too hard.
Basically you'll be taking some text out of a json object,
running it through your markdown converter, and sending back the
result (together with some information about your implementation).

I don't plan to display formatted HTML at all, so that cuts down one
source of potential problems.


>    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."


I'm already doing everything I can think of in the multidingus.