静的アプリケーションセキュリティテスト（SAST）の市場は、今日、大きなブームを迎えていると言っても過言ではありません。 このトピックに関する定期的な科学作品の出版から数か月は経過していませんが、毎年、セキュリティの静的分析のための新しいツールがますます市場に導入されています。SASTは、国際情報セキュリティ会議でソフトウェア全体の開発プロセスに参加しています。 SASTツールのサプライヤからの絶え間ない情報のプレッシャーの中で、何が真実で何が現実と弱く相関するマーケティングトリックにすぎないのかを理解することは容易ではありません。 SASTツールが実際に何ができるか、そしてそれらが「難しすぎる」という事実に対処する方法を理解してみましょう。 これを行うには、コードセキュリティの静的分析の現代的な手段の基礎となる理論を少し掘り下げる必要があります。

チューリング、ライス-これらはすべて

TL / DR：プログラムセキュリティの静的テストのタスクはアルゴリズム的に解決できません。



入力データのいくつかのセットでハングアップし、他のいくつかの操作の後に停止する方法のみを知っている多くの完全に抽象的なPプログラムを想像してください。 明らかに、クラスPは理論的に可能なすべてのプログラムをカバーします。このプロパティはそれらのいずれかに起因するためです。



ここで、これらのプログラムの1つ（それをhと呼びます）が簡単な質問に答えることができるアナライザーであると想像してください。セットPからの任意のプログラムpは、特定のデータセットnでハングしますか？ 明らかに、hは、自分の作業を完了し、それによってpがnで停止していることを報告することによってのみこの質問に答えることができます。 つまり、p（n）が停止しない場合、h（p（n））は有限数のステップで作業を完了する必要があり、p（n）が停止する場合、h（p（n））はフリーズする必要があります。



さて、今、そのようなアナライザーの助けを借りて質問に答えようとするとどうなるか想像してみてください：それ自体を分析し、それ自体を分析した結果、それ自体がフリーズしますか？ h）？ この場合、h（h（n））が停止するとh（n）の分析がハングし、h（h（n）））がハングするとh（n）の分析が停止することがわかります。 しかし、hは正確にh（n）であり、したがって、ここで矛盾があり、hのようなアナライザーには存在する権利がありません。



説明されているのは、1936年にアランチューリング（現代の理論的コンピューターサイエンスの創始者）によって定式化されたストップ定理の証明の無料プレゼンテーションです。 この定理は、別のプログラムを分析し、入力データの特定のセットで停止するかどうかの質問に答えるようなプログラムは存在しないことを示しています。 しかし、プログラムの他のプロパティに関する質問に答えるプログラムを作成できますか？



セットPにはすべての可能なプログラムが含まれているため、プログラム内の非自明な不変プロパティの存在に基づいて、常に2つのクラスに分割できます（AとBがあります）。 非自明な不変プロパティとは、セットPの任意のプログラムが所有するか、または所有せず、同時にすべての機能的に同一のプログラム（出力で同じデータセットに入力で同じデータセットを与える）またはすべて一緒にこのプロパティを持つプロパティを意味します。またはすべて一緒に所有していません。



集合Pの任意のプログラムpを取得し、pがクラスの1つに属する場合に停止するqアナライザーがあると想像してみましょう。 明確にするため、クラスAとします。paをクラスAに属し、任意の入力でループするプログラムとします。 また、クラスBから任意のプログラムpbを選択します。 各プログラムpに対して、データxを入力として受け取り、次のアルゴリズムを実行するプログラムp 'を定義します。

1. p(p) 2. pb(x)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、任意のプログラムpを入力として受け取り、そのためにp 'を構築し、q（p'）を計算するプログラムq 'を構築します。



pが最初のステップでハングした場合、pは機能的にpaと同じであり（クラスAに属します）、したがってqはすぐに停止する必要があります。 pが最初のステップを通過した場合、pは機能的にpbと同じ（クラスBに属する）であるため、qはハングするはずです。 したがって、プログラムpについては、p（p）が停止しないときにq '（p）が停止します。 しかし、q '自身もpの役割を果たしている可能性があります。したがって、p（p）は、p（p）が停止しない場合にのみ停止します。 再び矛盾が生じました。



任意のプログラムの非自明な不変特性の存在についての質問に答えることができるようなプログラムはないという声明は、1953年に科学者ヘンリー・ライスによって証明されました。 実際、特定のデータセットで停止するプロパティは自明ではなく不変なので、彼の研究は停止定理を一般化します。 ライスの定理は、「プログラムを使用して別のプログラムによって実装されたアルゴリズムを分類することは不可能です」、「プログラムを使用して他の2つのプログラムが同じアルゴリズムを実装することを証明することはできません」、「使用できない」によって、実用的な意味が無限にありますデータセット上の別のプログラムがどの状態にもなっていないことを証明するプログラム...」など そして、ここでさらに詳しく説明する最後の例を示します。



ユニバーサル実行プログラム（たとえば、OSがインストールされた本格的なコンピューターをエミュレートする仮想マシン）の（抽象および実）アルゴリズムの実行時に、マシンとその外部環境のアドレス空間におけるプログラム自体の状態を含む、このマシンのスナップショットを取得できますディスクドライブ、外部デバイスのステータスなど。 その後、復元して、同じ場所からプログラムを続行します。 実際、プログラムを実行するプロセス全体は一連の変化する状態であり、そのシーケンスはコードによって正確に決定されます。 さらに、プログラム自体とそれを実行するマシンの両方の構成または実装にエラーがある場合、実行プロセスは開発者が本来意図していない状態になる可能性があります。



そして、脆弱性とは何ですか？ これは、入力データを使用して、プロセスによって処理される情報に関する脅威のいずれかの実現につながる状態を実行プロセスに強制するための機会です。 そのため、プログラムのセキュリティ機能を、その初期の入力データに関係なく、そのセキュリティポリシーを決定する許容状態の所定のセットのフレームワーク内で、いつでも維持できる能力として定義することができます。 この場合、プログラムのセキュリティを分析するタスクは明らかに、任意の入力データのセキュリティポリシーによって解決されない状態への移行の不可能性を分析することになります。 つまり、アルゴリズムの解けないことがヘンリー・ライスによってずっと前に証明されたまさにその問題に対してです。



結局のところ、SASTツールキット市場全体はデマ産業です。 理論的には-はい、実際にはすべてが通常通りです-オプションが可能です。

実際のSAST理論

理論的な分野に残っていても、実際の環境で実行されている実際のプログラムに対するライスの声明にいくつかの譲歩をすることはかなり可能です。 まず、理論情報学では、「プログラム」とは、最も強力なコンピューティングマシンであるチューリングマシン（MT）と同等の数学的抽象化を意味します。 ただし、実際のプログラムでは、コードのすべてのフラグメントがMTに相当するわけではありません。 計算能力の階層の下には、線形境界、スタック、および有限状態マシンがあります。 後者の2つのセキュリティの分析は、理論的理論自体の枠組み内でも可能です。



第二に、MTの特徴は、無限のサイズのメモリにアクセスできることです。 計算プロセスのすべての可能な状態を取得することは不可能であるのは、この機能からです-単純に無限の数があります。 ただし、実際のコンピューターでは、メモリは無限ではありません。 さらに重要なことは、実際のプログラムでは、セキュリティ分析問題の観点からの関心のある状態の数も有限です（ただし、無数に大きい）。



第三に、ライスによるプログラムの特性の計算は、少数の状態とそれらの間の可能な遷移を持つ多数の小さなMTにとって解決可能な問題です。 2〜4つの状態を持つ実際のプログラムを想像するのは困難です。 ただし、このようなプログラムの*フラグメント*は想像しやすいものです。



その結果、リストされた基準に該当するプログラムコードの個々のフラグメントの効果的な分析が可能です。 実際には、これは次のことを意味します。

1. サイクルと再帰のないコードフラグメントを包括的に分析できます。 ステートマシンと同等;
2. 終了条件が入力データに依存しないサイクルまたは再帰を含むフラグメントは、有限オートマトンまたはスタックオートマトンとして分析できます。
3. ループまたは再帰を終了するための条件が、妥当なしきい値によって長さが制限されている入力データに依存する場合、場合によっては、そのようなフラグメントは線形境界オートマトンまたは小さなMTのシステムとして分析できます。

しかし、他のすべて-悲しいかな、ああ-は静的なアプローチでは分析できません。 さらに、ソースコードセキュリティアナライザーの開発は、エンジニアが毎日EXPSPACE <-> EXPTIMEトレードオフで作業する方向であり、特別なケースをサブ指数に減らしても、彼らは本当にクールなので、子供として幸せです。 最後の実行ポイントで変数parm1の多くの値のパワーはどうなるかを考えてください。

 var parm1 = Request.Params["parm1"]; var count = int.Parse(Request.Params["count"]); for (var i = 0; i < count; i++) { i % 2 == 0 ? parm1 = parm1 + i.ToString(): parm1 = i.ToString() + parm1; } Response.Write(parm1);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それが現在の計算能力でそれらにぶつかるのが非常に難しいので、あなたが本当に理論的な制限について心配することができない理由です。 ただし、これらの制限の前述の緩和は、最新の静的アナライザーの開発に正しい方向を設定するため、まだ留意する価値があります。

DAST、IAST、およびすべてすべて

実際に実行せずにプログラムコードを操作する静的なアプローチとは対照的に、動的（動的アプリケーションセキュリティテスト、DAST）は、開発されたアプリケーションランタイムの存在と、分析の観点から最も興味深い入力データセットでの実行を意味します。 簡略化するために、「情報に基づいた科学的突破」の方法として説明できます（「このような攻撃に特徴的なこれらのデータをプログラムに与えて、その結果を確認しましょう」）。 その欠点は明らかです：分析されたシステムを迅速に展開する（そしてしばしば単純に組み立てる）ことは常に不可能であり、システムの任意の状態への移行は以前のデータセットの処理の結果である場合があり、実際のシステムの動作の包括的な分析のためには、入力データセットの数は非常に素晴らしいので、彼の有限性について理論的に推測することしかできません。



比較的最近、SASTとDASTの利点を組み合わせたアプローチ-インタラクティブ分析（Interactive ...、IAST）が有望であると見なされました。 このアプローチの特徴は、SASTを使用して入力データのセットと期待される結果のパターンを生成し、DASTがこれらのセットに対してシステムテストを実行することです。 このアプローチの皮肉な点は、SASTとDASTの長所と短所の両方を取り入れていることです。これらは、実際の適用可能性に影響を与えるだけでした。



しかし、動的解析の場合、プログラム全体を実行する必要があると誰が言ったでしょうか？ 上記のように、静的アプローチを使用してコードの大部分を分析することは非常に現実的です。 動的な残りのフラグメントのみを使用して分析することを妨げるものは何ですか？ 計画のように聞こえます...

そして彼女のネオンカの中

静的解析にはいくつかの伝統的なアプローチがあり、アナライザーが調査中のコードの特定のプロパティを導出する基礎となるモデルが異なります。 最も原始的で明白なのは、コード表現の構文モデルでのテンプレートの出現の検索に基づく署名検索です（原則として、トークンのストリームまたは抽象構文ツリーのいずれかです）。 このアプローチの実装には、やや複雑なモデル（セマンティックツリー、個々のデータストリームのグラフへのマッピングなど）を使用するものがありますが、一般的に、このアプローチは、補助的なものとしてのみ考えることができます。手動検証。 これについては詳しく説明しませんが、興味のある人は、Ivan Kochurkinが彼に捧げた一連の記事に目を向けることができます。



より洗練されたアプローチは、コードの（表現やセマンティクスではなく）実行モデルで既に動作しています。 そのようなモデルは、原則として、「外部から制御されたデータストリームが脆弱性につながる実行ポイントに到達することができますか？」という質問に対する答えを提供します。 ほとんどの場合、ここでのモデルは、 実行フローグラフとデータ フローのトピックのバリエーション、またはそれらの組み合わせ（ コードプロパティグラフなど ）です。 このようなアプローチの欠点も明らかです。重要なコードでは、この質問に答えるだけでは脆弱性を検出するのに十分ではありません。 たとえば、フラグメントの場合：

 var requestParam = Request.Params["param"]; var filteredParam = string.Empty; foreach(var symbol in requestParam) { if (symbol >= 'a' && symbol <= 'z') { filteredParam += symbol; } } Response.Write(filteredParam);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなアナライザーは、構築されたモデルから、 `Response.Write（filteredParam）`実行ポイントの到達可能性と、データストリーム `Request.Params [“ param”]による特定のポイントでのXSS脆弱性の存在に関する肯定的な回答を導きます。 同時に、実際には、このストリームは効果的にフィルタリングされており、攻撃ベクトルのキャリアにはなり得ません。 データストリームの前処理に関連する特定のケースに対応する方法は多数ありますが、最終的にはすべて、第1タイプと第2タイプの誤検知の合理的なバランスになります。









両方のタイプのエラーを最小化するにはどうすればよいですか？ このため、潜在的に脆弱な実行ポイントと、そのようなポイントに到着するデータストリーム値のセットの両方の到達可能性条件を考慮する必要があります。 この情報に基づいて、方程式のシステムを構築することが可能になります。方程式の解のセットは、プログラム内の潜在的に脆弱なポイントに到達するために必要なすべての入力データのセットを提供します。 このセットと考えられるすべての攻撃ベクトルのセットの交差点は、入力データのすべてのセットのセットを提供し、プログラムを脆弱な状態にします。 それは素晴らしいように聞こえますが、必要なすべての情報を含むモデルを取得するにはどうすればよいですか？

抽象解釈とシンボリックコンピューティング

符号が式「-42 / 8 * 100500」を定義する番号を決定するタスクに直面していると仮定します。 最も簡単な方法は、この式を計算し、負の数が受信されることを確認することです。 すべての引数の明確に定義された値を持つ式の計算は、具象計算と呼ばれます。 しかし、この問題を解決する別の方法があります。 何らかの理由でこの式を具体的に計算する方法がないことを少し想像してみましょう。 たとえば、変数 `-42 / 8 * 100500 * x`が追加された場合。 数値の演算結果が符号規則のみによって決定され、引数の値が無視される抽象算術を定義します。

 (+a) = (+) (-a) = (-) (-) * (+) = (-) (-) / (+) = (-) ... (-) + (+) = (+-) ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このセマンティクスのフレームワークで元の式を解釈すると、次のようになります： `（-）/（+）*（+）*（+）`-> `（-）*（+）*（+）`-> `（-）*（ +） `->`（-） `。 このアプローチは、加算または減算演算が式に現れるまで提起された問題に対する明確な答えを与えます。 算術を補完して、演算の引数の値も考慮されるようにしましょう。

 (-a) * (+b) = (-c) (-a) / (+b) = (-c) ... (-a) + (+b) = a <= b -> (+) a > b -> (-) ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいセマンティクスで式「-42 / 8 * 100500 + x」を解釈すると、結果「x> = -527625->（+）、x <-527625->（-）」が得られます。



上記のアプローチは抽象解釈と呼ばれ、順序セット上の単調関数に基づく式のセマンティクスの安定した近似として正式に定義されています。 簡単に言えば、これは、特定のセマンティックフィールド内の情報を収集するために、特定の計算を行わない式の解釈です。 個々の式の解釈から任意の言語のプログラムコードの解釈にスムーズに移行し、言語自体のセマンティクスをセマンティックフィールドとして定義し、すべての入力データを未知の変数（シンボリック値）として操作するルールで補完すると、シンボリックというアプローチが得られます静的コード分析の有望な分野の大部分を実行し 、その基盤としています。



シンボリック計算の助けを借りて、シンボリック計算のコンテキストグラフ（別名：計算フローのグラフ）-調査中のプログラムを計算するプロセスを包括的に記述するモデルを構築することが可能になります。 このモデルは、レポート「ソースコードのパッチの自動生成」およびコードセキュリティの分析への応用- 「ソースコードの分析とエクスプロイトの自動生成」の記事で検討されました。 この記事のフレームワークでそれらを再度考慮することはほとんど意味がありません。 このモデルを使用すると、実行フローの任意のポイント、およびそれに到達するすべての引数の値のセットの到達可能性条件を取得できることに注意してください。 つまり、問題を解決するためにまさに必要なものです。

計算フローグラフで脆弱性を検索する

特定のクラスの攻撃に対する脆弱性の基準をフローグラフの観点から定式化したので、調査中のコードの抽象的な解釈の結果として得られた特定のモデルのプロパティを解決することにより、コードセキュリティの分析を実装できます。 たとえば、インジェクション攻撃（SQLi、XSS、XPATHi、パストラバーサルなど）の脆弱性基準は、次のように形式化できます。

Cを調査中のコードの計算フローのグラフとします。



pvf（t）をCの制御フローの到達可能な頂点とします。これは、形式文法Gに対応するテキストtの直接または間接解釈の関数の呼び出しです。



eをCの入力引数ストリームとします。



Deをeから生成されたC上のデータストリームのセットとします。



tがDeに属し、De値のセットに少なくとも1組の要素が含まれている場合、アプリケーションは、pvf（t）コールポイントでのインジェクション攻撃に対して脆弱です。友達の木。

同様に、他の攻撃クラスに対する脆弱性も形式化されています。 ただし、ここでは、分析されたコードのみから派生したモデルのフレームワーク内ですべてのタイプの脆弱性を正式化できるわけではないことに注意してください。 場合によっては、追加情報が必要になることがあります。 たとえば、ビジネスロジックに対する攻撃に対する脆弱性を形式化するには、アプリケーションサブジェクトエリアの形式化されたルール、アクセス制御に対する攻撃に対する脆弱性を形式化する必要があります（アクセス制御の形式化されたポリシーなど）。

真空中の理想的な球面コードセキュリティアナライザー

過酷な現実から少し脱線し、仮想の理想的なアナライザーのコアに必要な機能について少し考えてみましょう（「IA」と呼びましょう）。



まず、SASTとDASTの利点を取り入れる必要があります。それらの欠点は含まれません。 特に、IAは、ランタイム環境でのアプリケーションの完全性または展開を必要とせずに、既存のアプリケーションコード（ソースまたはバイナリ）で排他的に動作できる必要があります。 言い換えれば、外部依存関係が欠落しているプロジェクトや、アプリケーションのアセンブリとデプロイを妨げるその他の要因があるプロジェクトの分析をサポートする必要があります。 同時に、不足している依存関係へのリンクを含むコードの断片を使用する作業は、それぞれのケースで可能な限り完全に実装する必要があります。 一方、IAはチューリング計算モデルによって課せられた理論上の制限を効果的に「回避」できるだけでなく、妥当な時間でスキャンを実行し、合理的な量のメモリを消費し、可能なサブ指数の「重みカテゴリ」を遵守できる必要があります。



第二に、第1種のエラーが発生する確率は、論理方程式のシステムを構築および解決し、ユーザーが1つのアクションで脆弱性の存在を確認できる作業攻撃ベクトルを生成することによって最小限に抑える必要があります。



第三に、IAは第2種のエラーを効果的に処理する必要があり、ユーザーは実行フローの潜在的に脆弱なポイントをすべて手動でチェックできます。IA自体の脆弱性は確認も拒否もできません。



シンボリック計算に基づいたモデルを使用すると、理論上の制限と副指数に関連する部分を除き、「設計」と呼ばれるこれらすべての要件を実装できます。そして、ここで、ところで、私たちの計画があります-静的解析が失敗した場所で動的解析を使用することです。

部分計算、逆関数、および遅延解釈

IAには、標準言語ライブラリまたはアプリケーションランタイム、最も一般的なフレームワーク、CMSに実装されている入力データ変換関数のセマンティクスを記述する特定の知識ベースが含まれていると想像してください。たとえば、Base64Decode関数とBase64Encode関数は相互に逆であるか、StringBuilder.Appendを呼び出すたびに、このクラスの中間アキュムレーター変数に既に格納されている行に新しい行を追加します。このような知識があれば、IAはライブラリコードに「フォールスルー」する必要性を免れ、その分析もすべての計算上の制限に該当します。

 //       cond2            if (Encoding.UTF8.GetString(Convert.FromBase64String(cond2)) == "true") { var sb = new StringBuilder(); sb.Append(Request.Params["param"]); //  sb.ToString       StringBuilder,       Response.Write(sb.ToString()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、IAナレッジベースに記載されていない関数呼び出しがコードに含まれている場合はどうでしょうか？ IAには、特定のコンテキストで分析されたコードの任意のフラグメントを実行し、その実行結果を取得できる、ある種の仮想サンドボックス環境があることを想像してみましょう。これを「部分計算」と呼びます。次に、正直に未知の関数に「失敗」し、抽象的に解釈を開始する前に、IAは「部分ファジング」と呼ばれるトリックを試みることがあります。彼の一般的なアイデアは、ライブラリ変換関数と、既知のテストデータセットに対する連続した呼び出しの組み合わせに関する知識ベースを事前に準備することです。このようなデータベースを使用すると、同じデータセットで未知の機能を実行し、結果を知識ベースのサンプルと比較できます。未知の関数を実行した結果が、ライブラリ関数の既知のチェーンを実行した結果と一致する場合、これは、IAが未知の関数のセマンティクスを認識し、解釈する必要がないことを意味します。



フラグメントについて、このフラグメントに来るすべてのデータストリームの値のセットが既知であり、フラグメント自体に危険な操作が含まれていない場合、IAはすべての可能なデータストリームで単純に実行し、このコードフラグメントの抽象解釈の代わりに結果を使用できます。さらに、このフラグメントは、計算の複雑さの任意のクラスに属することができ、実行の結果には影響しません。さらに、フラグメントに到着するデータストリームの値のセットが事前にわからない場合でも、IAは特定の危険な操作の方程式の解が始まるまで、このフラグメントの解釈を延期する場合があります。解決段階では、特定の攻撃のベクトルの入力データ内の存在に関する入力データの値のセットに追加の制限が課されます。これにより、遅延フラグメントに入力される複数の入力値も想定できるため、この段階で部分的に計算できます。



さらに、ソリューション段階では、IAが危険点とその引数の到達可能性の最終式（分析されたコードが記述されているのと同じ言語の構文とセマンティクスを組み込むのが最も簡単）を取得し、対象のベクトルの既知のすべての値で「歪める」ことを妨げるものはありません式のすべてのフィルタリング関数を通過するサブセットを取得します。

 //   Response.Write,      ,           parm1     XSS Response.Write(CustomFilterLibrary.CustomFilter.Filter(parm1));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のアプローチにより、チューリング完全なコードのフラグメントのかなりの部分の分析に対処することができますが、知識ベースを埋め、標準型のセマンティクスのエミュレーションを最適化する観点から、および部分的なコード実行のサンドボックスを実装する観点から、十分なエンジニアリング研究が必要です（誰も望んでいません）分析プロセスは、File.Deleteのようなものを突然実行しました）、nローカルの未知の関数のファジングをサポートし、部分計算の概念をSMTソルバーなどと統合しました。ただし、従来のSASTのレーキとは異なり、実装に大きな制限はありません。

厄介なカモタイピングが白鳥になるとき

次のコードを分析する必要があると想像してください。

 var argument = "harmless value"; // UnknownType - ,     UnknownType.Property1 = parm1; UnknownType.Property2 = UnknownType.Property1; if (UnknownType.Property3 == "true") { argument = UnknownType.Property2; } Response.Write(argument);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、XSSに対する達成可能な脆弱性を簡単に見ることができます。しかし、既存の静的アナライザーのほとんどは、UnknownType型について何も知らないため、安全にそれを台無しにします。ただし、ここでIAに必要なことは、静的型付けを忘れて、アヒルに移ることだけです。そのような構成の解釈のセマンティクスは、その使用のコンテキストに完全に依存する必要があります。はい、インタープリターは `UnknownType.Property1`が何であるかを知りません-プロパティ、フィールド、さらにはデリゲート（C＃のメソッドへの参照）です。しかし、それを使用した操作は、ある種の変数メンバーのように実行されるため、インタープリターがこの方法で処理することを妨げるものは何もありません。そして、例えば、コードのさらに下に「UnknownType.Property1（）」が構築されている場合、そのメソッドの呼び出しの解釈を妨げるものは何もありません。以前にProperty1に割り当てられたリンク。など、アヒルのチャンピオンのブリーダーの最高の伝統で。

まとめると

もちろん、販売者の観点から、あるアナライザーが別のアナライザーと他のアナライザーを好意的に比較するマーケティングのmarketingがたくさんあります。ただし、製品のコアが使用する基本機能を提供できない場合、それらは使用できません。そして、それを提供するために、分析装置は記述されたIAに対する能力に従って努力しなければなりません。そうでなければ、彼が処理するプロジェクトに本当のセキュリティの話はできません。



数年前、クライアントの1人が、彼が開発したシステムのセキュリティの分析を求めました。入力データの中で、彼は、当時のSASTツール市場のリーダーだった製品を使用したプロジェクトのコードの分析に関するレポートを提供しました。レポートには約2,000件のレコードが含まれており、そのほとんどがポジティブフォールスポジティブとして検証されました。しかし、最悪のことは、レポートにないものでした。手動でコードを分析した結果、スキャン中に見逃された数十の脆弱性を発見しました。このようなアナライザーを使用すると、すべての偽陽性の結果を解析するのに時間がかかり、偽陰性の結果によるセキュリティの錯覚が生じ、良いことよりも害が大きくなります。ところで、この事件は、独自のアナライザーを開発した理由の1つになりました。

「話は安い。コードを見せてください。」

実際にアナライザーの理想の度合いを確認できる小さなコード例で記事を終了しないのは奇妙です。出来上がり-以下のコードには、抽象的な解釈に対する説明されたアプローチでカバーされるすべての基本的なケースが含まれていますが、より原始的なアプローチではカバーされていません。各ケースは可能な限り簡単に、最小限の言語指示で実装されます。これはC＃/ ASP.Net WebFormsの例ですが、詳細は含まれておらず、他のOOP言語およびWebフレームワークで簡単にコードに変換できます。

 var parm1 = Request.Params["parm1"]; const string cond1 = "ZmFsc2U="; // "false"  base64- Action<string> pvo = Response.Write; // False-negative // ,         ,      pvo(parm1); //  ,   ,     #region var argument = "harmless value"; UnknownType.Property1 = parm1; UnknownType.Property2 = UnknownType.Property1; UnknownType.Property3 = cond1; if (UnknownType.Property3 == null) { argument = UnknownType.Property2; } // False-positive // ,   ,     Response.Write(argument); #endregion // False-positive // ,      ,     if (cond1 == null) { Response.Write(parm1); } // False-positive // ,      ,     Response.Write(WebUtility.HtmlEncode(parm1)); // False-positive // ,      ,     // (CustomFilter.Filter   `s.Replace("<", string.Empty).Replace(">", string.Empty)`) Response.Write(CustomFilterLibrary.CustomFilter.Filter(parm1)); if (Encoding.UTF8.GetString(Convert.FromBase64String(cond1)) == "true") { // False-positive // ,      ,     Response.Write(parm1); } var sum = 0; for (var i = 0; i < 10; i++) { for (var j = 0; j < 15; j++) { sum += i + j; } } if (sum != 1725) { // False-positive // ,     ,     Response.Write(parm1); } var sb = new StringBuilder(); sb.Append(cond1); if (sb.ToString() == "true") { // False-positive // ,      ,     Response.Write(parm1); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードの分析結果は、式 `pvo（parm1）`のXSS攻撃に対する唯一の脆弱性に関するメッセージになるはずです。こちらからスキャン対応プロジェクトを入力してコンパイルできます。



しかし、彼らが言うように、「一度見た方がいい...」と、まず、開発中のIAアナライザーのコンプライアンスをチェックしました。これは、偶然AIと呼ばれています。







すでにチェックしましたか？ ;）

最後まで読んだ人へのボーナスとして：

無料のApproofユーティリティのパブリックアルファテストを開始します。コード分​​析の機能は含まれておらず、上記の完全なハードコアを使用していませんが、プロジェクト内の脆弱な外部コンポーネント、データ漏えいに敏感な構成の欠陥、埋め込みWebシェルおよび悪意のあるコードを検出する機能が含まれています：











このユーティリティは、公式Webサイトからダウンロードできます。使用する前に、必ずライセンス契約をお読みください。分析中に、Approofは非機密のプロジェクト統計（CLOC、ファイルタイプ、使用済みフレームワークなど）を収集し、オプションでPTサーバーに送信します。アプリケーションの[About]セクションで、統計の送信を無効にするか、収集されたデータを含む生のjsonを表示できます。