contact at alanhogan.com
Fri Oct 19 00:10:02 EDT 2012
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,
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4887 bytes
Desc: not available
Url : <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20121018/bc9a321c/attachment-0001.bin>
More information about the Markdown-Discuss