クライアントコードに存在する可能性のあるエラーを考慮してください。
コードインジェクション
コードインジェクションの可能性を残しました-OWASP分類によると、最も一般的で最も危険な脆弱性の1つです。 OpenSSL Heartbleed（2014年4月29日）やEbayプラットフォームのハッキング（2014年5月22日）など、よく知られた脆弱性のほとんどは、意図せずにプログラムにユーザー入力を注入する可能性に関連しています。 この種のエラーの危険性は、脆弱なプログラムの実行のほとんど予測不可能な結果にあります。 SQLコードを挿入すると、パスワードリークが発生したり、すべてのシステムデータが完全に削除されたりする可能性があります。 このような脆弱性に関連する追加の問題は、自動化された手段でそれらを見つけることが難しいことです。 ルールやパターンに基づいた検索では、多数の誤って定式化された仮定により、肯定的な結果が得られません。 エラーを見つけるための本当に効果的な唯一の方法は、プログラムに入るデータストリームの静的分析（情報フロー制御）です。 データストリームの静的分析により、潜在的に危険なポイントに到達するデータを追跡し、コードインジェクションの脆弱性の有無について最も正確な仮定を立てることができます。
ディレクトリバイパス
もう1つの危険なコードエラーは、入力データのなりすましの可能性を意図せずに放棄したことで、これによりディレクトリトラバーサルが可能になります。 このような脆弱性を使用する攻撃者は、事前定義されたディレクトリの外部にあるデータを読み書きできます。 したがって、重要なシステム設定を読み取ったり、構成ファイルを上書きしたりすることができます。これにより、システムが十分に長期間無効になる可能性があります。 このエラーを使用するための非常に具体的なオプションが可能です。 たとえば、Unixシステムで読み取り用にファイルを開くOPEN DATASET dset FILTER iv_filterステートメントを呼び出すと、読み取りファイルから、オペレーティングシステムレベルで予期しないアクションを実行できる定義済みプロセスにデータが配信されます。 したがって、誤ったOS構成と、個々にエラーのない脆弱なコードは、連携するときに重大な結果につながる可能性があります。 次の記事では、不適切な構成の問題について学習します。
認証エラー
プログラマーは、アプリケーションの開発における権限の概念に導かれていますか？ この概念に従って、プログラムの機能ブロックへのアクセスは、反対のことが決定されるまで禁止されるべきです。 残念ながら、多くのプロジェクトでは、アクセス制御はトランザクションレベルで行われます。これにより、禁止されている情報にアクセスするために、さまざまな既存の権限を組み合わせることができます。 たとえば、トランザクションレベルでアクセス制御を行うプロジェクトでCALL TRANSACTIONステートメント（開発者が広く使用している）を使用することは安全ではありません。 WITH AUTHORITY-CHECKを指定せずに、CALL TRANSACTIONステートメントを使用すると、他のトランザクションをジャンプできます。 許可チェックがある可能性もありますが、誤って行われました。 そのような場合も見つけて修正する必要があります。
バックドア
その前に、プログラマが意図しないエラーを犯した結果、コードが脆弱になった脆弱性のいくつかのケースを調べました。 ただし、プログラマーが特定のユーザーのプログラム実行コースを意図的に変更したり（「文書化されていない機能」）、いわゆるバックドアを残すこともあります。これにより、システムによって設定されたすべてのチェックをバイパスできます。 開発者は、実装プロジェクトでの「効率的な」作業のためにSAP_ALL権限を取得するなど、悪意のある目的なしでバックドアを作成できます。 明らかに、これはバックドアがもたらすリスクを損なうものではありません。 ネットワーク上にこのようなバックドアの多くの例があり、それらは単にコピーして本稼働システムに転送できます。 文書化されていない機能やバックドアの存在を把握することは非常に困難です。これは、第一に大量のクライアントコードのため、第二にSAPプログラミング言語の機能のためです。 ABAPはコードをその場で実行することを許可し、DBMSに保存されます。 非常に深く隠すことができます
エラーを探す方法は？
コード内の脆弱性を検索する方法はいくつかありますが、最も高度なものはデータストリームの静的分析です。 SAP Netweaver ASには、脆弱性の有無に関するデータフロー分析（コード脆弱性分析）を実装するモジュールがあります。 脆弱性がないかアプリケーションコードをスキャンできる認定パートナーソリューションがあります。 SAP Code Vulnerability Analysis（CVA）は、Code Inspectorツールに基づいており、長年にわたってクライアントコードで潜在的に危険な構造をチェックできますが、Code Inspectorとは異なり、データフロー分析を使用します。 最も適切なのは、プロジェクトの最初の段階から-開発段階から（開発がランドスケープに沿ってさらに転送されるまで）CVAを使用することです。 後で修正する（たとえば、本稼働中）のはより複雑でコストがかかります。 CVAの実装は、エラーの検索と修正だけでなく、企業の開発標準へのアプローチの変更を意味します。 生産システムへの新しい開発の導入は、最新の開発分析ツールによって作業を指導される専門家によって承認される必要があります。
まとめ
この記事では、SAP製品のセキュリティ問題がお客様がよく想像するよりもはるかに広いことを示したかったのです。 SAPベースのソリューションをサポートする際に発生する可能性のあるすべての問題を明確に理解することが重要です。 これを行うには、現状を把握しておく必要があります。これについては、一連の記事の一部として説明します。
著者-ダニエル・ルージン
SAP CIS LLCのコンサルティング部門
コスモダミアン堤防 52 / 7、113054モスクワ
T. +7 495 755 9800 ext。 3045
M. +7 926 452 0425
F. +7 495 755 98 01