Missionsの紹介：開発者中心のセキュリティトレーニングの新たなステージ

私たちは2015年以来、セキュリティに対する前向きで積極的なアプローチを通じて世界中の開発者を支援してきました。開発者が自身のコードを守るスキルを身につけ、手戻りや修正作業を減らし、セキュリティチームを「取り締まり役」ではなく頼れるパートナーとして見てもらえるようになることを目指しています。

私たちはこれからも、開発者が銀河の隅々でコードを保護する取り組みを全力でサポートしていきます。しかし、今こそ変革の時です。戦いの中で鍛え上げられた、セキュリティ意識の高い開発者の皆様を次のレベルへと引き上げます。

Secure Code Warriorプラットフォームに、待望の新機能「Missions（ミッション）」が登場しました。この全く新しいチャレンジカテゴリーは、開発者向けセキュリティトレーニングの次なるフェーズです。ユーザーはセキュリティ知識を思い出す段階から、現実のシミュレーション環境でそれを応用する段階へとステップアップします。この段階的なマイクロラーニング手法は、業務に直結する強力なセキュアコーディングスキルを構築します。仕事の合間に延々とトレーニングビデオを眺めるよりも、はるかに楽しく学べるはずです。

公開された最初のプレイ可能なミッションは、GitHubのUnicode脆弱性のシミュレーションです。一見単純そうに見えますが、非常に巧妙で、分析しがいのある脆弱性です。セキュリティ研究者の0xsha氏は、包括的なケーススタディの中で、このバグがどのようにDjangoのケース変換を悪用し、プログラミング言語によって脆弱性の挙動がどう変化するかを明らかにしています。このセキュリティ問題にはまだ多くの発見があり、私たちのミッションはそれを学ぶ絶好の機会となるでしょう。

GitHubの正面衝突（ケースマッピングの衝突）

2019年11月28日のブログ記事において、セキュリティ研究グループのWisdomは、GitHubで発見したセキュリティバグについて報告しました。彼らは、Unicodeのケースマッピングの衝突を利用して、パスワードリセットメールを誤ったメールアドレス（攻撃者の視点に立てば、攻撃者が指定したメールアドレス）に送信させる方法を解説しました。

セキュリティ脆弱性は決して歓迎すべきものではありませんが、ホワイトハットのセキュリティ研究者たちは、コードベースに潜む悪用可能なエラーを発見することで、災害を未然に防ぐ機会を与えてくれます。彼らのブログやレポートは非常に読み応えがあり、新しい脆弱性の仕組みを知ることは知的好奇心を刺激されます。

セキュアコーディングの腕を次のレベルへ引き上げるには、一般的な脆弱性を見つけるだけでなく（特に、悪意のある攻撃者が新たな手法でデータを盗もうと虎視眈々と狙っているような、クールで新しい脆弱性はなおさらです）、安全なハンズオン環境でその悪用方法を理解することが非常に強力な手段となります。

それでは、実際にやってみましょう。読み進めて、Unicodeのケースマッピングの衝突がどのように悪用されるのか、リアルタイムでどのような挙動を示すのかを確認し、セキュリティ研究者の視点を持って自分自身で試してみてください。

今すぐケースマッピングの衝突に挑戦する準備はいいですか？さあ、始めましょう。

Unicode：複雑で無限にカスタマイズ可能、そして絵文字以上の存在

「Unicode」という言葉は一般的には馴染みがないかもしれませんが、ほとんどの人が毎日何らかの形で利用しています。WebブラウザやMicrosoftのソフトウェアを使ったり、絵文字を送ったりしたことがあるなら、すでにUnicodeと深く関わっています。これは、世界中のほとんどの言語のテキストを統一的にエンコード・処理するための標準規格であり、誰もが単一の文字セットを使ってデジタル上で自分を表現できるようにするものです。現在、143,000文字以上が登録されており、アイスランド語からトルコ語のドットなし「i」まで、あらゆる文字に対応しています。

Unicodeには膨大な数の文字が含まれているため、ある文字を別の「等価な」文字に変換する方法が必要になるケースが多くあります。例えば、ドットなしのUnicode文字列をASCIIに変換する場合、単純に「i」に変換されるのが妥当に思えますよね？

文字エンコーディングの膨大な量には、大惨事を引き起こす大きな可能性が潜んでいる

Unicodeにおけるケースマッピングの衝突はビジネスロジックの欠陥であり、根本的には2要素認証（2FA）で保護されていないアカウントの乗っ取りにつながる可能性があります。この脆弱性を説明するために、実際のコードスニペットでこのバグの例を見てみましょう。

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

ロジックは以下のようになっています：

1. ユーザーから提供されたメールアドレスを受け取り、一貫性を保つために大文字に変換する
2. データベース内にそのメールアドレスが既に存在するかを確認する
3. 存在する場合、新しい一時パスワードを設定する（ちなみに、これはベストプラクティスではありません。代わりに、パスワードリセットを有効にするトークン付きのリンクを使用してください）
4. ステップ1で取得したアドレスに、一時パスワードを含むメールを送信する（これは多くの理由から非常に不適切な手法です。恐ろしいですね。）

元のブログ記事で紹介されている例を見てみましょう。ユーザーがJohn@GıtHub.com（トルコ語のドットなしiに注目）というメールアドレスでパスワードリセットを要求した場合です。

1. ロジックがJohn@Gıthub.comをJOHN@GITHUB.COMに変換します。
2. データベースでそのアドレスを検索し、ユーザーJOHN@GITHUB.COMを見つけます。
3. 新しいパスワードを生成し、John@Gıthub.comに送信します。

このプロセスでは、機密性の高いメールが誤ったアドレスに送信されてしまうことに注意してください。大変です！

このUnicodeの悪魔を追い出す方法

この脆弱性の興味深い点は、複数の要因が重なって脆弱性が生まれていることです。

1. 実際のUnicode変換の挙動
2. データベースに存在するメールアドレスではなく、ユーザーが入力したメールアドレスを使用するという判定ロジック。

理論上、Wisdomのブログ記事で指摘されているように、この特定の問題は2つの方法で修正できます。

1. Punycode変換を使用してメールアドレスをASCIIに変換する
2. ユーザーが入力したアドレスではなく、データベース内のメールアドレスを使用する

ソフトウェアの堅牢化において、偶然に頼らず、可能な限り多くの防御層を設けることは非常に重要です。私たちがまだ知らないだけで、このエンコーディングを悪用する他の方法が存在するかもしれません。リスクを軽減し、攻撃者に隙を与えないためのあらゆる対策が価値を持ちます。

実際に試してみますか？

データ漏洩がビジネスに悪影響を及ぼすことは、多くの開発者が認識しています。しかし、セキュリティ意識の高いエンジニアは、増え続ける脆弱性や侵害、サイバーセキュリティの脅威に対する強力な対抗策となります。

セキュアコーディングとセキュリティ意識を次のレベルへ引き上げましょう。GitHubの脆弱性を安全なシミュレーション環境で体験し、フロントエンドとバックエンドの両方で不適切なコードがどのような影響を及ぼすかを確認してください。攻撃者が優位に立つ現状を覆し、ホワイトハッカーとしてのスキルを磨いて対抗しましょう。