Make "placeholder" of ODBC configurable in UI

[jarnedemunter1]

Parametrize the "placeholder" variable in the ODBC hook, making it configurable from the connection defined in the UI.
For some databases, the placeholder is not the standard "%s" as defined earlier.
By making it configurable in the connection properties, users can easily pick the placeholder of their specific database.
This makes the generic_transfer operator more flexible.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: [email protected]
  Slack: https://s.apache.org/airflow-slack

[hussein-awala]

A small nit, otherwise LGTM

[hussein-awala]

This could be moved to __init__ since it's no longer a class attribute.

[potiuk]

We should only allow fixed set of placeholders - not a "Free placeholder" = only alow "%s" or "?" - nothing else.

The problem with such an input provided by the user who can configure a connection from the UI, that by allowing "ANY" values, it opens up the doors to all kind of vulnerabilities - similar to SQL INJECTION.

So we should always sanitize any input passed down from the user when such conection is defined via UI.

While we cannot prevent existing cases and some kinds of "inherent" vulnerabilities in some connection types, adding a gateway to such "user input" (even if we do not know if it can be exploited) is dangerous.

In this case I think "?" and "%s" are the only "reasonable" values placeholder can take and we should validate if user value is exactly one of those..

Maybe there are others that we might find and add, but adding a possibility of using ANY placeholder provided by the user here is too dangerous IMHO.

[hussein-awala]

We should only allow fixed set of placeholders - not a "Free placeholder" = only alow "%s" or "?" - nothing else.

The problem with such an input provided by the user who can configure a connection from the UI, that by allowing "ANY" values, it opens up the doors to all kind of vulnerabilities - similar to SQL INJECTION.

So we should always sanitize any input passed down from the user when such conection is defined via UI.

While we cannot prevent existing cases and some kinds of "inherent" vulnerabilities in some connection types, adding a gateway to such "user input" (even if we do not know if it can be exploited) is dangerous.

In this case I think "?" and "%s" are the only "reasonable" values placeholder can take and we should validate if user value is exactly one of those..

Maybe there are others that we might find and add, but adding a possibility of using ANY placeholder provided by the user here is too dangerous IMHO.

Makes sense! We can achieve this easily by adding a list of whitelisted placeholders in each provider, and checking if the provided placeholder exists in this list.

[potiuk]

Makes sense! We can achieve this easily by adding a list of whitelisted placeholders in each provider, and checking if the provided placeholder exists in this list.

Yes. Easy to implement and safer.

[jarnedemunter1]

We implemented the change by adding the fixed set of default values to the ODBC provider. The other providers already used a "standard" placeholder. This first example can be used for other providers should it be necessary in the future

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.