Опасность использования стороннего кода JavaScript из npm (или другого диспетчера пакетов) заключается в том, что используемая вами библиотека или одна из ее зависимостей могут содержать гнусные биты. Есть даже вероятность, что код, который вы видите на GitHub, не соответствует предварительно скомпилированному коду library.min.js, который будет использовать npm. Вся надежда потеряна? Надо ли кодировать все вручную? Отказываемся ли мы от JavaScript из-за этого? А как насчет других языков и других сред?
Я пишу это в ответ на статью Дэвида Гилбертсона под названием Я собираю номера кредитных карт и пароли с вашего сайта. Вот как." Это сенсационный материал, который должен прочитать каждый разработчик веб-сайтов. Обязательно прочтите также часть 2, которая так же важна для чтения, как и описывает действия, которые вы можете предпринять для защиты ваших критически важных данных, а также здоровую дозу «не покидать корабль.
У меня возникло желание прокомментировать, когда я прочитал ответ на эту оригинальную статью. Ответ содержал:
Я думаю, что это самая большая проблема. Открытый исходный код должен означать, что любой может проверять код, какой смысл, если такие вещи станут обычной практикой, и никто не сможет этого сделать?
Общее, глобальное беспокойство
Во-первых, это касается не только JavaScript. У большинства языков есть сторонние библиотеки, и у многих есть менеджеры библиотек, чтобы облегчить их приобретение. Это проблема любого языка. Большинство, если не все, серьезные программные пакеты на каждой платформе и везде используют сторонние библиотеки. Это серьезно относится к каждому программному пакету, который когда-либо распространялся.
Это правда: проекты с открытым исходным кодом могут проверяться кем угодно, и это может обеспечивать более высокий уровень проверки, и, следовательно, улучшенная безопасность по сравнению с программным обеспечением с закрытым исходным кодом. Однако история доказала, что такая реальность случается редко, если вообще когда-либо. Многие ключевые проекты с открытым исходным кодом живут с серьезными дырами в безопасности (иногда десятилетиями!): OpenSSL, OpenSSH, Bash и другие! Дефекты безопасности в коде, которые были открыты для всеобщего обозрения и поэтому вызывали большее доверие, чем программное обеспечение с закрытым исходным кодом.
По сути, речь идет о доверии. Нам нужен какой-то способ проверить надежность используемых библиотек. Вопрос в том, как? Очевидно, что, судя по исходной статье, нельзя согласовать доверие с количеством загрузок. Метры? Нет, это не даст ничего, кроме понимания популярности - хотя для каждого модуля количество оценок будет намного меньше, чем количество загрузок. Возможно, нам нужен блокчейн доверия сторонней библиотеки! Ладно, я бросил туда ради забавы - даже если в этом что-то есть. По правде говоря, у меня нет ответа, и я не знаю, есть ли у кого-нибудь на самом деле.
Проблема доверия к программному обеспечению - это та проблема, которую Microsoft и Apple (и другие!) Пытались решить в своих операционных системах в течение многих лет - в основном, переходя к более жесткому контролю над тем, какое программное обеспечение будет запускаться по умолчанию. На сегодняшний день они в основном решили эту проблему с помощью подписи кода с более строгими требованиями к коду драйвера ядра, чем к коду приложения. Несмотря на то, что эти улучшения имеют большое значение, вредоносный код по-прежнему ежедневно попадает на вычислительные устройства. Это доверие так же хорошо, как и проверка, проводимая для организаций, которым разрешено подписывать код. Даже если эти сущности не являются злонамеренными, беззаботное использование стороннего кода может вызвать проблемы в бэкдоре из-за надежности разработчиков.
Я согласен с мнением автора в его втором сообщении: вам не нужно прекращать использование сторонних библиотек и терять всякую надежду. Вам нужно работать умнее и с повышенным скептицизмом. Как сообщество разработчиков в целом, независимо от языков и платформ, мы должны работать вместе, чтобы решить проблему доверия - каким бы это ни было решение.
Ответ, сфокусированный на JavaScript
У меня есть кое-что сказать в ответ на специфические проблемы JavaScript. npm ... Мы не должны разрешать автоматическое использование предварительно скомпонованных миниатюрных версий библиотеки. После установки пакета npm должен собрать и связать его. То, что он этого не делает, является фундаментальной ошибкой. Установка модуля может быть медленнее, но уверенность в том, что то, что вы используете, это то, что вы видите в репозитории, стоит дополнительного времени. Возможно, удастся написать инструмент для сканирования предварительно собранных версий, которые не соответствуют ожидаемому источнику.
Далее, пожалуйста, прекратите использовать каждую маленькую библиотеку, потому что это кажется крутым. Когда я работал над своей Стартовой архитектурой JavaScript для общего веб-сайта, я специально принял сознательное решение, что код, который я буду использовать на своем сайте, не будет использовать кучу сторонних библиотек. В худшем случае планирую использовать несколько полифиллов. В первую очередь это было сделано из-за желания сохранить небольшой размер JavaScript, но нельзя упускать из виду дополнительное преимущество, заключающееся в том, что его легче проверять.
Заключение
Нам всем нужно больше думать об этом. Это все, что я могу сделать на данный момент. Подумайте об этом больше и продолжайте говорить об этом.
