ブラウザを開いて、google.comを入力すると、1秒後にページが表示されます。魔法？いいえ。この1秒には、一連のイベントが隠されています。 各開発者 理解する必要があります。ハッカーのように考える場合（もちろん倫理的なハッカー😏）、知ることは選択肢ではなく必要です。
すべてを整理しましょう。退屈なことなく、人生の例を使って。
🔍 DNS — インターネットの電話帳
コンピューターはgoogle.comを理解しません。142.250.74.206のようなIPアドレスで動作します。DNS（ドメインネームシステム）は、人間のアドレスをマシンのアドレスに変換する巨大な電話帳です。
サイトのアドレスを入力すると、次のことが起こります。
ブラウザのキャッシュ — すでにログイン済みですか？IPはすでに保存されています。
オペレーティングシステムのキャッシュ — システムも記憶します。
ルーター — 彼もDNSキャッシュを保持しています。
プロバイダーのDNSリゾルバー — どこにも見つからない場合、リクエストはプロバイダーのサーバーに送信されます。
ルートDNS → TLD →権威サーバー — 回答が見つかるまでの問い合わせの連鎖。
この全体の話はミリ秒単位で行われます。しかし、セキュリティの観点からは興味深いのは次のことです。
DNS スプーフィング — 攻撃者はDNS応答を置き換え、偽のサイトに送ります。bank.comを入力すると、詐欺師のクローンにアクセスします。外見上は、1対1です。そのため、DNSだけでは不十分で、HTTPSが必要です。
自分で試してみてください。 ターミナルを開き、nslookup google.comまたはdig google.comを入力します。システムがIPを検索する方法が表示されます。
📡 HTTP — 封筒なしのカード
HTTP（ハイパーテキスト転送プロトコル）は、ブラウザがサーバーと通信するためのプロトコルです。「要求と応答」の原則に従って動作します。
HTTPリクエストの構造：
GET /profile HTTP/1.1
Host: example.com
Cookie: session_id=abc123
User-Agent: Mozilla/5.0サーバーの応答：
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session_id=abc123
<html>...</html>簡単ですよね？しかし、 大きな問題：HTTPはすべてを送信します プレーンテキスト。郵便でカードを送っていると想像してみてください。どの郵便配達員でもそれを読むことができます。ログイン、パスワード、カード番号など、すべてが表示されます。
主なHTTPメソッド：
GET「データをください」
POST「これが私のデータです」
「これを更新」を入れる
DELETE「これを削除」
覚えておくべき回答コード：
200 すべてOK
301リダイレクト
403アクセス拒否
404見つかりません
500サーバーがダウンしました
HTTPトラフィックを傍受したハッカー （たとえば、公衆Wi-Fi ）、絶対的にすべてを見ることができます。したがって、現在のクリーン HTTP は脆弱性です。
🔒 HTTPS — ワックスシール付き封筒
HTTPSは、同じHTTPですが、TLS（トランスポートレイヤーセキュリティ）を介して暗号化されています。現在、データは送信者と受信者以外のすべての人にとって文字の寄せ集めのように見えます。
安全な接続（TLSハンドシェイク）の確立方法：
クライアント: 「こんにちは、安全に話したいです。これが私の暗号化機能です。」
サーバー： 「こんにちは！これが私のSSL証明書です。本物であることを確認できます。」
クライアント: 認証局（CA）を介して証明書を検証します。
両方 共通の秘密鍵を生成します。
次へ すべての通信はこのキーで暗号化されます。
ハッカーはなぜこれを行うのですか？
攻撃者がHTTPSトラフィックを傍受した場合でも、暗号化されたデータしか見ることができません。ただし、次のような注意点があります。
古いバージョンのTLS (1.0、1.1) には既知の脆弱性があります。 証明書の設定が正しくありません — ユーザーが「とにかく移動する」をクリックすることに慣れてしまうと、だまされる可能性があります。 MITM (Man-in-the-Middle) — 攻撃者はクライアントとサーバーの間に立ち、自分の証明書を置き換えます。アドレスバーのロック 🔒 に注意してください！
🍪 クッキー — デジタルバッジ
HTTPプロトコル 状態なし （ステートレス）。サーバーはリクエスト間であなたを覚えていません。毎回、あなたは彼にとっては見知らぬ人です。Cookieはこの問題を解決します。
Cookie — サーバーがブラウザに保存を依頼し、リクエストごとに送信する小さなテキスト。
仕組み：
サイトにログインします。
サーバーはセッションを作成し、次のように応答します。
Set-Cookie: session_id=xyz789ブラウザはこのクッキーを保存します。
次の各リクエストで、ブラウザは次のものを送信します。
Cookie: session_id=xyz789サーバーはIDを見て、「ああ、このユーザーだ！」と認識します。
クックの種類：
セッション-ブラウザが閉じるまで存続します
永続的 - 指定された日付まで有効
HttpOnly-JSはそれらを読み取ることができません—XSSからの保護
安全 - HTTPS経由でのみ送信
SameSite - CSRF攻撃からの保護
ハッカーがクッキーを狙う理由：
他人のセッションCookieを盗むと、サイトにログインできます 被害者の代理人 ログインとパスワードなしで。これは session hijacking （セッションハイジャック）。
盗難の方法： XSS（悪意のあるスクリプトがCookieを盗む）、トラフィックの傍受（HTTPSがない場合）、他人のブラウザへの物理的なアクセス。
🎫 セッション — サーバーにとってあなたは誰ですか？
セッションは、ユーザーに関するデータを保存するためのメカニズムです サーバー側CookieにはセッションID（キー）のみが含まれ、すべてのデータ（名前、役割、ショッピングカート）はサーバー上にあります。
Cookieとセッションの違いは何ですか？
Cookie | Session | |
|---|---|---|
保存場所 | ブラウザで | サーバー上 |
サイズ | 最大約4KB | 制限なし |
安全性 | クライアントは変更可能 | クライアントにはIDのみが表示されます |
例 |
|
|
JWT — 代替アプローチ:
サーバーにセッションを保存する代わりに、 JSON Web Token (JWT)これは、ユーザーに関する暗号化された情報を含むトークンです。サーバーは状態を保存しません。すべてトークン内にあります。
構造: header.payload.signature
長所：スケーラビリティ（共有セッションデータベースは不要）。短所：期限が切れる前に個別のトークンを「キル」することはできません。
📱 本当に理解したいなら、練習してください！
理論は基礎ですが、本当の理解は実践を通じてのみ得られます。試してみてください コディック — 実際の課題を解決しながらプログラミングを学べるアプリケーション。水は一切使用せず、練習とわかりやすい説明のみ。
また、私たちのチャンネルを登録してください テレグラムチャンネル — プログラミングに役立つ投稿、テーマの分析、ライフハック。地下鉄で、昼食時に、または就寝前に読んでください🚀
🧠 まとめ
インターネットは魔法ではありません。インターネットは、それぞれが独自のタスクを解決する一連のプロトコルです。DNSは名前をアドレスに変換し、HTTPはデータを配信し、HTTPSはデータを暗号化し、Cookieは状態を保存し、セッションはユーザーを識別します。
これらの基本を理解することは、安全なコードを書き、一歩先を考えるための最初のステップです。普通のユーザーとしてではなく、何が起こっているのかを知っている人として ボンネットの下. 🧠