Когда вы принимаете ввод от пользователей своего веб-приложения, будь то через поле ввода, API или другими способами, вы рискуете открыть себя для злонамеренных пользователей, которые хотят вмешаться в ваше приложение.
Взгляните на следующий пример кода:
В этом примере мы переводим деньги с одного аккаунта на другой. Это один из самых канонических примеров, используемых для иллюстрации недостатков санитарной обработки. Если злонамеренный пользователь находит способ вызвать функцию transferMoney
от имени другого пользователя (через что-то вроде XSS), то у целевого пользователя не хватает той суммы денег, которую он указал (по крайней мере, до тех пор, пока их банковский счет не иссякнет). Эта функция может быть связана с кнопкой в вашем приложении или быть частью поля ввода на странице транзакции; Тем не менее, это серьезная проблема и приводит ко многим другим проблемам.
Вы можете исправить подобные проблемы, очистив и проверив вводимые пользователем данные, чтобы убедиться, что они соответствуют ожиданиям вашего приложения. В этом примере вы можете проверить, что экземпляр User
, вызывающий transferMoney
, разрешил переводы на учетную запись, указанную параметром accountID
.
Для дальнейшего изучения: Статья OWASP о проверке данных, Экспресс-валидатор и Узел-валидатор (для проверки на стороне сервера и на стороне клиента).
Установите защиту с помощью заголовков HTTP
Заголовки HTTP - это биты запросов, которые отправляются каждый раз, когда вы вызываете API с HTTP-клиентом, и при правильном применении они могут фактически обеспечить дополнительную защиту безопасности.
Для этого создана библиотека Шлем. Вы можете применять защиту от XSS, утечки информации (например, утечки типов MIME ваших запросов) и принудительного закрепления открытого ключа (что повышает надежность ваших HTTPS-сайтов).
Использовать HTTPS в производстве
В 2017 году это несложно. Теперь Google не только повысит рейтинг сайтов, если они будут защищены этим красивым зеленым замком в верхнем левом углу браузера, но и ваши пользователи будут больше доверять вам. Самое главное, если вы когда-либо обрабатываете конфиденциальные данные пользователя или даже входите в систему с кем-то в своей службе, вам понадобится HTTPS.
Вы можете получить бесплатные сертификаты от Let's Encrypt или просто направить свой трафик через CloudFlare и получить все преимущества размещения статических файлов за CDN и их бесплатных сертификатов HTTPS, применяемых к вашему сайту.
Боковое примечание: Вы также можете увидеть упоминание SSL или TLS при упоминании HTTPS. SSL и TLS - это реализации протокола, которые обеспечивают шифрование и целостность данных поверх протокола HTTP.
Аутентифицируйте пользователей с помощью надлежащих механизмов
Выполняя аутентификацию для пользователей, не запускайте собственную аутентификацию, если можете. В 99% случаев подойдет такая библиотека, как PassportJS, у которой есть более 300 способов аутентификации пользователей, от аутентификации Facebook до чистого OAuth 2.0.
Обработка файлов cookie
Если вы храните конфиденциальные данные в файлах cookie, к которым можно получить доступ с помощью XSS-атак (которые происходят, когда вы не дезинфицируете ввод пользователя), рассмотрите возможность установки флагов HttpOnly
(не разрешает доступ к файлам cookie через клиентский JavaScript) и secure
(отправлять файлы cookie только через HTTPS) для ваших файлов cookie. Для этого вы можете использовать библиотеку cookie-session.
Безопасность не должна быть сложной
Теперь, когда вы знаете несколько полезных советов, чтобы начать работу с безопасностью своих приложений JavaScript, приступайте к реализации некоторых из них и дайте мне знать, как это происходит!
Вы можете связаться со мной в любое время через Twitter или напишите мне, и я буду рад поболтать. Если вам нужна еще более подробная презентация о безопасности в JavaScript, ознакомьтесь с моей презентацией на популярной конференции по JavaScript и Node.js Nodevember.
Удачного взлома!