InformAction Forums

Hi there!

Right now, LiveJournal has an exception from XSS warnings/blocks:

499 if (/\.livejournal\.com$/.test(originSite) &&
500 /^https?:\/\/www\.livejournal\.com\/talkpost_do\.bml$/.test(originalSpec) &&
501 ns.getPref("filterXExceptions.livejournal")) {
502 if (ns.consoleDump) this.dump(channel, "Livejournal comments exception");
503 return;
504 }

Dreamwidth Studios (www.dreamwidth.org) is a code fork of LJ, starting with the same base and taking it in a different direction (removing ads, improving features, etc). The code is at http://hg.dwscoalition.org/ for you to verify that we haven't done anything evil to the LJ code. We have the same setup as LJ, though, where a form from a subdomain (username.dreamwidth.org) gets submitted to the www subdomain as part of commenting. Is there any way we could also have an exception added in?

(One note: we've made the .bml suffix on links optional, so both www.dreamwidth.org/talkpost_do.bml and www.dreamwidth.org/talkpost_do function equally. The version without the .bml is standard, but we still support both.)

Thanks!

I was actually trying to further generalize the Livejournal exception, like this: which means that any POST to "/talkpost_do" or "/talkpost_do.bml" done across domains sharing the same 2nd level domain (e.g. "randomsite.livejournal.com" and "www.livejournal.com") will bypass injection checks limited to the body parameter, which we know Livejournal's code sanitizes on its own.

It should be noted that such a setup is quite difficult to exploit, since an attacker should

1. Have both the origin and the target whitelisted
2. Manage to automate (or trick the user to initiate) a POST request from the origin (i.e. the origin, which shares the same 2nd level domain with the target, should be in its full content control)
3. Have a working "/talkpost_do" endpoint on the target, which must be also vulnerable to injection in the "body" parameter

Oooh, that looks like an even better solution, since there are many other sites out there running the LJ code.

Thanks for your development work on this!

Shouldn't there rather be efforts for moving away from hard-coded solutions?

dhouwn wrote:Shouldn't there rather be efforts for moving away from hard-coded solutions?

Those efforts are being made when possible.
What would you suggest in this case, exactly?
Notice that we're talking about a cross-site request whose "body" parameter may contain any arbitrary HTML markup by design.

I am not against this exception per se, I just don't the idea of having it in the code.

dhouwn wrote:I am not against this exception per se, I just don't the idea of having it in the code.

Having it in the code helps to make it more specific than a simple "bypass to this URL or from this URL", and therefore prevent its exploitation.
If you don't want it to apply, you just need to turn the related noscript.filterXExceptions.* preference to false.

Giorgio Maone wrote:Having it in the code helps to make it more specific than a simple "bypass to this URL or from this URL", and therefore prevent its exploitation.

Like I said in the other thread (but perhaps too incomprehensible), it would be nice if the XSS exceptions setting was more flexible to allow more specific exceptions.