имеем: Код (Text): блаблабла=-2323%20UNION%20SELECT%20NULL%2C%20NULL%2C%20NULL%2C%20NULL%2C%20CONCAT%280x3a6a6b723a%2C0x794f62766f6655634366%2C0x3a6b737a3a%29%23 %20 - это к примеру пробел...бог с ним, а как бы понять что вот это? CONCAT%280x3a6a6b723a%2C0x794f62766f6655634366%2C0x3a6b737a3a%29%23 есть какой-то способ привести это к удобоваримому виду?
0x3a6a6b723a 0x794f62766f6655634366 0x3a6b737a3a спасибо, но уж больно хочется понять что вот это обозначает...
В качестве urldecode использую обычно google http://www.google.com/?q=-2323%20UNION%20SELECT%20NULL%2C%2 ... 7a3a%29%23 Добавлено спустя 8 минут 45 секунд: CONCAT(0x3a6a6b723a,0x794f62766f6655634366,0x3a6b737a3a) - это типа, чтобы обойти фильтр magic_quotes или что-то в этом духе. Надо сделать что-то типа UNHEX(3a6a6b723a), UNHEX(794f62766f6655634366), UNHEX(3a6b737a3a), чтобы узнать, что там спрятано. Добавлено спустя 7 минут 56 секунд: CONCAT(0x3a6a6b723a,0x794f62766f6655634366,0x3a6b737a3a) означает примерно следующее - :jkr:yObvofUcCf:ksz:
да это не только в мускул инъекции делают-то. так что не парься. в таком формате оно для мускула безопасно.
ну...безопасно не безопасно, но в итоге именно так и сломали....ломали долго и последовательно, около сотни запросов, вот финальный: Код (Text): =-4145%20UNION%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2C%28SELECT%20CONCAT%280x3a6a6b723a%2CIFNULL%28CAST%28code_page%20AS%20CHAR%29%2C0x20%29%2C0x69676c797970%2CIFNULL%28CAST%28enabled%20AS%20CHAR%29%2C0x20%29%2C0x69676c797970%2CIFNULL%28CAST%28full_name%20AS%20CHAR%29%2C0x20%29%2C0x69676c797970%2CIFNULL%28CAST%28id%20AS%20CHAR%29%2C0x20%29%2C0x69676c797970%2CIFNULL%28CAST%28lang%20AS%20CHAR%29%2C0x20%29%2C0x69676c797970%2CIFNULL%28CAST%28login%20AS%20CHAR%29%2C0x20%29%2C0x69676c797970%2CIFNULL%28CAST%28pass%20AS%20CHAR%29%2C0x20%29%2C0x3a6b737a3a%29%20FROM%20названиеБД.таблицаБД%20LIMIT%200%2C1%29%23
1. очевидно, что входящие параметры не проходят должную фильтрацию, иначе бы не взломали 2. эта херота с SELECT CONCAT очевидно способ получить нужную строковую константу в теле запроса, не указывая апострофов мы не знаем как выглядит атакуемый запрос, очевидно цель инъекции вместо параметра подсунуть целый запрос, который будет выполнен вместо исходного. т.е. первая настоящая часть обломается, а вернутся строки, что после union. ваш К.О. Добавлено спустя 1 минуту 15 секунд: несколько NULL нужны только для того, чтобы выровнять число столбцов настоящего запроса и фейкового. это необходимо для UNION Добавлено спустя 18 минут 26 секунд: настоящая цель — добыть ту последнюю колонку. она состоит из code_page . enabled . full_name . id . lang . login . pass. остальное технологический мусор а для защиты всего то нужно $s = my_real_escape_string($param); $query="SELECT ... '{$s}'" а у вас вероятно какая-то самодельная магия
igordata, вот это в этом никакого смысла. точно также прочтут данные из другой бд. фильтровать надо параметры
ну ладно, ТОЧНО ТАКЖЕ, не прочтут. придется сначала надругаться над SQL, затем над скриптами. параметры надо фильтровать, а не обходные пути искать Добавлено спустя 2 минуты 2 секунды: мне просто лень рисовать схемы покорения мира. если другая бд на том же сервере, атака будет сложнее на одно слово Добавлено спустя 2 минуты 56 секунд: а если на другом сервере, то я хуею от таких беглецов. держать отдельный сервер только потому что злоумышленники ебут тебя как хотят!!! Добавлено спустя 34 секунды: а где же "матное слово"? ))) Добавлено спустя 13 минут 17 секунд: Dmitriy A. Arteshuk, злоумышленник явно написал имяБД.имяТаблицы. откуда он мог знать базу? или он свой или вы оставили какое-то дефолтовое имя или вы где-то неосторожно слили инфу
ты не прав. другая БД - другой логин, пароль и т.п. Выносом в другую бд мы снижаем количество дыр до того, которое содержится в модуле, обслуживающем авторизацию. А там по сути один запрос - авторизация. Когда у нас вся авторизация сидит в той же бд что и сайт, то каждый запрос таит в себе опасность. Соотв. чем меньше запросов - тем меньше вероятность быть вскрытым. Соотв, выносом мы уменьшаем вероятность весьма и значительно.
Скорее мы защищаем авторизацию от других частей системы. Если к примеру в поиске будет уязвимость для инъекции, через нее не получится достучаться до таблицы авторизации.
имя БД и юзера он вытащил так: Код (Text): -7513%20UNION%20SELECT%20NULL%2C%20NULL%2C%20NULL%2C%20NULL%2C%20CONCAT%280x3a6a6b723a%2CIFNULL%28CAST%28CURRENT_USER%28%29%20AS%20CHAR%29%2C0x20%29%2C0x3a6b737a3a%29%23 -4775%20UNION%20SELECT%20NULL%2C%20NULL%2C%20NULL%2C%20NULL%2C%20CONCAT%280x3a6a6b723a%2CIFNULL%28CAST%28DATABASE%28%29%20AS%20CHAR%29%2C0x20%29%2C0x3a6b737a3a%29%23
igordata, не путай базу и соединение. в пределах одного соединения я могу обращаться к разным базам просто указав `somebase`.`sometable` если права есть (а они матное слово есть! почему догадайся сам), я прочитаю что надо автор, любая школота может прочитать пособие и пойти тренироваться на вашем сайте. фильтруйте как следует!!! Добавлено спустя 11 минут 17 секунд: каждый костыль заставляет в будущем искать новый костыль и так далее. просто следуйте правильным рекомендациям: - register_globals off - magic_quotes off - числовые параметры пропускать через intval() - строковые через mysql_real_escape_string - если PDO, то использовать плейсхолдеры
ну я как раз рассматриваю позитивный сценарий, когда права есть только на свою базу. когда заходят в базу под рутом вопрос "как меня сломали" задавать бессмысленно. так что если ты про негативный сценарий, то да - не поможет НИЧЕГО =)
так можно узнать текущую выбранную базу, т.е. ту, для которой незачем явно писать имя ) зачем же он его писал там?… наверное просто по шпаргалке действовал. ну или робот так запрограммирован.