Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 88
В некоторых банках можно логин менять
Ещё бывает 0
а так же true, false, "", '', `` etc
Я знавал человека по имени Drop Database
Кошмар веб девелоперов - мистер [object Object]
Хм. Это его родителям звонили из школы, а они отвечали «это научит вас экранировать строки»? ))
Древнее зло ;)
Кстати, что за странная повозка?
Что бд называется "TABLICE" это еще знать надо.
Я тупой и ничего не смыслю в веб-разработке. Поясните, допустим, так или иначе, через sql injection, на сервер попала подобная команда. Или там drop table XXX, неважно. Ну и что? Неужели у пользователя есть полномочия на выполнение подобных операций??? Будет сообщение о какой-нибудь ошибке и все.
Бекэнд в 99.9% случаев подключается под юзером с правами на DELETE строк, потому что как-то должна же работать админка, где есть функция удаления записей. Разграничения прав доступа идёт на уровне бекэнда, а не СУБД.
Также очень часто бекэнд имеет право на создание и удаление таблиц, потому что он же и выполняет миграцию схемы данных при обновлении ПО.
Единственное, что DROP DATABASE может не быть, но только если админ заморочился сделать отдельного юзера под бекэнд. Что вовсе не факт, если СУБД обслуживает лишь один бекэнд.
под юзером с правами на DELETE строк, потому что как-то должна же работать админка, где есть функция удаления записей.
Это там, где soft delete не завезли, ну и прочие излишества. Пользователи, права, зачем это все? Бизнесу надо быстрее фичи в прод выкатывать, а то конкуренты обгонят, бггг)
А чем фундаментально отличается право делать UPDATE от права делать DELETE в плане "напакостить"? Да ничем, затирание таблицы мусором ничем не лучше удаления.
Чтобы нормально задействовать систему прав уровня СУБД, эта самая система прав должна существовать, и не для галочки. А существующие реализации row level security именно для галочки и сделаны.
У камеры должны быть права только на insert. Тут вся иньекция и закончилась.
как уже написали только insert и только в определенную таблицу, права на удаление таблиц только у админа.
в крайности впадать не стоит, но если что-то торчит наружу, надо хорошо подумать что пользователю можно делать, а что нельзя
У нас на такой случай миграции проходят от одной учетки с админскими правами, а реальная работа уже с урезанными.
Удаление записей не принято делать. Обычно добавляют дополнительное поле "deleted" и переключают его значение на true
Надеюсь он никогда не будет заполнять анкету на Госуслугах
Я много лет использую логин null или undefined везде, где могу. Это первое, что я пробую при регистрации, и делаю это как раз в надежде столкнуться с чем-то описанным в статье. За всё время ничего не случилось. Только на сайте одного известного онлайн-магазина электроники лет 5 назад получил уведомление о том, что мой ник был изменён модератором сайта.
На одном крупном сайте зарегистрировался с ником admin. В комментарии к посту пришли настоящие админы и долго возмущались занятым мной ником (который оставался свободным всё 10+ лет существования сайта).
Значит там работает нормальная валидация на входе или есть черный список зарезервированных имен. Как раз пример того, как надо делать
Вот в такие моменты понимаешь, почему в SQL NULL <> NULL и есть всякие IS DISTINCT FROM
Вот в такие моменты понимаешь, что есть программисты, не знающие основ SQL
Да здесь давно любой может писать, не?
Нынче все ORMом отгораживаются от бесовского SQL :)
Инструмент с граблями на каждом шагу -- фиговый инструмент. Туда же повсеместный Shell, который в виде Bash делается лишь чуточку безопаснее (и понятнее).
Водитель пусть в ДТП и виноват, а системы безопасности продолжают наращивать. А нашей отрасли, видать, понадобилось 40+ лет (1970-2010) с момента популяризации инструментов, чтобы радикализоваться в достаточной степени, наплевать на и начать активно отвергать старые подходы к безопасности в парадигме "не был аккуратен -- сам виноват".
Ага. Я за больше 10 лет работы в ембеде ни разу SQL не щупал - не было нужды.
А вчера вечером за 2 часа разобрался как из mysql базы Ampache(музыкальный сервер) вытащить данные в нужном формате. И то - не по работе, а хобби.
Но как?? С чем нужно сравнить строку 'NULL' и как спроектировать базу данных чтобы оно сработало? Те ученые записи, на которых иньекция сработала - были с логином NULL штоле?
Подозреваю, что данные в JSON между сервисами передавались, и в какой то момент "NULL" заменился на NULL, либо наоборот
Ну, если специально не ломать, то в json есть null. Но если даже найти способ сломать - что с чем нужно сравнить?
Зря нас пугают вайбкодингом. Люди руками делают весьма странное.
Не так давно я отправлял строку "NULL" в одну подсистему только потому, что она в этом месте в принципе принимает только строки. Так что случаи бывают разные.
В этом-то и вопрос: с какого перепугу "NULL" вдруг заменился на NULL? Почему ни у кого не заменяется, а здесь заменилось? Из какого места должны расти руки, чтобы заменилось? Что сделать, чтобы не заменялось? Без ответов на эти вопросы статья теряет весь смысл. Остаётся беллетристика "Жила-была девочка, ей пришло письмо". Ну очень интересно
Произошло явно прямо противоположное, в каком-то из мест null вдруг заменился на строку null. Допустить подобную ошибку несложно, достаточно подобрать правильный язык программирования.
Банальное защитное преобразование в строку на JS делает ровно то, что случилось.
Как только встречаются несколько разных языков, появляется масса вариантов.
От банально забытого экранирования данных (например, при "ручной" сборке SQL) до особенностей сериализации/десериализации данных.
Статья — три абзаца, ничего не понятно, написано с мелким привкусом пафоса, и вы, мол, сами все поймете…
В каком-то языке привели null к строке и получится 'NULL'
В JS, например, null + '' === 'null'
Зашла на аккаунт проверить появились ли у меня в управлении эти домены - нет, это были просто сообщения на почту, которые судя по всему дублировались на мой аккаунт.
Видимо сервис отправки уведомлений ищет адрес почты запросом к БД по логину, а вместо того чтобы обработать null как ошибку, экранирует и делает запрос к БД, а сервис переноса аккаунтов работает по id и по каким то причинам на время изменения данных ставит логин null.
Есть форматы, где null не предусмотрен. Например, url encoded формы. Конечно, по-хорошему, туда и не надо пихать null (а обозначать отсутствие значения отсутствием поля или ещё как-то более однозначно), но если очень хочется... Между тем некоторые сериализаторы делают тупо toString всем полям и, соответственно, null превращается в "null" и дальше едет как строка и становится неотличим от явно переданной строки "null".
Отдает байкой ради рекламы. По ссылке 404.
Ссылка на раскрытый репорт:
https://bugbounty.bi.zone/reports/6777
Но там не 404, а "This is a private report" и к тому же, Program: SBER WILDCARD BUG$ ZONE III
Сомнительно, что на Bug Zone от Сбера нашли уязвимость у TW
Самое важное осталось за кадром. Конкретный механизм этого "иногда превращаются" остался совершенно неясен, а без него ценность статьи близка к нулю.
так blackbox же
Статья показывает метод поиска уязвимостей "понатыкать null/undefined строк туда, где им не место, и посмотреть что будет". Так как это достаточно распространённая ошибка - привод к строке nullable значения, в результате получается "null" неотличимое от переданной строки вручную. И дальше может что-то пойти не так.
Знать внутреннее устройство сервиса при этом не обязательно.
Известная байка, как кто-то умный сделал себе номер на машину NULL (в америке можно любые буквы делать). Задумка была, что камеры не смогут выписать такому номеру штраф. В реальности, хозяину авто приходили все штарфы, где камера не смогла распознать номер.
Эх, на многих сайтах мне отказывают в регистрации по причине "в имени пользователя обязательно должны быть буквы"
Баян же, не боян.
Багбаунти это круто. Но только не в МТС. Я им баг заводил раз 100. И номер мой не NULL. И ситуация стандартная питерский номер в Питере и области через mnp не может дозвониться в РОСТЕЛЕКОМовский номер зарегистрированный в краснодаре и находящийся в Питере. При этом через их же приложение звонок идёт, не mnp номер дозванивается, меняется регион mnp номера и все начинает работать. Напомнило сбер 2000х - вот где карту открывали в то отделение и идите.
Я уже читал где-то эту статью, уверен на 100%. Причем довольно давно.
NULL - не логин, а дырка в валидации. В итоге чужие уведомления летят куда попало
Там проблема скорее в сериализации, что где-то сделали toString значению, которое может быть null. Причём сделали даже не при регистрации, а там где идёт рассылка емейлов. Просто раньше прилетевшую строку null искали в базе и не находили. А теперь нашли соответствующего ей пользователя и отправили ему уведомление.
Баг был и без этого пользователя. Например, емейлы не уходили в каких-то ситуациях, базу лишний раз дергали и т п
Скорее всего где то в коде была конструкция типа SELECT ... WHERE username = ?, и при отсутствии юзернейма в каком-то сервисе туда подставлялся SQL NULL. А база данных при сравнении username = NULL не находила ничего. Но какой то другой сервис, видимо, делал username || '', получал строку 'NULL' и по ней уже находил аккаунт автора
Веселый зоопарк
Так вот зачем нужна фича смены логина) Не для удобства пользователей, а для того, чтобы багхантеры могли занять все зарезервированные имена вроде NULL, None, admin, root и посмотреть, что сломается...
Сколько человек загуглили слово багбаунти?)
А про эту уязвимость будет статья?
https://bugbounty.bi.zone/reports/12220
Поправьте ссылку на HackerOne, там  прилип
Я один раз был подписан как Atom Sgm-Port
И ко мне из-за этого Украинцы добавлялись, раньше они в ВК сидели
подпоручик Киже неистребим
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я создала аккаунт с именем «NULL» и мне стали приходить уведомления о покупке доменов другими пользователями