Наша команда разработчиков рассматривала возможность использования Node.js для нового корпоративного приложения, которое требует высокого уровня безопасности. Среди пользователей есть федеральная полиция, поэтому высока вероятность того, что нас в конечном итоге проверит на предмет безопасности.
Я ценю помощь.
Редактировать: некоторые пользователи StackOverflow предложили использовать обратный прокси, но мне любопытно, есть ли у кого-нибудь еще предложения.
Хотя я не могу указать на какие-либо конкретные обнаруженные дефекты, я бы нервничал по поводу архитектуры node.js - где ваш код работает как часть кода веб-сервера. Хотя с чем-то вроде mod_php все еще есть только один процесс, обрабатывающий как HTTP, так и логический уровень, существует четкое функциональное разделение между двумя, а интерфейс между веб-сервером и логическим уровнем был специально разработан и протестирован для устранения сбоев. - особенно на логическом уровне.
Кроме того, для веб-серверов (в частности, Apache) доступно множество инструментов, которые облегчают управление и (при правильном использовании) повышают безопасность.
Еще одно важное соображение - наличие навыков / поддержки / обучения - независимо от его качества / полезности, node.js многое предстоит сделать по сравнению с другими платформами веб-разработки.
Наша команда разработчиков рассматривала возможность использования Node.js
То, что вы специально пытаетесь предоставить то, что должно быть очень безопасным приложением на платформе, с которой (судя по вашему заявлению выше) вы не до конца знакомы, кажется очень безрассудным. Большинство уязвимостей безопасности в веб-приложениях возникает не из-за сбоев в среде разработки, а из-за ошибок в специально добавленном коде.
Безусловно, использование обратного прокси-сервера облегчит получение стандартного протокола HTTP, обнаружение аномалий и уменьшит влияние атак на уровне протокола.
Один из лучших инструментов для создания безопасных веб-приложений - это mod_security - AFAIK, это доступно только для запуска в Apache, но это даст возможность (вместе с mod_proxy) развертывания интерфейсной системы, обеспечивающей обычные функции веб-сервера (ведение журнала, статический контент) вместе, скажем, со службами аутентификации, и использование node.js в качестве бэкэнда.
В основном это помогает с параллелизмом, если этот параллелизм связан с вводом-выводом, как вы, вероятно, знаете.
Вариант, который намного быстрее, чем NodeJS, - это использование mono + F # и его поддержки async. Затем вы можете использовать HttpListener, чтобы приблизиться к сокету, как с NodeJS.
Не обращая внимания на выбор выше; SELinux и chroot, вероятно, являются хорошими инструментами для остальных.
По моему опыту, большинство уязвимостей безопасности в коде, которые приводят к выполнению произвольного кода, связаны либо с плохими разрешениями на запись в базу данных / диск, позволяющими запрашивать файлы, которые вы загрузили, либо с неуправляемым кодом, который выполняет плохое управление памятью / проверку границ.
Обратный прокси - тоже хороший вариант, потому что они надежны в боях. HAProxy например - он может обрабатывать как WebSockets, так и обычный HTTP в своих последних версиях.
Затем вы можете использовать некоторые инструменты для фактического тестирования реализации. Google использует инструмент skipfish: https://code.google.com/p/skipfish/
Вы можете использовать фаззер на уровне протокола, а также на уровне приложения, но это становится все менее и менее важным, чем больше доказывает вам ваш компилятор, например, с JS, где вы не можете изменить тип экземпляра объекта или F #, где у вас есть более статическая проверка, например различаемые союзы и единицы измерения.
Наконец, если вам нужна действительно высокая безопасность кода, я бы порекомендовал Stact Framework с Haskell, который вы можете сделать очень безопасным с помощью компилятора. С Haskell вы даже можете писать небольшие доказательства с помощью Coq, помощника по доказательству или Agda (см. Средства доказательства теорем Haskell)
Для связи с вашими серверами вам, вероятно, понадобится DNS. Вам также необходимо защитить это с помощью DNSSec, иначе вы можете получить отравление DNS.
Если они получат доступ к локальной сети, вы можете получить ARP Poisioned, что означает, что кто-то может украсть ваши IP-адреса; но вы можете настроить DNS-сервер на статическое обслуживание всех, кто находится в сети, в таблице поиска IP-to-MAC, которую также проверяют все хосты.
Наконец, вы можете добавить IDS, например Фырканье в вашу сеть и запишите «нормальное» выполнение вашей программы, чтобы вы также могли реагировать на аномалии.
В идеале все приложение должно быть ограничено либо интрасетью, либо VPN, либо по крайней мере IP-адрес клиента, особенно если он будет использоваться каким-либо федеральным служащим. Если злоумышленник не может даже попасть на веб-сервер, то он точно не сможет использовать Node.js, верно?