10月は国家サイバーセキュリティ認識月間です！OWASP TOP 10 で、不法で損害を与えるサイバー攻撃からアプリケーションやビジネス、顧客をどのようにして守るかを思い出しましょう。そうすることで、正しい場所に正しい手順で予防できます。
OWASP とは何か？
Open Web Application Security Project は非営利団体で、Web アプリケーション セキュリティについての認識を高め、アプリケーションやインフラストラクチャ、内部プロセスに予防策をインストールする方法の手引きを提供して皆さんを助けるために設定されました。
この団体にはセキュリティトレーニングで使用される安全でない_ JavaScript アプリケーション_を含む複数のプロジェクトがありますが、今回ここで取り扱うのは OWASP Top 10 です。
OWASP Top 10 は定期的に更新され、今日 Web アプリケーションに影響を与える主なセキュリティ脅威をリストアップしています。それぞれの脅威について説明しており、できるだけ脅威を軽減するために行う点を要約しています。Auth0 では、以下の主な問題を軽減する対策を講じていますから、お客様の認証ニーズを当社に委託されるとき、多くの問題点が解消されます。
脅威のリストで、独自のアプリケーションをどのようにセキュアにし、脅威を軽減したりあるいは脅威全体を取り除いたりするのに役立つ Auth0 プラットフォームの機能を調べていきましょう。
第１：インジェクション
クラシックな SQL インジェクションはよく知られた攻撃で、特にレガシ コードなどは長期にわたって存在するものです。OWASP は SQL インジェクションを一般的な攻撃として認識し続けており、アプリケーションの短所を悪用したり検出したりするのは簡単でないというだけでなく、攻撃による悪用が成功した場合に壊滅的な影響を及ぼします。
ほとんどの場合、このタイプの攻撃は次の理由で成功します。
- アプリケーションが SQL クエリで直接サニタイズされていないユーザー入力に依存する
- クエリ―自体がパラメーター化されていない
すべてのユーザー入力は悪意がある可能性があるとして仮定することはユーザー入力を検証し、処理するときに持つべき良い信念です。SQL _クエリをパラメーター化_することも好ましくない損害を与える方法で操作する無効なクエリからデータ ストアを守るのに役立ちます。
SQL クエリのパラメーター化がどのようなものかは、次のような新規ユーザーをデータベースに挿入するクエリを想像してみてください。
sql = db.prepare "INSERT INTO users (name, email) VALUES ('#{name}', '#{email}')" sql.execute
上記のコード スニペットでは、
nameemailsql = db.prepare "INSERT INTO users (name, email) VALUES (?, ?)" sql.execute 'some_user', 'some_user@email.com'
この場合、値は SQL ステートメントに含まれる前に、データベース ライブラリによってエスケープされたり、サニタイズされたりできます。このようにして、SQL ステートメントはデータに損害を与えたり公開したりしかねないように変形されません。
最近では、NoSQL _インジェクション_は Mongo のような NoSQL データベースを使用するときの要因になってきています。SQL を使用しませんが、ユーザー入力は、検証やサニタイズされていないときにクエリ自体が操作されるので攻撃を受けやすくなる可能性があります。ユーザー入力を検証して、想定されたフォームに準拠しない値を拒否することは良い戦略です。
SQL および NoSQL インジェクション攻撃はインジェクション攻撃の広いカテゴリの中の単なるサブセットであり、それにはコマンド, 記述言語 および LDAP も含まれます。
第2：認証の不備
Auth0 が気にかけているのは認証の不備で、OWASP では簡単に利用可能で、損害の可能性が非常に高いと認めています。
「認証の不備」は次を含むアプリケーションやサーバーでユーザーを認証するために行うことを多数取り上げています。
- 既知のパスワードリストを使う自動化されたブルート フォース攻撃
- 脆弱または良く知られたパスワードのアクセス許可
- プレーンテキストまたは強いハッシュよりも弱いハッシュのパスワードの格納
- 多要素認証(MFA)の使用
- ログアウトするとき、またはアイドル時間後の不適切なセッションの無効化
MFA をアプリケーションに実装することで、攻撃者はタイムリーに、自動化された方法で MFA ステップを完了することができないので、「_Credential Stuffing 攻撃」（クレデンシャルスタッフィング攻撃）やブルート フォース攻撃の対策に役立ちます。パスワードについては、一般的なパスワードリストを使って弱いまたはよく知られたパスワードを検証し、強いハッシュアルゴリズム（Bcrypt または [PBKDF2_](https://en.wikipedia.org/wiki/PBKDF2) など）を使ってユーザーのパスワードをハッシュしてください。MD5 のような弱いハッシュは絶対に使用しないでください。または絶対にパスワードをプレーンテキストで保管しないでください。
ユーザーが誤ったユーザー名やパスワードを入力したときに、意図的に漠然としたログインの失敗メッセージを表示するのも良いプラクティスです。そうでなければ、攻撃者は攻撃を引き起こすために使って、有効なアカウントを特定できるかもしれません。
Auth0 _汎用 ログイン_を使うとき、クロスサイトスクリプティング（XXS）攻撃や強いパスワードハッシュを含む、ブルート フォース攻撃のほとんどの問題が処理されます。さらに、セキュリティのレベルを上げるために電源をオンにしてMFA _をアプリケーションに統合する_のを簡単にしています。
第3：機密データの露出
この OWASP Top 10 の記述では攻撃が成功したときに機密データが露出されないようにすることを扱っており、それはその他の攻撃を妨げることにも役立ちます。機密データを安全に処理し、保存データを暗号化し、必要な期間に必要なだけのデータのみを保持するよう努力することについて記載されています。EU の 一般データ保護規則（GDPR） が今日存在する理由のひとつは機密個人データの間違った処理のためです。
アプリケーションから機密データが盗まれないようにする方法の一部には次があります。
- 確実に Web トラフィックを暗号化し、有効な SSL 証明書を使って HTTPS 上で送信し、安全でない接続を可能な場合に更新する_(HSTS)。Let’s Encrypt_ は無料 SSL 証明書を発行し、確実に Web トラフィックを簡単に安全にしている
- 機密情報を含むブラウザーの Cookie を暗号化し かつ 署名する
- 必要なくなった機密データを削除する
- Bcrypt や PBKDF2 のような強いハッシュ アルゴリズムを使ってパスワードをハッシュする
- 機密保存データを暗号化する
自動データベース暗号のテクノロジーを使っても SQL インジェクション攻撃が成功すれば、データが読み込まれ、データベース レベルで暗号化されなければならないのでさらされたままです。コア アプリケーション ロジックの一貫として行う暗号化・解読ステップはこの防止に役立ちます。
第4：XML 外部エンティティ（XXE）
XXE 攻撃は不完全に設定された XML パーサーの脆弱性をさらすように設計されています。このような攻撃は機密データをさらしたり、リソース上のサービス拒否攻撃（DoS）を呼び出すために使用されます。
この種の攻撃を防ぐには開発者の教育と正常に構成された XML パーサーによって左右されます。パーサーの特定の要件がない限り、ドキュメントの型宣言:（DTD）を検証・処理しないで、DTD 内の外部エンティティの解像度や処理を無視しないで構成しなければなりません。
できれば、XXE の影響を受けやすくない JSON のような別の、よりシンプルなデータ形式を使ってください。
第5：壊れたアクセス制御
アプリケーションがアクセス特権やアクセス許可を基にしてユーザーを区別する機能があれば、攻撃者が持つべきでないアクセス許可を高めることができる壊れたアクセス制御の脆弱性を開くことになります。その一部の例には次があります。
- ユーザーがログインしていないときに、またはページを見るための該当する権限がないときに「メンバー専用」ページへのアクセス防止に失敗する
- ユーザーによって変更可能な URL パラメーターを検証しない（他のユーザーからあるユーザー ID をスワップするなど）
- 値はユーザーの役割を決めるために使用する場合に Cookie の値が変更されていないと信頼する。Cookie の暗号化と署名の両方を確認することで、その値が変更されていないという自信を得ることになる
ユーザーのアクセス許可を検証して注意することが重要です。ユーザーができることでうまくいっているときは、そのユーザーが変更できる入力を信頼しないでください。
第6：セキュリティ設定のミス
この Top 10 リストのこの記載は悪用が簡単で、発見が簡単で、極めて一般的なものとして OWASP が特定しました。その懸念には次があります。
- ホスト システム上の時代遅れのセキュリティ パッチ
- アプリケーション フレームワークのセキュリティ機能がオンになっていない、または設定が不適切
- 既定のアカウント、パスワード、およびセキュリティ キーが有効なまま、または変更されないまま
- 未使用または既定のポート、サービスがホストシステム上で有効なまま
- 詳細エラーページまたはディレクトリ一覧がオンのまま
アプリケーションを実行しているホストシステムのセキュリティ パッチが最新のもので更新され、アプリケーション フレームワークの適切なセキュリティ機能がオンになっていることを確認することが重要です。
この分野でもうひとつ重要なことは、第三者のプラットフォーム（Auth0 など）の秘密キー、特にアプリケーションがオープンソースの場合は 残りのコードがソース管理プロバイダにコミットされ、アップロードされていないようにしてください。これらは攻撃者が自動化ツールでスキャンできます。これらキーはソースコードとは別に保管することをお勧めします。
第7：クロスサイト スクリプト（XXS）
XXS は長い間使われている用語のひとつで、ほとんどのソフトウェア開発者が知っているものですが、非常に一般的で簡単に利用可能な攻撃ベクトルとして特徴付けられています。
この手の攻撃はほとんどの場合、サニタイズされていない入力の挿入が関係し、ユーザーがうっかりと悪意のあるサイトやファイルにふれたことが原因ですが、次の異なる種類が入ります。
- 反射型 XXS：ある Web サイトで URL を通して適切にサニタイズされていない入力が見つかりました。攻撃者はその Web サイトにリンク（攻撃を含む）を作り、疑うことを知らない受信者がそのリンクをクリックすることを願いながら、通常電子メールを通して配信します。受信者がクリックすると、その攻撃は実行され、さらにユーザーのセッションや Cookie を盗むスクリプトをダウンロードし、攻撃者にそれらを送信します。
- 格納型 XXS：未検証のユーザー入力（ファイルなど）が、後でユーザーや管理者が開くことができる場所にアップロードされたり格納されたりします。これは、その入力が適切にサニタイズされていないフォーラムやソーシャルメディアでユーザーが提供したコメントにも拡がります。
- DOM XSS：DOM は悪意のあるコンテンツを含みかねない JavaScript API を呼び出し、ランタイムに挿入された結果、操作されたものです。
XXS 問題の大半は第三者ソースから取得したデータはコンテキストに従って適切にエンコードされれば、軽減されるものです。また、ユーザー入力をサニタイズするビルトインのメカニズムを含むフレームワークを使うことで（Ruby on Rails や Play Framework など）この手の攻撃からアプリケーションを守る大きな役目を果たします。
第8：安全でない逆シリアル化
安全でないデシリアライゼーション攻撃は悪用が難しく、Top 10 にあるその他のベクタほど一般的ではありませんが、OWASP は業界調査の結果として含まれていることを指摘しています。言うまでもなく、攻撃者がこの手の攻撃で成功した場合、リモートコード実行の攻撃に導かれる可能性があり、潜在的に非常に重大なものです。
アプリケーションが信頼されていないソースからのオブジェクトを逆シリアル化すると、この手の攻撃を受けやすくなります。このようなことが起きないようにする唯一安全な方法は信頼できない場所からのシリアル化されたオブジェクトを受け入れないことです。それが可能でない場合は、OWASP はデジタル署名を使って整合性を検証し、厳しくプリミティブ型を確認し、特権の低い環境においては逆シリアル化ロジックを実行することを勧めています。
第9：既知の脆弱性でコンポーネントを使用する
今日のソフトウェアはたくさんの第三者コンポーネンツを使用する傾向があるので、使用するコンポーネントのバーションについて熱心になり、それらを最新のものに保つことが、脆弱性の依存関係から発生する攻撃からアプリケーションを守るには最重要事項です。
残念なことに、アプリケーション使用に与えられた依存関係の数は、直接的または間接的にかかわらず、攻撃を受けやすいコンポーネントを識別したりトリアージしたりするのを困難にします。つまり、開発者が作業を終えることができず、その存在にまったく気づかずにいることになります。
OWASP はセキュリティ リスクを表すコンポーネントを特定し更新するのに役立つ、独自の OWASP _依存関係チェック_を含むツールを数点推奨しています。NPM バージョン 5.10.0 または 6 以降を使用する Node.js アプリケーションは端末の
コマンドを使用でき、攻撃を受けやすいと特定されている依存関係を特定し、自動的にアップグレードできます。audit
依存関係の脆弱性をチェックする人気の高いもうひとつのツール（Auth0 でも使用しています）は Snyk です。Snyk は直接 GitHub のプロジェクトを評価するために設定したり、プロジェクトコードで直接実行するコマンドライン_ ツール_として使用できます。
第10：不十分なログと監視
違反や攻撃パターン、ユーザー アクティビティを検出することができることはシステム保護のキープロパティです。十分なログとアプリケーション監視がないと、システムがどのようにしてセキュリティ違反を受けたか、どこからセキュリティ違反が発生したか、アプリケーション セキュリティの戦略のどこに穴があったかなどを解明するのが難しくなります。どこに穴があるかを知らないと、そこを埋めることはできません！
OWASP ではアプリケーションの活動、特に認証やアクセス許可の活動が一元ログシステムで簡単に処理できるような共通な形式でログすることを推奨しています。できるだけ多くのユーザー コンテキストの詳細がログされ、できるだけ個人データが侵害を受けないように保持してください。個人データは個人を特定できる情報（PII）だけでなく、セキュリティ キー、アクセス トークン、セッション トークンも含みます。個人を特定するために使用する詳細情報が法医学的目的で記録されなければならない場合は、信頼できる個人だけが使用できる厳しいアクセス制御と一体となった安全なデータ ウェアハウスを使用してください。
Auth0 でセキュリティ問題を軽減する
Auth0 プラットフォームにはアプリケーション保護やセキュリティ攻撃からユーザーを守るのに役立つ機能がたくさんあります。初心者の方は当社の汎用ログインをご利用いただくと、ログインページを安全にし、攻撃に対する回復力を高めるあらゆる作業を当社が行います。
さらに、多要素認証（MFA）は任意のアプリケーションで簡単に有効にでき、ユーザーがログインして認証されていないアクセスの可能性を高めたときにセキュリティ レイヤーを増やすことができます。MFA ステップを完了するオプションにはモバイル認証アプリを通してプッシュ通知やコードを受けることも含みます。
Auth0 の 異常検出にはブルート フォース攻撃からの保護、ログインしようと繰り返すブロック化、無許可の試行について指定受信者への通知などのオプションが含まれます。さらに、パスワードの侵害の検知機能を有効化すると、ユーザーは資格情報がセキュリティ違反して発行されて検知すると、通知を受けます。
包括的なログは Auth0 プラットフォームの機能で、次のようなイベントを問い合わせます。
- 無効なログイン
- パスワード変更を失敗する
- アクセス トークンの交換で失敗する
- 失敗が多過ぎる
その他多数。ログはそれぞれの拡張子を通して Logstash、Papertrail、Splunk などのプロバイダーにも送付されます。
中間者攻撃_ _に対する保護が加えられ、当サービスへの HTTPS 接続が強化されましたので、HTTPS 以外の接続は HSTS _仕様_に従ってアップグレードされます。
最後に、SAML を通した XXE 攻撃から守るために、独自の_ XML パーサーライブラリ のフォーク「XMLDOM」_ を使い、XXE 攻撃のキー コンポーネントである DOCTYPE エンティティの解析をさせません。
セキュリティの失敗を避ける
これらソリューションには簡単に実行でき、時間もあまりかからないものもあるほか、反対に正常に機能するためによく考えよい計画を必要とするものもあります。しかし、製品のセキュリティを向上させるために行うこと、特に個人情報など機密データに関しては、役立つことばかりで、攻撃が計画されたときにデータの災害から守る主要な要因になりかねません。
本書では、簡単に OWASP Top 10 に目を通し、今日存在する Web アプリケーションのセキュリティに対する主な脅威を調べてきました。そのような脅威に対して可能な軽減策を考え、不良で安全でない実装の結果から発生する問題からビジネスやユーザーをどのようにして守るかについて話し合ってきました。
また、汎用ログインを通してこれら多数の問題から軽減されることから、包括的なログを通して監査証跡を豊かにすることまで、Web アプリケーションや API のセキュリティを支える Auth0 プラットフォームの主な機能についても見てきました。そのためには、無料アカウントに今すぐサインアップされることをお勧めします。