-1

I'm intending to code a solution where table and command are fixed but parameters can vary i.e. are entered by internet users. How risky is this?

So far only PHP code was used.

predefined: SELECT
user defined:    select_expr [, select_expr ...]
predefined:    [FROM table_references
WHERE + user defined:    [where_condition]
GROUP BY  + user defined:    {col_name | expr | position}
  [ASC | DESC], ... [WITH ROLLUP]]
[HAVING + user defined where_condition]
[ORDER BY + user defined {col_name | expr | position}
  [ASC | DESC], ...]
[LIMIT + user defined {[offset,] row_count | row_count OFFSET offset}]

The proposal should work if the PHP code only uses mySQL commands where the right side is defined. WHERE is combined with the user input 'Temp > 10' as example

1 Answers1

3

How risky is this?

Very risky. There are a number of ways I can think of, off the top of my head, that this could go wrong:

  1. Information exposure. There are a lot of ways that users could potentially inject clauses into this query which perform queries against tables that you didn't intend. One possibility would be to inject a subquery into the select_expr clause. Another would be to add a JOIN at the beginning of the where_condition.

  2. Denial of service. The most obvious method would be injecting a time-consuming function like BENCHMARK() into any clause. If it's possible to inject JOINs through the where_condition, a series of expensive cross-joins could be used.

Don't allow users to write SQL.

  • for further readers Information exposure should be read/researched as SQL injection, the Information exposure is the cause of SQL injection – Raymond Nijland Aug 09 '19 at 16:39
  • Would ist be sufficient to remove all critical SQL commands from the user input? Remaining could be CONCAT, COUNT,... –  Aug 11 '19 at 07:25