コードの脆弱性。マイナーエラーから危険な欠陥をどのように見分けることができますか？

通常、アプリケーションコードの脆弱性をチェックするように見えますか？セキュリティスペシャリストが手順を開始し、コードがスキャンされ、アプリケーションで何千もの脆弱性が発見されます。セキュリティ担当者と開発者の両方の全員がショックを受けています。開発者の自然な反応：「はい、確かに半分は誤検知であり、残りは重大ではない脆弱性です！」



誤検知については、ここではすべてが単純です。誤検知の疑いで脆弱性が発見されたコード内の場所を直接確認できます。確かに、それらのいくつかは誤検知であることが判明する可能性があります（明らかに全体の半分ではありませんが）。



しかし、何が重要で何が重要でないかについて、私はもっと実質的に話したいと思います。SHA-1を使用できなくなった理由と、「;」をエスケープする理由を理解していれば、おそらくこの記事では新しいことはできません。しかし、見つかった脆弱性のスキャン結果が目がくらむ場合は、カットの下で歓迎します-モバイルおよびWebアプリケーションで最も頻繁に見られる「穴」、それらの動作、修正方法、そして最も重要なこと-目の前にあるものを理解する方法を説明します-コードの危険な欠陥または軽微なエラー。

実装

よくあるタイプの脆弱性です。これらは、SQL、LDAP、XML、XPath、XSLT、Xqueryクエリなど、あらゆる場所に埋め込まれています。これらのインジェクションはすべて、信頼できないデータの使用によって区別されます。これにより、攻撃者は情報にアクセスしたり、アプリケーションの動作を変更したりできます。たとえば、十分に検証されていないユーザー入力がある場合。



脆弱性OWASPの国際分類によると、インジェクション方式を使用した攻撃は、Webアプリケーションのセキュリティに対する脅威の重大度のレベルで最初にランク付けされます。最も典型的なタイプの実装について考えてみましょう。



SQLインジェクション。信頼できないデータは、データベースへのSQLクエリに入ります。







データベースへのクエリが入力データの正しい認証を実装していない場合、攻撃者はSQLクエリを破壊する可能性があります。

• 悪意のあるコードを送信します。
• 記号「-」または「;」を追加します 正しいSQLコマンドを終了します。「-」の後のすべてはコメントとして解釈され、文字「;」は コマンドの終わりを示します。
• 一連のSQLクエリを順番に実行して、パスワードを推測します。

自分を守る方法は？OWASPからのいくつかの推奨事項は次のとおりです。

• パラメータ化されたインターフェイスまたはオブジェクトリレーショナルマッピング（ORM）ツールを提供するAPIを使用します。
• ユーザーが入力したデータの検証メカニズムを実装します。サーバー側の検証ホワイトリストを使用します。
• 特殊文字をエスケープします（ ";"、 "-"、 "/ *"、 "* /"、 "'";正確なリストはデータベースによって異なります）。
• ストアドプロシージャをパラメータのフィルタリングメカニズムと組み合わせて使用​​して、ユーザー入力を検証します。

XMLインジェクション。アプリケーションはXMLを使用してデータを保存または交換するため、貴重な情報を含めることができます。







攻撃者がXMLドキュメントにデータを書き込むことができる場合、攻撃者はそのセマンティクスを変更できます。この場合、最も無害なシナリオでは、ドキュメントに追加のタグを挿入できます。その結果、XMLパーサーはエラーで終了します。ただし、より深刻な問題に直面する可能性があります。たとえば、顧客ベースの認証データやストアの製品データベースの価格を置き換える場合などです。 XMLインジェクションは、クロスサイトスクリプティング（XSS）（ページが開かれたときにユーザーのブラウザーで実行される悪意のあるコードのインジェクション）につながる可能性もあります。



何をアドバイスできますか？

• 信頼できないソースからのデータ（ユーザーが入力したものなど）から名前が派生したタグや属性を作成しないでください。
• XMLドキュメントに書き込む前に、ユーザーが入力したデータをエンコード（XMLエンティティエンコード）します。

XQueryインジェクションは従来のSQLインジェクションの形式ですが、この場合、攻撃はXMLデータベースを標的とし、信頼できないデータはXQuery式になります。



以下の例では、アプリケーションが作成され、パラメータに基づいてXQuery式を実行usernameし、passwordHTTPリクエスト（信頼できないソース）からの：

XQDataSource xqs = new XQDataSource();
XQConnection conn = xqs.getConnection();
String query = "for \$user in doc(users.xml)//user[username='" + request.getParameter("username") + "'and pass='" + request.getParameter("password") + "'] return \$user";
XQPreparedExpression xqpe = conn.prepareExpression(query);
XQResultSequence rs = xqpe.executeQuery();

データが正しい場合、リクエストは適切な名前とパスワードでユーザーに関する情報を返します。

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

攻撃者が特殊な文字（たとえばadmin' or 1=1 or ''='）を含む文字列をパラメーターとして指定すると、要求のセマンティクスが変更されます。

//user[username='admin']

受信したリクエストは、すべてのユーザーに関するデータを返します。



安全なオプション（使用prepared statements）：

XQDataSource xqs = new XQDataSource();
XQConnection conn = xqs.getConnection();
String query = "declare variable $username as xs:string external; declare variable $password as xs:string external; for \$user in doc(users.xml)//user[username='$username' and pass='$password'] return \$user";
XQPreparedExpression xqpe = conn.prepareExpression(query);
xqpe.bindString(new QName("username"), request.getParameter("username"), null);
xqpe.bindString(new QName("password"), request.getParameter("password"), null);
XQResultSequence rs = xqpe.executeQuery();

アプリケーションがXSLを操作するときに信頼できないソースからのデータを使用する場合、XSLT（XMLドキュメント変換言語）への埋め込みが可能です。



アプリケーションはXSLを使用してXMLドキュメントを変換します。XSLスタイルのファイルには、変換を説明する関数が含まれており、正しく実装されていない場合は、脆弱性が含まれる可能性があります。この場合、攻撃者がXSLスタイルファイルの構造とコンテンツ、したがって対応するXMLファイルを変更する攻撃シナリオのリスクが高まります。出口で何が得られますか？



まず、XSS攻撃：Webシステムによって発行されたページに悪意のあるコードを挿入し、このコードを攻撃者のサーバーと相互作用させます。次に、ハッカーはシステムリソースにアクセスできます。第三に、任意のコードの実行。そしてデザートの場合-XXE攻撃（XML eXternalエンティティ-XMLへの外部エンティティの注入）。軽量ディレクトリアクセスプロトコル（



LDAP）をコマンドに挿入すると、データが失われたり変更されたりする可能性があります。この場合、信頼できないデータがLDAP要求に入ります。



悪意のあるインタープリターコマンドの挿入。信頼できないデータがインタプリタコマンドに入ります。攻撃者はそのような入力を選択して、コマンドが正常に実行され、アプリケーションの追加のアクセス許可を利用できるようにすることができます。



以下の例では、アプリケーションはスクリプトを実行してデータベースのバックアップを作成します。アプリケーションは、バックアップタイプをパラメーターとして受け取り、昇格された特権でスクリプトを実行します。

String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\utl\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);

ここでの問題は、パラメーターがbackuptype検証されないことです。通常Runtime.exec()、複数のコマンドを実行することはありませんが、この場合、cmd.exeを最初に起動して、を呼び出して複数のコマンドを実行しますRuntime.exec()。コマンドラインシェルが開始されると、「&&」文字で区切られた複数のコマンドを実行できます。攻撃者&& del c:\\dbms\\*.*が文字列 " "をパラメータとして指定すると、アプリケーションは指定されたディレクトリを削除します。



開発者向けのヒント：

• アプリケーションが実行するコマンドをユーザーが直接制御できないようにしてください。アプリケーションの動作がユーザーが入力したデータに依存する必要がある場合は、許可されたコマンドの特定のリストからユーザーに選択肢を提供します。
• , . , . , .
• , , . . .

安全でないファイルのアップロード。この場合、個々のデータは信頼できないソースからのものだけでなく、ファイル全体からのものです。したがって、攻撃者は悪意のあるデータまたはコードをターゲットサーバーにアップロードできます。たとえば、企業ネットワーク上のユーザーが公的にアクセス可能なディレクトリにファイルをアップロードすることを許可されている場合、ハッカーは企業のサーバー上で悪意のあるコードをリモートで実行できます。



HTMLに外部ファイルを安全に含めない。ファイルインクルードの脆弱性は、ユーザーがインクルードされたファイルへのパスを入力したときに発生します。事実、最新のスクリプト言語では、サードパーティのファイルからコードを動的にリンクして再利用することができます。このメカニズムは、ページの外観を統一したり、コードを小さなモジュールに分割したりするために使用されます。ただし、攻撃者はパスを変更してファイルを接続することにより、この包含を悪用する可能性があります。



企業の情報セキュリティの専門家は、有効なファイル接続パスの「ホワイトリスト」を作成して、従業員がこのリストのスクリプトに従ってのみファイルを追加できるようにすることをお勧めします。

ブックマーク

ブックマークは、アプリケーションコードに意図的に導入された部分であり、特定の条件下で、アプリケーションに含まれていないアクションを実行できます。最も一般的な種類のブックマークについて考えてみましょう。



特別アカウント。アプリケーションがパスワードまたはログイン変数の値を変更されていない値と比較する場合は、注意してください。このアカウントはブックマークの一部である可能性があります。これがどのように起こるか見てみましょう。







アプリケーションの開発者は、デバッグ時に特別なアカウント（おそらく昇格された特権を持つ）を使用し、コードの対応するセクションを最終バージョンのままにして、アプリケーションへのアクセスを保持します。攻撃者は、アプリケーションの元のコードを復元し、特別なアカウントの定数値を抽出して、アプリケーションにアクセスすることができます。

ログイン、パスワード、キーをアプリケーションのソースコードに保存することは断固として不可能です。

隠し機能（NDV）。非表示の機能コードは、特定のトリガーが起動したときに実行されます。Webアプリケーションでは、トリガーは「非表示」のクエリパラメーターであることがよくあります。さらに、トリガー付きのリクエストがどのIPから送信されたかをチェックして、作成者だけがブックマークをアクティブ化できる場合もあります。このようなチェックは、可能なブックマークのシグナルとして機能します。



文書化されていないネットワークアクティビティ。このタイプのアクティビティには、バックグラウンドでのサードパーティリソースへの接続、文書化されていないポートのリッスン、SMTP、HTTP、UDP、ICMPを介した情報の転送が含まれます。

既知の安全なアドレスのリストにないアドレスの疑わしい接続をコードで見つけた場合は、それを削除することを強くお勧めします。

セキュリティ設定を変更します。アプリケーションには、認証の成功を格納する変数の値を変更するコードが含まれています。よくある間違いは、比較（==）の代わりに割り当て（=）を使用することです。認証方法では、バックドアの一部になる可能性があるため、特に危険です。

if (isAuthenticated = true)
{
    someDangerousAction();
}

タイムトリガー（時限爆弾）。特定の時点で起動するブックマーク。アプリケーションは、現在の日付を特定の年、月、日と比較します。2021年1月1日に、驚きが皆を待っています。

Date now = java.util.Date();    // current time
if ((now.getYear() == 2021) && (now.getMonth() == 1) && (now.getDate() == 1))
{
    activateNewYearBackdoor();
}

またはそうではないかもしれません...実際には、一時的なトリガーを検索するときに、誤検知が頻繁に発生します。たとえば、time APIが意図された目的（ロギング、実行時間の計算、HTTP要求に対するサーバー応答のタイムスタンプ）に使用されている場合。



だが！そのような脆弱性の実際の例を知っているので、そのようなすべてのアラームに目を閉じないことをお勧めします。



デッドコード。何も役に立たない挿入されたコードの断片。デッドコード自体は危険ではありませんが、複数のファイルに分散されているブックマークの一部である可能性があります。または、ブックマークトリガーは後で実装される予定です。いずれにせよ、デッドコードは疑わしいはずです。

暗号化の欠如と弱い暗号化アルゴリズムの使用

暗号化の主な問題は、暗号化がまったく使用されていないか、弱いアルゴリズムが使用されていることと、キーとソルトが単純すぎるか、安全に保存されていないことです。これらすべての脆弱性の結果は同じです-機密データを盗むのは簡単です。



この例は、従来のDESアルゴリズムを使用した暗号化の初期化を示しています。

Cipher cipher = Cipher.getInstance("DES");

脆弱な暗号化アルゴリズムの例：RC2、RC4、DES。安全なオプション：

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

OWASPの 国際分類によると、「機密データ漏洩」などの脆弱性は、Webアプリケーションのセキュリティ脅威の重大度の観点から3番目にランク付けされています。



開発者への推奨事項：セキュリティを念頭に置いて暗号化を使用してください。



HTTPSの代わりに安全でないHTTPプロトコルを使用すると、攻撃の途中でManが発生します。



安全なHTTPSプロトコルはHTTPに基づいていますが、SSL / TLS暗号化プロトコルを介した暗号化もサポートしています。 HTTPSは、HTTPSを介して送信されるすべてのデータ、特にログインとパスワードの入力ページまたはユーザーの銀行カードデータを暗号化し、不正アクセスや変更から保護します。送信されたデータを保護しないHTTPとは異なります。その結果、攻撃者はHTTPを介して情報Webサイトを偽装し、ユーザーに偽のページにデータを入力させる可能性があります（フィッシング攻撃）。



暗号化キーはソースコードで指定されています。その結果、このようなキーはすべてのアプリケーション開発者が利用できます。さらに、アプリケーションのインストール後は、更新を使用してのみコードからキーを削除できます。



一般に、定数文字列は、ソースコード回復プログラム（デコンパイラー）を使用して実行可能ファイルから簡単に抽出されます。したがって、攻撃者は、使用されているキーの値を見つけるためにソースコードにアクセスする必要はありません。私たちの実践では、開発者がキー値としてnull空の文字列を指定する場合がよくありますが、これは単に受け入れられません。



私たちのアドバイス：暗号的に強力な疑似ランダム番号ジェネレーター（PRNG）を使用してキーを生成し、特別なモジュールを使用してそれらを保存します。



暗号化のための安全でないパディングアルゴリズム。 RSA暗号化アルゴリズムをOAEPパディングなしで使用すると、暗号化されたデータが脆弱になります。



RSAを使用する前にメッセージを処理するには、OAEPアルゴリズムが必要です。メッセージは最初にOAEPを使用して固定長にパディングされ、次にRSAを使用して暗号化されます。この暗号化スキームはRSA-OAEPと呼ばれ、現在の標準の一部です。



これは、パディングなしでRSA暗号化を初期化する例です。

rsa = javax.crypto.Cipher.getInstance("RSA/NONE/NoPadding");

安全なオプション：

rsa = javax.crypto.Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding");

暗号化キーのサイズが不十分です。短いキーを使用する場合、この暗号化はブルートフォース攻撃に対して脆弱です。



暗号分析は静止しておらず、新しい攻撃アルゴリズムが絶えず出現しており、コンピューターはより強力になっています。以前は安全であると見なされていた暗号化設定は廃止され、使用が推奨されなくなりました。そのため、キーの長さが1024ビットのRSAは、2010〜2015年には安全であるとは見なされなくなりました。



弱いハッシュアルゴリズム。前の段落で説明した理由により、ハッシュ関数MD2、MD5、SHA1は安全ではありません。 MD2およびMD5関数の衝突を見つけるために、多大なリソースを必要としません。



SHA1の場合、同じハッシュを持つ2つの異なるファイルの例があります。提案されたハッキングアルゴリズムGoogleとアムステルダムの数学およびコンピュータサイエンスセンターの従業員。







ユーザーパスワードがハッシュとして保存されているが、安全でないハッシュ機能を使用している場合、攻撃者は次のシナリオを実装することで簡単にアクセスできます。パスワードのハッシュを知り、ハッシュアルゴリズムの脆弱性を利用することで、ハッシュがパスワードと同じである文字列を計算することができます。攻撃者は、計算された文字列を使用して認証します。



パスワードを保存するためのハッシュ関数は、ブルートフォース攻撃を実装できないように、衝突に強く、速すぎないようにする必要があります。安全なアルゴリズムPBKDF2、bcrypt、scryptを使用する必要があります。



いくつかの興味深い数字：PBKDF2を使用キーの検索速度は、Intel Core2では毎秒70個、FPGA Virtex-4FX60では約1,000個に低下しました。比較すると、従来のLANMANパスワードハッシュ機能の検索速度は、1秒あたり約数億のオプションです。



弱い暗号化アルゴリズム。ハッシュアルゴリズムと同様に、暗号化アルゴリズムのセキュリティは、復号化に費やす必要のある時間とリソースによって決まります。 RC2、RC4、DESは脆弱なアルゴリズムと見なされます。後者は、キーの長さが短い（56ビット）ため、ブルートフォースによってクラックされる可能性があります。



弱い疑似ランダム数ジェネレーター（PRNG）は、予測可能なシーケンスを生成します。ハッカーは認証をバイパスして、ユーザーのセッションを乗っ取ることができます。



PRNGの性質についてもう少し詳しく見ていきましょう。これらは、パラメータの初期値に基づいて数値の文字列を生成しますseed。 PRNGには、統計と暗号の2種類があります。



統計的PRNGは、ランダムなシーケンスと統計的に類似した予測可能なシーケンスを生成します。セキュリティ目的で使用することはできません。



逆に、seedエントロピーの高いソースからパラメータ値を取得した場合、暗号化PRNGの動作結果を予測することはできません。現在の時間値にはエントロピーがほとんどなく、品質も安全ではありませんseed。 Javaでは、クラスからのPRNGjava.util.Randomとjava.lang.Math予測可能なシーケンスを生成し、情報セキュリティの目的のために使用すべきではありません。



疑似乱数ジェネレータの弱いシード。seed信頼できないソースからの値を使用すると、予測可能なシーケンスが生成されるため、安全ではありません。



多くの暗号化アルゴリズムの作業は、暗号分析に耐性のあるPRNGの使用に基づいています。一部のアルゴリズムは、値を追加の引数として受け取り、seedこのパラメーターの値ごとに予測可能なシーケンスを生成できます。この場合、システムのセキュリティは、値seedが予測できないという仮定に基づいています。



塩はソースコードで与えられます..。塩の目的を思い出しましょう。ブルートフォース方式でパスワードを解読するには、一般的なパスワードのハッシュ関数の値を含むコンパイル済みのテーブルを使用します。Saltは、このような攻撃をより困難にするために、パスワードとともにハッシュ関数の入力に供給される任意の文字列です。



ソルトがソースコードに保存されている場合、パスワードやキーの場合とまったく同じ問題が発生します。ソルトの価値は開発者が利用でき、侵入者が簡単に入手できます。ソルトは、アプリケーションの次のアップデートでのみ、アプリケーションの最終バージョンから削除できます。

ログによる操作

ログ内のさまざまなエラーは、悪意のあるコードがアプリケーションに導入されることで発生します。ロギングに関連する最も一般的な脆弱性は、ログファイルの改ざんと非構造化ロギングです。



ログファイルの改ざんは、アプリケーションが信頼できないデータをイベントログ（ログ）に書き込むときに発生します。ハッカーはログエントリを偽造したり、悪意のあるコードを挿入したりする可能性があります。



通常、アプリケーションは、トランザクション履歴をログに書き込んで、さらに処理、デバッグ、または統計を収集します。ログは手動または自動で解析できます。

データが「現状のまま」ログに書き込まれる場合、攻撃者は偽のレコードをログに挿入したり、ログプロセッサを失敗させてファイル構造を破壊したり、プロセッサの既知の脆弱性を悪用する悪意のあるコードを挿入したりできます。



この例では、Webアプリケーションが要求パラメーターから整数値を読み取ろうとします。入力した値を整数に変換できなかった場合、アプリケーションはこの値をエラーメッセージとともにログに記録します。

String val = request.getParameter("val");
try {
    int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
    log.info("Failed to parse val = " + val);
}

攻撃者はログに任意のエントリを追加できます。たとえば、行twenty-one%0a%0aINFO:+User+logged+out%3dbadguyは次のようにログに反映されます。

INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy

同様に、任意のレコードをログに埋め込むことができます。



安全なオプション（使用NumberFormatException）：

public static final String NFE = "Failed to parse val. The input is required to be an integer value."

String val = request.getParameter("val");
try {
    int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
    log.info(NFE);
}

非構造化ロギング、つまり、エラーメッセージを標準のoutまたはerrストリームに出力することは安全でない方法です。代わりに、構造化ロギングを使用することをお勧めします。後者を使用すると、レベル、タイムスタンプ、標準フォーマットでログを生成できます。プログラムが構造化されたロギングメカニズムを実装しているが、エラーメッセージが標準ストリームに出力される場合、ログに重要な情報が含まれていない可能性があります。

開発の初期段階でのみ、エラーメッセージを標準ストリームに出力することが許可されています。

安全でないCookieの処理

ユーザーCookieの収集に関連する脆弱性は非常に多様です。



クッキーの安全でない取り扱い。アプリケーションのCookieには、信頼できないソースからのデータが含まれています。これにより、キャッシュポイズニング、XSS（クロスサイトスクリプティング）、および応答分割攻撃が発生する可能性があります。



悪意のあるコード（クロスサイトスクリプト）がアプリケーションに挿入された場合、攻撃者はユーザーのCookieを変更できます。



HTTP応答ヘッダーにCookieが設定されているため、Cookieに含まれているデータの確認に失敗すると、分割応答攻撃が発生する可能性があります。 「HTTP応答分割」は、ハッカーがそのようなHTTP要求を送信する攻撃であり、その応答は、（正しい応答ではなく）2つのHTTP応答で被害者によって受け入れられます。

攻撃者authorがフォームの文字列をパラメータとして指定した場合、Hacker \r\nHTTP/1.1 200 OK\r\n...答えは次のように2つに分割されます。

HTTP/1.1 200 OK
...
Set-Cookie: author=Hacker

HTTP/1.1 200 OK
...

2番目の応答の内容は完全に攻撃者の制御下にあり、キャッシュポイズニング、XSS、悪意のあるリダイレクト、およびその他の攻撃につながります。



HttpOnlyのないCookie。アプリはフラグなしでCookieを作成しますhttpOnly。httpOnly応答ヘッダーに含まれている場合http、攻撃者はJavaScriptコードを使用してCookieを取得できません。また、ユーザーがクロスサイトスクリプト（XSS）の脆弱性があるページを開いた場合、ブラウザーはCookieをサードパーティに開示しません。フラグがhttpOnly設定されていない場合、スクリプトを使用してCookie（通常はセッションCookie）を盗むことができます。



フラグなしでCookieを作成する例httpOnly：

Cookie cookie = new Cookie("emailCookie", email);
response.addCookie(cookie);

httpOnlyCookieを作成するとき にフラグを設定します。ただし、攻撃を回避する方法はいくつかあるhttpOnlyため、入力を慎重に検証することにも注意する必要があることに注意してください。



注意：OWASPの国際分類によると、「機密データ漏洩」の脆弱性は、Webアプリケーションのセキュリティ脅威の重大度で3番目にランク付けされています。



一般的すぎるドメインのCookie。 cookieドメインが一般的すぎる場合（たとえば.example.com）、1つのアプリケーションの脆弱性により、同じドメイン内の他のアプリケーションが脆弱性にさらされます。



次の例では、アドレスにインストールされた安全なWebアプリケーションhttp://secure.example.comが、ドメイン値を使用してCookieを設定します.example.com。

Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain(".example.com");

http://insecure.example.comたとえば、XSSを含むアプリケーションが アドレスにインストールされている場合、そのアドレスにhttp://insecure.example.comアクセスした安全なアプリケーションの許可されたユーザーのCookieが危険にさらされる可能性があります。



攻撃者はCookieポイズニング攻撃を実行することもできhttp://insecure.example.comますhttp://secure.example.com。共通ドメインが作成されたCookieはCookieを上書きします。



安全なオプション：

Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain("secure.example.com");

一般的なパラメータが多すぎるCookiepath。Cookieのパスが不正確な場合（たとえば、/）、共有ドメインの場合と同じ問題が発生します。あるアプリケーションの脆弱性により、同じドメイン内の他のアプリケーションが公開されます。



次の例では、URLにインストールされたアプリケーションhttp://pages.example.com/forumが、パス/でCookieを設定します。

Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/");

次に、そのアドレスにインストールされた悪意のあるアプリケーションhttp://pages.example.com/evilがユーザーのCookieを危険にさらす可能性があります。攻撃者はCookieポイズニング攻撃を実行することもでき/evilます/forum。共有パスが作成されたCookieはCookieを上書きします。



安全なオプション：

Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/forum");

CookieはSSL経由ではありません。アプリケーションは、フラグをsecure等しく設定せずにCookieを作成しますtrue。これらのCookieは、暗号化せずにHTTP経由で送信できます。「安全でないHTTPプロトコルの使用」という脆弱性はすぐに思い出されます。



次の例では、アプリケーションはフラグなしでCookieを作成しますsecure。

Cookie cookie = new Cookie("emailCookie", email);
response.addCookie(cookie);

アプリケーションがHTTPSとHTTPの両方を使用している場合、セキュアフラグがない場合、HTTPS要求の一部として作成されたCookieは、後続のHTTP要求で暗号化されずに送信され、アプリケーションの侵害につながる可能性があります。 Cookieに貴重なデータ、特にセッションIDが含まれている場合、これは特に危険です。



安全なオプション：

Cookie cookie = new Cookie("emailCookie", email);
cookie.setSecure(true);
response.addCookie(cookie);

有効性が無制限のCookie。貴重なCookieを長期間保存すると、攻撃者がそれらにアクセスする可能性があります。



デフォルトでは、非永続（セッション）Cookieが使用されます。これはディスクに保存されず、ブラウザーを閉じた後に削除されます。ただし、Webアプリケーションの開発者は、Cookieを保持する期間を指定できます。この場合、Cookieはディスクに書き込まれ、ブラウザの再起動とコンピュータの再起動の間に保存されます。これにより、攻撃者は攻撃計画を立てるのに長い時間を費やすことができます。



開発者の推奨事項：アプリが長期間有効なCookieを作成しないようにしてください。

Cookie cookie = new Cookie("longCookie", cookie);
cookie.setMaxAge(5*365*24*3600); // 5 !

OWASP ガイドラインに従って妥当な最大時間制限を提供します。

情報漏えい

おそらく、アプリケーションユーザーにとって最も敏感なタイプの脆弱性です。



エラーページからの外部情報漏えい。アプリケーションは、システム構成に関する情報を含むことができる標準のエラーページを使用します。



エラーメッセージとデバッグ情報は、ログに書き込まれるか、コンソールに表示されるか、ユーザーに送信されます。エラーメッセージから、攻撃者はシステムの脆弱性について知ることができます。これにより、攻撃者の生活が楽になります。たとえば、データベースエラーは、SQLインジェクションに対する不安定さを示している可能性があります。オペレーティングシステムのバージョン、アプリケーションサーバー、およびシステム構成に関する情報により、ハッカーがアプリケーションへの攻撃を計画しやすくなります。



貴重な情報の外部漏洩..。この場合、アプリケーションに関する技術情報がネットワーク経由で別のコンピューターに転送されることによる漏洩について話します。一般に、外部リークは内部リークよりも危険です。







貴重な情報の内部漏洩。操作メカニズムは前の2種類のリークと似ていますが、この場合、システムに関する情報がログに書き込まれるか、ユーザーの画面に表示されます。



機密データの漏洩。ユーザーの貴重な個人データは、ユーザー自身、さまざまなデータベース、サードパーティのストレージなど、さまざまなソースからアプリケーションに入力されます。このデータが機密としてマークされていない場合や、それ自体ではなく特定のコンテキストでのみ価値があることが判明する場合があります。



これは、アプリケーションのセキュリティと個人データのプライバシーが互いに矛盾する場合に当てはまります。セキュリティ上の理由から、悪意のあるアクティビティを検出するために、システム内のアクティビティに関する詳細情報を記録することをお勧めします。逆に、データのプライバシーの観点から、機密情報をログに記録する場合、その漏洩のリスクは大きくなります。一般に、アプリケーションユーザーの個人データの機密性を確保することがより優先されます。

あとがき

この記事で検討する脆弱性の種類は、さまざまなプログラミング言語で記述されたアプリケーションの「普遍的な」ギャップのほとんどをカバーしています。ただし、一部の言語には固有の脆弱性があります。しかし、これはすでに別の記事のトピックです。最後に、アプリケーションを作成するときは、上記の推奨事項に従うことを忘れないでください。ドキュメントを注意深く読み、専用のソフトウェアを使用してアプリケーションの脆弱性を確認してください。



著者：Elizaveta Kharlamova、分析部門長、Solar appScreener