DDOC comments are not escaped and this results in a XSS vulnerability.
Proof of concept:
test.d:
/// <script>alert(2)</script>
void f() {
return;
}
$ dmd -D test.d
$ firefox test.html -> an alert box appears
The security issue is clear although it requires manipulating the user to compile and display malicious comments. But as compiling the documentation is something many do before thoroughly reading the code it's still a valid security issue.
Also, aside from that, it breaks valid documentation so there's a usability issue as well.
Comment #1 by dlang-bugzilla — 2017-05-10T21:10:03Z
Hmm... DDoc allows embedding HTML "by design", so this is not a bug.
It might be an issue for websites which display documentation of third-party packages though.
Perhaps it would make sense to forbid certain HTML tags in .d files (i.e. inline documentation comments and the "Macros" section), while still allowing them in macro definitions in .ddoc files.
Comment #2 by cpicard — 2017-05-10T21:20:22Z
I was not aware that it is so by design. However if it is a design decision I believe the security consequences should be made very explicit and clear in DDOC's documentation so that people avoid distributing third-party projects' documentation or do it very carefuly.
Limiting the use to some tags would help the usability issue but not the security one.
Comment #3 by dlang-bugzilla — 2017-05-10T21:36:30Z
(In reply to Cédric Picard from comment #2)
> I was not aware that it is so by design. However if it is a design decision
> I believe the security consequences should be made very explicit and clear
> in DDOC's documentation so that people avoid distributing third-party
> projects' documentation or do it very carefuly.
As I understand, this only matters from a security standpoint when DDoc output is placed on the same domain as some dynamic content being targeted.
> Limiting the use to some tags would help the usability issue but not the
> security one.
As I understand, there is no usability issue here because it's working as designed. Use $(LT) and $(GT) (or < and > if you don't care about any output formats other than HTML) for < and >.
Anyway, limiting the use of some tags probably wouldn't work because the document template is likely to have some macros involving script tags (or allowing constructing aribitrary HTML tags, such as dlang.org's $(TAG) macro). Fixing it from this angle would be much more complicated.
Comment #4 by cpicard — 2017-05-10T21:49:21Z
(In reply to Vladimir Panteleev from comment #3)
> As I understand, this only matters from a security standpoint when DDoc
> output is placed on the same domain as some dynamic content being targeted.
Not at all, while what you describe is the most common case there are many things that are possible through XSS that do not target the current domain. Also bugs in browsers are a common thing.
> > Limiting the use to some tags would help the usability issue but not the
> > security one.
>
> As I understand, there is no usability issue here because it's working as
> designed. Use $(LT) and $(GT) (or < and > if you don't care about any
> output formats other than HTML) for < and >.
Well, I first discovered the thing because I hit it. But sure, if it's as designed, no comment here.
> Anyway, limiting the use of some tags probably wouldn't work because the
> document template is likely to have some macros involving script tags (or
> allowing constructing aribitrary HTML tags, such as dlang.org's $(TAG)
> macro). Fixing it from this angle would be much more complicated.
Indeed, also there are much more subtle XSSs than <script>. Given how DDOC works I don't think it is fixable at all if not dropping all support for inlined html which I didn't realize was an issue at the time.
I suppose it's a won't fix, at least a bug report will be there for the next person to discover this.
Comment #5 by dlang-bugzilla — 2017-05-10T21:55:21Z
(In reply to Cédric Picard from comment #4)
> Not at all, while what you describe is the most common case there are many
> things that are possible through XSS that do not target the current domain.
Could you provide some examples which would be applicable to us?
> Given how DDOC
> works I don't think it is fixable at all if not dropping all support for
> inlined html which I didn't realize was an issue at the time.
>
> I suppose it's a won't fix, at least a bug report will be there for the next
> person to discover this.
Yep, I think documenting this is the immediate fix.
Comment #6 by dlang-bugzilla — 2017-05-10T22:13:47Z
(In reply to Vladimir Panteleev from comment #5)
> (In reply to Cédric Picard from comment #4)
> > Not at all, while what you describe is the most common case there are many
> > things that are possible through XSS that do not target the current domain.
>
> Could you provide some examples which would be applicable to us?
Well, I'm not sure this is the right place to talk about that, but it's an XSS, it can do anything JS in a webpage can, so making external calls to APIs, executing an IRC bot, delivering malware...
With some timing tricks it is also possible to scan the user's network for available ports on local and nearby computers.
With a browser bug such as https://www.brokenbrowser.com/sop-bypass-uxss-stealing-credentials-pretty-fast/ (taking one from today, those are pretty common) it's possible to bypass any security tying the code to the local domain. From there you can get data from other pages, read and send local files etc.
Anything a normal malicious webpage can do, this is in no way specific to D.
Comment #8 by github-bugzilla — 2017-05-13T08:02:18Z