Webアプリケーションのセキュリティ：自分自身と戦うか、適切な線を引く

アプリケーションの安全性はどの程度ですか？ 一部の人にとって、この質問は意味がありません。 「可能な限り。安全であるほど良い。」 しかし、これは完全な答えではありません。 また、彼はプロジェクトのセキュリティポリシーの作成を支援していません。 さらに、この指令（「セキュリティが高いほど良い」）のみを順守する場合、自分自身に損害を与えることができます。 なんで？ 答えは下にあります。

セキュリティはユーザビリティと競合します

追加のセキュリティチェックにより、アプリケーションの利便性が低下します。 これは、主にアプリケーションの2つの部分、認証とパスワード回復に影響します。

SMSの強制送信とパスワードに加えて追加データの入力を含む多要素認証により、ユーザーの生活は少し安全になりますが、満足度は低下します。 そして、サービスの本質が猫と写真を交換できることである場合、ユーザーは自分の経験をより安全にするためにあなたの熱意に感謝しないかもしれません。

認証エラーが発生した場合、セキュリティのベストプラクティスでは、攻撃者がユーザーデータベースを収集できないように、エラーが発生した可能性のある場所に関する情報をできるだけ少なくすることをお勧めします。 これらの推奨事項によると、サイト訪問者が33の認証手順を経てフィールドの1つでタイプミスをした場合、最善のセキュリティソリューションは「ごめん、何かがうまくいきませんでした。もう一度やり直してください」です。 開発者のおかげで、サイトセキュリティシステムの高貴な意図に対する誠実な賞賛は、この場合にユーザーが感じる感情ではありません。

特定のセキュリティプラクティスを実装する場合、ユーザーエクスペリエンスがどのような場合にどの程度悪化するかを明確に理解する必要があります。 そして、それがアプリケーションに特に必要かどうかを決定します。

セキュリティにより、アプリケーションの開発と保守が難しくなります。

アプリケーションが実装するセキュリティが高いほど、開発が難しくなります。 セキュリティをわずかに改善するために、個別の機能を記述する期間は数倍長くなる場合があります。

多くの活動は、実際に脆弱性から保護するためではなく、サイバー犯罪者の生活をより悲惨にするために費やされる可能性があります。 この場合の極端な例として、REST APIメソッドとそのパラメーターの名前の難読化を挙げることができます。

多くの場合、開発者は、ログイン、登録、またはパスワード回復フォームを使用して、攻撃者がユーザー名のデータベースを収集するのを防ぐことに多くの時間を費やします。

アプリケーションがユーザーを攻撃者としてマークするが、それに関する情報を提供しない場合にアプローチを考え出すことができます。 ユーザーのリクエストは単に無視されます。

多要素認証に、ユーザーごとに個別の「秘密の質問」が含まれている場合、存在しないユーザー名については、アプリケーションに秘密の質問が表示される場合があります。 さらに、Webアプリケーションは、同じ情報を一貫して要求するために、この存在しないユーザーの名前と初めて表示された質問をセッションまたはデータベースに保存できます。

攻撃者を混乱させる方法は他にも数百あります。 しかし、もちろん、実装には時間がかかります。 これらのメカニズムは、優れたコードと付随するコメントがあっても、理解およびサポートすることが非常に困難な場合があります。 しかし、最も重要なことは、これらのことは脆弱性をカバーしておらず、これらの脆弱性の検索を複雑にするためだけに行われているということです。

「優れた設計と安全な機能」を「想像上のハッカーによるクレイジーマインドゲーム」と区別することは必ずしも容易ではありません。 さらに、この境界線は、アプリケーションが潜在的な攻撃者を引き付ける方法に応じて変動します。

セキュリティにより、アプリケーションのテストが難しくなります

すべてのルールとチェックをテストする必要があります。 単体テスト、統合テスト、手動テスト-特定のセキュリティメカニズムごとにどのアプローチを使用するかを決定する必要があります。

ただテストすることはできません。 エラーがコードに忍び込むからです。 そして、最初にエラーなしですべてを書いたとしても、サポート、修正、リファクタリングの過程で間違いなくエラーが発生します。 誰もすぐにレガシーコードを書くことはありません。 徐々にレガシーコードになります。

ビジネス機能が厳密なテストを受ける場合、完全に合理的ではありませんが、セキュリティメカニズムは破壊不可能、非の打ちどころのない、絶対的なものと見なされます。

これらすべてを手動でテストする場合、どのくらいの頻度で問題が発生します。 REST APIを使用して多少なりとも洗練されたWebアプリケーションがある場合、数百ではないにしても、数十の場所に潜在的に壊れた認証が潜む可能性があります。 脆弱性の典型的な例は、HTTPリクエストで何らかのパラメーター（ユーザーIDなど）を変更し、アクセスできないはずの情報が返される状況です。 同様のすべてのケースをチェックすることは、巨大な作業です。 すべてのメジャーリリースの前にこれを行う必要がありますか？ このために個人を選択する必要がありますか？ または別のチームですか？

これらの問題は重要です 壊れた認証を有効にするのは非常に簡単です。 モデルの変更、および新しいRESTメソッドでは、この脆弱性が現れるかどうかを常に考慮する必要があります。 普遍的でシンプルなソリューションはありません。 しかし、プロジェクトが問題に一貫して対処できるようにするさまざまなアプローチがあります。 たとえば、CUBAプラットフォームでは、 ロールとアクセスグループを使用して 、誰でもアクセスできるエンティティを設定できます。 ルールの構成にはまだ多くの作業がありますが、これらのルールには一貫性と一貫性があるため、メンテナンスが容易です。

壊れた認証に加えて、チェックする価値があるセキュリティの問題が多数あります。 そして、新しいチェックとメカニズムを導入して、これがどのようにテストされるかを考える必要があります。 長期間にわたってテストされていないものは壊れがちです。 そして、通常のセキュリティがないだけでなく、それが存在するという誤った保証もあります。

特定の問題は、2つのカテゴリの防御メカニズムによって引き起こされます。生産のみに含まれるものと、第2（第3、第4）レベルの保護を表すものです。

プロダクションでのみ実装される保護。 セッショントークンCookieにhttpsチェックボックスが必要だとしましょう。 ただし、テスト環境でhttpが使用されている場合、これはテストと実稼働用に別々の構成があることを意味します。 したがって、使用するものが正確にテストされていません。 また、移行中または一部の変更中にこのチェックマークがオフになった場合、すぐに気付かない場合があります。 この問題を解決するには？ 運用前に別の環境を導入しますか？ その場合、機能のどの部分をテストするのですか？

マルチレベル保護。 セキュリティに精通した人々は、最初の障壁が破られた場合にのみチェックできる保護を作成することを好みます。 アイデアは合理的です。 攻撃者が最初の階層で脆弱性を見つけたとしても、彼は2番目に閉じ込められます。 しかし、それをテストする方法は？ 典型的な例は、アプリケーションのユーザーごとに異なるdbユーザーを使用することです。 RESTに壊れた認証が含まれている場合でも、攻撃者はデータを編集/削除できません。 彼のdbユーザーには権限がありません。 もちろん、これらの構成は廃止され、サポートおよびテストされていない場合は機能しなくなります。

多くのセキュリティは、アプリケーションの安全性を低下させる可能性があります。

セキュリティチェックが多いほど、複雑さが増します。 複雑さが大きいほど、ミスを犯しやすくなります。 間違いを犯す可能性が高いほど、セキュリティは悪化します。

もう一度ログインフォームを見てください。 2つのフィールド（ユーザー名とパスワード）を持つログインは簡単に実装できます。 システムにそのようなユーザーがいるかどうか、およびパスワードが正しく入力されているかどうかを確認するだけです。 まあ、あなたはまた、ログイン/パスワードがURLパラメータではなく、リクエストの本体にあることを確認する必要があります。 アプリケーションがエラーがログインまたはパスワードのどこにあるかを示唆しないことを確認することをお勧めします-そのため、ユーザーのリストを使用してデータベースを収集することはできません（この項目は、より良いユーザーエクスペリエンスの名前で一部のアプリケーションでは無視できます）。 そして、反ブルートフォースメカニズムが実装されていることを確認する必要があります。 もちろん、これはフェールオープンの脆弱性に耐える必要があります。 さらに良いことに、クラッカーに「クラッカー」とマークしたことを示さず、単にリクエストを無視し始めたら-彼がログインに侵入していると考え続けてください。 はい、送信されたパスワードをログのどこにも記録しないことを忘れないでください。 まあ、そしてあなたが覚えておく必要があるいくつかの微妙な点。 一般に、2つのフィールドを持つ通常のログインフォームよりも単純なものは何ですか？

もう1つは、多要素認証です。 メールまたはSMSで何らかのトークンを送信する場所。 または、追加データを入力する必要がある場所。 または、いくつかの手順を実行して、自分に関する情報を徐々に入力する必要があります。 これはすべて複雑です。 理論的には、これらの追加チェックはすべて、ハッキングの可能性を減らすはずです。 すべてが正しく実装されていれば、これは事実です。 ハッキングの可能性は残りますが（SMS、電子メールメッセージ、またはハッキングに対する100％の保証はありません）、減少します。 しかし、すでに非常に複雑な認証ロジックはさらに複雑になり、どこかで間違いを犯しやすくなります。 少なくとも1つのエラーまたは1つの誤った仮定が存在するため、このモデル全体は、2つのフィールドを持つ単純なフォームよりも安全性が低くなります。

さらに、迷惑で不便なセキュリティ対策により、ユーザーは情報の安全性が低下する可能性があります。 たとえば、企業ネットワークで毎月パスワードを変更する必要がある場合、これらの奇妙な要件を完全に理解できないユーザーは、ステッカーにパスワードを書き始め、モニターに貼り付けるだけです。 「これは、ユーザーがこのような愚かな間違いを犯した場合のユーザーの問題です」-あなたは反対することができます。 しかし、違います。 これがあなたの問題です。 最後に、アプリケーションを作成するのはこれらの同じユーザーではないのですか？

いいね 何を提案しますか？

開発の最初から攻撃者を欺くためにどこまで進んでいくかを決めることをお勧めします。 ログイン要求への応答時間がその名前のユーザーが存在するかどうかを決して出さないように、ログインフォームを最適化する準備ができていますか？ ハッキングの被害者の友人が電話を手に持っていて、コンピューターからでも私たちのアプリケーションに入ることができないような認証チェックを実装する準備はできていますか？ 時には開発を複雑にし、予算と開発時間を大幅に増やし、攻撃者の生活をもう少し複雑にするために優れたユーザーエクスペリエンスを犠牲にする準備はできていますか？

セキュリティに無限に取り組み、新しいレベルの保護を強化し、ユーザーの行動の監視と分析を改善して、情報の取得を困難にすることができます。 私たちがすべきこととする必要のないことから私たちを隔てる線がなければなりません。 もちろん、プロジェクトの開発中に、この機能を再考して変更することができます。

最悪のシナリオでは、別の場所のアプリケーションに大きなセキュリティ違反がある場合、プロジェクトは1つのタイプの攻撃に対して侵入できない壁を構築するために多くのリソースを費やすことができます。

特定のセキュリティメカニズムを使用するか、別のレベルの保護を設定するかを選択する際には、多くの要因を考慮する必要があります。

• この脆弱性の悪用はどれくらい簡単ですか？ 壊れた認証は非常に使いやすく、このための技術的な背景を必要としません。 したがって、この問題にはかなりの注意を払う必要があります。
• この脆弱性はどれほど重要ですか？ 攻撃者が他のユーザーの情報にアクセスしたり、他のユーザーの情報を変更できる場合、これは明らかに非常に重要な問題です。 攻撃者がシステム内の特定の製品のIDを収集できるが、これらのIDで何もできない場合、問題の重要性は数倍低くなります。
• サイトのセキュリティを実装すると、どれだけ増加しますか？ 最初の保護レベルではない場合（たとえば、前post基地をサニタイズするための適切なメカニズムが既に実装されている場合に入力のXSS問題をチェックする）、または攻撃者をさらに混乱させるだけの場合（アクションをブロックする代わりに、リクエストを無視して、 「攻撃を認識しなかったということです）-これらの変更の優先度は、実装する必要がある場合でもそれほど高くありません。
• どれくらい時間がかかりますか？
• この変更の結果、ユーザーエクスペリエンスはどの程度悪化しますか？
• 保守とテストはどれくらい難しいですか？ 禁止されているリソースにアクセスしようとすると403コードを使用せず、常に404を返すため、既存の識別子に関する情報を収集するのが難しくなります。 このソリューションは、理にかなっており、実際に攻撃者の生活をより困難にしますが、同時に、テスト、生産のエラーの分析を複雑にし、ユーザーにこれを取得する十分な権限がないことを伝えるのではなく、ユーザーの肯定的なエクスペリエンスに影響を与える可能性がありますリソース、そのようなリソースは原則として存在しないと言います。

はい 特定のケースでは、複雑な多要素認証が必要になる場合があります。 しかし、サポートと開発がどれほど難しいか、そしてこれがどれほどアプリケーションのユーザーフレンドリー性を低下させるかを認識しておく必要があります。

セキュリティの怠慢を正当化する

まさか。 ユーザーエクスペリエンスと開発コストを犠牲にしても、追加の保護が必要になる可能性のあるセキュリティに敏感なアプリケーションがあります。

まあ、とにかく、アプリケーションの目的に関係なく、持つことが許されない脆弱性がいくつかあります。 CSRFはそのような脆弱性の例です。 明らかにそれと戦うことは、ユーザー体験を悪化させず、開発を大きく複雑にしません。 多くのサーバー側（Spring MVCなど）およびクライアント側（Angularなど）のフレームワークにより、CSRFトークンをすぐにサポートできるようになります。 さらに、同じSpring MVCを使用して、いくつかの必要なヘッダー（Access-Control- *ヘッダー、Content-Security-Policy）を追加することも非常に簡単なタスクです。

壊れた認証、XSS、SQLインジェクション、およびその他の脆弱性は、アプリケーションでは見つかりません。 それらからの保護は理解しやすく、多数の本や記事の棚にまとめられています。 ここでは、URLパラメーター内の機密情報の転送または弱くハッシュされたパスワードの保存が適用されます。

理想的には、プロジェクトはセキュリティポリシーを管理するマニフェストを持つ必要があります。何をどのように保護するか、パスワードポリシーの説明、テスト対象などです。 このマニフェストは、プロジェクトごとに異なります。 オペレーティングシステムコマンドへのユーザー入力の挿入があるプロジェクトには、インジェクションOSコマンドに対する保護の説明が含まれます。 ユーザーが自分のファイルをサーバー（アバターを含む）にアップロードできるプロジェクトでは、この場合に現れる可能性のある基本的な脆弱性の説明が必要です。

もちろん、そのようなマニフェストを書いて維持するのは簡単なことではありません。 しかし、チームの各メンバー（テストチームとサポートチームを含む）がプロジェクトで従うべきプラクティスを記憶し、それらを一貫して一貫して実装することを希望することは単純です。 さらに、問題は多くの脆弱性に対して、いくつかの防止オプションがあることです。 また、明確に定義されたポリシーがない場合、ある場所ではあるプラクティス（たとえば、入力パラメーターの検証）が適用され、別のプラクティスでは-逆（たとえば、出力パラメーターの検証）が適用される場合があります。 一部の場所では、サニタイズが使用され、一部では検証エラーの開始が使用されます。 また、これらのさまざまなメカニズムが非常にうまく実装されていても、バグが発生したり、サポートが困難になったり、コードに関する誤った期待が形成されたりするための不整合は良い場所です。

チームが小さく、テクニカルマネージャーが変更されておらず、セキュリティポリシーが開発されている場合、マニフェストがなくてもこのような問題を回避するには、絶え間ないコードレビューで十分です。

結論：

• セキュリティに取り組むとき、サイトがセキュリティに対してどれだけ敏感であるかを考慮する必要があります。 銀行アプリと逸話公開アプリには、異なるアプローチが必要です。
• セキュリティに取り組む場合、変更の結果としてユーザーエクスペリエンスがどの程度悪化するかを考慮する必要があります。
• セキュリティに取り組むときは、この決定によってコードがどれほど複雑になり、サポートがより苦痛になるかを考慮する必要があります。
• セキュリティメカニズムをテストする必要があります。
• チームでは、セキュリティの問題に関する教育活動を導入するか、作業全体を徹底的なセキュリティレビューにかけることをお勧めします。
• 任意のレベルのWebアプリケーション（xss、xsrf、インジェクション（SQLを含む）、壊れた認証など）を取り除くことが望ましい脆弱性があります。