バックエンド

10最も一般的なWebセキュリティの脆弱性

あまりにも多くの企業にとって、それは 後 セキュリティ違反が発生しました Webセキュリティのベストプラクティスが優先事項になります。 ITセキュリティの専門家として働いていた数年間、Web開発のセキュリティ問題の世界が私の多くの人にとってどれほど曖昧になるかを何度も目にしました。 仲間のプログラマー 。

Webセキュリティの脅威に対する効果的なアプローチは、定義上、予防的かつ防御的でなければなりません。その目的に向けて、この投稿はセキュリティの考え方を刺激することを目的としており、読者に健康的な量のパラノイアを注入することを願っています。

特に、このガイドでは、Webセキュリティの10の一般的で重要な落とし穴に焦点を当てており、それらを軽減する方法に関する推奨事項も含まれています。焦点は Webの脆弱性トップ10 によって識別されます オープンWebアプリケーションセキュリティプロジェクト（OWASP） 、世界中のソフトウェアセキュリティを向上させることを目標とする国際的な非営利団体。



誰も直面したくない一般的なWebの脆弱性の例。

始める前のちょっとしたサイバーセキュリティ入門書–認証と承認

他のプログラマーやIT専門家と話すとき、認証と認証の違いについて混乱することがよくあります。そしてもちろん、略語という事実 auth 両方によく使用され、この一般的な混乱を悪化させるのに役立ちます。この混乱は非常に一般的であるため、この問題は「Common WebVulnerabilityZero」としてこの投稿に含める必要があります。

したがって、先に進む前に、これら2つの用語の違いを明確にしましょう。

  • 認証： 個人が特定のユーザーである（または少なくともそのように見える）ことを確認します。これは、そのユーザーがセキュリティ資格情報（パスワード、セキュリティの質問への回答、指紋スキャンなど）を正しく提供しているためです。
  • 承認： 特定のユーザーが特定のリソースにアクセスできること、または特定のアクションを実行するためのアクセス許可が付与されていることを確認します。

別の言い方をすれば、 認証 エンティティが誰であるかを知っている間 承認 特定のエンティティが何ができるかを知っています。これを念頭に置いて、インターネットセキュリティの問題トップ10に入りましょう。

一般的なWebセキュリティの間違い＃1：インジェクションの欠陥

インジェクションの欠陥は、信頼できない入力をフィルタリングするという古典的な失敗に起因します。これは、フィルタリングされていないデータをSQLサーバー（SQLインジェクション）、ブラウザー（XSS –これについて説明します）に渡すときに発生する可能性があります。 後で ）、LDAPサーバー（LDAPインジェクション）、またはその他の場所へ。ここでの問題は、攻撃者がこれらのエンティティにコマンドを挿入し、データを失い、クライアントのブラウザを乗っ取る可能性があることです。

アプリケーションが信頼できないソースから受け取るものはすべてフィルタリングする必要があります。 できればホワイトリストに従ってください。ブラックリストを正しく取得するのは非常に難しく、通常はバイパスしやすいため、ブラックリストを使用することはほとんどありません。ウイルス対策ソフトウェア製品は通常、失敗したブラックリストの優れた例を提供します。パターンマッチングは機能しません。

防止： 良いニュースは、インジェクションから保護することは、入力を適切にフィルタリングし、入力が信頼できるかどうかを考えることの「単純な」問題であるということです。しかし、悪いニュースはそれです すべて 間違いなく信頼できる場合を除いて、入力は適切にフィルタリングする必要があります（ただし、ここでは「決して言わない」という言葉が思い浮かびます）。

たとえば、1,000個の入力があるシステムでは、999個の入力を正常にフィルタリングするだけでは不十分です。これは、システムをダウンさせるためのアキレス腱として機能できるフィールドが1つ残っているためです。また、データベースは信頼されているため、SQLクエリの結果を別のクエリに入れるのは良い考えだと思うかもしれませんが、境界が信頼されていない場合、入力は悪意のある人から間接的に行われます。これは呼ばれます 二次SQLインジェクション 興味がある場合に備えて。

フィルタリングは（暗号のように）正しく行うのがかなり難しいので、私が通常アドバイスするのは、フレームワークのフィルタリング機能に依存することです。それらは機能することが証明されており、徹底的に精査されています。フレームワークを使用しない場合は、本当に ない それらを使用することは、サーバーのセキュリティコンテキストで本当に意味があります。 99％の確率でそうではありません。

一般的なWebセキュリティの間違い＃2：認証の失敗

これは、認証の失敗中に発生する可能性のある複数の問題のコレクションですが、すべてが同じ根本原因に起因するわけではありません。

誰かが2014年にまだ自分の認証コードをロールしたいと思っていると仮定すると（あなたは何を考えていますか??）、私はそれに反対することをお勧めします。正しく理解することは非常に困難であり、いくつか言及するだけで、考えられる落とし穴は無数にあります。

  1. URLにセッションIDが含まれていて、それをリファラーヘッダーで他の誰かに漏らしている可能性があります。
  2. パスワードは、ストレージでも転送でも暗号化されていない可能性があります。
  3. セッションIDは予測可能である可能性があるため、アクセスを取得するのは簡単です。
  4. セッション固定が可能かもしれません。
  5. セッションハイジャックが可能である、タイムアウトが正しく実装されていない、またはHTTP（SSLセキュリティなし）を使用しているなど…

防止： このWebセキュリティの脆弱性を回避する最も簡単な方法は、フレームワークを使用することです。これを正しく実装できるかもしれませんが、前者の方がはるかに簡単です。独自のコードを作成したい場合は、非常に偏執的になり、落とし穴について自分自身を教育してください。かなりの数があります。

一般的なWebセキュリティの間違い＃3：クロスサイトスクリプティング（XSS）

これはかなり広範囲にわたる入力サニタイズの失敗です（本質的には よくある間違い＃1 ）。攻撃者は、入力時にWebアプリケーションにJavaScriptタグを与えます。この入力がサニタイズされていないユーザーに返されると、ユーザーのブラウザがそれを実行します。リンクを作成してユーザーにクリックするように説得するのと同じくらい簡単な場合もあれば、もっと不吉なものにする場合もあります。ページの読み込み時にスクリプトが実行され、たとえば、攻撃者にCookieを投稿するために使用できます。

防止： シンプルなウェブセキュリティソリューションがあります。HTMLタグをクライアントに返さないでください。これには、HTMLインジェクション、つまり攻撃者がプレーンなHTMLコンテンツ（画像や大音量の​​非表示のFlash Playerなど）をインジェクトする同様の攻撃から防御するという追加の利点があります。通常、回避策は単にすべてを変換することです HTMLエンティティ 、したがって、