Как работают браузеры

1656534623 kak rabotayut brauzery

Алексей Надалин

Введение в безопасность веб-приложений

LIFd-0L9YdixoIiqgvRFXgi3Ef3I28Q9JedF
Фото Лиама Такера на Unsplash

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

Браузер является механизмом визуализации. Его работа заключается в том, чтобы загрузить веб-страницу и воспроизвести ее в способ, понятный человеку.

Несмотря на то, что это почти криминальное упрощение, это все, что нам нужно знать.

  • Пользователь вводит адрес в строке обозревателя.
  • Браузер загружает «документ» по этому URL-адресу и воспроизводит его.
36UVnQqt7Pi8y5VreXig8MFoon65civsswLS

Возможно, вы привыкли работать с одним из самых популярных браузеров, таких как Chrome, Firefox, Edge или Safari, но это не означает, что нет других браузеров.

lynx, например, это легкий текстовый браузер, работающий с командной строки. В основе lynx лежат те же принципы, которые вы найдете в любых других «основных» браузерах. Пользователь вводит веб-адрес (URL), браузер получает документ и воспроизводит его – единственная разница заключается в том, что lynx не использует визуальный механизм визуализации, а скорее текстовый интерфейс, благодаря которому такие веб-сайты, как Google выглядят так:

22-zfqmwHAaTX9h7UPlxalWVXn4u6Amd9agj

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

Что делает браузер?

Короче говоря, работа браузера в основном состоит из:

  • разрешение DNS
  • HTTP обмен
  • Воспроизведение
  • Промойте и повторите

Разрешение DNS

Этот процесс гарантирует, что, как только пользователь введет URL, браузер знает, к какому серверу он должен подключиться. Браузер связывается с DNS-сервером, чтобы найти это google.com переводится на 216.58.207.110IP-адрес, к которому браузер может подключиться.

HTTP Exchange

После того, как браузер определит, какой сервер будет обслуживать наш запрос, он инициирует с ним TCP-соединение и начнет HTTP обмен. Это не что иное, как способ для браузера связаться с сервером, что ему нужно и для того, чтобы сервер ответить.

HTTP – это просто название самого популярного протокола для общения в Интернете, и браузеры обычно общаются через HTTP во время общения с серверами. Обмен HTTP предполагает отправку клиентом (нашим браузером) a запроса сервер отвечает a ответ.

К примеру, после того, как браузер успешно подключился к серверу сзади google.comон пришлет запрос, который выглядит так:

GET / HTTP/1.1Host: google.comAccept: */*

Разберем запрос строку за строкой:

  • GET / HTTP/1.1: в этой первой строке браузер просит сервер получить документ в этом месте /добавив, что остальной запрос будет соответствовать протоколу HTTP/1.1 (он также может использовать 1.0 или 2)
  • Host: google.com: это есть единственный HTTP-заголовок, обязателен в HTTP/1.1. Поскольку сервер может обслуживать несколько доменов (google.com, google.co.ukи т.д.) здесь клиент вспоминает, что запрос был для этого конкретного хоста
  • Accept: */*: необязательный заголовок, где браузер сообщает серверу, что он примет любой ответ. Сервер может иметь ресурс, доступный в форматах JSON, XML или HTML, поэтому он может выбрать нужный формат

После браузера, выполняющего функцию a клиента, выполненный с его запросом, настал черед сервера ответить. Вот как выглядит ответ:

HTTP/1.1 200 OKCache-Control: private, max-age=0Content-Type: text/html; charset=ISO-8859-1Server: gwsX-XSS-Protection: 1; mode=blockX-Frame-Options: SAMEORIGINSet-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly
<!doctype html><html">......</html>

Вау, это много информации для переваривания. Сервер сообщает нам, что запрос был успешным (200 OK) и добавляет несколько заголовков к ответнапример, он рекламирует, какой сервер обработал наш запрос (Server: gws), что такое X-XSS-Protection политика этой реакции и так далее, и так далее.

Сейчас вам не нужно понимать каждую строчку в ответе. Мы рассмотрим протокол HTTP, его заголовки и т.п. в этой серии.

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

Воспроизведение

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

<!doctype html><html">......</html>

В тело ответы сервер включает представление ответа в соответствии с Content-Type заголовок. В нашем случае был установлен тип содержимого text/htmlпоэтому мы ожидаем HTML-разметки в ответе – это именно то, что мы находим в теле.

Вот где браузер действительно сияет. Он анализирует HTML, загружает дополнительные ресурсы, включенные в разметку (например, могут быть получены JavaScript или документы CSS) и представляет их пользователю как можно скорее.

Опять же, конечный результат – это то, что может понять рядовой Джо.

PsZC9DUwnoX9m5jPVkT8lWMr5lZ1GliyEjKS

Для более подробной версии того, что происходит, когда мы нажимаем клавишу Enter в адресной строке браузера, я бы предложил прочитать «Что происходит, когда…», очень сложную попытку объяснить механику процесса.

Поскольку эта серия сосредоточена на безопасности, я собираюсь дать намек на то, что мы только что узнали: злоумышленники легко зарабатывают на жизнь за счет уязвимостей в части обмена и рендеринга HTTP. Уязвимости и злонамеренные пользователи также скрываются в других местах, но лучший подход к безопасности на этих уровнях уже позволяет вам добиться успехов в улучшении вашей безопасности.

Продавцы

4 самых популярных браузера принадлежат разным производителям:

  • Chrome от Google
  • Firefox от Mozilla
  • Safari от Apple
  • Edge от Microsoft

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

W3C является органом, стоящим за разработкой стандартов, но не удивительно, что браузеры разрабатывают собственные функции, которые в конечном итоге превращаются в веб-стандарты, и безопасность не является исключением.

Chrome 51, например, представил файлы cookie SameSite, функцию, которая позволит веб-приложениям избавиться от определенного типа уязвимости, известной как CSRF (подробнее об этом позже). Другие поставщики решили, что это хорошая идея, и последовали ее примеру, что привело к тому, что SameSite стал веб-стандартом: на данный момент Safari является единственным основным браузером без поддержки файлов cookie SameSite.

rAkCeGgFkTBqnbxYa7c0qu6m2TNjKNK847tw

Это говорит нам о 2 вещах:

  • Safari, похоже, недостаточно заботится о безопасности своих пользователей (шучу: файлы cookie SameSite будут доступны в Safari 12, который, возможно, уже был выпущен к тому времени, когда вы читаете эту статью)
  • Устранение уязвимости в одном браузере не означает, что все ваши пользователи в безопасности

Первый пункт – это выстрел в Safari (как я уже упоминал, шучу!), в то время как второй момент действительно важен. Разрабатывая веб-приложения, мы не просто должны убедиться, что они выглядят одинаково в разных браузерах, но и обеспечить одинаковую защиту наших пользователей на разных платформах.

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

В нашем случае, если мы решим смягчать атаки CSRF только с помощью файлов cookie SameSite, мы должны знать, что подвергаем риску наших пользователей Safari. И наши пользователи тоже должны это знать.

И последнее, но не менее важное, вы должны помнить, что вы можете решить, поддерживать или нет версию браузера: поддержка каждой версии браузера была бы нецелесообразна (вспомните Internet Explorer 6). Однако убедиться, что последние несколько версий основных браузеров поддерживаются, как правило, хорошее решение. Однако, если вы не планируете предлагать защиту на определенной платформе, обычно целесообразно сообщить об этом своим пользователям.

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

Поставщик или стандартная ошибка?

Тот факт, что пользователь получает доступ к нашей программе через сторонний клиент (браузер), добавляет еще один уровень опосредованности к четкому, безопасному просмотру: сам браузер может представлять уязвимость в безопасности.

Продавцы, как правило, предоставляют вознаграждения (он же вознаграждения за ошибок) исследователям безопасности, которые могут обнаружить уязвимость в самом браузере. Эти ошибки не связаны с вашей реализацией, а скорее с тем, как браузер самостоятельно справляется с безопасностью.

Программа вознаграждения Chrome, например, позволяет инженерам безопасности связаться с командой безопасности Chrome, чтобы сообщить об обнаруженных уязвимостях. Если эти уязвимости подтверждаются, кажется патч, обычно обнародуется рекомендация по безопасности, и исследователь получает (обычно финансовое) вознаграждение от программы.

Такие компании как Google вкладывают относительно значительную сумму капитала в свои программы Bug Bounty, поскольку это позволяет им привлекать исследователей, обещая финансовую выгоду, если они обнаружат какие-либо проблемы с программой.

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

Джейк Арчибальд — защитник разработчиков в Google, недавно обнаруживший уязвимость, влияющую на более одного веб-браузера. Он задокументировал свои усилия, как он обратился к разным поставщикам и их реакции в интересном сообщении в блоге, который я рекомендую вам прочитать.

Браузер для разработчиков

Мы должны были понять очень простую, но довольно важную концепцию: браузеры – это просто клиенты HTTP, созданные для рядового интернет-серфера.

Они, безусловно, мощнее голого HTTP-клиента платформы (вспомните NodeJS require('http')например), но, в конце концов, они «только» естественной эволюцией более простых клиентов HTTP.

Как разработчиков, нашим HTTP-клиентом, вероятно, является cURL от Daniel Stenberg, одна из самых популярных программ, которые веб-разработчики используют каждый день. Это позволяет нам осуществлять обмен HTTP на лету, отправляя HTTP-запрос из нашей командной строки:

$ curl -I localhost:8080
HTTP/1.1 200 OKserver: ecstatic-2.2.1Content-Type: text/htmletag: "23724049-4096-"2018-07-20T11:20:35.526Z""last-modified: Fri, 20 Jul 2018 11:20:35 GMTcache-control: max-age=3600Date: Fri, 20 Jul 2018 11:21:02 GMTConnection: keep-alive

В приведенном выше примере мы запросили документ по адресу localhost:8080/и локальный сервер удачно ответил.

Вместо того чтобы сбрасывать тело ответа в командную строку, мы использовали -I флажок, сообщающий 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 OKHTTP/1.1 200 OK< server: ecstatic-2.2.1server: ecstatic-2.2.1< Content-Type: text/htmlContent-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 GMTlast-modified: Fri, 20 Jul 2018 11:20:35 GMT< cache-control: max-age=3600cache-control: max-age=3600< Date: Fri, 20 Jul 2018 11:25:55 GMTDate: Fri, 20 Jul 2018 11:25:55 GMT< Connection: keep-aliveConnection: keep-alive
<* Connection #0 to host localhost left intact

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

Как мы видели, браузеры – это не что иное, как сложные HTTP-клиенты. Конечно, они добавляют огромное количество функций (подумайте об управлении учетными данными, закладках, истории и т.п.), но правда в том, что они родились как HTTP-клиенты для людей. Это важно, поскольку в большинстве случаев вам не нужен браузер, чтобы проверить безопасность вашего веб-приложения, поскольку вы можете просто свернуть его и посмотреть на ответ.

Последнее, на что я хотел бы отметить, это что угодно может быть браузером. Если у вас есть мобильное приложение, которое использует API с помощью протокола HTTP, тогда это приложение является вашим браузером — это просто очень настроенное приложение, которое вы создали самостоятельно, которое понимает только определенный тип ответов HTTP (из вашего собственного API). .

В протокол HTTP

Как мы упоминали, HTTP обмен и предоставление фазы – это те, которые мы в большинстве своем рассмотрим, поскольку они обеспечивают наибольшее количество. векторы атаки для злоумышленников.

В следующей статье мы глубже рассмотрим протокол HTTP и попытаемся понять, какие меры мы должны принять, чтобы защитить обмен HTTP.

Первоначально опубликовано на odino.org (29 июля 2018 г.).
Вы можете следить за мной в Твиттере – разговоры приветствуются! ?

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *