Когда вы принимаете ввод от пользователей своего веб-приложения, будь то через поле ввода, 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.

Удачного взлома!