create issue API fails by dropping connection for **some** payloads

Question

(added some edits for clarity and some more info)

Hi, have an (non-JIRA) automation in place which "dispatches" JIRAs, from some "intermediary" project to "final" projects, where developers are supposed to work on them. The workflow, high level, is "find untouched JIRAs in interim project, for each one create a payload for API creation keeping description and so on the same, while changing project (and labels, parent issue, custom fields), call JIRA issue creation API with the payload, mark initial issue as touched".

The JIRAs pertain to websites vulnerabilities (XSS and so on), and do contain URLs with scary looking strings (js code, "alert()", unicode chars and so on). Some issues are being created correctly, some fail, hard to pinpoint the exact issue.

A list of odd and confounding behaviors:

* dug into one of the failing issues, found out that if a URL inside the description ends with a parenthesis (truncate URL after parenthesis) it fails (consistently), if I take that parenthesis out (truncate URL before it), works (consistently)* FAILS - ...long URL...%3C%2Fscript%3E%3Cscript%3Ealert(
* SUCCEEDS -  ...long URL...%3C%2Fscript%3E%3Cscript%3Ealert

* after more tests, look like URLs with "alert(...)" and "import(...)" in them fail consistently. If I add a "t" to alert or import (e.g. alertt(...) or importt(...)), they work :(  
* when JIRA creation fails, doesn't fail with 400, but get a "The response ended prematurely" in HTTP client call. This kind of suggests that there's another system before hitting the actual API, and this one inspects traffic, if traffic doesn't look good, drops the connection. Maybe some "smart" API gateway with WAF protection (with AI?)
* related, not sure how the initial JIRA in the "intermediary" project gets successfully created, there's some integration from some third-party product I can't look into
* tried both v2 and v3 "create issue" API (/rest/api/3/issue and /rest/api/2/issue), both fail the same way
* finally, running the automation from my machine works fine (without the hack above), but running it from Azure makes it fail consistently (it seems)

Any idea what might happen and how I can successfully create JIRAs which contain URLs with "questionable" content?

Thanks!

Trudy P Claspill · Answer

Thank you for the additional information.

My reference to the Create Work Item action was applicable only if you were using the native Automation for Jira feature within Jira itself. Since this is code executing outside of Jira, that is not applicable.

I don't have a comparable environment where I can test out your scenario, so unfortunately I can't offer any additional advice.

sebastian.popa · Answer

Hi @Trudy P Claspill, in short:

* the automation is not a JIRA automation, but a workflow running outside JIRA. Picks JIRA issues, massages them, creates "clones" in different project. So not sure about "create work" item action
* I cannot provide an example of payload, as it pertains to some vulnerability
* RELATED to above though, same payload works if I run the automation on my machine vs. from Azure (so yes to your question 3). If the payload was incorrectly formatted, I would get a 400 status code. I don't, connection is being dropped with no response at all

All in all, looks like payloads with "alert(..." and "import(..." in them, coming from Azure, are being dropped at a connection level (no http 400 response or such). Looks like behavior of some "smart" WAF, but I could be wrong (a WAF would work at layer 7, this connection drop looks like a layer 4), would like a confirmation of the above if that's the case, or any other possible explanation.

Thanks.

Trudy P Claspill · Answer

Hello @sebastian_popa

Welcome to the Atlassian community.

I have a couple of questions.

1. Is there a reason you are using an API call (is that in a Send Web Request action in your rule?) to create the issue rather than using the Create Work Item action?

2. Can you provide an example of your payload?

3. Are you adhering to this?

Note that the description, environment, and any textarea type custom fields (multi-line text fields) take Atlassian Document Format content.