[Security Solution][Case] Markdown links are not properly shown on external services

[cnasikas]

When pushing a case with a markdown link to its content or in a comment they are not being shown properly on external services. In addition, Jira does not fully support Markdown.

Jira:

IBM Resilient:

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[YulNaumenko]

@cnasikas could it be related to the issue #87344? (cc @pmuellr )

[pmuellr]

It's possible that it's related to #87344, which was caused by PR #83919.

However, guessing it's not. Some background ...

The way PR #83919 should be working, is that we now do per connector action param escaping of the context variables - but almost all the action params escaping is a no-op - nothing is escaped at all. Previously, all context variables were escaped as HTML.

With the PR, we change a few action params to escape the context variables differently:

• message in email escapes context variables for Markdown
• message in Slack escapes context variables for Slack markdown
• body in webhook escapes context variables for JSON

So nothing should be escaped now, for Jira, or any connector besides the three mentioned above.

[cnasikas]

Hey @YulNaumenko and @pmuellr! Thank you for your answers. I am not talking about context variables inside the content. I am talking about the whole content itself. For example, when you _execute the action of IBM Resilient with description set as Check this [link](https://elastic.co). For cases, that support markdown that's how content could look like.

[pmuellr]

Currently the case-ish connectors themselves do no escaping for any context variables for any of the connector params.

If there are some special parameters that should be treated as markdown (or similar), we can extend the escaping logic for the connectors to handle them.

So for now, you could put all of [link](https://elastic.co) in a context variable, say link, and then the template could reference that variable via {{link}}.

But it's probably safer to keep the "markup" in the template, and fill in the link slots via variables; eg, the template would be

Check this [{{context.linkText}}]({{context.linkURL}})  

That way, in the future, if we want to do special escaping for this parameter, we won't have to worry about the "markup" itsef being escaped like in #87344.

The reason you may want to change this in the future to escape the context variables for this field, would be if the linkText or linkURL might have "markup" characters in it, itself. Eg, if linkText happened to be link](http://evil.org) , mustache would render the markdown as [link](http://evil.org) <contents of linkURL here>, which isn't going to do what you want. If we added escaping for this connector parameter, it would be more like

[link\[\(http://evil.org\)](contents of linkURL here)

which would render as HTML

<a href="contents of linkURL here">link](http://evil.org) </a>

[elasticmachine]

Pinging @elastic/security-threat-hunting-cases (Team:Threat Hunting:Cases)

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[biscout42]

FYI: Same happens for slack integration.

Following action markdown:

[View alert details]({{context.alertDetailsUrl}})

Looks great in email, but in slack message the result is (actual url is obfuscated):

[View alert details](https://kibana.host/alert-guid)

[pmuellr]

Slack doesn't support full Markdown - they call theirs MrkDwn - doc here: https://api.slack.com/reference/surfaces/formatting

That page also references BlockKit, which provides more formatting but also requires you to use JSON. It's supported in recently stack releases, in the Slack API connector, but not with the Slack webhook connector yet.

[biscout42]

Thanks, @pmuellr , I could confirm that following syntax works for slack integration:

<{{context.alertDetailsUrl}}|View alert details>