Create and show in the API are not storing data the same way

[IAmAStealer]

Describe the bug

Via the api if you create a target with a character that can be url encoded. It won't be encoded within the POST request and so within the database.

def target_create():
    """Add a target in the database"""
    # Only POST data are handled
    if request.method != "POST":
        return utils.response("ERROR: POST method is required ", 405)

    # Simplification for the reading
    name = request.form["name"].replace(" ", "")

Via the API if you want to show that element the filter used for research is quoted :

    name = urllib.parse.quote(name)
    query = db.session.query(target.Target.name)\
        .filter_by(name=name).first()

Leading to a bug that any target with a url encoded character unfindable.

And it is the same for user/target and so on.

I understand that it is for security reason, but it should be urlencoded in POST and Decoded only when displaying for the user.

Tested on my side just the urllib.parse.quote to be sure it is this line posing the problem.
I have two version installed and only the old one before this change doesn't have problem.

For security reason everything should be quoted before stored in the database and unquoted for user display.

To Reproduce

Create a target with "@" in the name for example
try to show the same target.
it will display an error saying it is not found because @ will be transformed in %40 before being filter_by in SQLAlchemy.

Expected behavior

Expected to change every storage with urllib.parse.quote() before any databse action and every display to users with urllib.parse.unquote(). Those leading in a heavy change that may have side effects.

[IAmAStealer]

At first sight, Database injection is not possible, protected by the python code around it via SQLAlchemy.
So except if you had a particular reason to add :

name = urllib.parse.quote(name)

When searching for target or other element, this line doesn't look very useful, except generating errors.
Please tell me what you think.

[elg]

Hey,

I'm not sure that removing the parse will not cause security issues. I have to check more deeply.

Maybe writing more encode/decode would do the trick... Need to check.