помогите узнать оригинальный запрос при sql injection

[ridlle]

нашел уязвимое место, но не могу понять какой оригинальный запрос на беке
выводит 10 записей (вижу не свои)

?search=-")+or+1=1+limit+10--+-

хочу узнать количество колонок. при order by 1 ошибки нет, при order by 2 есть ошибка (к сожалению не сырая ошибка базы а человекочитабельная)
тут очень интересно почему только 1 колонка? в таблице куда выводят данные 13 колонок

?search=-")+order+by+1--+-

начал думать что там два запроса. первый (уязвимый) возвращает строки с id. а второй достает все данные по этим id. что то вроде

ids = SELECT id FROM users
WHERE group="XXXX" AND (name LIKE "%$GET['search']%" OR email LIKE "%$GET['search']%"
)
SELECT * FROM users WHERE id IN(ids)

думаю ок, попробую через union добавить известный мне id, не помогло. ничего не возвращает

?search=-")+union+select+217--+-

все ок, выводит запись с id 2

") or id=2 -- -

а тут ошибка. то есть получается что если запрос до union ничего не возвращает то ошибки нет, если что то возвращает то ошибка

") or id=2 union select 217 -- -

 

[noted]

Как вариант, запустить sqlmap с верболизацией, там увидишь и пейлоад и ответ (может какой фактор не учитываешь)

 

[ridlle]

Как вариант, запустить sqlmap с верболизацией, там увидишь и пейлоад и ответ (может какой фактор не учитываешь)

sqlmap вообще не видит уязвимости. та и смысла не вижу, ведь это все можно и так посмотреть

небольшие размышления. синтаксис select такой

SELECT [STRAIGHT_JOIN]
       [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
       [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS] [HIGH_PRIORITY]
       [DISTINCT | DISTINCTROW | ALL]
    select_expression,...
    [INTO {OUTFILE | DUMPFILE} 'file_name' export_options]
    [FROM table_references
      [WHERE where_definition]
      [GROUP BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [HAVING where_definition]
      [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [LIMIT [offset,] rows]
      [PROCEDURE procedure_name]
      [FOR UPDATE | LOCK IN SHARE MODE]]

когда использую `ORDER BY1` или `LIMIT 1`, то нет ошибок. но при использование `GROUP BY1` ошибка. то есть вроятней иньекция находится после GROUP BY, думаю ок, наверное поиск реализован в HAVING. попробовал `HAVING 1=1`, ошибки нет. но использовать два `HAVING` нельзя