安全なソースコード分析を実行するには、優れたプログラマである必要がありますか？
ある人は、全体的なセキュリティリスクについて十分な知識を持ち、OWASPのトップ10の脆弱性を知っており、CEH、CISSP、OSCPなどのブラックボックステストである認定を受けています。また、OWASPテストガイド、コードレビューガイドなど、チートシートも参照しています。彼は、複数のプログラミング言語の知識がなく、それらを熟知していなくても、安全なコードレビューを実行できますか？
それは「安全なソースコード分析」が何を意味するかに依存します。何でも好きなことができます。問題は、おそらく誰かが「安全なソースコード分析」と呼ばれるものを求めたときであり、なぜそれが適格でないのか不思議に思うでしょう。
多くの場合、そのような分析はSubject Matter Expert（SME）が行う必要があります。最終的な製品では、SMEは、「このコードは安全であることを宣言します」と基本的に述べたステートメントを提供します。パターン、および問題は見つかりませんでした。」
中国の哲学の真正な翻訳に興味があるなら、哲学について多くのことを知っていて、それを解読するのに役立つたくさんのチートシートを持っていたが、実際には中国語を知らなかった個人を信頼しますか？
頭に浮かぶ素晴らしい例の1つは、SQLエンジンにヒットするバグです。確認できるように、どのエンジンまたはどのバージョンの名前がないのかを許してください。それ以来、それを見つけるのに苦労しました。ただし、エラーは切実なものでした。エラーは次のようなコードにありました：
_int storeDataInCircularBuffer(Buffer* dest, const char* src, size_t length)
{
if (dest->putPtr + length < dest->putPtr)
return ERROR; // prevent buffer overflow caused by overflow
if (dest->putPtr + length > dest->endPtr) {
... // write the data in two parts
return OK;
} else {
... // write the data in one part
return OK;
}
}
_このコードは、循環バッファーの一部となることを目的としています。循環バッファーでは、バッファーの最後に到達するとラップします。これにより、受信メッセージを2つの部分に分割しなければならない場合がありますが、これは問題ありません。ただし、このSQLプログラムでは、lengthが_dest->putPtr + length_をオーバーフローさせるのに十分な大きさになり、次のチェックが正しく機能しないためにバッファーオーバーフローが発生する可能性があるケースに懸念を抱いていました。したがって、彼らはテストを行います：if (dest->putPtr + length < dest->putPtr)。彼らの論理は、このステートメントが真になる可能性がある唯一の方法は、オーバーフローが発生した場合であり、したがってオーバーフローをキャッチすることでした。
これにより、実際に悪用されるセキュリティホールが作成され、パッチを適用する必要がありました。どうして？まあ、元の作者には知られていないが、C++仕様では、ポインターのオーバーフローは未定義の動作であることを宣言しているため、コンパイラーは必要な処理をすべて実行できます。このように、元の作者がテストしたとき、gccは実際に正しいコードを出力しました。ただし、数バージョン後のgccには、これを活用するための最適化がありました。そのifステートメントがテストに合格できる定義済みの動作がないことがわかり、最適化されました！
したがって、いくつかのバージョンでは、コードにエクスプロイトを防ぐための明示的なチェックがあったとしても、エクスプロイトがあったSQLサーバーがありました！
基本的にプログラミング言語は、開発者を簡単にかじることができる非常に強力なツールです。これが発生するかどうかを分析するには、問題の言語の強固な基盤が必要です。
（編集：Greg Baconは、これに関するCERT警告を掘り下げるのに十分でした： 脆弱性ノートVU＃162289 Cコンパイラは、ラップアラウンドチェックを静かに破棄する可能性があります。 、そして this 関連1つ。Gregに感謝！）
成功するには、優れたプログラマーである必要があると思います。ツールキット/スキャナーが見落としていることがたくさんあるかもしれません。悪用は絶えず変化し、スキャナーが脆弱性を検出できない方法で誰かがコード化した可能性があるため、正直に言って、ツールに完全に依存してコードをスキャンすることはお勧めしません。
コードをステップ実行して、コードがどのように機能し、どのように機能しないかを確認する機能は、ソフトウェア開発を保護するための基本です。開発者にセキュリティの問題を認識させることは、確かな製品を製造するために必要なことであり、コードレビュー中に必要なことです。
可能ですが、スキャナーやツールキットを使用して脆弱性をポイントアンドクリックして確認することはできますが、大規模な計画ではそれほど効果的ではありません。自分でコードを見て、それが良いか悪いかを判断できれば、どれほど効果が上がるか知っていますか？いいね.
何をしているのかわからない場合は、安全なコードレビューに合格しようとしないでください。ただし、良いレビューを実施できる段階にいないと感じた場合は、あきらめないでください。自分でモックアップの安全なコードレビューを作成し、何回か試してすべてが問題ないことを確認して学ぶことをお勧めします。
しかし、それでも、あなたは間違いなくコーディングだけでなく、うまくコーディングすることを学ぶべきです。
セキュリティの専門家が、熟練したプログラマーでなくても、ソースコード分析を効果的に行えるかどうかは疑問です。多くの脆弱性は、いくつかのマイナーな方法で誤用されている技術的または構文的なコーディングプラクティスの結果です。セミコロンがない、二重等号の代わりに等号、1日目に二重に定義されている配列境界、ただし次のリリースで1つのバージョンが変更されている、括弧がない、メモリリークがあるなど、すべて脆弱性につながっています。経験豊富な開発者はこれらを見るかもしれませんが、初心者はおそらく見ないでしょう。
セキュリティの専門家がすべきことは、静的コードアナライザー、ファズテスター、動的アプリ検証ツールなどの自動スキャンツールを使用することをエンジニアに奨励することです。エンジニアリングチームが入力検証、インジェクション攻撃、信頼境界を理解できるように支援します。セキュリティの欠陥に適切に優先順位を付け、迅速に対処する必要があることを認識させます。ペンテストをスケジュールして実施します。そして最も重要なことは、エンジニアに互いの作業のコードレビューを行わせることです。
はい、セキュリティの専門家はコードを読み取ることができるはずですが、それは彼がコードセキュリティの調停者としての資格があることを意味するものではありません。
それはあなたの期待次第です。設計上の問題（CSRF保護の欠如、プロトコルの初歩的な実装のみなど）によって引き起こされるセキュリティの脆弱性は、テスターがセキュリティコンセプトの深い知識を持っている場合、おそらく、コードフローを追跡することなく、特定のプログラミング言語についての深い知識を持っている。
ただし、バッファオーバーフロー、オフバイワンエラー、ユニコードまたは\0の処理、データタイプのサイズと符号付きと符号なしの問題など、言語固有のセキュリティ問題は、テスターにない場合は検出されません言語、悪習、および言語固有の典型的な不安パターンの深い知識。 Java脆弱性の履歴を例に取ってみましょう。ここでJavaエキスパート開発者でさえ、リフレクションを追加して言語のサンドボックスに穴を開けたことに気づきませんでした言語のみ 外部の専門家 言語の内部を深く理解し、内部で欠陥を検出しました。
安全なコードレビューには、高水準言語の知識だけでなく、コンパイラオプションと、コードが実際にCPUでどのように機能するかについての知識も必要です！高水準言語は複雑さの多くを隠すため、コードを記述するのに効率的です。しかし、多くのエラーやバグが複雑さの中に隠れています。別の答えで指摘されているように、コンパイラーは正しいことを行おうとしますが、コードを逆アセンブルし、それがどのように機能するかを深く理解することによって、何が起こっているのかを本当に理解する必要があります。
この理解は、JavaScriptのようなスクリプト言語でも、CPU命令とメモリ割り当てに対する高レベルのコードを解釈するために必要です。残念ながら、このレビューはプラットフォームに依存します。たとえば https://en.m.wikipedia.org/wiki/Interpreted_language を参照してください。
安全なソースコード分析を実行するには、優れたプログラマである必要がありますか？
番号。
彼は、複数のプログラミング言語の知識がなく、それらを熟知していなくても、安全なコードレビューを実行できますか？
番号。
プログラミングには、さまざまな言語がどのように機能するかの詳細に関する専門知識以上のものがあります。これは、優れたプログラマーになるために必要なことの1つであり、セキュリティの観点（またはその他の品質）からソースコードを分析するために必要なことの1つでもあります。
したがって、優れたプログラマーである必要はありませんが、関係する言語を習得する必要があります。
サイドチャネル攻撃の危険性を適切に把握するには、ハードウェアを知る必要があります。特権のあるプロセスと並行して非特権プロセスをマルチCPUセットアップで実行し、暗号化/復号化タスクを実行して、どの共有キャッシュラインがどのような時間パターンでダーティになるかを調べるなど、本当に醜いサイドチャネル攻撃があります。暗号化される特定のパターンシーケンスのそれぞれの配信のタイミング。
暗号化アルゴリズムは数学者や他の理論家の厳しい調査のもとにあり、サイドチャネル攻撃はゲームを再びオープンにするためのますます重要な方法です。欠点は、特定の実装、コード、およびハードウェアに向けて細工する必要があることです。