Как бороться со старым сайтом с проблемами безопасности?

Question

Я недавно обнаружил старое веб-приложение, полное старых трюков

1. GET param: информация о пользователе в параметрах URL
2. Информация о сеансе
3. Скрытые элементы, используемые для хранения информации
4. HTML / JS / CSS выгружается на странице. Без правильного кодирования. и т.д.
5. Window.open для отображения всплывающих окон.
6. XSS и т. Д.
7. Объединенная строка SQL подходит для слепых SQL-атак.

и еще много всего ...

чтобы все заработало. Похоже, приложение устарело за последние 5-7 лет (ASP.NET 1.1) и выглядит так, как будто код приложения не поспевает за лучшими методами обеспечения безопасности.

К счастью, похоже, что браузеры и инструменты тестирования безопасности развивались очень хорошо. Помогая людям / клиентам сообщать о многих проблемах безопасности время от времени. Держать их счастливыми и безопасными для системы стало болью.

Может кто-нибудь, пожалуйста, сообщите мне, если вы столкнулись с чем-то похожим, и помогите мне перейти к какому-либо конкретному исследованию или что-то, как решить эту проблему? «свободно» доступные инструменты тестирования, которые можно использовать для тестирования веб-сайтов на безопасность в среде разработчика? Какие стратегии следует использовать, чтобы справиться с этой ситуацией? Как прогрессировать.

Answer 1

Позвольте мне вначале сказать следующее: хотя существуют открытые и бесплатные инструменты для сканирования безопасности, ни одно из них не будет идеальным.И по моему опыту (по крайней мере, с PHP) они имеют тенденцию возвращать достаточно ложных срабатываний, что их едва ли стоит запускать (но это могло бы стать лучше с тех пор, как я в последний раз их использовал).Если вы хотите использовать один, чтобы попытаться помочь выявить проблемы, обязательно сделайте это.Но ни в коем случае не доверяйте выводу (с ложноположительной и ложноотрицательной точки зрения).

Что касается того, как его решить, я бы предложил пошаговый подход.Выберите один тип уязвимости и устраните ее во всем приложении.Затем перейдите к следующему типу уязвимости.Таким образом, потенциальный план игры может быть (упорядочен по серьезности и простоте исправления):

1. Исправить все уязвимости SQL Injection.

   Пройдите по коду, найдите все местагде он выполняет запросы SQL, и убедитесь, что они используют подготовленные операторы и что ничто не может попасть внутрь.

2. Исправить все уязвимости XSS

   Найти все места, где есть локальная информация (предоставленный пользователем или иным образом) должным образом очищается и экранируется (в зависимости от варианта использования).

3. Исправление всех уязвимостей CSRF

   Перейдите на сайт и убедитесь, что все отправляемые формы правильно используют систему токенов CSRF для защиты их от мошеннических запросов.

4. Устранить все уязвимости аутентификации и фиксации сеанса

   Убедитесь, что системы аутентификации и сеанса защищены от злоупотреблений.Это включает в себя проверку того, что ваши куки-файлы чистые и что идентификаторы сеансов часто меняютсяИ убедитесь, что вы правильно храните пароли ...

5. Исправление уязвимостей и внедрение информации

   Вы утверждаете, что в URL-адресах и скрытых элементах формы содержится информация о пользователе.Пройдите через все из них и измените его так, чтобы пользователь не мог ввести значений там, где он не должен быть в состоянии.Если это означает сохранение данных в объекте сеанса, сделайте это.

6. Исправлены все уязвимости раскрытия информации

   Это относится к предыдущему пункту, но немного отличается.Если вы используете имя пользователя в URL-адресе, но не можете ничего изменить, изменив его, то это не уязвимость для инъекций, а просто проблема с раскрытием.Удалите их, но они не так критичны (в зависимости от того, что, конечно, раскрыто).

7. Исправьте вывод

   Исправьте проблемы с кодировкой и любой метод, который мог быгенерировать неверный вывод.При выводе убедитесь, что все в порядке.

Важно отметить, что все, что вы исправите , сделает приложение более безопасным.Если это живое приложение прямо сейчас, не ждите!Не пытайтесь делать все, тестируйте и выпускайте.Выберите цель разумного размера (максимум от 2 до 4 дней работы), завершите ее, протестируйте и отпустите.Затем промыть и повторить.Итерируя проблемы в этом поместье, вы делаете сайт более безопасным и безопасным.Это будет казаться вам менее трудоемким, потому что всегда есть конец.

Теперь, если приложение достаточно серьезное, оно может потребовать полного переписывания.Если это так, я бы по-прежнему предлагал очистить хотя бы большие элементы билета в существующем приложении до начала перезаписи.Прежде чем делать что-либо еще, устраните уязвимости SQL Injection, XSS и CSRF.

Это нелегко сделать.Но если сделать небольшой укус за раз, вы можете добиться значительного прогресса, оставаясь над водой ... Любая небольшая часть поможет, поэтому рассматривайте путешествие как последовательность шагов, а не как целое.В конце тебе будет лучше ...

Answer 2

Что ж, гугл по каждой из проблем поможет это исправить, поэтому я предполагаю, что вы просто беспокоитесь о реальных рисках.

1. Это легко исправить, просто измените на $_POST, что немного более безопасно, особенно при использовании с токенами сессии.
2. Это все еще широко используется, поэтому я не вижу проблемы?
3. Мех, до тех пор, пока эти данные проверяются на стороне сервера, и если они не проверяются, пользователь должен повторно войти или подобный, это приемлемо. Конечно, сеанс предпочтительнее, или даже куки.
4. Уборка - это просто долгая работа, никаких проблем, если только пароли и т. Д. Не обнаруживаются в JS. Css + html почти всегда не закодированы, так что это выглядит нормально.
5. Я просто не фанат всплывающих окон и никогда ими не пользуюсь, тут ничего не поделаешь.
6. Ну, если возможно, разместите сценарий локально и продезинфицируйте все необходимые XSS, убрав теги, URL, кодирующие подобные вещи.

Answer 3

Я столкнулся именно с такой ситуацией пару лет назад на веб-сайте электронной коммерции. Это было в ASP.NET 1.1 и было абсолютно ужасным с точки зрения качества кода и практики безопасности. Кроме того, мне сказали, что переписывание было совершенно исключено, и я не смог убедить их сдвинуться с места.

За 2 года мне удалось привести эту систему в соответствие с PCI-DSS. Это означает, что мы должны были закрыть все эти лазейки безопасности одну за другой и внедрить методы, чтобы избежать их повторения.

Первая проблема - вы должны найти все ошибки и недостатки безопасности. Вы можете использовать внешние инструменты обнаружения уязвимостей (я рекомендую QualysGuard ). Но ручное тестирование - единственный способ получить полное покрытие. Напишите старомодные тестовые сценарии для тестирования XSS, SQL-инъекций, CSRF и т. Д. И заручитесь поддержкой тестировщиков для выполнения этих сценариев. Если вы можете автоматизировать эти тесты, это стоит сделать. Но не избегайте освещения тестового примера только потому, что его слишком сложно автоматизировать. Если вы можете позволить себе консультантов по безопасности, попросите их помочь вам охватить охват тестированием и написать тестовые примеры.

Это даст вам: а) список ошибок / недостатков б) повторяемый способ проверить, действительно ли вы исправили каждый из них

Затем вы можете начать рефакторинг и исправить каждый недостаток.

Процесс, которому я следовал: Шаг 1: рефакторинг, шаг 2: тестирование и выпуск, шаг 3: вернуться к шагу 1. То есть Существует непрерывный цикл исправления, тестирования и выпуска. Я бы порекомендовал вам совершать регулярные развертывания в своих производственных системах, например ежемесячно и втисните в каждый цикл выпуска столько «рефакторингов», сколько сможете.

Я обнаружил, что автоматизированные средства безопасности практически бесполезны из-за: а) они могут дать вам ложное чувство безопасности б) они могут дать вам так много ложных срабатываний, что вы отправляетесь по бессмысленным касательным вместо того, чтобы работать с реальными угрозами безопасности.

Вам действительно нужно разобраться с характером каждой уязвимости безопасности и точно понять, как она работает. Хороший способ сделать это - исследовать каждый недостаток (например, начать с топ-10 OWASP) и написать документ, который вы могли бы дать любому разработчику в вашей команде, который объяснил бы им, какой именно недостаток вы пытаетесь защитить. против и почему. Я думаю, что слишком часто мы обращаемся к инструментам, чтобы помочь исправить недостатки безопасности, думая, что мы можем избежать усилий по-настоящему понять каждую угрозу. Вообще говоря, инструменты полезны только для повышения производительности - вам все равно нужно взять на себя ответственность и запустить шоу.

Ресурсы:

1) Читайте OWASP top 10 .

2) Спецификация PCI-DSS также очень полезна и помогает вам целостно думать о безопасности - то есть охватывает не только веб-приложения, но и базы данных, процессы, брандмауэр, разделение DMZ / LAN и т. Д. Даже если оно закончилось топ для ваших требований, его стоит посмотреть.