nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JQL input sanitization

Theo Gravity

I'm looking into creating a set of REST endpoints that call the Jira cloud API using JQL, specifically this API:

https://developer.atlassian.com/cloud/jira/platform/rest/v3/#api-api-3-search-post

I'm using JQL to search issues because I have custom fields that I need to query against and do not intend on using the issue id(s) at all as part of the search.

// javascipt
const jql = `project = PROJ AND "Some field" ~ ":input_from_user"`

// :input_from_user needs to be sanitized so things like
// "some value AND" cannot be used for the value

Usually with this kind of access, when you allow custom parameters to be sent by the end-user, you have to be careful with SQL-like injection.

Is there anything I can use to build JQL queries in a secure fashion in this scenario? In most database libraries, you can create prepared statements w/ parameter binding.

Is there a good list of operators / keywords / escape items that can be referenced against to possibly build my own sanitization function?

Or is it recommended that JQL-based APIs only be used for internal purposes only?

I'd rather not resort to having to connect to the database that Jira connects to and write SQL directly against it (but at least the SQL drivers / libraries have the capability of preventing injection attacks), so was curious.

Accepted answers

All comments

Tom Lister_fo1j4e

Hi @Theo Gravity

a you can safely search using JQL over REST as you will still have to provide credentials and pass Jira persmission checks.

See the docs here

https://developer.atlassian.com/server/jira/platform/jira-rest-api-examples/

For examples of searching for issues.

Nic Brough -Adaptavist-

JQL is not SQL, and you can't inject anything dangerous into it. JQL does nothing but search and return a list of issues. It doesn't do anything else, it really is just a list of matching issues.

The worst attack someone can make is an attempt at a denial of service - a JQL string that would return a lot of issues, and even that won't do a lot because the service is throttled so it can continue to serve real users.

On top of all of that, to use JQL, you have to be authenticated (unless you have allowed "anonymous" access).

Theo Gravity

I don't think both answers understood my question.

Here's a hypothetical setup:

Public API:

/getIssuesByStatus/:status

Untrusted user - [sends :status] -> Public API - [Calls Jira Cloud Issue Search API using :status under JIRA user with project read/write permissions for issues] -> JIRA API

My query looks like this:

project = PROJ AND status = ":status"

Ideally, the user should only be sending values that fall under the status.

Because I lack the ability to sanitize the :status param, the user could do something like

/getIssuesByStatus/closed%22%20AND%20id%20%3D%20%22123 // closed" AND id = "123

This gets translated in the Public API to:

project = PROJ AND status = "closed" AND id = "123"

Which should not be sent to the JIRA endpoint because only status values should be sent.

I really want to know if there is a recommended escaping / sanitization solution specific for dealing with JQL queries here to prevent the above issue.

Nic Brough -Adaptavist-

I think we've understood you fine.

What we're telling you is that there is no problem with this. If the user sends a nonsense query, or even one that makes sense but returns nothing because they're not authorised to see them, so what? Who cares that they get nothing back?

If you want to do this level of "sanitisation", then you need to (re)write your external application in a way that hides all of this from the user, and does all the work of finding out what might be valid and limits them to those values.

It's a lot of work compared with telling the user "send valid data if you want a useful response"

Theo Gravity

What if they get something back and that something isn't meant for them? That is possible if they are able to guess the right query.

Limiting the values is a good idea, however. Although in some of the cases, they're not straight enumerations, something like a string pattern can be used to ensure the input only matches it.

Thanks.

Nic Brough -Adaptavist-

>What if they get something back and that something isn't meant for them? That is possible if they are able to guess the right query.

It is only possible if you have given them the permission to see the "thing that isn't meant for them" in Jira. External calls respect the permissions in Jira.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-server

jql

security