Другой вопрос, программист дэ'был, что бы создавать подобную уязвимость? ) Такое можно сделать только намеренно, или если ты программист после курсов. )
CSRF-токен все же является главной защитой. CORS не блокирует запросы, а лишь ограничивает чтение данных в ответе на запрос, не попадающий под правила. К тому же под CORS попадают межсайтовые способы обмена данными, но CSRF через GET и POST запросы никто не отменял.
"Случайно попадаете на страницу хакера" - причем эта страница обязана быть на том же сайте, где хакер хочет сменить пароль юзера. Другими словами, хакер УЖЕ взломал сайт и подобный хак на видео уже неактуальный. Это в лохматые годы можно было прочитать куки фрейма, сейчас такого нет.
Ты не прав, сайт 1 site дефолтный обрабатывает запросы и хранит куки. А сайт 2 пусть будет bad-site (домен) на своей стороне просто отображает форму с методом post на целевой сайт, в данных формы скрытыми инпутами выставляет новый пароль, например, кверти и отображает только кнопку. Юзер открывает bad-site и видит валидную форму (просто кнопку), нажимая её браузер уводит юзера на site с методом пост и новым паролем, при этом подтягивает авторизационные куки/токены так как юзер фактически валидно вернулся на site. В итоге меняется пароль и злоумышленник знает на какой он изменился, так как он его выбрал. Csrf токен тут в роли ключа, который злоумышленник не может знать заранее. Атака чисто клиент сайдовая и очень популярная. Никакие корсы тут не защищают и в целом видос вектор атаки не раскрывает.
@@ilyag5572 твоя схема это древность. Как минимум при смене пароля нужно указать старый. Это по дефолту сейчас. А еще есть капчи, 2FA, иногда и сброс через Email по спец. ссылке.
@@ilyag5572 > юзер фактически валидно вернулся на site Так в этом и проблема, разве нет? Если у злоумышленника есть возможность дать ссылку на свой фишинговый сайт из под нужного домена, то это уже считай что вся трудная работа сделана до этого
Именно, каша из терминов и отсутствие сути. Откуда взялся «случайный» такой же url? Где неожиданная страница изменения пароля, когда это та же самая «случайная» страница. Кука всегда идет с доменом, архитектуру веба делали люди с сильно большим интеллектом, чем у автора видео.
Она неактуальна уже лет 15 так точно, в любом фреймворке уже есть функционал что бы в одну строку обезопасить себя от такого. А вот что действительно опасно, так это XSS атаки если говорить про онлайн. В офлайне наиболее опасное MITM.
Уже 100 лет сессии хранятся не в куках а в стореджах к которому доступ есть только тот сайт с которого ты подключен и на другой адрес они не высылаются.
Зависит от директивы SameSite у куки. В Хроме по умолчанию у куки с неопределенной SameSite выставляется значение Lax - т.е. при переходе со стороннего сайта кука не передастся (только если чел сам не кликнул на ссылку + это должен быть GET-запрос). Но у Фаерфокса значение Lax по умолчанию нужно включать в настройках, в Сафари та же ситуация. Так что зависит от браузера.
Согласен Недавно писал ИИ на питоне и подключал его к своему вебу. Бразуер тупо не позволяет отправлять к-л данные, если корса нет (выдает ошибку при отправке файлов в консоли)
@@dest8488 CORS блокирует лишь получение ответа на запрос, а не сам запрос если он относится к простым. Про что такое простые запросы можно нагуглить легко. В другом случае если запрос не простой, то браузер отправит preflight запрос, и если CORS одобрит,то полетит и основной запрос
@@dest8488 CORS не всегда защищает. Если приложение принимает простые запросы (лучше погуглить что это за запросы),то смысла от CORS как от защиты CSRF нет, потому что он блокирует получение ответа, а не отправление самого запроса
Ничего сложного нет. DDoS атака - это когда со множества взломанных/специально купленных компов делают очень много запросов на сервере. Сервер слишком сильно нагружается, и начинает лагать
Неинтересно есть ли какой-нибудь пример самый защищённого сайта или типа того Который взломает либо что-то подобное сделать можно но очень трудно и по-своему даже бессмысленно относительно труда
Пошел потестил. Ты когда запрос делаешь браузер самостоятельно вкладывает куки того сайта куда ты отправил запрос, т.к они хранятся у тебя. Злоумышленник подготавливает post запрос на смену пароля с нужными ему параметрами, ты у ся в браузере жмешь кнопку (ну или скрипт сам выполняется при прогрузке страницы) идет запрос на оригинальный сайт с нужными параметрами, а браузер прикладывает в этот запрос куки оригинального сайта.
Когда пользователь переходит на сайт хакера, то происходит post запрос на смену пароля. Браузер автоматически прикладывает куки в запросе, поэтому так происходит
Это смотря как организовать хэширование этого токена. Зашифруй в токене уникальные данные броузера, которому принадлежит кука и ты не обойдешь никогда.
Теоретически возможно, практически - нереально. Вирус - это код исполняемый внутри системы. Сайт - это код исполняемый внутри браузера. Если браузер имеет критическую уязвимость которая позволяет чужому коду попасть в память системы - то да. Однако подобные баги фиксятся быстрее чем ими успевают попользоваться. И сложность разработки подобных вирусов довольно высокая.
@@PurpleDaemon_ а кто сказал что нельзя сразу после закрытия вкладки очистить куки? Например я настроил что браузер всё данные после закрытия стирает. Да не всегда удобно ибо нужно заново заходить но зато безопаснее.
@@user-bc8xh4hf1r понятное дело, что в браузере, но разве браузер должен отдавать куку с другого ресурса? Тогда я могу зайти на Ютуб, а они просто в открытую заберут куку сессии, допустим, ВК и спокойно залогинятся. Есть же политика безопасности браузера. По идее, единственный вариант, когда можно получить куку с другого ресурса, это если другой ресурс сам по определенному адресу отдает кукис.
@@AggressiveCHANNEL это все ещё популярная уязвимость. Куки подставляются автоматически браузером, засчет чего атака и возможна. Плюс не всегда csrf токены реализованы в приложении адекватно,или SameSite не защищает,если авторизационные функции принимают Get запрос
