Pull to refresh

Comments 50

У такой крупной корпорации с мешком денег нет специалистов способных оформить работу с базой без таких дыр?
С такой проектировкой вполне себе возможно ожидать подобные проблемы в других местах их сервиса, вопрос в том когда методом тыка ткнем куда надо. А если не методом тыка, а подумать… То сколько дыр найдем?
Дыры есть у всех. Просто чтобы их найти все, нужен нетрадиционный подход. Кто то выплачивает вознаграждение, кто то прячет голову в песок, а кто то грозит судом.
кто то прячет голову в песок, а кто то грозит судом.
и правда, некоторые используют
нетрадиционный подход
Была подобная некрасивая история с каким то нашим банком. Косяк долго не закрывали и чел сказал СБ банка что расскажет обществу. Ну а те не долго думали. Деталей к сожалению память не сохранила. В поиске уже не ищется(видимо выпилили).
Очень хочется верить, что выпилили не чела.
Как ниже подсказали, это был все же сбербанк(в чем я не был до конца уверен). А чел тот писал по ситуации на форумах, по моему даже на банки.ру. Но что то я его сообщений больше не вижу.
ПриватБанк. Этого чела довольно долго чморили, вплоть до навешивания уголовки.
Конкатенация вместо параметризованных запросов? В 2018? Это не дыры…
Код писали еще в 2012, когда такого не было.
Вы ни разу не сталкивались в работе с древним кодом что-ли?
Это где это аж в 2012 не было prepared stmt?
он и сейчас не во всех либах используется. между прочим
А если еще с persistent connection то в малом их числе.
я парочку видал где жестко всегда с параметрами(ну никто конечно не мешает обойти)
В каком-то древнем фреймворке — вполне может быть.
Код писали еще в 2012, когда такого не было.

Если этого не было в 2012, то как я это мог изучать в середине 00х…
Сталкивался, году эдак в 99ом… А если серьезно то в любой книжке еще лет 20 назад было написано, что данные должны быть отделены от запросов.

Справедливости ради, даже джуниоры знать, что делать, чтобы не допускать таких тупых инъекций. Так что да, это позор, а не то, для нахождения чего нужен «нетрадиционный подход».

Кто то выплачивает вознаграждение, кто то прячет голову в песок, а кто то грозит судом.

Был в одной знакомой фирме проект — не было никакой программы вознаграждения.
Написал некто, попросил денег за уязвимости. Ему вообще не ответили.
Затем система сломалась (наверное он сломал).
Просто заплатили мне (не ему), чтобы я поставил новую обновленную (без уязвимостей) версию системы.

Искать уязвимости и на этом зарабатывать — не так уж и романтично.
Недавно слышал интересную историю от исследователя с немного другим результатом: он нашел достаточно специфичный баг, написал о нем в компанию. Ему ответили нечто неопределенное, потом стали игнорировать. Через некоторое время баг закрыли заплаткой. Но оказалось, что заплатка не закрывала баг полностью, а только очень сильно усложняла нахождение бага и немного — его эксплуатацию.

Итоги: есть компания с серьезным багом, требующим еще более специфичных знаний для обнаружения и понимания, что он здесь вообще есть, и внешний исследователь, который о нем знает, но при этом очень неоднозначно относится к компании.
У Valve очень много старого легаси кода, который написан много лет назад, когда компания ещё не была такой большой. В то время они тесты вообще не писали.
а тестами такие штуки не больно таки и найдешь.
только ревью, пожалуй, поможет
Круто, что Valve начали платить за найденные уязвимости. Всего с лет пять назад они тикеты с сообщениями об уязвимостях просто молча закрывали, даже без спасибо.
Видимо дошло чем это грозит. Особенно на фоне последних крупных сливов.
Не знаете, а у Сбербанка есть такая программа — платить за найденные уязвимости? Я нашел в Сбербанк Онлайн потенциальную уязвимость.
Нет, более того, у них очень своеобразный подход к безопасности: возможность получения доступа к информации о балансе карты и списку операций при некоторых условиях (крайне слабая авторизация) они считают нормальной.
Хорошо, если не обвинят тебя во взломе и не попытаются посадить.
Причем что то такое мелькало в новостях. Не помню конкретно ли со сбером или с другим российским(представительством) банком.
Именно со Сбером и было, самый невменяемый банк.
Ясно, спасибо за предупреждение.
Продайте ее в даркнете, напишите им через тор, а после напишите сюда — все будут довольны
Классная статья. Короткая и захватывающая.
Мы так-то на работе тоже Akamai WAF используем, и до сих пор я особо не задавался вопросами «можно ли его обойти?» и «насколько он эффективен вообще?».
Было познавательно.

Мы отправили заспрос с DB_NAME/всёчтоугодно/() — WAF ничего не понял — можно репортить еще и в WAF?

когда-либо сгенерированные разработчиками игор Steam.
Не
игор
, а игр
«Игор» — это мем откуда-то. Ну и опечатки лучше в личку :)
UFO just landed and posted this here
когда-либо сгенерированные разработчиками игор Steam.

когда-либо сгенерированные разработчиками Игор, Steam
WAF блокирует запрос, когда встречает в нём функцию. Вы знали, что DB_NAME/**/() — вполне валидный вызов функции? Файрвол тоже знает и блокирует. Но, благодаря этой фиче, мы можем разделить вызов функции на два параметра!

Не совсем понял. Если WAF блокирует запрос, в котором встречается DB_NAME/**/(), то почему он не заблокировал countryFilter[]=UA’,DB_NAME/*&countryFilter[]=*/(),’RU?
потому-что этот запрос был раздлен по разным никак не связанным параметрам как мозайка. Логика её обработки лежит все-же на бэкенде.
UFO just landed and posted this here
Фокус с кавычкой так и не понял. Как количество кавычек может влиять на исход дела? MySQL вообще капризная к синтаксису штука, кавычку/скобку не там поставил и запрос тупо вылетает по синтаксической ошибке.
try {
    return $db->getResults();
} catch(...) {
    return [];
}

?
Спасибо автору, только что сгенерировал себе 100500 тысяч ключей
через закрытую уязвимость?

А вот интересно, гипотетически, valve заметит генерацию такого количества ключей или будет все валидно? Так что не ясно является ли эта уязвимость настолько критической (но то что она желанная — это до), если аккаунт потом всё равно забанят.

Как я понял, там таки идет не генерация, а запрос уже выданных разработчику.
Уязвимость была в функциональности скачивания ключей, а не генерации. Какое-то количество ключей уже продано конечным покупателям, какое-то количество продаётся прямо сейчас на легальных торговых площадках. Так что заблокировать все ключи или забанить аккаунты — это большой ущерб как для Valve, так и для партнеров.
Я не совсем понимаю как такие уязвимости вообще появляются, за всё время своей коммерческой практики я не разу не писал sql запросы вручную, всегда использую драйвера к базе в которых уже есть защита от подобного, последний раз писал сам только в школе на продвинутых курсах информатики.
Sign up to leave a comment.

Articles