CrazyAsian1によるビッグファイブパート3



こんにちは 私の名前はサーシャ・バランニクです。 Mail.Ru Groupでは、15人のWeb開発部門を率いています。 私たちは何千万人ものユーザーのためにウェブサイトを作成する方法を学び、毎日数百万のオーディエンスを冷静に扱っています。 私自身は約20年間Web開発に携わっており、過去15年間は主にPHPでプログラミングする必要があります。 この間、言語と開発アプローチの機能は大きく変化しましたが、主要な脆弱性を理解し、それらから自分自身を保護する能力は、どの開発者にとっても重要なスキルです。



インターネットには多くの記事とセキュリティガイドがあります。 この本は、私には非常に詳細に見えましたが、簡潔で理解しやすいものでした。 新しいことを学び、サイトの信頼性と安全性を高めるのに役立つことを願っています。



PS本は長いので、翻訳はいくつかの記事にまとめられます。 それでは、始めましょう...

PHPの別のセキュリティブックですか？

PHPでセキュリティブックを開始するには多くの方法があります。 残念ながら、私はそれらのいずれも読んでいません。そのため、執筆プロセスでこれに対処する必要があります。 おそらく最も基本的なものから始めて、すべてがうまくいくことを願っています。



X社がオンラインで起動した抽象Webアプリケーションを検討する場合、それがクラックされると重大な損害を引き起こす可能性のある多くのコンポーネントが含まれていると想定できます。 たとえば、どれですか？

1. ユーザーへの害：電子メール、パスワード、個人データ、銀行カードの詳細、ビジネスシークレット、連絡先リスト、取引履歴、および高度に保護されたシークレット（誰かが彼の犬Sparkyと呼んだものなど）へのアクセスを取得します。 このデータの漏洩は、ユーザー（個人および企業）に損害を与えます。 このようなデータを悪用するWebアプリケーションや、ユーザーの信頼を利用するサイトも有害な場合があります。
2. 会社X自体への損害：ユーザーへの損害、評判の悪化、報酬の支払い、重要なビジネス情報の損失、追加費用の発生-インフラストラクチャ、セキュリティの改善、結果の清算、法的費用、解雇されたトップマネージャーへの大きなメリットなど

Webアプリケーションのセキュリティシステムが防止しなければならないトラブルのほとんどが含まれているため、これら2つのカテゴリに焦点を当てます。 深刻なセキュリティ侵害に直面したすべての企業は、プレスリリースやウェブサイトに彼らがどのように感じているかをすぐに書きます。 ですから、実際にこの問題に出くわす前に、この問題の重要性を感じることを心からお勧めします。



残念ながら、セキュリティの問題はしばしば遡及的に対処されます。 最も重要なことは、許容できる予算と期限で、ユーザーのニーズを満たす実用的なアプリケーションを作成することであると考えられています。 これは完全に理解できる一連の優先事項ですが、セキュリティを永久に無視することはできません。 変更のコストがまだ低い開発中に特定の決定を導入することを常に念頭に置いておく方がはるかに優れています。



安全性の二次的要因は、主にプログラミング文化の結果です。 一部のプログラマーは、脆弱性を考えると冷静になりますが、他のプログラマーは、脆弱性ではないことを証明できるまで脆弱性の存在に異議を唱えるかもしれません。 これらの両極端の間には、彼らがまだ間違っていないので、肩をすくめる多くのプログラマーがいます。 彼らがこの奇妙な世界を理解するのは難しいです。



Webアプリケーションのセキュリティシステムは、アプリケーションのサービスを信頼するユーザーを保護する必要があるため、質問への回答を知る必要があります。

1. 誰が私たちを攻撃したいですか？
2. 彼らはどのように私たちを攻撃できますか？
3. どうすればそれらを止めることができますか？

誰が私たちを攻撃したいですか？

最初の質問への答えは非常に簡単です：それだけです。 はい、宇宙全体があなたにレッスンを教えたいと思っています。 Kali Linuxを実行しているオーバークロックされたコンピューターの子供ですか？ 彼はおそらくすでにあなたを攻撃しました。 車輪に棒を入れるのが好きな不審な男？ 彼はおそらくあなたを攻撃するために誰かをすでに雇っています。 1時間ごとにデータを受け取る信頼できるREST API おそらく彼は、感染したデータをあなたに投げかけるために1か月前にハッキングされました。 私もあなたを攻撃できます！ したがって、この本を盲目的に信じないでください。 私が嘘をついていると考えてください。 そして、きれいな水に連れて行って私の悪いアドバイスを公開してくれるプログラマを見つけてください。 一方、多分彼もあなたをハックするでしょう...



このパラノイアのポイントは、Webアプリケーションと対話するすべてのもの（「ユーザー」、「ハッカー」、「データベース」、「信頼できない入力」、「マネージャー」、「REST API」）を精神的に簡単に分類できるようにすることです、次に各カテゴリに信頼性指標を割り当てます。 明らかに、ハッカーを信頼することはできませんが、データベースについてはどうですか？ 「信頼性の低い入力」という名前には理由がありますが、同僚の信頼できるAtomフィードから受け取ったブログ投稿を本当にフィルタリングしますか？



Webアプリケーションのハッキングに真剣に取り組んでいる人々は、この考え方を利用することを学び、脆弱なデータソースではなく、優れたセキュリティシステムを持つ可能性が低い信頼できるデータソースを攻撃することがよくあります。 これは偶然の決定ではありません。実生活では、信頼指数が高い被験者ほど疑いが少ないです。 アプリケーションを分析するときに主に注意を払うのは、このようなデータソースです。



データベースに戻ります。 ハッカーがデータベースにアクセスできると仮定した場合（そして、私たちは妄想し、常にこれを仮定します）、あなたは彼女を信頼することはできません。 ほとんどのアプリケーションは、質問なしでデータベースを信頼します。 外では、Webアプリケーションは全体のように見えますが、内部ではデータを交換する別個のコンポーネントのシステムです。 これらすべてのコンポーネントが信頼できると見なされている場合、そのうちの1つがハッキングされると、他のすべてのコンポーネントがすぐに侵害されます。 このような壊滅的なセキュリティ問題は、「基地がハッキングされた場合、私たちはまだ負けています」というフレーズでは解決できません。 あなたはそう言うことができますが、最初に基地を信頼し、それに応じて行動しなければ、それをしなければならないということはまったくありません！

彼らはどのように私たちを攻撃できますか？

2番目の質問に対する答えは、かなり広範なリストです。 Webアプリケーションのすべてのコンポーネントまたはレイヤーがデータを受信する場所であればどこからでも攻撃を受ける可能性があります。 基本的に、Webアプリケーションはデータを処理し、場所から場所へ転送するだけです。 ユーザーリクエスト、データベース、API、ブログフィード、フォーム、Cookie、リポジトリ、PHP環境変数、構成ファイル、再度構成ファイル、実行するPHPファイル-これらはすべて、データに感染してセキュリティシステムを突破し、損害を引き起こす可能性があります。 実際、悪意のあるデータがリクエストに使用されるPHPコードに明示的に存在しない場合、おそらく「ペイロード」として送信されます。 a）ソースPHPコードを作成し、b）正しくレビューされ、c）犯罪組織の代表者があなたに支払いをしなかったと仮定します。



データが完全に安全で使用に適していることを確認せずにデータソースを使用すると、攻撃を受ける可能性があります。 また、受信したデータが送信したデータと一致することを確認する必要があります。 データが出力に対して完全に安全にされていない場合、深刻な問題も発生します。 これらはすべて、PHPの「入力をチェックしてください。 画面出力。」



これらは、何らかの方法で制御する必要がある明らかなデータソースです。 ソースには、クライアント側のリポジトリも含まれる場合があります。 たとえば、ほとんどのアプリケーションは、Cookieに保存できる一意のセッションIDを割り当てることでユーザーを認識します。 攻撃者がCookieから値を取得すると、別のユーザーになりすますことができます。 また、ユーザーデータの傍受または改ざんに関連するリスクの一部は軽減できますが、ユーザーのコンピューターの物理的なセキュリティを保証することはできません。 ユーザーが「123456」を「password」に続く最も愚かなパスワードと見なすことさえ保証できません。 今日では、ユーザー側のストレージの種類がCookieだけではないという事実によって、追加の海賊行為が行われています。



見落とされることが多い別のリスクは、ソースコードの整合性です。 PHPでは、互いに弱く接続されているフレームワークの多数のライブラリ、モジュール、およびパッケージに基づくアプリケーション開発がますます一般的になっています。 これらの多くはGithubなどの公開リポジトリからダウンロードされ、ComposerやそのWebコンパニオンであるPackagist.orgなどのパッケージインストーラーを使用してインストールされます。 したがって、ソースコードのセキュリティは、これらすべてのサードパーティのサービスとコンポーネントのセキュリティに完全に依存しています。 Githubが侵害された場合、悪意のあるコードを配布するためにGithubが使用される可能性が最も高くなります。 Packagist.orgの場合-攻撃者はパケット要求を自分の悪意のあるパッケージにリダイレクトできます。



これまで、ComposerとPackagist.orgには依存関係の判別とパッケージの配布に関する既知の脆弱性が存在するため、常に作業環境のすべてを再確認し、Packagist.orgからすべてのパッケージのソースを確認してください。

どうすればそれらを止めることができますか？

Webアプリケーションのセキュリティシステムを突破することは、ばかばかしいことも、非常に時間のかかる作業でもあります。 すべてのWebアプリケーションのどこかに脆弱性があると仮定するのは公平です。 その理由は簡単です。すべてのアプリケーションは人によって作成され、人は間違いを犯しがちです。 完璧なセキュリティは夢のようなものです。 すべてのアプリケーションには脆弱性が含まれている可能性があり、プログラマの仕事はリスクを最小限に抑えることです。



Webアプリケーションへの攻撃による損害の可能性を減らすために、慎重に考える必要があります。 物語の過程で、可能な攻撃方法についてお話します。 それらのいくつかは明らかですが、他はそうではありません。 しかし、いずれにせよ、問題を解決するには、いくつかの基本的な安全原則を考慮する必要があります。

セキュリティの基礎

保護装置を開発する場合、その有効性は次の考慮事項を使用して評価できます。 すでに上記で引用したものもあります。

1. 誰も何も信じないでください。
2. 常に最悪のシナリオを想定してください。
3. マルチレベルの保護を適用します（多層防御）。
4. 「シンプルな方が良い」という原則を守ります（KISS It Simple Stupid、KISS）。
5. 「最小特権」の原則を順守してください。
6. 攻撃者はあいまいさを感じます。
7. ドキュメント（RTFM）を読みますが、決して信用しないでください。
8. これがテストされていない場合、これは機能しません。
9. これは常にあなたの間違いです！

すべてのポイントを簡単に見ていきましょう。

1.誰も何も信じない

上記のように、正しい位置は、Webアプリケーションとやり取りするすべてのものがすべてハッキングしたいと想定することです。 リクエストを処理するために必要な他のコンポーネントまたはアプリケーション層を含みます。 それだけです。 例外なし。

2.常に最悪のシナリオを想定します。

多くのセキュリティシステムには共通の特性があります。どれほどうまく作られていても、それぞれが壊れる可能性があります。 これを考慮すると、2番目のポイントの利点をすぐに理解できます。 最悪のシナリオをターゲットにすると、攻撃の範囲と重大度を評価するのに役立ちます。 そして、それが本当に起こった場合、追加のセキュリティ機能とアーキテクチャの変更による不快な結果を減らすことができるでしょう。 おそらく、あなたが使用している従来のソリューションは、すでにより良いものに置き換えられていますか？

3.複数レベルの保護を適用する（多層防御）

人々が長い間、敵の弾丸や刃から重要な臓器を保護する多くの壁、土嚢、装備、防具、フラスコがセキュリティへの正しいアプローチであることを認識していたため、マルチレベルの保護は軍事科学から借用されています。 上記のどれが保護されないのか決してわかりません。また、いくつかの保護レベルでは、フィールドの強化や戦闘の形成以上のものに依存できるようにする必要があります。 もちろん、単一の障害だけではありません。 階段の上にある巨大な中世の壁に登り、その後ろに別の壁があり、そこから矢印がシャワーを浴びているのを見つけた攻撃者を想像してください。 ハッカーも同じように感じるでしょう。

4.「シンプルな方が良い」という原則を守る（KISS It Simple Stupid、KISS）

最高の治療法は常にシンプルです。 開発、実装、理解、使用、テストが簡単です。 シンプルさにより、エラーの数が減り、アプリケーションの正しい動作が促進され、最も複雑で使いにくい環境でも実装が容易になります。

5.「最小特権」の原則を順守する

情報交換の各参加者（ユーザー、プロセス、プログラム）には、自分の機能を実行するために必要なアクセス権のみが必要です。

6.攻撃者は不明瞭さを感じる

「 あいまいさによるセキュリティ 」は、防御Aを使用し、これがどのように機能するのか、また存在するのかを誰にも言わない場合、攻撃者が迷子になるため魔法のように役立つという仮定に基づいています。 実際、これはわずかな利点しか与えません。 多くの場合、経験豊富な攻撃者はあなたが取った対策を計算できるため、明示的な防御を使用する必要があります。 あいまいな保護が本当の保護の必要性を取り消すと過度に確信している人は、幻想を取り除くために特に罰せられるべきです。

7.ドキュメント（RTFM）を読むが、決して信用しない

PHPマニュアルは聖書です。 もちろん、 Flying Pasta Monsterによって書かれたものではないため、正式にはまだ気付いていない、または修正されていない、ある程度の半分の真実、欠陥、誤解、または誤りを含む可能性があります。 スタックオーバーフローについても同じことが言えます。



一般に、セキュリティの分野における専門知識（PHPのみを対象とするのではなく）は、より詳細な知識を提供します。 PHPのセキュリティ聖書に最も近いものは、記事、ガイド、およびヒントが掲載されたOWASPサイトです。 OWASPでの実行が推奨されていない場合は、絶対に実行しないでください！

8.テストされていない場合、機能しません。

セキュリティ機能を実装する場合、検証に必要なすべての動作テストを作成する必要があります。 あなたが刑務所で泣くハッカーであるふりを含む。 これは大げさなように思えるかもしれませんが、Webアプリケーションをハッキングする方法を知ることは良い習慣です。 潜在的な脆弱性について学習し、妄想が増加します。 同時に、Webアプリケーションを壊したことに対する新たな感謝の気持ちを経営者に伝える必要はありません。 必ず自動ツールを使用して脆弱性を特定してください。 これらは便利ですが、もちろん、高品質のコードレビューや手動のアプリケーションテストに代わるものではありません。 テストに費やすリソースが多いほど、アプリケーションの信頼性は高くなります。

9.これは常にあなたの間違いです！

プログラマーは、セキュリティの脆弱性は散在する攻撃であり、その結果は無視できると信じていることに慣れています。



たとえば、データリーク（十分に文書化された広範囲のハッキング）は、ユーザーに直接影響を与えないため、多くの場合、軽微なセキュリティ問題と見なされます。 ただし、ソフトウェアバージョン、開発言語、ソースコードの場所、アプリケーションロジックとビジネスロジック、データベース構造、Webアプリケーション環境および内部操作のその他の側面に関するデータ漏洩は、攻撃を成功させるためにしばしば重要です。



同時に、セキュリティシステムに対する攻撃は、多くの場合、攻撃の組み合わせです。 別に、それらは重要ではありませんが、同時に他の攻撃への道を開くこともあります。 たとえば、SQLコードを実装するには、特定のユーザー名が必要な場合があります。これは、はるかに高価で目立つブルートフォースではなく、管理インターフェイスに対するタイミング攻撃を使用して取得できます。 同様に、SQLの導入により、多数の不審なログエントリの注意を引くことなく、特定の管理アカウントにXSS攻撃を実装できます。



脆弱性を単独で考慮することの危険性は、それらの脅威を過小評価することであり、したがって、それらに対する不注意な態度にあります。 プログラマーは、あまりにも取るに足りないと見なしているため、脆弱性を修正するのが面倒です。 安全な開発の責任をエンドプログラマーまたはユーザーに移す慣行も実践されます。多くの場合、特定の問題を文書化せずに、これらの脆弱性の存在さえ認識されません。



見かけ上の重要性は重要ではありません。 特にプログラマーやユーザーに脆弱性を修正するように強制することは無責任です。特に脆弱性について知らされていない場合は無責任です。

入力検証

— -. -, . , , , . , , . ( ) «», «», « » « ». , , … . , .



, ? . PHP « ». . , , , . そうではありません。 — , .

— , -. - , , . , . , , , , . , , . , PHP , , . , :

filter_var('php://example.org', FILTER_VALIDATE_URL);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィルタは問題なく通過します。 問題は、受け入れられたphp：// URLが、実行可能なPHPスクリプトから（PHPハンドラーを介して）データを返すのではなく、リモートHTTPアドレスの受信を期待するPHP関数に渡すことができることです。 フィルターオプションに有効なURIを制限するメソッドがないため、脆弱性が発生します。 アプリケーションは、PHP固有のURIではなく、http、https、またはmailtoリンクを想定しているという事実にもかかわらず。 このようなあまりにも一般的な検証方法を避けることは、どうしても必要です。

コンテキストに注意してください。

入力を検証することにより、安全でないデータがWebアプリケーションに入力されないようにする必要があります。 重大な障害：データセキュリティチェックは通常、最初の使用目的に対してのみ実行されます。



名前を含むデータを取得したとします。 アポストロフィ、ハイフン、角かっこ、スペース、および英数字のUnicode文字の数を確認するだけです。 この名前は、表示に使用できる正しいデータです（最初の使用目的）。 ただし、他の場所（たとえば、データベースへのクエリ）で使用すると、新しいコンテキストに表示されます。 また、このコンテキストでは、名前に有効な文字の一部が危険になります。名前がSQLインジェクションを実行するために文字列に変換される場合。



入力データの検証は本質的に信頼できないことが判明しています。 明確に無効な値を削除するのに最も効果的です。 何かが整数、英数字文字列、またはHTTP URLである必要があるときに言います。 このような形式と値には制限があり、適切に検証されれば、脅威になる可能性は低くなります。 その他の値（無制限のテキスト、GET / POST配列、およびHTML）はチェックが難しく、それらの値で悪意のあるデータを受け取る可能性が高くなります。



ほとんどの場合、アプリケーションはコンテキスト間でデータを転送するため、すべての入力データを確認して問題が完了したと見なすことはできません。 入力チェックは最初の保護回路のみですが、決して唯一の保護回路ではありません。



入力データのチェックに加えて、シールドなどの保護方法が頻繁に使用されます。 これにより、新しいコンテキストを入力するたびにデータのセキュリティがチェックされます。 通常、この方法はクロスサイトスクリプティング（XSS）から保護するために使用されますが、フィルタリングの手段として他の多くのタスクで要求されています。



エスケープは、受信者が送信データを誤って解釈することを防ぎます。 しかし、これは十分ではありません-データが新しいコンテキストで到着するので、特定のコンテキスト専用のチェックが必要です。



これは最初の入力時の検証の複製と考えることができますが、実際には、データ要件が非常に異なる場合、追加の検証手順は現在のコンテキストをよりよく考慮します。 たとえば、フォームのデータには割合が含まれる場合があります。 最初の使用時に、値が実際に整数であることを確認します。 しかし、アプリケーションのモデルに移行する場合、新しい要件が発生する可能性があります。値は特定の範囲に収まらなければなりません。これは、アプリケーションのビジネスロジックが機能するために必須です。 また、この追加チェックが新しいコンテキストで実行されない場合、深刻な問題が発生する可能性があります。

ブラックリストではなく、ホワイトリストのみを使用します

ブラックリストとホワイトリストは、入力データを検証するための2つの主要なアプローチです。 黒いものは無効なデータのチェックを意味し、白いものは有効なデータを意味します。 ホワイトリストが望ましいのは、検証中に送信されるのは予想されるデータのみだからです。 同様に、ブラックリストは、考えられるすべての誤ったデータに関するプログラマーの仮定のみを考慮しているため、混乱したり、何かを見逃したり、ミスを犯したりするのがずっと簡単です。



良い例は、テンプレートの非スクリーニング出力に関してHTMLを安全にするために設計された検証手順です。 ブラックリストを使用する場合、HTMLに危険な要素、属性、スタイル、実行可能なJavaScriptが含まれていないことを確認する必要があります。 これは大量の作業であり、ブラックリストに登録されたHTMLクリーナーは常に、コードの危険な組み合わせを見逃してしまいます。 また、ホワイトリストを使用するツールは、許可されている既知の要素と属性のみを許可することにより、この不確実性を排除します。 残りはすべて、それらが何であるかに関係なく、単純に分離、分離、または削除されます。



したがって、ホワイトリストはセキュリティと信頼性が高いため、検証手順に適しています。

入力を修正しないでください

多くの場合、入力検証にはフィルタリングが伴います。 検証中にデータの正当性を単純に評価する場合（正または負の結果が発行される場合）、フィルタリングは特定のルールを満たすようにチェック対象のデータを変更します。



通常、これはやや有害です。 従来のフィルターには、たとえば、電話番号からすべての文字を削除する（数字を除く）（余分な角かっこやハイフンを含む）、不要な水平スペースや垂直スペースを削除するなどがあります。 このような状況では、表示または送信エラーを回避するために最小限のクリーニングが実行されます。 ただし、フィルタリングを使用して悪意のあるデータをブロックすることはあまりにも夢中になります。



入力を修正しようとすることの結果の1つ：攻撃者は修正の効果を予測できます。 無効な文字列値があると仮定します。 検索して削除し、フィルタリングを完了します。 しかし、攻撃者が文字列で区切られた値を作成してフィルターに勝る場合はどうでしょうか？

 <scr<script>ipt>alert(document.cookie);</scr<script>ipt>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、タグによる単純なフィルタリングは何も行いません。明示的な<script>



を削除すると、データはHTMLスクリプトの完全に有効な要素と見なされます。 特定の形式によるフィルタリングについても同じことが言えます。 これはすべて、アプリケーションの最後の保護回路では入力データをチェックできない理由を明確に示しています。



入力を修正しようとする代わりに、ホワイトリストベースのバリデータを使用して、そのような入力試行を完全に拒否します。 また、フィルタリングする必要がある場合は、必ずチェックする前にフィルタリングし、その後にはフィルタリングしないでください。

外部検証ツールを信頼せず、常に脆弱性を監視する

以前、データが新しいコンテキストに転送されるたびに検証が必要であることに注意しました。 Webアプリケーション自体の外部で実行される検証にも同じことが当てはまります。 そのようなツールには、ブラウザーのHTMLフォームに適用される検証またはその他の制限が含まれます。 HTML 5のこのフォームを見てください（ラベルは省略されています）：

 <form method="post" name="signup"> <input name="fname" placeholder="First Name" required /> <input name="lname" placeholder="Last Name" required /> <input type="email" name="email" placeholder="someone@example.com" required /> <input type="url" name="website" required /> <input name="birthday" type="date" pattern="^d{1,2}/d{1,2}/d{2}$" /> <select name="country" required> <option>Rep. Of Ireland</option> <option>United Kingdom</option> </select> <input type="number" size="3" name="countpets" min="0" max="100" value="1" required /> <textarea name="foundus" maxlength="140"></textarea> <input type="submit" name="submit" value="Submit" /> </form>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

HTMLフォームは、入力データに制限を課すことができます。 固定アイテムのリストを使用して選択を制限し、最小値と最大値を設定し、テキストの長さを制限することもできます。 HTML 5はさらに広くなっています。 ブラウザはURLとメールアドレスをチェックし、日付、数値、範囲を制御できます（ただし、最後の2つのサポートはかなり条件付きです）。 ブラウザは、テンプレート属性に含まれるJavaScript正規表現を使用して入力をチェックすることもできます。



この豊富なコントロールをすべて忘れないでください。それらの目的は、アプリケーションの利便性を向上させることです。 攻撃者は、元のフォームからの制限を含まないフォームを作成できます。 自動フォーム入力用のHTTPクライアントを作成することもできます！



外部検証ツールのもう1つの例は、TwitterなどのサードパーティAPIからデータを受信することです。 このソーシャルネットワークは評判が高く、通常は疑いなく信頼されています。 しかし、私たちは妄想的であるため、Twitterを信頼するべきではありません。 妥協の場合、彼の回答では安全でないデータが表示され、その外観については準備ができていません。 したがって、ここでも、何かが起こっても無防備にならないように、独自の検証を使用してください。



外部の検証手段に自信がある場合は、脆弱性を追跡すると便利です。 たとえば、HTMLフォームが最大長に制限を設定し、サイズが制限に達した入力を取得した場合、このユーザーがチェックをバイパスしようとしていると仮定するのは論理的です。 したがって、外部手段にギャップを登録し、潜在的な攻撃に対してさらにアクションを実行して、アクセスまたはリクエストの数を制限できます。

PHPでの型変換を避ける

PHPは強く型付けされた言語ではなく、その機能と操作のほとんどは安全に型付けされていません。 これは深刻な問題につながる可能性があります。 さらに、値自体ではなく、バリデーターは特に脆弱です。 例：

 assert(0 == '0ABC'); // TRUE assert(0 == 'ABC'); // TRUE (    !) assert(0 === '0ABC'); // NULL/     
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バリデータを開発するときは、入力値または出力値が文字列である可能性がある場合、厳密な比較と手動の型変換を使用してください。 たとえば、フォームは文字列を返すことができるため、整数である必要があるデータを操作している場合は、必ず型を確認してください。

 function checkIntegerRange($int, $min, $max) { if (is_string($int) && !ctype_digit($int)) { return false; //    } if (!is_int((int) $int)) { return false; //       PHP_MAX_INT } return ($int >= $min && $int <= $max); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを絶対にしないでください：

 function checkIntegerRangeTheWrongWay($int, $min, $max) { return ($int >= $min && $int <= $max); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、目的の範囲に入る数値で始まる行はすべてテストに合格します。

 assert(checkIntegerRange("6' OR 1=1", 5, 10)); // NULL/  assert(checkIntegerRangeTheWrongWay("6' OR 1=1", 5, 10)); //  TRUE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

型変換の微妙さは、多くの操作や関数に見られます。たとえば、配列内に有効なオプションが存在するかどうかの値を確認するためによく使用されるin_array()



などです。

データ検証の種類

入力データの検証でエラーが発生すると、脆弱性とデータ破損が発生します。 以下のPHPの例では、いくつかのタイプの検証を検討します。

データ型チェック

データの種類が文字列、整数、浮動小数点数、配列などに関連していることを確認します。多くのデータはフォームを介してis_int()



ため、 is_int()



ようなPHP関数を盲目的に使用することはできません。 1つの値は文字列にすることができ、同時にPHPでサポートされている整数の最大値に達します。 KISSの原則に違反する可能性があるため、あまり独創的である必要も、正規表現を使用する必要もありません。

文字検証

文字列に有効な文字のみが含まれていることを確認します。 ほとんどの場合、このためにPHPはctype



関数を使用し、より複雑な場合は正規表現を使用します。 ASCII文字のみが必要な場合は、 ctype



関数にctype



することをお勧めします。

フォーマットチェック

これにより、データが有効な文字の特定のセットと一致するようになります。 鮮明な例は、電子メール、URL、日付です。 PHPのfilter_var()



関数、 DateTime



クラス、および他の形式の正規表現を使用することをおfilter_var()



ます。 形式が複雑になるほど、形式や構文をチェックするための信頼できるツールに頼る必要が増えます。

制限チェック

これにより、値が許容範囲内にあるかどうかが確認されます。 たとえば、5より大きい値、0〜3、または34以外の値のみを受け入れる必要があります。チェック制限は、文字列、ファイルサイズ、画像解像度、日付範囲などにも適用できます。

データチェック

今後の作業に必要なすべてのデータが利用可能かどうかを確認します。 たとえば、登録フォームでは、これはユーザー名、パスワード、メールアドレスです。 何かが入力されていない場合、データが正しくないと見なされます。

データマッチング

このタイプのチェックは、エラーを排除するために2つの同一の値を入力する必要がある場合に使用されます。 たとえば、サイトに登録するときにパスワードを繰り返します。 2つの値が同じ場合、データは正しいと見なされます。

論理チェック

本質的に、これは、受信したデータがアプリケーションでエラーや例外を引き起こさないことを確認したい場合のエラー制御です。 たとえば、検索文字列を正規表現に置き換えると、式のコンパイルエラーが発生する場合があります。 特定の値を超える整数も危険である可能性があります。除算操作中の分母のゼロ、または+ 0、0、–0などの奇妙なものです。

リソースの可用性を確認する

データでリソースが指定されている場合、それが実際に存在するかどうかを確認する必要があります。 これには、ほとんどの場合、存在しないリソースの自動作成、エラーのあるリソースのオープンの除外、およびディレクトリトラバーサル攻撃を実行するためにファイルシステムパスを置換する試みの追加チェックが伴います。

入力ソースの確認

努力にもかかわらず、入力検証はすべてのセキュリティ問題を解決するわけではありません。 多くの場合、ユーザーが入力した情報を確実に検証することは不可能です。 アプリケーションが信頼できると考えられるデータソース（たとえば、ローカルデータベース）で動作する場合、この可能性が高くなります。 データベースの場合、追加のチェックタイプは多くありません。 しかし、たとえばHTTPSを介してAPIから情報を要求する場合など、SSLまたはTLSで保護されたリモートWebサービスの例を見てみましょう。



HTTPSは、攻撃者が2つのデータ交換ポイントの間の仲介者になったときに、中間者（MITM）攻撃から保護する主な方法です。 そのような仲介者はサーバーを装います。 つまり、クライアントはサーバーに接続していると考えています。 実際、要求されたサーバーへの別の接続を作成するのは攻撃者です。 攻撃者はデータを両方向に中継して読み取ることができますが、クライアントもサーバーもこれを認識していません。 さらに、中継者は中継中にデータを変更できます。



このような攻撃を防ぐには、サーバーを偽装し、サーバーとクライアント間で交換されたメッセージを読み取る能力を攻撃者に与える必要があります。 これにはSSL / TLSがあり、2つの主要なセキュリティ機能を実行します。

1. クライアントとサーバーのみがアクセスできる共有キーを使用して、送信されたすべてのデータを暗号化します。
2. サーバーは、信頼できる組織によって発行され、クライアントによって認識される公開証明書と秘密キーを使用して、サーバー自体を識別する必要があります。

SSL / TLS暗号化は任意の2者間で発生する可能性があることに注意してください。 「中間者」攻撃では、クライアントは攻撃している「サーバー」に連絡し、相互データ暗号化の使用について議論し始めます。 この場合、「サーバー」に自分が主張するとおりの人物であることを証明するように依頼しなかったため、それ自体は役に立ちません。 したがって、SSL / TLSの第2段階が必須であり、正式にはオプションです。 Webアプリケーションは、「中間者」攻撃から自身を保護するために、通信するサーバーのIDを検証する必要があります。



暗号化はそのような攻撃から保護するのに十分であると広く信じられており、多くのアプリケーションとライブラリは第2段階を使用しません。 これは、オープンソースアプリケーションで頻繁に検出される脆弱性です。 いくつかの不可解な理由により、 stream_socket_client()



、 fsockopen()



またはその他の内部関数が使用されている場合、PHP自体はデフォルトでHTTPSラッパーのサーバーチェックを無効にします。 例：

 $body = file_get_contents('https://api.example.com/search?q=sphinx');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、中間攻撃の男性に対する脆弱性が明らかです。 このHTTPS要求からのデータは、必要なサービスから受信したと見なすことはできません。 インテリジェントに、サーバーチェックを使用して要求を実行する必要があります。

 $context = stream_context_create(array('ssl' => array('verify_peer' => TRUE))); $body = file_get_contents('https://api.example.com/search?q=sphinx', false, $context);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UPD。 PHP 5.6以降では、ssl.verify_peerオプションはデフォルトでTRUE



設定されています。



cURL拡張機能には、サーバーのチェックアウトが含まれているため、何も構成できません。 ただし、プログラマーは、自分のライブラリーとアプリケーションのセキュリティーについて思いやりなく考えることがあります。 このアプローチは、アプリケーションが依存するライブラリで見つけることができます。

 curl_setopt(CURLOPT_SSL_VERIFYPEER, false);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SSLのコンテキストで、またはcurl_setopt()



を使用しているときにサーバー検証を無効にすると、中間者攻撃の脆弱性が発生します。 ただし、SSL証明書が正しく構成されていないか有効期限が切れているホストへの攻撃またはアプリケーションの接続試行を示す迷惑なエラーの問題を解決するためだけにオフにします。



多くの場合、Webアプリケーションは、ユーザーアクションのプロキシとして、たとえばTwitterクライアントとして機能できます。 そして、私たちにできることは、ユーザーに警告し、疑わしいサーバーへの接続からユーザーを保護しようとする、アプリケーションのブラウザーによって設定された高水準に準拠することです。

結論

多くの場合、安全なアプリケーションを作成するあらゆる機会があります。 しかし、開発、デバッグ、および迷惑なエラー出力の無効化を容易にするために、いくつかの合理的な制限を回避しています。 または、正当な理由のために、アプリケーションのロジックを不必要に複雑化しようとしています。



しかし、ハッカーは自分のパンを食べても無駄ではありません。 . -, — . .