Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

URGENT - Jira Cloud API now blocks GET with Body #143

Closed
bmcalary-atlassian opened this issue Jan 24, 2025 · 12 comments · Fixed by #144 · May be fixed by #145
Closed

URGENT - Jira Cloud API now blocks GET with Body #143

bmcalary-atlassian opened this issue Jan 24, 2025 · 12 comments · Fixed by #144 · May be fixed by #145
Assignees
@raviks789
Milestone
1.3.5

Comments

@bmcalary-atlassian
Copy link

Hello Team,
Ben from Atlassian Networking.

We are rolling out AWS Cloudfront and WAF to address ongoing DDOS attacks. Rollout will be completed within 1 month.

We have detected that IcingaWeb2-Jira/v1.0 is sending 148-246 bytes/characters of (usually) json encoded body with GET requests.

We found a bit of code here

icingaweb2-module-jira/library/Jira/RestApi.php

Lines 499 to 502 in 42e6fa4

public function get($url, $body = null)
{
return $this->request('get', $url, $body);
}

We are not exactly sure where or how in your codebase the body is being passed into this GET function, but it is. Both Cloudfront and our Envoy Proxy layer report GET's having body bytes.

We have already begun our rollout, and we already see some requests from IcingaWeb2-Jira/v1.0 being dropped by AWS.

Could you please ensure GET never sets a body.

Kind Regards,
Ben
@nilmerg
Copy link
Member

nilmerg commented Jan 27, 2025

@raviks789 I couldn't find any usage of RestApi::get with the second parameter set in the latest release. Please have an additional look, maybe there's a call that isn't detected by the IDE.

@bmcalary-atlassian
Copy link
Author

We cannot see in the code where the body is getting inserted either.
But maybe this line can be made conditional on http method

icingaweb2-module-jira/library/Jira/RestApi.php

Line 442 in 42e6fa4

CURLOPT_POSTFIELDS => $body,

Let us know if you need any more information.
If it helps, we see the body for:

/rest/api/2/field
/rest/api/2/issue/*******

@raviks789
Copy link
Contributor

@nilmerg I couldn't find any usage of RestApi::get with the second parameter as well. I think this parameter can be removed for RestApi::get method.

@bmcalary-atlassian, you might be right, setting CURLOPT_POSTFIELDS for GET Http requests might be causing the requests to be rejected and must be made conditional.

@raviks789 raviks789 mentioned this issue Jan 28, 2025
Merged
@nilmerg nilmerg added this to the 1.3.5 milestone Jan 30, 2025
@scratttt
Copy link

Hi @nilmerg @raviks789,
is it solved? I have downloaded the RestApi.php file but I still get the 403 error.
ERROR: RuntimeException in /etc/icinga/web/modules/jira/library/Jira/RestApi.php:484 with message: REST API Request failed, got 403: Forbidden

Thanks,
Regards.

@nilmerg
Copy link
Member

nilmerg commented Feb 19, 2025

Unless, and if I'm not mistaken, the library we use doesn't do anything unusual, the patch ensures that no body is passed to http requests with method GET. So yes, the module shouldn't perform such requests anymore with the patch applied. Not sure though, if your 403 response is even caused by this. Are you sure?

@scratttt
Copy link

If I use the new RestApi.php file I got the following error with the "--host" var:
{"errorMessages":["The value 'vm-jump' does not exist for the field 'project'."],"warningMessages":[]}

And the request:

<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Bad request.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: RufQwOPZTsBCzDaLTNCOCZ2Gg2Ybzg0tsk0dCwnhqv2NtcHZnLyLcg==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

ERROR: RuntimeException in /apps/icinga/web/modules/jira/library/Jira/RestApi.php:488 with message: REST API Request failed, got 403: Forbidden

I have to set the value of "--project" to "--host", It no longer gives me errors but the request is the same:

"issues":[]}

Let me ask to Atlassian (https://community.atlassian.com/t5/Atlassian-Platform-articles/Jira-Confluence-Cloud-APIs-return-403-Error-The-request-could/ba-p/2928153), although the problem of the "--host" var is different than the 403 error·

@bmcalary-atlassian
Copy link
Author

@scratttt Ben from Atlassian. I reviewed our Cloudfront logs and can confirm this GET request came with a BODY payload.
If it helps, the following paths we can see are coming in with a body payload are:

/rest/api/2/field

/rest/api/2/issue/XXXX-1234 (where XXXX-1234 is a placeholder)

@raviks789
Copy link
Contributor

@bmcalary-atlassian could you share those logs? It would help us understand the issue better, as we are not setting the body for GET method anywhere in the code.

Also, according to Jira Rest API docs (https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-post), Forbidden: 403 error is thrown, if the user does not have sufficient permissions to create the issue.

@scratttt, you could also check if you have sufficient project permissions.

@scratttt
Copy link

Yes, I have. If I run the same command from another server in other country... the issue is open.

@bmcalary-atlassian
Copy link
Author

bmcalary-atlassian commented Feb 20, 2025 •
edited
Loading

Hello Team, old-network.csv shows logs from our Envoy proxy based solution - which is still active in a few countries. "bytes_in" is BYTES_RECEIVED from https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#config-access-log-format-dictionaries which is "Body bytes received.".

GET requests bytes_in is normally zero for the extreme majority of API calls. IcingaWeb2-Jira/v1.0 is one of the few exceptions where we see a positive value.

cloudfront.csv shows logs from our new AWS Cloudfront CDN. We spoke with AWS and "InvalidRequest" means the GET request had a body.

I cannot share any more details from our logs.

Can I suggest you perform a TLS interception with Charles, MITM Proxy, or https://github.com/monasticacademy/httptap ?
I believe it will show the existence of a body payload in GET requests, then you can work backwards from that.

cloudfront.csv
old-network.csv

@raviks789 raviks789 mentioned this issue Feb 25, 2025
Open
@raviks789
Copy link
Contributor

@bmcalary-atlassian thank you for the logs and your input. It was helpful in debugging this issue.

@scratttt pull request #145 should fix this issue.

@scratttt
Copy link

scratttt commented Feb 25, 2025 •
edited
Loading

Cool! It's working. Thanks @raviks789.

@bmcalary-atlassian you can redirect to this fix if you receive issues between Icinga2 - Jira Cloud. Thanks for the help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@raviks789 raviks789

Labels
None yet
Projects
None yet
Milestone
1.3.5
4 participants
@nilmerg @raviks789 @scratttt @bmcalary-atlassian