Я создаю статический генератор сайта с динамическим админ-сервером для одного пользователя. Сайт не принимает пользователей. Означает ли это, что я в безопасности от злоумышленников, которые пытаются украсть мой админ-файл?Кража Cookies без ввода пользователем?
(нет пользовательского ввода, так XSS и другие методы не работают, не так ли?)
Если нет нет входного пользователя (ссылки не кликать, что есть какие-либо эффекты и т.д.), как бэкэнд администратора квалифицируется как «динамический»?
Но в основном: Нет, если вы не используете HTTPS. Даже если вы не принимаете ввод, cookie передается в виде открытого текста и поэтому может быть захвачен (с помощью атаки «человек в середине» и т. Д.) И используется. (Я предполагаю, что вы не хотите, чтобы другие люди использовали куки-файл, чтобы увидеть материал администратора.)
Или я полностью не понял вопрос? ;-)
Я уточню: сайт не принимает пользователей. Он обслуживает страницы, содержимое которых хранится в базе данных mysql. Существует «панель администратора», где я могу редактировать содержимое существующих записей или добавлять новые. Я хочу, чтобы мой компьютер имел доступ к этой функции. Я планирую дифференцировать свой компьютер от потенциальных злоумышленников, проверяя действительный файл cookie администратора. Даже если у вас есть только статический сайт на переднем конце, возможно ли кому-то каким-то образом украсть мой файл cookie и получить доступ к панели управления admin? – Yongho
@Yongho: Если кто-то может получить файл cookie (через доступ к вашему компьютеру или сетевое обнюхивание и т. Д.), То да, они могут получить доступ. Так ты защищаешься. Если вы можете потребовать, чтобы ваш доступ администратора к * только * работал через HTTPS (а не HTTP), это касается аспекта сетевого нюхания, оставляя хранилище файлов cookie вашего компьютера слабым. Также будьте осторожны при атаках грубой силы путем ведения журнала и * просмотра * журналов, чтобы знать о неудачных попытках получить доступ к консоли администратора (кто-то может попытаться угадать файл cookie). Вы поняли эту идею. :-) –
@Yongho - Если вы держите панель управления admin в отдельном домене и обслуживаете этот домен только в локальной интрасети, и не заботьтесь о посещении какого-либо другого веб-сайта или не нажимаете на какую-либо ссылку, пока у вас активная сессия администратора, вы все в порядке. Если какое-либо из этих условий не выполняется, вам придется исправить свои уязвимости. –
Следующая уязвимость. Это может быть вектор, в который можно было получить доступ с помощью злоумышленных средств с использованием CSRF. Вредоносный JavaScript может быть введен с помощью атаки CSRF->Stored XSS.
Существует «админ панель», где я может редактировать содержимое существующих записей или добавить новые.
Проблема в том, что, когда вы проверку подлинности этой административной консоли хакер все еще могут получить доступ к этой функции с помощью «верховых» на вашей авторизованной сессии, и это является основой CSRF. Короче говоря, злоумышленнику не нужно знать свой идентификатор сеанса, потому что ваш браузер делает это! Посещая вредоносный веб-сайт, злоумышленник может заставить ваш браузер отправлять HTTP-запрос в административную консоль. Чтобы снять эту атаку, злоумышленник должен знать сервер, путь к скрипту и все параметры POST/GET, но ему не нужен ваш пароль или файл cookie. Если это внутренняя административная консоль, это маловероятный вектор атаки. Но его легко защищать. Самый простой способ - проверить http referer http-запроса, который делает эту «модификацию контента», Motorola делает это для многих своих сетевых устройств. Более общий подход - использовать «токен csrf».
CSRF: Проблема 0: проблема, если вы используете basic-auth через файл .htaccess или файл cookie на основе auth. Независимо от того, что вам нужно для предотвращения вредоносных поддельных запросов и защиты от обнюхивания с помощью HTTPS. Это более подробно описано в OWASP Top 10, убедитесь, что вы прочитали «A3:« Сломанная аутентификация и управление сеансом ».
Модуль администратора - он обслуживается в одном домене и обслуживается через Интернет? Например, если ваша страница администратора обслуживается только в локальной интрасети, и вы доверяете своей интрасети/коллегам, тогда все в порядке, чтобы не волноваться. В противном случае вам все равно придется беспокоиться о том, что кто-то украл ваш cookie администратора, и все, что указано ниже, применимо. –
.. Кроме того, вы должны быть внимательны, чтобы не посещать вредоносные веб-сайты или не использовать ссылки по электронной почте/им/чату, когда вы вошли в панель управления администратора. В противном случае кто-то может csrf вас. –