Комментарии 22
А кто-нибудь вообще понимает, как могло прийти в голову получать по id инфу пользователя без проверки прав доступа?)
Но так и непонятно с кэширование, удалось ли?
Безопасность закладывается при написании кода либо сразу, либо как получилось, так получилось. Судя по багфиксу разработчики даже не поняли в чём проблема.
Я далеко не профи, совершенно, любитель. Но почему мне понятно с первой же мысли, что получение данных рандомного пользователя по простому id без авторизации существовать не должно никогда и ни при каких условиях, а целой команде разработчиков, которые делают достаточно массовый сервис, работающий с детскими персональными данными - нет? Меня такие моменты сильно удивляют
Впрочем, стоит радоваться, наверное, что оценки выставляются не простым POST так же без защиты))) Ну или ТС просто этим не занимался
Не совсем понял вопрос про кеширование)
Мы просто брали пароли с компа, вставляли флешку с автораном и получали сохраненные пароли. Пару двоек исправил, но скандал был. За ночь рейтинг школы обвалился, исправлять исправленные оценки никто не стал)
Такая простая уязвимость в государственном приложении
Есть одна ГИС, данные из которой потом уходят на ЕПГУ (Госуслуги). Там можно было переключиться на другого пользователя, дёрнув api из браузера. На пользователя другой организации или даже учётки админа находили. Но это всё баловство, в этом году нашли дыру посерьёзнее - во время редактирования сущности по id перепутали боевой и тестовый контур и отредактировали ЧУЖИЕ данные.
Если речь про элжур и их апи, то как вы проходили авторизацию через госуслуги для получения токена/кук/etc ? Когда я раньше учился в школе, сейчас в институте. У нас был электронный журнал барс там было апи и всё гораздо проще. Но с элжуром всё поменялось
Что насчёт "Моей школы", там могут быть подобные уязвимости, или все таки уже успели залатать?
💪
Ну и извращения с прехватом запросов на Android. Можно легко декомпильнуть приложение и легко найти все эндпоинты по интерфейсам, где у каждого метода висит аннотация с путём из url. Я таким образом в своё время написал кастомный клиент с поддержкой мультиаккаунта. (https://github.com/TheDearbear/DigitalJournal)
Я ещё находил один раз уязвимость в "Сетевом городе" тоже ПО для эл. журнала. Суть была в том, что если не указать ID при получении оценок, то возвращались все оценки класса.
Написал разработчикам в форму обратной связия а они просто молча исправили и ничего даже не написали :(
У нашей школы несколько лет назад была вообще странная ситуация: журнал и некоторые сопутствующие сервисы (moodle) хостились прямо в школе, а вход на них был по просто IP адресу, без домена
Однажды со скуки в классе восьмом я обнаружил, что на этом IP адресе еще есть и FTP без авторизации. А там, помимо тонны всяких разных файлов, прямо в корне лежал файл с незашифрованным бэкапом всего школьного журнала. К счастью, именно персональных данных там почти не было (их можно было указать в учетке, но этого не делали ни школьники, ни учителя), зато были пароли надежно (нет) защищенные MD5 без соли
Я не стал об этом никому говорить тогда (остерегаясь последствий), поэтому этот архив пролежал там еще год, пока в новом учебном году школа не решила перейти на другой журнал (и заодно подчистить тот FTP-сервер)
В общем, это я к тому, что в целом в этой "индустрии" все довольно печально и проблемы далеко не единичны
Как я уязвимости в школьном электронном журнале искал