On Oct 18, 2012, at 8:48 PM, John MacFarlane <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Markdown-Discuss mailing list [email protected] http://six.pairlist.net/mailman/listinfo/markdown-discuss
