Давайте начнем серию статей о безопасности веб-приложений с объяснения того, что делают браузеры и как именно они это делают. Поскольку большинство ваших клиентов будут взаимодействовать с вашим веб-приложением через браузеры, необходимо понимать основы работы этих замечательных программ.
Хром и Рысь
Браузер механизм рендеринга .
Его задача — загрузить веб-страницу и представить ее в удобочитаемом виде.
Хотя это почти преступное упрощение, это все, что нам нужно знать на данный момент.
- Пользователь вводит адрес в строку ввода браузера.
- Браузер загружает «документ» с этого URL-адреса и отображает его.
Lynx основан на тех же принципах, что и любой другой «основной» браузер.
Пользователь вводит веб-адрес (URL), браузер загружает документ и отображает его — с той лишь разницей, что lynx использует не механизм графического рендеринга, а текстовый интерфейс, благодаря которому сайты, подобные Google, выглядят следующим образом: 
Общее представление о том, что делает браузер, мы имеем, но давайте подробнее рассмотрим действия, которые выполняют для нас эти гениальные приложения.
Что делает браузер?
Короче говоря, работа браузера в основном состоит из- Разрешение DNS
- HTTP-обмен
- Рендеринг
- Сбросить и повторить попытку
Разрешение DNS
Этот процесс помогает браузеру узнать, к какому серверу ему следует подключиться, когда пользователь вводит URL-адрес.Браузер связывается с DNS-сервером и обнаруживает, что google.com соответствует набору чисел 216.58.207.110 — IP-адрес, к которому может подключиться браузер.
HTTP-обмен
Как только браузер определит, какой сервер будет обслуживать наш запрос, он установит с ним TCP-соединение и начнет HTTP-обмен .Это не что иное, как способ связи браузера с нужным ему сервером, а также ответа сервера на запросы браузера.
HTTP — это просто название самого популярного протокола для общения в Интернете, и браузеры чаще всего выбирают HTTP при общении с серверами.
HTTP-обмен означает, что клиент (наш браузер) отправляет запрос , и сервер отправляет отвечать .
Например, после успешного подключения браузера к серверу, обслуживающему google.com он отправит запрос, который выглядит следующим образом
Давайте рассмотрим запрос построчно:GET / HTTP/1.1 Host: google.com Accept
- ПОЛУЧИТЬ / HTTP/1.1 : В этой первой строке браузер запрашивает сервер получить документ из местоположения.
/ , добавив затем, что остальная часть запроса будет выполняться по протоколу HTTP/1.1 (или вы также можете использовать версию 1.0 или 2)
- Хост: google.com : это единственный HTTP-заголовок, требуемый протоколом HTTP/1.1. .
Поскольку сервер может обслуживать несколько доменов (google.com, google.co.uk и т. д.), клиент здесь упоминает, что запрос был для этого конкретного хоста.
- Принимать: */* : необязательный заголовок, который сообщает браузеру серверу, что он примет любой ответ. Сервер может иметь ресурс, доступный в форматах JSON, XML или HTML, поэтому он может выбрать любой формат, который предпочитает.
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.
google.com; HttpOnly
<!doctype html><html">
.
.
</html>
Ух ты, на этот раз довольно много информации, которую нужно переварить.
Сервер сообщает нам, что запрос выполнен успешно ( 200 ОК ) и добавляет к Я отвечу несколько заголовков, из которых, например, можно узнать, какой сервер обработал наш запрос ( Сервер: gws ), какова политика X-XSS-Защита этот ответ и так далее и тому подобное.
Прямо сейчас вам не нужно понимать каждую строчку в ответе.
Позже в этой серии статей мы поговорим подробнее о протоколе HTTP, его заголовках и т. д.
На данный момент все, что вам нужно знать, это то, что клиент и сервер взаимодействуют и делают это через протокол HTTP.
Рендеринг
И последнее, но не менее важное: процесс рендеринга.
Насколько хорош браузер, если единственное, что он показывает пользователю, — это список забавных символов? <!doctype html><html">
.
.
</html>
В теле отвечать сервер включает представление запрошенного документа согласно заголовку Тип содержимого .
В нашем случае тип контента был установлен на текст/html , поэтому мы ожидаем в ответе HTML-разметку — и именно ее мы находим в теле документа.
Именно здесь браузер действительно проявляет себя.
Он читает и парсит HTML-код, загружает дополнительные ресурсы, включенные в разметку (например, могут быть указаны для загрузки файлы JavaScript или CSS-документы) и максимально быстро представляет их пользователю.
Еще раз повторюсь, конечный результат должен быть чем-то доступным восприятию среднестатистического Васи.
Если вы хотите более подробное объяснение того, что на самом деле происходит, когда мы нажимаем Enter в адресной строке браузера, я бы посоветовал прочитать статью "Что происходит, когда…" , очень тщательная попытка объяснить механизмы, лежащие в основе этого процесса.
Поскольку это эпизод, посвященный безопасности, я собираюсь дать подсказку о том, что мы только что узнали: злоумышленники легко зарабатывают на жизнь.
уязвимости в HTTP-коммуникациях и рендеринге .
Уязвимости, злонамеренные пользователи и другие фантастические звери существуют и в других местах, но применение более эффективного подхода к обеспечению защиты на этих уровнях уже позволит вам добиться прогресса в улучшении вашего состояния безопасности.
Продавцы
4 самых популярных браузера принадлежат разным производителям:- Гугл Хром
- Firefox от Mozilla
- Сафари от Apple
- Эдж от Microsoft
W3C является краеугольным камнем разработки стандартов, но браузеры часто разрабатывают свои собственные функции, которые в конечном итоге становятся веб-стандартами, и безопасность не является исключением.
Например, в Chrome 51 появился Файлы cookie SameSite — это функция, позволяющая веб-приложениям избавиться от определенного типа уязвимости, известной как CSRF (подробнее об этом позже).
Другие производители решили, что это хорошая идея, и последовали ее примеру, в результате чего подход SameSite стал веб-стандартом: Safari в настоящее время является единственным широко используемым браузером.
Без поддержки файлов cookie SameSite .
Это говорит нам о двух вещах:
- Похоже, Safari недостаточно заботится о безопасности своих пользователей (шучу: файлы cookie SameSite будут доступны в Safari 12, который, возможно, уже был выпущен к моменту, когда вы читаете эту статью).
- Исправление уязвимости в одном браузере не означает, что все ваши пользователи в безопасности.
При разработке веб-приложений нам необходимо не только убедиться, что они выглядят одинаково в разных браузерах, но и обеспечить одинаковую защиту для наших пользователей на разных платформах.
Ваша стратегия онлайн-безопасности будет зависеть от того, какие возможности предоставляет вам поставщик браузера.
В настоящее время большинство браузеров поддерживают один и тот же набор функций и редко отклоняются от общего плана действий, но случаи, подобные приведенному выше, все еще случаются, и это то, что мы должны учитывать при определении нашей стратегии безопасности.
В нашем случае, если мы решим, что будем смягчать атаки CSRF только с помощью файлов cookie SameSite, нам нужно знать, что мы подвергаем риску наших пользователей Safari. И наши пользователи тоже должны это знать.
И последнее, но не менее важное: вы должны помнить, что вы можете решить, поддерживать ли ту или иную версию браузера или нет: поддержка каждой версии браузера будет непрактичной (вспомните Internet Explorer 6 xpro).
В любом случае, сильная поддержка нескольких последних версий основных браузеров обычно является хорошей идеей.
Однако если вы не планируете обеспечивать защиту на конкретной платформе, вашим пользователям настоятельно рекомендуется знать об этом.
Совет профессионала : Никогда не следует поощрять своих пользователей использовать устаревшие браузеры или активно их поддерживать.Даже если вы приняли все необходимые меры предосторожности, другие веб-разработчики этого не сделали.
Поощряйте пользователей использовать последнюю поддерживаемую версию одного из основных браузеров.
Вендор или стандартный баг?
Тот факт, что средний пользователь получает доступ к нашему приложению через стороннее клиентское программное обеспечение (браузер), добавляет еще один уровень сложности на пути к комфортному и безопасному просмотру веб-страниц: сам браузер может быть источником уязвимости безопасности.Поставщики обычно предоставляют вознаграждение (также известное как вознаграждение за обнаружение ошибок) исследователям безопасности, которые могут искать уязвимости в самом браузере.
Эти ошибки связаны не с вашим веб-приложением, а с тем, как сам браузер обеспечивает безопасность.
Например, Программа вознаграждений Chrome позволяет исследователям безопасности связываться с командой безопасности Chrome и сообщать об обнаруженных ими уязвимостях.
Если уязвимость подтвердится, будет выпущен патч и, как правило, выдано уведомление о безопасности, а исследователь получит вознаграждение (обычно финансовое) от программы.
Такие компании, как Google, вкладывают довольно много капитала в свои программы поиска ошибок, поскольку это позволяет компаниям привлекать большое количество исследователей, обещая им финансовые выгоды, если они обнаружат какие-либо проблемы с программным обеспечением, которое они тестируют. С программой Bug Bounty выигрывают все: поставщик улучшает безопасность своего программного обеспечения, а исследователи получают деньги за свои выводы.
Мы обсудим эти программы позже, поскольку я считаю, что инициативы Bug Bounty заслуживают отдельного раздела в сфере безопасности.
Джейк Арчибальд — разработчик защитник " в Google, который обнаружил уязвимость, затрагивающую несколько браузеров.Он задокументировал свои усилия по ее обнаружению, процесс обращения к различным поставщикам, затронутым этой уязвимостью, и реакцию представителей поставщиков в интересный пост в блоге , который я рекомендую вам прочитать.
Браузер для разработчиков
К этому моменту мы должны были понять очень простую, но весьма важную концепцию: браузеры — это всего лишь HTTP-клиенты, предназначенные для обычного пользователя Интернета.Браузеры определенно более мощны, чем простой HTTP-клиент для какой-либо платформы (например, помните, что NodeJS имеет зависимость от «http»), но, в конце концов, они «просто» продукт естественной эволюции более простых HTTP-клиентов.
Что касается разработчиков, наш HTTP-клиент, вероятно, КУЛЬ от Дэниела Стенберга, одна из самых популярных программ, которые веб-разработчики используют каждый день.
Это позволяет нам выполнять HTTP-обмен «на лету», отправляя HTTP-запрос из командной строки: $ curl -I localhost:8080
HTTP/1.1 200 OK
server: ecstatic-2.2.1
Content-Type: text/html
etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
last-modified: Fri, 20 Jul 2018 11:20:35 GMT
cache-control: max-age=3600
Date: Fri, 20 Jul 2018 11:21:02 GMT
Connection: keep-alive
В приведенном выше примере мы запросили документ по адресу локальный хост: 8080/ , и локальный сервер успешно на него ответил.
Вместо того, чтобы выгружать тело ответа в командную строку, мы использовали флаг -Я , который сообщает cURL, что нас интересуют только заголовки ответов.
Сделав еще один шаг вперед, мы можем указать cURL выдать немного больше информации, включая фактический запрос, который он делает, чтобы мы могли лучше рассмотреть весь этот HTTP-трафик.
Вариант, который мы должны использовать: -v ( подробный , подробнее): $ curl -I -v localhost:8080
* Rebuilt URL to: localhost:8080/
* Trying 127.0.0.1.
* Connected to localhost (127.0.0.1) port 8080 (#0)
> HEAD / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< server: ecstatic-2.2.1
server: ecstatic-2.2.1
< Content-Type: text/html
Content-Type: text/html
< etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
< last-modified: Fri, 20 Jul 2018 11:20:35 GMT
last-modified: Fri, 20 Jul 2018 11:20:35 GMT
< cache-control: max-age=3600
cache-control: max-age=3600
< Date: Fri, 20 Jul 2018 11:25:55 GMT
Date: Fri, 20 Jul 2018 11:25:55 GMT
< Connection: keep-alive
Connection: keep-alive
<
* Connection #0 to host localhost left intact
Примерно такая же информация доступна в популярных браузерах через их DevTools.
Как мы уже видели, браузеры — это не что иное, как сложные HTTP-клиенты.
Конечно, они добавляют огромное количество функций (например, управление учетными данными, создание закладок, история и т. д.), но правда в том, что они были рождены как HTTP-клиенты для людей.
Это важно, поскольку в большинстве случаев вам не нужен браузер для проверки безопасности вашего веб-приложения, когда вы можете просто «покурить» и посмотреть ответ. И последнее, что я хотел бы отметить: все может быть браузером , что-либо.
Если у вас есть мобильное приложение, использующее HTTP API, то этим приложением является ваш браузер — вы просто настроили его так, чтобы он распознавал только определенный тип HTTP-ответа (от вашего собственного API).
Погрузитесь в протокол HTTP
Как мы уже упоминали, мы собираемся рассмотреть этапы более подробно.HTTP-обмен И рендеринг , поскольку они обеспечивают наибольшую сумму векторы атак для злоумышленников.
В следующая статья мы более подробно рассмотрим протокол HTTP и попытаемся понять, какие меры нам следует предпринять для обеспечения безопасности HTTP-коммуникаций.
Перевод выполнен при поддержке компании.
Программное обеспечение ЭДИСОН кто профессионально занимается развитие веб-сайта для крупных клиентов, а также веб-разработка на C# и .
NET .
Теги: #информационная безопасность #браузеры #разработка веб-сайтов #веб-дизайн #безопасность #веб-разработка #браузеры #edisonsoftware #edisonsoftware #edisonsoftware
-
Пользовательские Веб-Сайты Питтсбурга
19 Oct, 24 -
Как Я Настраивал Ipv6 6To4 На Keenetic
19 Oct, 24 -
И Снова О Стакснете
19 Oct, 24
