🔽 😄 😣 Pysa：Pythonコードのセキュリティ問題を回避する方法 🐹 👣 👩‍🎤

8月7日、FacebookはPysaを発表しました。これは、何百万ものInstagram文字列を操作するのに役立つオープンソースのセキュリティに焦点を当てた静的アナライザーです。制限が開示され、設計上の決定に触れ、そしてもちろん、誤検知を回避するための手段が示されます。 Pysaが最も役立つ状況と、アナライザーが適用できないコードが示されています。カットの下のFacebookエンジニアリングブログからの詳細。

昨年、1億行を超えるハックコードを分析し、エンジニアが数千の潜在的なセキュリティ問題を防ぐのに役立つ静的分析ツールであるZoncolanをどのように構築したかについて書きました。成功は、Pysa - PythonStaticAnalyzerの作業に影響を与えました。パーサーは、FacebookのPythonタイプチェックツールであるPyreの上に構築されています。 Pysaは、コード内のデータフローを処理します。多くの場合、セキュリティとプライバシーの問題は、本来あるべきではない場所に移動するデータとしてモデル化されるため、データフロー分析は役立ちます。

Pysaは、さまざまな種類の問題を特定するのに役立ちます。アナライザーは、コードが特定の内部構造を正しく使用して、技術的なプライバシーポリシーに基づいてユーザーデータへのアクセスや開示を防止しているかどうかを確認します。さらに、アナライザーは、XSSやSQLインジェクションなどの一般的なWebアプリケーションのセキュリティ問題を検出します。Zoncolanと同様に、新しいツールはPythonアプリケーションのセキュリティへの取り組みを拡大するのに役立ちました。これは特にInstagramに当てはまります。

InstagramのPysa

Facebookで最大のPythonリポジトリは、Instagramサーバー上の数百万行です。開発者が提案したコード変更でPysaを実行すると、手動で確認するのにかかる数週間または数か月ではなく、約1時間で結果が得られます。これは、問題がコードベースに入らないように、問題をすばやく見つけて防止するのに役立ちます。チェックの結果は、問題のタイプと特定の状況での信号対ノイズ比に応じて、開発者または安全エンジニアに直接送信されます。

Pysaとオープンソース

Pysaソースコードと多くの問題定義は、他の開発者がプロジェクトのコードを分析するために公開されています。DjangoやTornadoなどのオープンソースのサーバー側フレームワークを使用しているため、Facebook内での最初の起動から、Pysaはこれらのフレームワークを使用するプロジェクトでセキュリティの問題を発見します。まだカバレッジがないフレームワークにPysaを使用することは、通常、数行の構成を追加するのと同じくらい簡単です。データがどこからサーバーに送られるかをアナライザーに伝える必要があります。

Pysaは、オープンソースのPythonプロジェクトでCVE-2019-19775などの問題を検出するために使用されています。Zulipプロジェクトとも協力しました Pysaをコードベースに含めました。

使い方？

Pysaは、Zoncolanから学んだ教訓を基に設計されています。同じアルゴリズムを使用して静的分析を実行し、Zoncolanとコードを共有します。 Zoncolanと同様に、Pysaはプログラム内のデータの流れを監視します。ユーザーは、重要なデータのソースとデータの宛先を定義します。セキュリティアプリケーションでは、最も一般的な種類のソースは、DjangoのHttpRequest.GETディクショナリなど、ユーザーが制御するデータがアプリケーションに入力されるポイントです。レシーバーは一般的にはるかに多様であり、APIの実行を含めることができます。たとえば、evalまたはos.open..。 Pysaは、分析を繰り返し実行して要約を作成し、ソースからデータを返している関数と、宛先に到達するパラメーターを持つ関数を判別します。アナライザーは、ソースが最終的にレシーバーに接続していることを検出すると、問題を報告します。このプロセスの視覚化は、上部に問題があり、葉にソースとフローがあるツリーです。

クロスプロシージャ解析を実行するには（関数呼び出し間のデータフローを追跡するため）、関数呼び出しをそれらの実装にマッピングできる必要があります。これを行うには、オプションの静的型が存在する場合はそれを含め、コードで利用可能なすべての情報を使用する必要があります。私たちはPyreと協力してこの情報を把握しました。PysaはPyreに大きく依存しており、両方のツールが同じリポジトリを共有していますが、これらは別々のアプリケーションを持つ別々の製品であることに注意することが重要です。

偽陽性

セキュリティエンジニアは、FacebookでのPysaの主なユーザーです。自動エラー検出ツールを使用する他のエンジニアと同様に、誤検知（問題なし、信号なし）と陰性（問題なし、信号なし）の処理方法を理解する必要がありました。

Pysaの設計は、問題を見落とさないようにし、できるだけ多くの実際の問題を検出することを目的としています。ただし、誤警報の数を減らすには、不要な信号の数を増やすトレードオフが必要になる場合があります。誤検知が多すぎると、不安疲労が発生し、実際の問題がノイズで見落とされるリスクがあります。 Pysaには、不要な信号を削除するための2つのツールがあります。サニタイザーとサインです。

サニタイザーシンプルなツールです。ストリームが関数または属性を通過した後、データストリームを追跡しないようにパーサーに指示します。サニタイザーを使用すると、常に安全で機密性の高い方法でデータを提示するドメイン変換の知識をエンコードできます。

兆候は微妙です。それらは、Pysaが追跡するときにデータストリームに添付するメタデータの小さなチャンクです。消毒剤とは異なり、標識は分析結果から問題を取り除くことはありません。属性およびその他のメタデータを使用して、分析後に結果をフィルタリングできます。フィルタは通常、特定の送信元と宛先のペアに対して作成され、特定のタイプ（すべてのタイプではない）の宛先のデータがすでに処理されている場合の問題を無視します。

Pysaが最も役立つ状況を理解するために、次のコードを実行してユーザープロファイルをロードするとします。

# views/user.py
async def get_profile(request: HttpRequest) -> HttpResponse:
   profile = load_profile(request.GET['user_id'])
   ...
 
# controller/user.py
async def load_profile(user_id: str):
   user = load_user(user_id) # Loads a user safely; no SQL injection
   pictures = load_pictures(user.id)
   ...
 
# model/media.py
async def load_pictures(user_id: str):
   query = f"""
      SELECT *
      FROM pictures
      WHERE user_id = {user_id}
   """
   result = run_query(query)
   ...
 
# model/shared.py
async def run_query(query: str):
   connection = create_sql_connection()
   result = await connection.execute(query)
   ...

この機能は常に有効取得：load_picturesの潜在的なSQLインジェクションが悪用されることはありません場所ですuser_id関数からload_userでload_profile。正しく構成されている場合、Pysaはおそらく問題を報告しません。ここで、コントローラーレベルのコードを記述している進取の気性のあるエンジニアが、ユーザーデータと画像を同時にフェッチすると結果がより速く返されることに気付いたと想像してみてください。

# controller/user.py
async def load_profile(user_id: str):
   user, pictures = await asyncio.gather(
       load_user(user_id),
       load_pictures(user_id) # no longer 'user.id'!
   )
   ...

この変更は無害に見えるかもしれませんが、実際には、ユーザーが制御する文字列user_idをのSQLインジェクションの問題とマージすることになりますload_pictures。エントリポイントとデータベースクエリの間に多くのレイヤーがあるアプリケーションでは、エンジニアは、データがユーザーによって完全に制御されていることや、注入の問題が呼び出された関数に隠されていることに気付かない場合があります。これはまさにアナライザーが作成された状況です。エンジニアがInstagramで同様の変更を提案すると、Pysaは、データがユーザー主導の入力からSQLクエリに送られていることを発見し、問題を報告します。

アナライザーの制限

完璧な静的アナライザーを作成することは不可能です。Pysaには、スコープ、データフロー、および設計上の決定に制限があり、精度と精度のパフォーマンスが低下します。動的言語としてのPythonには、これらの設計上の決定のいくつかの根底にある独自の特性があります。

問題空間

Pysaは、データストリームに関連するセキュリティの問題のみを検出するように構築されています。すべてのセキュリティまたはプライバシーの懸念がデータストリームとしてモデル化されているわけではありません。例を確認してください。

def admin_operation(request: HttpRequest):
  if not user_is_admin():
      return Http404
 
  delete_user(request.GET["user_to_delete"])

Pysaはuser_is_admin、特権操作の前に認証チェックが実行されることを保証するための適切なツールではありませんdelete_user。アナライザーはにrequest.GET向けられたからのデータを検出できますdelete_userが、そのデータは検証を通過しませんuser_is_admin。コードを書き直して問題をPysaモデルにするか、権限チェックを管理操作に組み込むことができますdelete_user。しかし、このコードはまず、Pysaが解決しない問題を示しています。

リソース制限

開発者によって提案された変更がコードベースに反映される前にPysaが分析を完了できるように、制約に関する設計上の決定を行いました。アナライザーがオブジェクトの非常に多くの属性でデータストリームを監視する場合、オブジェクト全体を単純化して、そのデータを含むものとして扱う必要がある場合があります。これは誤検知につながる可能性があります。

もう1つの制限は開発時間です。サポートされているPython機能についてトレードオフを余儀なくされました。Pysaは、関数を呼び出すときにまだデコレータを呼び出しグラフに含めていないため、デコレータ内の問題をスキップします。

動的言語としてのPython

Pythonの柔軟性により、静的分析が困難になります。タイプ情報のないメソッド呼び出しを介してデータストリームを追跡することは困難です。以下のコードでは、どの実装flyが呼び出されているかを判別することは不可能です。

class Bird:
  def fly(self): ...
 
class Airplane:
  def fly(self): ...
 
def take_off(x):
  x.fly()  # Which function does this call?

アナライザーは、完全に型指定されていないプロジェクトで機能します。しかし、重要なタイプをカバーするのにほとんど労力はかかりません。

Pythonの動的な性質により、別の制限が課せられます。下記参照：

def secret_eval(request: HttpRequest):
  os = importlib.import_module("os")
 
  # Pysa won't know what 'os' is, and thus won't
  # catch this remote code execution issue
  os.system(request.GET["command"])

実行の脆弱性はここにはっきりと表示されますが、アナライザーはそれをスキップします。モジュールはos動的にインポートされます。Pysaは、ローカル変数osがモジュールを正確に表していることを理解していませんos。Pythonを使用すると、ほぼすべてのコードをいつでも動的にインポートできます。さらに、この言語は、ほとんどすべてのオブジェクトの関数呼び出しの動作を変更できます。Pysaは、osを分析し、問題を検出する方法を学ぶことができます。しかし、Pythonのダイナミズムは、アナライザーが認識しない病理学的データストリームの例が無限にあることを意味します。

結果

2020年の前半、PysaはInstagramで検出されたすべての問題の44％を占めました。すべての脆弱性タイプの中で、提案されたコード変更で330の固有の問題が見つかりました。 49（15％）の問題が重大であることが判明し、131（40％）の問題は現実のものでしたが、緩和する状況がありました。偽陰性は150（45％）のケースで記録されました。

他の方法で報告された問題を定期的に確認します。たとえば、バグバウンティプログラムを通じて。これが、すべての偽陰性信号を確実に修正する方法です。各タイプの脆弱性の検出は構成可能です。安全エンジニアは絶え間ない改良を通じて、実際の問題を100％報告するために、より洗練されたタイプに移行しました。

全体として、セキュリティエンジニアの拡張を支援するために行ったトレードオフに満足しています。しかし、常に開発の余地があります。Pysaは、セキュリティエンジニアとプログラマーの緊密なコラボレーションを通じて、コードの品質を継続的に向上させるために作成されました。これにより、すぐに使用できるソリューションよりも優れたニーズを満たすツールをすばやく反復して作成することができました。エンジニアの協力により、Pysaムーブメントに追加と改良が加えられました。たとえば、問題のトレースを表示する方法が変更されました。偽陰性が見やすくなりました。

Pysaアナライザーのドキュメントとチュートリアル。

オンラインのSkillFactoryコースを受講して、注目を集める職業をゼロから取得する方法、またはスキルと給与をレベルアップする方法の詳細を確認してください。

«Python -» (9 )

«Python » (2 )

Python (10 )

E

Machine Learning (12 )

«Machine Learning Pro + Deep Learning» (20 )

« Machine Learning Data Science» (20 )

Data Science (12 )

- (8 )

(9 )

DevOps (12 )

Java- (18 )

JavaScript (12 )

Pysa：Pythonコードのセキュリティ問題を回避する方法