Краткое вступление в веб-безопасность

kratkoe vstuplenie v veb bezopasnost

Учебное пособие для веб-разработчиков по CORS, CSP, HSTS и всем аббревиатурам веб-безопасности!

Есть много причин узнать о веб-безопасности, например:

  • Вы озабочен пользователь, который озабочен утечкой ваших личных данных
  • Вы заинтересован веб-разработчик, который хочет сделать свои веб-приложения более безопасными
  • Вы веб-разработчик, претендующий на вакансии, и вы хотите быть готовым, если ваши интервьюеры зададут вам вопрос о веб-безопасности

и так дальше.

В этой публикации будут объясняться некоторые распространенные аббревиатуры веб-безопасности простой для понимания, но все еще точный способ.

Прежде чем это сделать, убедитесь, что мы понимаем несколько основных концепций безопасности.

Две основные концепции безопасности

Никто никогда не застрахован на 100%.

Нет понятия о 100% защите от взлома. Если кто-то скажет вам это, он ошибается.

Одного слоя защиты недостаточно.

Вы не можете просто сказать…

О, поскольку я внедрил CSP, я в безопасности. Я могу вычеркнуть межсайтовые сценарии из своего списка уязвимостей, потому что сейчас это не может произойти.

Возможно, кому это и дано, но легко найти себя так думать. Я считаю, что одна из причин, почему программисты могут легко найти себя в таком мышлении, состоит в том, что большая часть кодирования черно-белая, 0 или 1, истина или неправда. Безопасность не так просто.

Мы начнем с того, с которым каждый сталкивается рано на своем пути веб-разработки. А потом вы посмотрите на StackOverflow и найдете кучу ответов, рассказывающих, как его обойти.

Общий доступ между разными источниками (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 на временной шкале всех ваших друзей, а затем цикл продолжается по злостной схеме вширь, которая завоевывает всех пользователей Facebook, и мир поглощается superevilwebsite.rocks. ?

Однако в мире CORS Facebook разрешал бы только запросы с происхождением facebook.com редактировать данные на своем сервере. Другими словами, они ограничивают обмен между источниками ресурсов. Тогда вы можете спросить…

Может ли superevilwebsite.rocks просто изменить исходный заголовок по их запросу, чтобы он выглядел так, будто он поступает с facebook.com?

Они могут попробовать, но это не сработает, потому что браузер будет просто игнорировать это и использовать настоящее происхождение.

Хорошо, но что если superevilwebsite.rocks сделал запрос на стороне сервера?

В этом случае они могут обойти CORS, но они не выиграют, потому что не смогут отправить ваш аутентификационный файл cookie для поездки. Сценарий должен выполняться на стороне клиента, чтобы получить доступ к файлам cookie на стороне клиента.

Политика безопасности содержимого (CSP)

Чтобы понять CSP, нам сначала нужно поговорить об одной из самых распространенных уязвимостей в Интернете: XSS, что означает межсайтовый скрипт (yay – другая аббревиатура).

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:*  *.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:*  *.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-адреса, которые можно загрузить с помощью интерфейсов сценариев, поэтому fetch, 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.

Завершающие мнения

Веб-безопасность важна вне зависимости от того, где вы находитесь на своем пути веб-разработки. Чем больше вы будете подвергать себя этому, тем лучше вам будет. Безопасность – это то, что должно быть важно для всех, а не только для людей, которые четко указали это в должности! ?

Добавить комментарий

Ваш адрес email не будет опубликован.