Начиналось все как всегда — дело было вечером, делать было нечего... Ну и все в таком духе. Наткнулся я на sql-inj на одном интересном проекте — ну и как водится решил ее подраскрутиь :) И решил ка я поизучать строение БД этого проектенга...

СУБД оказалась MySQL 5-й ветки, что не могло не радовать. Начал изучать information_schema... и уж до того обширное строение базы у этого проекта оказалось, что просто аж жуть. С горем пполам перебрал (автоматически естественно) имена баз и имена таблиц — но и на то ушло немало времени. Отобрал наиболее интересные таблицы — решил получить имена их колонок... И тут я начал потихоньку ужасаться, видя сколько мне записей прийдется извлечь, и представляя сколько это займет времени. И начал думать — а как бы так мне сократить время... И тут мне вспомнилась интересная функция, которая появилась в 5-й ветке мускула, если мне не изменяет память. Имя сей чудной функции — group_concat():

http://dev.mysql.com/doc/refman/5.0/...n_group-concat

и начал я составлять запросы вида (допустим у нас скуль такая: site.com/?q={SQL}):

Код:

---

site.com?q=union+select+1,group_concat(table_schema,'.',table_name,'.',column_name),3+from+information_schema.columns+group+by+1

---

И радости моей не было предела, когда эта чудная конструкция отработала :)

Но как говорится — в наше время в любой бочке меда есть ложка дегтя... Дело в том, что group_concat() формирует строку не более длинны, заданной в системной переменной group_concat_max_len, которая по стандарту равна 1024.

Но все же время, потраченное на получение необходимой мне информации, удалось сократить в десятки раз, чем я остался очень доволен.

P.S. Возможно метод не новый, но я о подомном ничего не слышал, как думаю и многие. Поэтому решил поделится мини-зарисовкой на этот счет :)