Params in Custom Query

When I try to use Parameters into custom query it does not work.
This not working:
Even changing with “?” not working:
After debug i get:

  1. message: “SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘? (\n\tid INT(10) UNSIGNED,\n \tcliente_id INT(10) UNSIGNED,\n \ttaller_nombre VA…’ at line 1”
    I think is that this param :P1 or “?” that is not passing into query.
    The expression that suppose to be replace with param is {{$_POST.nombre_taller_post}}, this came from a form with a input name “nombre_taller_post”, but the error comes when submit.

To use a parameter, add the :P1 to the query ( not ?)

However, you can’t bind table names and column names with these prepared statements so I don’t think you can do what you intend. Maybe @patrick can confirm?

Parameters are only meant for values not for table or field names. You can’t create dynamic tables or fields.

Is a limitation in the sql drivers and also done for a reason - security.

1 Like

If my server actions are not connected directly with front end through server connections, is it still a security risk to use custom queries to generate dynamic tables and fields at the backend?

I am asking because I found a way to bypass the limitation and use parameters for table names. And I want to know in which areas does security get weakened.

SQL injection through $_GET or $_POST if accepting a string that could be used to refer to a table name. Or referring to some other table name than the one you intend

Thank you, Apple for the clarification.

For what I had in mind for the case application is only about creating tables for the first time with syntax ‘create if does not exist’, no dropping tables and columns, no deleting or updating rows. Moreover, I could security restrict and log sensitive transactions, so I think comprehensively there is nothing to achieve by injecting over normal UI. But I would do that as a last resort. Right now, rethinking database architecture.