От автора: азы CORS, CSP, HSTS и всех акронимов веб-безопасности для веб-разработчиков!
Существует много причин узнать про веб безопасность больше:
Вы обеспокоенный пользователь, который боится кражи своих персональных данных
Вы заинтересованный веб-разработчик, который хочет сделать свои веб-приложения более безопасными
Вы — веб-разработчик, ищущий работу, и хотите быть готовым к тому, что ваши интервьюеры зададут вам вопросы о безопасности в Интернете.
и так далее.
Ну, в этом посте мы объясним некоторые общие аббревиатуры веб-безопасности таким образом, который легко понять, но при этом точным.
Прежде чем мы это сделаем, давайте убедимся, что мы понимаем пару основных концепций безопасности.
Две основные концепции безопасности
Никто никогда не будет на 100% в безопасности.
Нет такого понятия, как 100-процентая защита от взлома. Если кто-нибудь когда-нибудь скажет вам это, они ошибаются.
Одного слоя защиты недостаточно.
Вы не можете просто сказать …
О, так как я реализовал CSP, я в безопасности. Я могу вычеркнуть межсайтовый скриптинг из списка уязвимостей своего сайта, потому что этого не может произойти сейчас.
Это вряд ли может быть, но легко поддаться искушению думать таким образом. Я думаю, что одна из причин, по которой программисты так думают заключается в том, что в кодировании все черно-белое, 0 или 1, истина или ложь. С безопасностью не все так просто.
Мы начнем с того, с чем все сталкиваются довольно рано в процессе веб-разработки.
Совместное использование ресурсов между разными источниками (Cross-Origin Resource Sharing — CORS)
Вы когда-нибудь получали ошибку, которая выглядела примерно так?
No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘null’ is therefore not allowed access.
Вы, конечно, в этом не одиноки. И тогда вы заходите в Google и ищете ответы, и кто-то говорит вам, что нужно установить это расширение, которое решит все ваши проблемы! Отлично, правда?
CORS предназначен для того, чтобы защитить вас, а не навредить вам!
Чтобы объяснить, как CORS помогает вам, давайте сначала поговорим о файлах cookie, в частности об аутентификационных файлах cookie. Аутентификационные файлы cookie используются, чтобы сообщить серверу, что вы вошли в систему, и они автоматически отправляются с любым запросом, который вы выполняете к этому серверу.
Допустим, вы вошли в систему Facebook, и они используют для аутентификации файлы cookie. Вы нажимаете на bit.ly/r43nugi, который перенаправляет вас на superevilwebsite.rocks. Скрипт в superevilwebsite.rocks выполняет клиентский запрос к facebook.com, который отправляет ваш файл cookie для аутентификации!
В мире без CORS они могут вносить изменения в ваш аккаунт, даже без вашего ведома. Затем они опубликуют bit.ly/r43nugi в вашей ленте, и все ваши друзья кликнут по этой ссылке, а затем bit.ly/r43nugi будет отправлено в ленты всех ваших друзей, и этот порочный круг расширится, пока весь мир не будет охвачен superevilwebsite.rocks.
Однако в мире CORS Facebook разрешает для редактирования данных на своем сервере только запросы с источником facebook.com. Другими словами, они ограничивают совместное использование ресурсов с помощью разных источников. Тогда вы можете спросить …
Ну может ли superevilwebsite.rocks просто изменить исходный заголовок на их запрос, чтобы он выглядело так, как будто он идет с facebook.com?
Они могут попробовать, но это не сработает, потому что браузер просто проигнорирует его и использует реальный источник.
Хорошо, но что, если superevilwebsite.rocks сделал запрос на стороне сервера?
В этом случае они могут обойти CORS, но они ничего не выиграют от этого, потому что не смогут отправить ваш cookie аутентификации. Скрипт должен выполняться на стороне клиента, чтобы получить доступ к вашим cookie на стороне клиента.
Политика безопасности контента (CSP)
Чтобы понять, что такое CSP, нам сначала нужно поговорить об одной из наиболее распространенных уязвимостей в Интернете: XSS, которая означает межсайтовый скриптинг (вау — еще одна аббревиатура).
XSS — это когда какой-то злой человек вводит JavaScript в ваш клиентский код. Вы можете подумать…
Что они собираются сделать? Изменить цвет с красного на синий?
Предположим, что кто-то успешно ввел JavaScript в клиентский код веб-сайта, который вы посещаете. Что они могут сделать, что навредит вам?
Они могут создать HTTP-запросы на другой сайт, притворяясь вами.
Они могут добавить тег ссылки, который отправляет вас на веб-сайт, который выглядит так же, как тот, с которым вы работаете, только его функции немного отличаются в худшую сторону.
Они могут добавить тег скрипта со встроенным JavaScript.
Они могут добавить тег скрипта, который откуда-то извлекает удаленный файл JavaScript.
Они могут добавить iframe, который перекрывает страницу и выглядит как часть веб-сайта, и в котором вам предлагается ввести пароль.
Возможности безграничны. CSP пытается предотвратить это, ограничивая:
что можно открыть в iframe
какие таблицы стилей можно загрузить
к чему могут быть выполнены запросы и т. д.
Итак, как это работает?
Когда вы нажимаете на ссылку или набираете URL-адрес веб-сайта в адресной строке браузера, ваш браузер выполняет GET-запрос. Он в конечном итоге пробивается к серверу, который обслуживает HTML вместе с некоторыми HTTP-заголовками. Если вам интересно, какие заголовки вы получаете, откройте вкладку «Сеть» в консоли и посетите любые веб-сайты.
Вы можете увидеть заголовок ответа, который выглядит так:
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Это политика безопасности контента на facebook.com. Давайте переформатируем этот код, чтобы его было легче читать:
content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Теперь давайте разложим директивы.
default-src ограничивает все другие директивы CSP, которые явно не указаны.
script-src ограничивает скрипты, которые могут быть загружены.
style-src ограничивает таблицы стилей, которые могут быть загружены.
connect-src ограничивает URL-адреса, которые могут быть загружены с использованием интерфейсов скриптов, XHR, ajax и т. д.
Обратите внимание, что здесь гораздо больше директив CSP, чем эти три. Браузер прочитает заголовок CSP и применит эти директивы ко всему в HTML-файлу, который был доставлен. Если директивы установлены надлежащим образом, они допускают только то, что необходимо.
Если заголовка CSP нет, тогда все разрешено, и ничего не ограничено. Везде, где вы видите *, это шаблон. Вы можете представить себе *, как замену на что угодно, и это будет разрешено.
HTTPS или HTTP Secure
Конечно, вы слышали о HTTPS. Возможно, вы слышали, как говорят некоторые люди …
Зачем мне обращать внимание на HTTPS, если я просто играю на сайте в игру.
Или, может быть, вы слышали другую сторону…
Вы сумасшедший, если на вашем сайте нет HTTPS. Это 2018 год! Не доверяйте никому, кто говорит иначе.
Возможно, вы слышали, что Chrome теперь будет помечать сайт как небезопасный, если на нем нет HTTPS.
По своей сути HTTPS довольно прост. HTTPS зашифрован, а HTTP — нет. Так почему это важно, если вы не отправляете конфиденциальные данные? Приготовьтесь к другому сокращению… MITM, что означает «Человек в середине».
Если вы используете в кафе общественный Wi-Fi без пароля, для кого-то очень просто сделать так, что он будет действовать, как ваш роутер, чтобы все запросы и ответы проходили через него. Если ваши данные не зашифрованы, они могут делать с ними все, что захотят. Они могут редактировать HTML, CSS или JavaScript, прежде чем те попадут в ваш браузер. Учитывая то, что мы знаем о XSS, вы можете себе представить, насколько это плохо.
Хорошо, но как получается, что мой компьютер и сервер знают, как шифровать / расшифровывать, а этот MITM не знает?
Вот где в дело вступает протокол SSL (Secure Sockets Layer), а в последнее время TLS (Transport Layer Security). TLS взяла на себя роль SSL в 1999 году в качестве технологии шифрования, используемой в HTTPS. Конкретно то, как работает TLS, выходит за рамки этой публикации.
HTTP Strict-Transport-Security (HSTS)
Это довольно просто. Давайте снова используем заголовок Facebook:
strict-transport-security: max-age=15552000; preload
max-age указывает, как долго браузер должен помнить, что должен заставить пользователя получить доступ к веб-сайту через HTTPS.
preload не важен для наших целей. Это сервис, размещенный Google, а не часть спецификации HSTS.
Этот заголовок применяется только в том случае, если вы получили доступ к сайту с помощью HTTPS. Если вы получили доступ к сайту через HTTP, заголовок игнорируется. Причина в том, что HTTP настолько небезопасен, что ему нельзя доверять.
Давайте используем пример Facebook, чтобы еще раз пояснить, насколько это полезно на практике. Вы впервые заходите на facebook.com, и знаете, что HTTPS безопаснее, чем HTTP, поэтому вы обращаетесь к нему через HTTPS, https://facebook.com. Когда ваш браузер получает HTML-код, он получает и заголовок, который указывает вашему браузеру принудительно перенаправить вас на HTTPS для будущих запросов. Через месяц кто-то отправит вам ссылку на Facebook с HTTP, http://facebook.com, и вы нажмете на нее. Поскольку один месяц меньше, чем 15552000 секунд, указанных в директиве max-age, ваш браузер отправит запрос в виде HTTPS, предотвращая потенциальную MITM-атаку.
Заключение
Веб-безопасность важна независимо от того, на какой стадии процесса веб-разработки вы находитесь. Чем больше вы уделяете этому внимания, тем лучше. Безопасность — это то, что должно быть важно для всех, а не только для людей, у которых это явно указано в названии их должности!
Автор: Austin Tackaberry
Источник: https://medium.freecodecamp.org/
Редакция: Команда webformyself.