Alan Hogan contact at
Fri Oct 19 00:10:02 EDT 2012

On Oct 18, 2012, at 8:48 PM, John MacFarlane <jgm at> 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 <>.

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: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4887 bytes
Desc: not available
Url : <>

More information about the Markdown-Discuss mailing list