we have using 5.2.8 version of jira. we have a problem, if we want to create a issue that description field has below content, we can not create. becouse our security tool blocked the creating request hat is sql injection or http attack problem for the security tool. if we want to add comment to same content in any issue, we have not any problem.
when other applications in our company have same problem, the applicaiton`s owner can solve seting parameter(s) or developing.
can we solve the problem ?
having content of the problem;
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_320.DTD">
<slir ver="3.2.0" res_type="SYNC">
<msid type="MSISDN" enc="ASC">xxxxxxx</msid>
WAF's are notoriously complex technology and do misfire sometimes. They require constant tuning and updating. Please post more details when you get them, until then this does not look like a JIRA issue.
P.S. Perhaps it is not wise to post your customer's phone number (MSISDN) on a public forum. Your XML snippet also includes a password, unless it is the redacted version.
That is still your security software interfering with the requests.
If Jira is working internally, then that is firm proof that the security software needs configuring to allow external access properly. It's nothing to do with Jira and Jira can't be expected to do anything to fix this - it's the WAF that needs configuring/fixing.
I'm sorry, I don't understand that. I understand that you're telling us that the WAF is set at low level security. I do not understand the "post open source content on the request" part.
However, I really do not think Jira, or even what you are posting is a problem.
The situation appears to be that your WAF is blocking access to parts of Jira. Jira works fine when not accessed through the WAF. Therefore, the WAF is a problem and needs to be fixed.
it is mean that; if our another web applications post request with specifice characters(like main content),
the requests can pass on WAF. becouse the applicaiton request content masked and the waf don not hold as sql injectin or http script attack.
WAF admins say that our some jira request content critical character for security(sql injection or http script attack). why does jira have this problem ?
Sorry to interrupt, but those guys before me just answered you that the problem is in your WAF, not JIRA. If your WAF is stupid and overreacts (think about a boss that doesn't let you explain the problem, but cries out immediately) it is the WAF problem, period.
"why does jira have this problem?" Well it doesn't
"applicaiton request content masked" - well, that may be custom stuff, how the h**l should we know ?
I have to agree with Radu here - it is irrelevant what your WAF administrators are telling you.
They need to EXPLAIN what content is "wrong" and why.
Then you need to explain to them why you are posting it and why it is safe.
Then you need to get them to change the settings on the WAF to accept it as valid.
I cannot emphasise this any more: the problem is entirely with your WAF.
Ok, there is a chance that your WAF is picking up some bug in Jira that Atlassian and all the other users have missed (or haven't notified us about yet). But you need your WAF to explain what they think the problem is.
a few days ago WAF admins said that, only jira some request`s content (like sql injection or http script attack) were blocked by WAF, deafult setting is same all web applications, setting down, low security but it is going on blocking.
i will ask, and get some logs, learn all details on first working days, sharing wtih you turn back
i have finished working with WAF admin.
working results; WAF is blocking the content or requesting that is like cross-site script attack, you can see below WAF logs
Ok, then your WAF has a rule that is wrong.
In both cases, it's saying "cross-site script check" failed. You'll need to get the WAF administrators to explain that rule and then get them to fix it so that it does not get triggered by Jira. The reason I say that is that there are no cross-site attack vectors in either of those posts, so the "default webapp policy" in your WAF is throwing false positives. At a guess, I'd say it's spotting the ampersand-gt, which is perfectly valid for entering data
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG