Comments 14
Как вариант решения проблемы с WebArchive - запрет отображения сайта во фреймах. Можно разрешить отображать сайт в отдельных доменах, если требуется отслеживание по веб-визору от Я.Метрики, например.
Проблема с тем, что данные утекают в WebArchive состоит скорее всего в том, что в файле /robots.txt не указано правило для сканирующих роботов какие url'ы можно сканировать, а какие нет. Крупные поисковые системы, llm придерживаются рекомендаций в файле robots.txt, который является стандартом в индустрии. Если рассматривать более мелких роботов, то они могут и не учитывать правила указанные в данном файле. В таком случае, либо закрывать доступ к файлам для не авторизованных юзеров (тем самым будут жалобы от клиентов, что они не могут посмотреть выписки), либо как вариант присылать на почту файлы с выписками, а не в виде ссылок.
Проблема с тем, что данные утекают в WebArchive состоит скорее всего в том, что в файле /robots.txt не указано правило для сканирующих роботов какие url'ы можно сканировать, а какие нет.
WebArchive игнорирует robotst.txt. Вот цитата из статьи Тихая смерть robots.txt:
Internet Archive в 2017 году просто заявил о том, что больше не придерживается правил robots.txt. «Мы уже долгое время видим, что файлы robots.txt, предназначенные для краулеров поисковых движков, не всегда служат нашим задачам архивирования», — так писал в то время директор Wayback Machine Марк Грэм. И на этом всё.
В МАХе не было проблем с " с доступом к изображениям из ЛС ".
Если пользователь сам добровольно сгружает свои персональные данные в Wayback Archive, то почему это уязвимость? Это примерно как если бы я сам загрузил скан своего паспорта на habrastorage, а потом затребовал бы оштрафовать Хабр за утечку персональных данных
Расширения для браузера, которые могут красть ссылки.
URL с query параметром также может улетать в Яндекс Метрику и их аналоги.
Ну так предъявляйте претензии к Яндексу и к этим расширениям, а не к авторам ссылок. Расширения могут с таким же успехом и пароли красть, и вообще втупую сохранять содержимое страниц целиком без всяких ссылок, если захотят
Достаточно того, что ссылка попала к злоумышленнику.
«Достаточно того, что пароль попал к злоумышленнику» принципиально ничем не отличается
Если пользователь сам добровольно сгружает свои персональные данные в Wayback Archive, то почему это уязвимость?
С чего взяли, что пользователь сам сгружает туда свои персональные данные? Я в статье привёл сомнения по этому моменту. А, может, это уволившийся сотрудник решил отомстить работодателю и сохранил в WayBack все ссылки, которые нашёл в логах, к которым имел доступ (но, по должности не должен был иметь)?
Вы, видимо, не в курсе: что вообще и в каком количестве есть в WayBack Machine. А там данных очень много. И они - от кучи разных пользователей. Как я уже указывал, если в массовое сохранение pdf пользователями ещё можно хоть как-то поверить. То в массовое сохранение json - вообще не верится.
Ссылка с json сохранена в WebArchive спустя 5 секунд
В статье есть эта картинка
Ну так предъявляйте претензии к Яндексу и к этим расширениям, а не к авторам ссылок.
Вы забыли ещё и про сами браузеры, которые собирают кучу данных. Ситуация: разработчик игнорирует рекомендации OWASP по безопасной разработке: "Additionally, use complex identifiers as a defense-in-depth measure, but remember that access control is crucial even with these identifiers." Что приводит к попаданию данных в Яндекс Метрику и краже URL браузерными расширениями. В конечном итоге ведёт к утечкам. Стоило только выполнить выше указанные рекомендации OWASP - проблема бы исчезла. Но, нет: вместо этого нужно найти на кого перевести стрелки.
А кому предъявлять утечку через URL из-за доступа к логам веб сервера (из-за плохой политики доступа, где любой сотрудник может получить доступы к логам)? Опять крайнего искать будем, вместо реализации безопасной разработки, которая бы исключила эту ситуацию на уровне архитектуры?
Я в статье привёл сомнения по этому моменту.
А конкретику не привели и причастность создателей ссылок не обосновали
уволившийся сотрудник решил отомстить работодателю
И залил секретные файлы на файлообменник без всяких Wayback Machine если захотел, ссылки здесь вообще ни при чём
А там данных очень много.
И что? Если кто-то добровольно сгружает туда свои ссылки — это всё ещё не проблема создателей ссылок
Вы забыли ещё и про сами браузеры, которые собирают кучу данных.
Ну так предъявляйте претензии создателям браузеров, а создатели ссылок здесь всё ещё ни при чём
краже URL браузерными расширениями
Создатели ссылок не могут нести ответственность за какие-то левые расширения. Как я уже отметил, они с таким же успехом могут красть и пароли, и весь остальной access control из этого вашего OWASP
из-за плохой политики доступа
К организаторам этого доступа, разумеется
реализации безопасной разработки, которая бы исключила эту ситуацию на уровне архитектуры
Как я пояснил выше, с архитектурой ссылок никаких проблем нет, или по крайней мере вы до сих пор не доказали обратное
Вот о чём реально стоит переживать, так это о Referer, через него реально можно случайно слить ссылку стороннему сайту, если на странице есть ссылки на сторонние сайты (о чём предупреждает RFC 2616). Но, опять же, это относится только к страницам, а не к pdf/json и не к несчастным фоточкам в максе (а о том, что у ВК ссылки на фотки тоже всегда были публичные, никто почему-то не вспоминает)
а о том, что у ВК ссылки на фотки тоже всегда были публичные, никто почему-то не вспоминает
Вы там ниже написали, что бремя доказательства лежит на утверждающем. Не соизволите последовать своим же словам и доказать? Ну, и чтоб не было скучно: в статье (Уязвимость «ВКонтакте» позволяла получить прямые ссылки на приватные фотографии) указано, что проблему исправили в 2015. А в комментарии к статье человек (который, согласно статье имел связи с разработчиками ВК) указал, что фикс сделан в виде проверки права доступа (в ответ на уточняющий вопрос: "начали проверять права при доступе или просто усложнили процедуру подбора URL?"). Т.е. Ваше утверждение про "всегда были публичными" вот уже 11 лет как потеряло актуальность.
А чего далеко ходить, вот обложка моего собственного альбома в ВК, который всегда был закрытым https://cs9502.userapi.com/v9502088/1b6/8XBzPas8qWY.jpg
Как много проверок доступа у вас запросили при переходе по этой ссылке?)
И обратите внимание на Last-Modified
И, разумеется, ВК ни разу не виноват в том, что я сам добровольно опубликовал здесь эту секретную ссылку
Создатели ссылок не могут нести ответственность за какие-то левые расширения. Как я уже отметил, они с таким же успехом могут красть и пароли, и весь остальной access control из этого вашего OWASP
По этой логике - за утечки из-за SQL-инъекции должны нести ответственность хакеры, которые им воспользовались. А разработчики тут ни при чём: не могут же они нести ответственность за какие-то там кавычки в запросах! Как в том анекдоте:
"Полиция, помогите, у меня сумку украли!
- Это не мы, Вам к ворам надо!"
Я так полагаю, помимо "этого вашего OWASP", разработчикам побоку и "этот ваш Secure by design"? Можете рассказать: к каким продуктам Вы руку приложили? Чтоб обходить их стороной.
Как я пояснил выше, с архитектурой ссылок никаких проблем нет, или по крайней мере вы до сих пор не доказали обратное
Я говорил про угрозы (обычная практика при построении безопасной архитектуры). А не про доказательство чего-то. Тем более человеку, который игнорирует общепринятые принципы безопасной разработки (OWASP, Secure by design и т.д.). Но, если Вам так нравятся доказательства - почему бы не начать с себя и не представить доказательства того, что в Wayback Machine ссылки на файлы (и access-токены в GET-запросах) попадают исключительно из-за пользователей? По крайней мере, Вы этого до сих пор не доказали.
SQL-инъекция даёт непредусмотренный разработчиками и неограниченный доступ, ссылка с неподбираемым идентификатором — предусмотренный и ограниченный, сравнение некорректно
Я говорил про угрозы
Угрозы, про которые вы говорите, находятся вне зоны ответственности создателей ссылок (в отличие от SQL-инъекций, которые в зоне ответственности бэкендеров, которые обязаны ставить кавычки и экранирование, так что сравнение всё ещё некорректно)
попадают исключительно из-за пользователей
Бремя доказательства лежит на утверждающем. Официальные способы попадания в Wayback Machine — ручное сохранение пользователем и краулеры, сканирующие сайты в открытом доступе, в котором секретные ссылки сами по себе не появляются. Если вы считаете, что есть ещё способы — покажите их
может я конечно ошибаюсь, но ссылка на файл на google drive которую я создал лет так 10 назад, до сих пор актуальна.да и у dropbox по моему нет ограничений на время жизни ссылки. почему тут это ставят в упрек для Max?
Wayback Machine как архив IDOR: как временные ссылки перестали быть временными