Multidingus

[Alan Hogan]

On Oct 18, 2012, at 8:48 PM, John MacFarlane <jgm at berkeley.edu> wrote:


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


Right. To be clear: No real additional *security* per se, but it does lighten the implementation burden for each individual dingus server: They don’t half to worry about throttling requests, checking length, etc., if the master multi-dingus server assumes those responsibilities.

And I think we can all agree that making it as simple as possible for someone to add a dingus server for their own implementation is a Good Thing.


> Right now I just use the jquery text() function to insert it into the "pre"; this automatically escapes everything. 


100% sufficient and correct.


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


Absolutely, there are advantages to link-ability.

However, consider the case where all of these are true:

1) It’s possible, using merely GET, to control the input of the multi-dingus;
2) The multi-dingus displays an HTML preview, automatically or in a manner configurable via a GET param;
3) The HTML is _not_ sanitized or scrubbed

Then it is possible to send people a link that run arbitrary (attacker-controlled) javascript, on your server.

If there is no value to be gained by stealing a user session, and no way to automate the propagation of the link via JS on that page, then this still isn’t a huge deal. I may be being paranoid here; I spent a lot of time thinking about this sort of thing while building Blogic <http://themer.blogic.com/>.

Keep in mind that *not* scrubbing HTML makes for a slightly more complete service that can test more real-world edge cases. (Not everyone who uses Markdown accepts guest input or has a need or desire to run an XSS scrubber.)

I don’t want to decide as to which trade-offs to make, but I do want to make sure they are understood.


> I don't plan to display formatted HTML at all, so that cuts down one

> source of potential problems.


This crosses off item 2 in my list. However, it is probably self-evident that being able to see formatted / rendered HTML is a faster way to notice most inconsistencies than reading raw HTML. Is it bold in one parser and not in another? I can see that in a glance, much faster than checking which tags open and close where, especially when whitespace around tags is inconsistent between implementations.

My *own* gut says to make rendered HTML available in the multi-dingus, but only as a user-controlled option (e.g., a button that runs a script like `$('div').html($('pre').text())`, in jQuery terms). This also crosses off item 2 in my list, without sacrificing scannability of output, if so desired.


> 

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


Fantastic to hear.

Alan Hogan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20121018/bc9a321c/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/bc9a321c/attachment-0001.bin>