ブラウザ
 Computer >> コンピューター >  >> ソフトウェア >> ブラウザ

ブラウザが Web コンテンツを処理する方法を理解する

ブラウザが Web コンテンツを処理する方法を理解する

アレックス・ナダリン

Web アプリケーション セキュリティの概要

ブラウザが Web コンテンツを処理する方法を理解する _写真提供:[Unsplash](https://unsplash.com/photos/cVMaxt672ss?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">リアム・タッカーが

Chrome、Firefox、Edge、Safari などの最も一般的なブラウザの使用に慣れているかもしれませんが、それは、世の中に別のブラウザがないという意味ではありません。

たとえば、lynx は、コマンド ラインから動作する軽量のテキストベースのブラウザです。 Lynx の中心には、他の「主流」ブラウザとまったく同じ原理が存在します。ユーザーが Web アドレス (URL) を入力すると、ブラウザがドキュメントを取得してレンダリングします。唯一の違いは、Lynx がビジュアル レンダリング エンジンを使用せず、テキスト ベースのインターフェースを使用するという事実です。これにより、Google などの Web サイトは次のようになります。

ブラウザが Web コンテンツを処理する方法を理解する

私たちはブラウザが何をするのかを大まかに理解していますが、これらの独創的なアプリケーションが私たちのために行うステップを詳しく見てみましょう。

ブラウザは何をしますか?

簡単に言うと、ブラウザの仕事は主に次のようなもので構成されます。

  • DNS 解決
  • HTTP 交換
  • レンダリング
  • すすいで繰り返します

DNS 解決

このプロセスにより、ユーザーが URL を入力すると、ブラウザーはどのサーバーに接続する必要があるかを認識できるようになります。ブラウザは DNS サーバーに接続して google.com を見つけます。 216.58.207.110 に変換されます 、ブラウザが接続できる IP アドレス。

HTTP 交換

ブラウザはリクエストを処理するサーバーを特定すると、そのサーバーとの TCP 接続を開始し、HTTP 交換を開始します。 。これは、ブラウザが必要なものをサーバーと通信し、サーバーが応答を返す方法にほかなりません。

HTTP は単に Web 上で通信するための最も一般的なプロトコルの名前であり、ブラウザはサーバーと通信するときにほとんどの場合 HTTP を介して通信します。 HTTP 交換には、クライアント (ブラウザ) がリクエスト を送信することが含まれます。 、そしてサーバーは応答を返します。 .

たとえば、ブラウザが google.com の背後でサーバーに正常に接続した後、 を指定すると、次のようなリクエストが送信されます。

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

リクエストを 1 行ずつ分解してみましょう。

  • GET / HTTP/1.1 :この最初の行で、ブラウザはサーバーに場所 / にあるドキュメントを取得するように要求します。 、残りのリクエストは HTTP/1.1 プロトコルに従うことを追加します (1.0 を使用することもできます) または 2 )
  • Host: google.com :これはHTTP/1.1 で必須の唯一の HTTP ヘッダーです。 。サーバーは複数のドメイン (google.com) にサービスを提供する可能性があるため、 、google.co.uk 、など）クライアントはここで、リクエストがその特定のホストに対するものであると述べています
  • Accept: */* :オプションのヘッダー。ブラウザーはサーバーに対して、あらゆる種類の応答を受け入れることを伝えます。サーバーは、JSON、XML、または HTML 形式で利用可能なリソースを保持できるため、好みの形式を選択できます

ブラウザの後はクライアントとして機能します。 、リクエストが完了すると、サーバーが応答する番になります。応答は次のようになります。

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 ドキュメントがある可能性があります) を読み込み、それらをできるだけ早くユーザーに表示します。

もう一度言いますが、最終的な結果は平均的なジョーなら理解できるものです。

ブラウザが Web コンテンツを処理する方法を理解する

ブラウザのアドレス バーで Enter キーを押したときに実際に何が起こるかについて詳しく知りたい場合は、プロセスの背後にあるメカニズムを説明する非常に精緻な試みである「What happens when…」を読むことをお勧めします。

これはセキュリティに焦点を当てたシリーズなので、今学んだことについてヒントを投下します。攻撃者は HTTP 交換およびレンダリング部分の脆弱性を利用して簡単に生計を立てているということです。 。脆弱性や悪意のあるユーザーは他の場所にも潜んでいますが、これらのレベルでのより優れたセキュリティ アプローチにより、セキュリティ体制の改善にすでに前進することができます。

ベンダー

最も人気のある 4 つのブラウザは、それぞれ異なるベンダーに属しています。

  • Google の Chrome
  • Mozilla の Firefox
  • Apple の Safari
  • Microsoft のエッジ

ベンダーは、市場への浸透を高めるために互いに争うだけでなく、ウェブ標準を改善するために互いに協力し合っています。 、これはブラウザの「最小要件」のようなものです。

W3C は標準の開発を支援する団体ですが、ブラウザが独自の機能を開発して最終的に Web 標準となることは珍しいことではなく、セキュリティもその例外ではありません。

たとえば、Chrome 51 では SameSite Cookie が導入されました。これは、Web アプリケーションが CSRF として知られる特定のタイプの脆弱性を取り除くことを可能にする機能です (これについては後で詳しく説明します)。他のベンダーもこれが良いアイデアであると判断し、これに倣い、SameSite が Web 標準になりました。現時点では、SameSite Cookie をサポートしていない主要なブラウザは Safari だけです。

ブラウザが Web コンテンツを処理する方法を理解する

これにより、次の 2 つのことがわかります。

  • Safari はユーザーのセキュリティを十分に考慮していないようです (冗談です。SameSite Cookie は Safari 12 で利用可能になります。この記事を読んでいる時点ではすでにリリースされている可能性があります)
  • 1 つのブラウザの脆弱性にパッチを適用しても、すべてのユーザーが安全であるとは限りません

最初のポイントはサファリでのショットです (先ほども言いましたが、冗談です!)、2 番目のポイントは非常に重要です。ウェブ アプリケーションを開発する場合、さまざまなブラウザで同じように見えることを確認するだけでなく、プラットフォーム間でユーザーが同じ方法で保護されていることも確認する必要があります。

Web セキュリティに対する戦略は、ブラウザのベンダーが許可している内容に応じて変化する必要があります 。現在、ほとんどのブラウザは同じ機能セットをサポートしており、共通のロードマップから逸脱することはほとんどありませんが、上記のような事例は依然として発生しており、セキュリティ戦略を定義する際にはそれを考慮する必要があります。

私たちの場合、SameSite Cookie を通じてのみ CSRF 攻撃を軽減すると決めた場合、Safari ユーザーを危険にさらしていることを認識する必要があります。そして、ユーザーもそれを知っておくべきです。

最後になりましたが、ブラウザのバージョンをサポートするかどうかは自分で決定できることを覚えておいてください。すべてのブラウザのバージョンをサポートすることは現実的ではありません (Internet Explorer 6 を考えてください)。ただし、主要なブラウザの最新のいくつかのバージョンがサポートされていることを確認するのは、一般的には良い決定です。ただし、特定のプラットフォームで保護を提供する予定がない場合は、一般にユーザーにそのことを知らせることをお勧めします。

プロのヒント :ユーザーに古いブラウザの使用を奨励したり、積極的にサポートしたりしてはなりません。あなたが必要な予防措置をすべて講じていたとしても、他の Web 開発者は講じていない可能性があります。主要なブラウザのいずれかのサポートされている最新バージョンを使用するようユーザーに奨励します。

ベンダーまたは標準のバグですか?

平均的なユーザーがサードパーティ クライアント (ブラウザ) を通じてアプリケーションにアクセスするという事実は、明確で安全なブラウジング エクスペリエンスに向けた別のレベルの間接性を追加します。つまり、ブラウザ自体にセキュリティ上の脆弱性が存在する可能性があります。

通常、ベンダーは報酬 ( 別名バグ報奨金) を提供します。 ）ブラウザ自体の脆弱性を発見できるセキュリティ研究者に。これらのバグは実装に関係しているのではなく、ブラウザが独自にセキュリティを処理する方法に関係しています。

たとえば、Chrome 報奨プログラムを利用すると、セキュリティ エンジニアは Chrome セキュリティ チームに連絡して、発見した脆弱性を報告できます。これらの脆弱性が確認された場合、パッチが発行され、セキュリティ勧告通知が一般に公開され、研究者はプログラムから (通常は金銭的な) 報酬を受け取ります。

Google のような企業は、アプリケーションに問題が見つかった場合に金銭的利益を約束することで研究者を惹きつけることができるため、バグ報奨金プログラムに比較的多額の資本を投資しています。

バグ報奨金プログラムでは、誰もが得をします。ベンダーはソフトウェアのセキュリティを向上させることに成功し、研究者はその発見に対して報酬を受け取ります。これらのプログラムについては後ほど説明します。バグ報奨金の取り組みはセキュリティ分野で別のセクションに置く価値があると私は考えています。

Jake Archibald は Google の開発者擁護者で、最近複数のブラウザに影響を与える脆弱性を発見しました。彼は、自分の取り組み、さまざまなベンダーにどのようにアプローチしたか、そしてベンダーの反応を興味深いブログ投稿に記録しましたので、ぜひ読んでください。

開発者向けのブラウザ

ここまでで、非常に単純だがかなり重要な概念を理解できたはずです。ブラウザは、平均的なインターネット サーファー向けに構築された単なる HTTP クライアントです。 .

これらは、プラットフォームの裸の HTTP クライアントよりも明らかに強力です (NodeJS の require('http') を思い出してください) 、たとえば）しかし、結局のところ、それらはより単純な HTTP クライアントの自然な進化に「すぎません」。

開発者として私たちが選択する HTTP クライアントは、おそらく、Daniel Stenberg の cURL です。これは、Web 開発者が日常的に使用する最も人気のあるソフトウェア プログラムの 1 つです。コマンドラインから 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 が実行する実際のリクエストを含む、もう少し詳しい情報をダンプするように 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

ほぼ同じ情報が、主流ブラウザの DevTools を通じて入手できます。

これまで見てきたように、ブラウザは精巧な HTTP クライアントにすぎません。確かに、膨大な量の機能 (資格情報管理、ブックマーク、履歴などを考えてください) が追加されていますが、真実は、それらは人間のための HTTP クライアントとして生まれたということです。これは重要です。ほとんどの場合、Web アプリケーションのセキュリティをテストするのにブラウザは必要なく、単純に「カール」して応答を確認できるからです。

最後に指摘しておきたいのは、あらゆるものがブラウザになり得るということです。 。 HTTP プロトコル経由で API を使用するモバイル アプリケーションがある場合、そのアプリケーションはブラウザになります。それは偶然にも、自分で構築した高度にカスタマイズされたものであり、(独自の API からの) 特定の種類の HTTP 応答のみを理解するものです。

HTTP プロトコルへ

前述したように、HTTP 交換 そしてレンダリング フェーズは最も多くの攻撃ベクトルを提供するため、主に説明するフェーズです。 悪意のあるユーザー向け。

次の記事では、HTTP プロトコルを詳しく見て、HTTP 交換を保護するためにどのような対策を講じるべきかを理解していきます。

元々は odino.org で公開されました (2018 年 7 月 29 日)。
_Twitter で私をフォローしてください - 暴言は大歓迎です!_ ?

無料でコーディングを学びましょう。 freeCodeCamp のオープンソース カリキュラムは、40,000 人以上の人々が開発者としての職に就くのに役立ちました。始めましょう


  1. プロになるために役立つ Firefox の設定について学ぶ

    正しく使用すれば、Firefox が便利な Web ブラウザーになることをご存知ですか?私たちの多くは、コンピューターで時々 Mozilla Firefox を使用しています。 Firefox の設定の使用について知っている場合は、要件に従って設定する方が簡単です。 Firefox の最後のセッションを復元する方法や、安全なブラウジングのために Firefox でトラッカーをブロックする方法など、Firefox の便利な設定は、ブラウザを最大限に活用するのに役立ちます! これらの Firefox 設定でブラウザを最大限に活用してください。 通常のブラウザーから完全に切り替える可能性がある F

  2. Google Chrome の新しい拡張機能プランが広告ブロッカーを無効にする可能性がある

    Google は、Chrome ブラウザのエクスペリエンスを強化する予定です。ただし、これはさまざまな拡張機能の開発者を刺激しました。この計画が実行されれば、Chrome のパフォーマンスとセキュリティが向上しますが、オンライン ブラウジング中に広告や悪意のあるリンクをブロックするように設計された拡張機能も機能しなくなります。 問題が発生するのはどの拡張機能ですか? Google の提案は、トラッカー ブロッカー Ghostery、uBlock Origin - オープン ソース広告ブロッカー、NoScript - JavaScript ソフトウェア ブロッカー、パスワード マネージャー