Семь шагов для создания безопасного веб-приложения. Часть 2

Эта статья является продолжением предыдущей статьи, которая находится здесь.

Шаг 3: Кодирование отображаемого кода для предотвращения межсайтового скриптинга

Межсайтовый скриптинг (XSS) или, JavaScript-инъекция, может использоваться для кражи данных, взлома сайта, сканирования сети, подрыва защиты от межсайтовой подделки запросов CSRF, перенаправления/фишинга сайта, загрузки произвольного JavaScript кода c удаленного хостинга, имитации нажатия клавиш, скрытого наблюдения за пользователями. Хакеры используют XSS все чаще и чаще.
Кодирование / экранирование выводимого текста - это важнейшая технология безопасного программирования, необходимая для предотвращения XSS. Оно выполняется при формировании ответа сервером.

Шаг 4: Политика безопасности контента

Политика безопасности контента (Content Security Policy) - это новый стандарт для браузеров. Идея заключается в создании стандартизованной структуры , которая остановит XSS на уровне браузера с минимальным участием разработчиков.
Чтобы политика безопасности контента была эффективной, весь JavaScript, встроенный в HTML, должен быть удален и развернут в отдельном внешнем файле JavaScript. С этого момента, если браузер, поддерживающий политику безопасности контента, обнаруживает JavaScript, встроенный в документ HTML, например, в случае, если хакер пытается вставить кусок такого кода, то данное действие отклоняется. Подобное поведение браузеров предотвращает многие формы XSS атак.

Шаг 5: Межсайтовая подделка запросов

Допустим, пользователь зашел на сайт, которым он пользуется каждый день. Затем он открыл другую вкладку, в которой, запустил сайт, который содержит какой-то вредоносной код. После с этого плохого сайта может быть совершен поддельный запрос на хороший сайт, которым наш пользователь пользуется каждый день. Хакер воспользуется тем фактом, что пользователь уже вошел в систему на хорошем сайте и посредством вредоносного кода, будет отправлять фальшивые запросы, которые могут нанести вред пользователю - например, списать деньги с банковского онлайн счета.

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

Шаг 6: Многофакторная аутентификация

Пароли, как единый фактор аутентификации, очень плохое решение. Лучшим решением для проверки подлинности пользователя является двухфакторная (2FA) или даже многофакторная аутентификация (MFA). Технология 2FA/MFA изо всех сил пыталась завоевать популярность в прошлом, но всегда уступала из-за нецелесообразности всегда носить второе устройство только для проверки личности пользователя. Однако, к счастью, мобильные устройства быстро стали популярным элементом в данной системе. Плюс к этому, сейчас уже многие веб-сайты и другие онлайн-сервисы предлагают многофакторную аутентификацию.

Шаг 7: Принципы безопасности при восстановлении паролей

Многие сайты позволяют пользователю запрашивать существующий или даже новый пароль путем его отправки на зарегистрированный адрес электронной почты с небольшой проверкой. Более безопасный процесс будет заключаться в следующем:

• Проверить идентификацию с помощью ключевых вопросов безопасности.
• Отправить пользователю случайно сгенерированный токен, через SMS например.
• Проверить код в том же веб-сеансе и применить политику блокировки.
• Изменить пароль.

Такой подход сильно усложнит работу взломщикам и даст время на исправление уязвимостей.

Конечно, то о чем я рассказал вам в данных двух статьях не искоренит полностью каждую уязвимость , но поможет значительно улучшить онлайн-сервисы и приложения.

На этом пока все. Всего доброго и успехов в деле защиты ваших сайтов!