この記事では、 AppChecker静的コードアナライザーを使用してオープンソースプロジェクトの脆弱性を検出するための一連のレビューを続けています。
このシリーズでは、深刻な脆弱性につながる可能性があるプログラムコードの最も一般的な欠陥について検討します。 この記事では、「表現の問題」などの広範なクラスの欠陥に焦点を当て、PHPおよびJavaの言語の例でそれらを調べます。
国際的なCWE分類では、このタイプの欠陥はCWE-569：Expression Issuesとして知られています。 プログラムコードの論理式にさまざまなエラーが含まれています。 このクラスの欠陥の特定のケースは、欠陥「比較ではなく割り当て」です。
比較の代わりに割り当てる（CWE-481：比較の代わりに割り当てる）-名前が示すように、欠陥は、比較演算子の代わりに、プログラムコードで割り当て演算子が使用されることです。 このようなコードのエラーは、プログラムの不正な操作につながり、深刻なセキュリティ侵害につながる可能性があります。
このようなミスをすることを恐れて、いわゆるヨーダ表記法が登場し、定数を書くか、比較演算子の左側に関数を呼び出す必要がありました。通常の「j == 7」ではなく「7 == j」です。 コードを見てみましょう。 たとえば、これ：
pswd=GetText(); if (consthash=hash(pswd)); //
pswdは、ユーザーが入力したパスワードが保存される変数であるとします。 条件文では、パスワードハッシュを事前定義された値と比較する必要があります。 これらの値が一致する場合、パスワードが一致し、ユーザーにアクセスが許可されていると見なされます。 ただし、この例では、比較演算子の代わりに「==」が割り当て演算子「=」です。 この場合、ハッシュ（pswd）の値がconsthash変数に割り当てられ、この操作が成功するため、プログラムは条件が満たされていると見なし、入力されたパスワードに関係なく、ユーザーの承認につながります。
この例は非常に人工的なものであり、深刻なソフトウェア製品にはほとんど見られないように思われます。 ただし、オープンソースプロジェクトの分析では、この欠陥は非常に一般的であることが示されました。 通常、このような欠陥は、開発者の不注意により発生します。 同様の欠陥は、シグネチャヒューリスティック分析を使用して検出できます。
逆の欠陥があると仮定することは論理的です：割り当ての代わりに比較。 実際、CWE分類では、このタイプの欠陥をCWE-482：割り当てではなく比較と定義しています。
次に、割り当て操作の代わりに比較操作が使用される実際のコードの例を示します。
if ($mValueCount == floor($mValueCount)) { ... } else { $mValueCount == floor($mValueCount); ... }
ご覧のとおり、プログラマーのミスにより、条件演算子の条件と本体の式は同じですが、2番目の場合には明らかに代入演算子が必要です。 このコードフラグメントは、PHP-PHPExcelバージョン1.8.1を使用してドキュメントを操作するためのライブラリから取得されます。 AppCheckerを使用して発見された欠陥を開発者に通知しており、この欠陥が修正されたパッチ（ https://github.com/PHPOffice/PHPExcel/pull/710/files ）がすでにリリースされています 。
このタイプの欠陥の別の例は、MP3を操作するためのライブラリで見つかりました。MP3は、一部のCMS、特にワードプレスの一部であり、PHPで記述されています-getID3-1.9.10 ：
if (ord($frame_ownerid) === 0) { $frame_ownerid == ''; }
このコードフラグメントからわかるように、比較は条件ステートメントの本文で行われますが、ロジックは割り当てである必要があります。 開発者にこの欠陥を通知し、彼らはすぐにこの欠陥を修正しました（ https://github.com/JamesHeinrich/getID3/pull/57/files ）。
ただし、式クラスの欠陥は、これら2つの欠陥に限定されません。 別の例は、「式は常に真」（CWE-571：式は常に真）および「式は常に偽」（CWE-570：式は常に偽）という欠陥です。 名前が示すように、これらの欠陥は、条件文に条件を記述することを伴います。条件文は常にtrue /常にfalseになります。つまり、このコードのセクションに条件文は必要ありません。
例として、PHPで記述されたオープンソースのCMSコードフラグメントChamilo LMS 1.10.4を考えます。
if ($row['item_type'] != 'dokeos_chapter' || $row['item_type'] != 'dokeos_module') {
'item_type'の同じ値が 'dokeos_chapter'と等しくないか、または 'dokeos_module'と等しくないことが必要であるため、条件文の式は常に真です。 したがって、この式がfalseになる唯一のオプションは、 'item_type'が同時に両方、一般的に異なる値に等しい場合です。 開発者に欠陥が通知され、すぐに修正されました（ https://github.com/chamilo/chamilo-lms/pull/1109/files ）。 判明したように、演算子は「||」ではなく「&&」という表現で立つ必要があります。
逆の例として、 OpenCart 2.2.0.0オープンソースeコマースプラットフォームを考えてみましょう。
if ($chr == 252 && $chr == 253) {
明らかに、$ chrを同時に252と253にすることはできません。開発者はこの問題も修正しました（ https://github.com/opencart/opencart/pull/4231/files ）。 結局のところ、ステートメントには&&の代わりに演算子||が必要です。
式の問題タイプの欠陥は、バイナリ式の両方の部分が同一の場合に起因する場合もあります（特定の場合、これは自己割り当てにつながります）。 次のJavaコードスニペットを検討してください。
if (s2.getClass() != s2.getClass()) return false;
このコードスニペットからわかるように、s2.getClass（）はそれ自体と比較され、その結果、条件は常にfalseになります。 ほとんどの場合、これはプログラマの単なる誤植ですが、ケースは人為的とはほど遠いものです。 この例は、クロスプラットフォームのメディアデータ管理システムであるgoogle sageTVからの抜粋です。 開発者にこの欠陥が通知され、すぐに修正されました（ https://github.com/google/sagetv/commit/93144762681a5f441ad011564ff8309095d9ca31 ）。
明らかに、そのような欠陥はプログラミング言語から独立しています。 AppCheckerを使用すると、サポートされているすべての言語でこのような欠陥が検出されます。
次のPHPの例は、 OpenEMR-4.2.1から取得したものです。
if ( !empty($obx24) || !empty($obx24) || !empty($obx25) )
このコードスニペットからわかるように、$ obx24の値は2回チェックされますが、最初のケースでは論理的に$ obx23である必要があります。 開発者のこのような不注意は、プログラムに重大な問題を引き起こす可能性があります。 OpenEMR開発者もこれに同意します-彼らはそれについて彼らに知らせたとき、彼らはすぐにこの欠陥を修正しました（ https://github.com/openemr/openemr/pull/179 ）。
このような欠陥は非常に長い間見過ごされる可能性がありますが、プログラムは正しく動作せず、場合によっては、既に発見したように、セキュリティの脆弱性につながる可能性があります。 欠陥は論理的であり、したがってプログラミング言語に依存しないことに注意する価値があります。
この記事では、式の問題などの欠陥を調べました。 このような欠陥は単純で見かけ上は見落とされがちですが、オープンソースと商用プロジェクトの両方で頻繁に発見されます。
PS>
AppCheckerの無料バージョンは、当社のWebサイトhttps://file.cnpo.ru/index.php/s/o1cLkNrUX4plHMVからダウンロードできます。