Пример использования защиты CSRF
У вас есть встроенное устройство, которое поддерживает веб-интерфейс на основе HTTP через частный IP-адрес.
Имеет ли смысл реализовать защиту CSRF через HTTP (не HTTPS)?
Ответы
Если HTTP-запрос может изменять состояние, ему может потребоваться защита CSRF. Независимо от того, зашифрован ли запрос на транспортном уровне, это практически не имеет отношения к этому.
Без защиты CSRF злоумышленник, который убеждает вас посетить их веб-сайт или даже отдельный ресурс, может отправить запросы на ваше встроенное устройство и получить контроль над ним, если браузер жертвы авторизован должным образом или аутентификация недостаточна или не работает. Это происходит независимо от того, используется ли HTTP или HTTPS.
Да, в идеале все было бы по HTTPS. Однако «лучший» вариант для большинства поставщиков на данный момент - это поставлять встроенные устройства с самозаверяющими сертификатами, которые, помимо того, что подходят для использования с доверием при первом использовании и препятствуют пассивному сниффингу, во многих сценарии. Часто пользователь по-прежнему получает предупреждение о сертификате и нажимает на него. Пока эта проблема не будет решена, перспективы HTTPS для встраиваемых устройств остаются мрачными.
(Обращение к вашим теперь удаленным правкам) Действительно, XSS обходит защиту от CSRF. Однако модель угроз здесь выглядит немного иначе, поскольку для злоумышленника менее вероятно, что злоумышленник сможет использовать XSS на вашем встроенном устройстве, чем проблема CSRF, поскольку в первом случае им придется добраться до устройства.
Без защиты CSRF злоумышленник может подделать электронное письмо (возможно, с прилично целевым поддельным адресом) с предупреждением мониторинга, предлагающим вам проверить, потому что существует критическая проблема. В письме может быть ссылка на http: // yourswitch / factory_reset.
Векторы атак могут быть разными.
Если вы не используете для этого устройства полное доменное имя или IP-адрес по умолчанию (скажем, вездесущий 192.168.1.1), этот конкретный вид атаки будет довольно целенаправленным. Злоумышленник должен будет сформировать запрос к коммутатору, который на самом деле делает что-то «интересное» (для этого нужно знать FQDN / IP и поставщика / модель, чтобы получить полезный путь) и отправить вам эту ссылку таким образом, чтобы не было слишком много Ваши брови (электронное письмо из Интернета было бы странным. Может быть, что-то подделывает письмо с мониторингом без ответа, которое вы используете?).
Как обычно, все сводится к пониманию вашей модели угроз и соотношению затрат и выгод ваших контрмер.
Да.
В случае сетевого коммутатора или маршрутизатора типичными атаками, которым он может подвергнуться, может быть изменение конфигурации устройства (например, перенаправление внутреннего порта на внешний), изменение DNS, который он предоставляет, на злонамеренные и т. Д. Эти действия должны потребовать аутентификации, но вы должны принять во внимание, что он также может использовать неизменный пароль по умолчанию.
(и да, такое бывает в дикой природе)
Тот факт, что он основан на частном адресе http://192.168.1.1не обеспечивает защиты, так как атака может быть осуществлена вредоносной веб-страницей, отправляя через браузер пользователя внутри сети вредоносный запрос, который - принятый из-за отсутствия защиты CSRF - приведет к неправильной настройке коммутатора.
В Mozilla Firefox уже 14 лет существует ошибка 354493 , позволяющая избежать атак с адресов, не относящихся к RFC-1918, на адреса RFC 1918, но до сих пор она не реализована.