界: Time and State

分散型計算とは、時間と状態に関するものです。つまり、複数のコンポーネントが通信するためには、状態を共有しなければならず、そのためには時間がかかります。

ほとんどのプログラマーは、自分の仕事を人であるかのように考えています。彼らは、自分で仕事をしなければならない場合、自分がするのと同じように、1 つのスレッドのコントロールでプログラム全体を実行することを考えます。しかし、最近のコンピュータは、タスクの切り替えが非常に速く、マルチコア、マルチ CPU、分散システムなどでは、2 つのイベントが全く同時に発生することもあります。不具合は、プログラマーが考えたプログラムの実行方法のモデルと、現実に起きていることとのギャップを埋めるために押し寄せます。これらの欠陥は、スレッド、プロセス、時間、および情報の間の予期せぬ相互作用に関連しています。これらの相互作用は、セマフォ、変数、ファイル システムなど、基本的には情報を保存できるあらゆるものを含む共有状態を通じて行われます。

19 見つかった項目
脆弱性
Abstract
シリアライズ可能ではないオブジェクトを HttpSessionState 属性として保存すると、アプリケーションの信頼性を損なう場合があります。
Explanation
デフォルトでは、ASP.NET サーバーでは HttpSessionState オブジェクト、その属性、および参照するすべてのオブジェクトがメモリに保存されます。この処理モデルでは、アクティブセッションの状態が 1 台のマシンのシステムメモリに保存できる範囲に制限されます。これらの制限を取り除き、容量を拡張するために、複数のサーバーに対して永続的なセッション状態情報が設定される場合がよくあります。これにより容量が拡張され複数のマシン間における複製が許可されるため、全体的なパフォーマンスが向上します。セッション状態を保持するために、サーバーは HttpSessionState オブジェクトをシリアライズする必要があり、このオブジェクトをシリアライズするためには、保存されるすべてのオブジェクトがシリアライズ可能である必要があります。

セッションが正しくシリアライズされるために、セッションの属性としてアプリケーションが保存するすべてのオブジェクトで [Serializable] 属性を宣言する必要があります。さらに、オブジェクトで独自のシリアライズメソッドが必要となる場合には、ISerializable インターフェイスを実装する必要があります。

例 1: 次のクラスは自分自身をセッションに追加しますが、シリアライズ可能ではないため、セッションを正しくシリアライズすることはできません。


public class DataGlob {
String GlobName;
String GlobValue;

public void AddToSession(HttpSessionState session) {
session["glob"] = this;
}
}
References
[1] Session State Providers Microsoft Corporation
[2] Underpinnings of the Session State Implementation in ASP.NET Microsoft Corporation
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 579
[8] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[9] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[10] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[11] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[12] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[13] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.structural.dotnet.asp_dotnet_bad_practices_non_serializable_object_stored_in_session
Abstract
ロックを保持しているときに sleep() をコールすると、パフォーマンスの低下を招いたり、デッドロックが発生したりする可能性があります。
Explanation
複数のスレッドが、リソースをロックしようとしている場合、ロックを保持しながら sleep() をコールすると、他のすべてのスレッドがそのリソースが解放されるのを待機するため、パフォーマンスが低下しデッドロックが発生する可能性があります。

例 1: 次のコードは、ロックを保持しながら sleep() をコールしています。

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();
References
[1] LCK09-J. Do not perform operations that can block while holding a lock CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 557
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II, APSC-DV-002950 CAT II
[33] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[34] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.code_correctness_call_to_sleep_in_lock
Abstract
Double-Checked Locking は、意図した効果が得られない不正な用法です。
Explanation
これまでも才能ある数多くの個人がかなりの時間を費やし、性能を向上させるために Double-Checked Locking を機能させようと取り組んできました。しかし、一度も成功したことはありません。

例 1: 一見して、次のコードのビットは不必要な同期化を回避しながらスレッドの安全を実現しているように思われます。


if (fitz == null) {
synchronized (this) {
if (fitz == null) {
fitz = new Fitzer();
}
}
}
return fitz;


プログラマは、Fitzer() オブジェクトが 1 つのみ割り当てられていることを保証したいと考えますが、このコードのコールのたびに同期化させるコストをかけたくはありません。この用法は Double-Checked Locking として知られます。

残念ながら、うまく機能せず、複数の Fitzer() オブジェクトが割り当てられます。詳細は「Double-Checked Locking is Broken」宣言を参照してください [1]。
References
[1] D. Bacon et al. The "Double-Checked Locking is Broken" Declaration
[2] LCK10-J. Use a correct form of the double-checked locking idiom CERT
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 609
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.structural.java.code_correctness_double_checked_locking
Abstract
スレッドが他のスレッドにシグナルを送信した後にミューテックスをアンロックできなかった場合、この送信先のスレッドは、ミューテックスを待機してロックされた状態のままとなります。
Explanation
あるシグナルがミューテックスを待機している他のスレッドにシグナルを送信した後、別のスレッドが実行を開始できるようにするためには、pthread_mutex_unlock() をコールしてミューテックスをアンロックする必要がありますシグナルを送信しているスレッドがミューテックスをアンロックできない場合は、2 番目のスレッドにある pthread_cond_wait() コールは返されず、スレッドは実行されません。

例 1: 次のコードは、pthread_cond_signal() をコールしてミューテックスを待機している他のスレッドにシグナルを送信していますが、他のスレッドが待機しているミューテックスのアンロックに失敗しています。


...
pthread_mutex_lock(&count_mutex);

// Signal waiting thread
pthread_cond_signal(&count_threshold_cv);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 373
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II, APSC-DV-002950 CAT II
[33] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[34] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.structural.cpp.code_correctness_erroneous_synchronization
Abstract
Insecure Temporary File を作成または使用すると、アプリケーションやシステムデータが攻撃に対して脆弱になることがあります。
Explanation
アプリケーションはテンポラリファイルを非常に頻繁に必要とするため、C ライブラリと Windows(R) API にはテンポラリファイルを作成するさまざまなメカニズムが数多く存在します。これらの関数の多くは、さまざまな形態の攻撃に対して脆弱です。
例: 次のコードは、ネットワークから収集された中間データを、処理するまで格納するテンポラリファイルを使用しています。


...
if (tmpnam_r(filename)){
FILE* tmp = fopen(filename,"wb+");
while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...


このコードは本来、平凡なコードですが、安全でないメソッドに依存してテンポラリファイルを作成するため、さまざまな攻撃に対して脆弱です。この関数などにより導入される脆弱性について、以降で説明します。テンポラリファイルの作成と関係がある最も顕著なセキュリティ上の問題が UNIX ベースのオペレーティングシステムで発生していますが、Windows アプリケーションにも同様のリスクがあります。このセクションでは、UNIX および Windows の両方のシステムにおけるテンポラリファイルの作成について説明します。

メソッドと動作はシステムにより異なりますが、それぞれで発生する基本的なリスクはほぼ一定です。安全なコア言語関数と、テンポラリファイルの作成に関する安全な手法については「Recommendations」セクションを参照してください。

テンポラリファイルの作成を支援するよう設計された関数は、単にファイル名を提供するだけか、または実際に新しいファイルを開くかどうかによって 2 つ のグループに分類することができます。

グループ 1 - 「一意の」ファイル名:

C ライブラリや WinAPI の最初のグループは、新しいテンポラリファイルに対して一意のファイル名を生成し、テンポラリファイルの作成処理を支援します。このテンポラリファイルをプログラムが開きます。このグループに含まれるのは、tmpnam()tempnam()mktemp()などの C ライブラリ関数と、先頭に _ (アンダースコア) が付けられた、それぞれに対応する C++ 関数、および Windows API に属する GetTempFileName() 関数です。このグループの関数は、選択されたファイル名の Race Condition の脆弱性があります。関数は、ファイル名が選択されたときに一意であることを保証しますが、ファイルの選択後、アプリケーションがファイルを開こうと試みる前に別のプロセスまたは攻撃者が同一の名前を持つファイルを作成するのを阻止するメカニズムがありません。同じ関数への別のコールによって発生する正当な衝突の危険のほかに、攻撃者が悪意ある衝突を作成する可能性も十分あります。これらの関数によって生成されたファイル名が十分にランダムでなく、推測が難しくないためです。

選択された名前のファイルが作成されると、ファイルの開き方に応じて、既存のコンテンツまたはファイルのアクセス許可は変更されないままとなります。ファイルの既存のコンテンツが悪意ある性質のものである場合、アプリケーションがテンポラリファイルからデータを読み戻す際に、攻撃者がアプリケーションに危険なデータを挿入できる可能性があります。攻撃者が事前にアクセス許可を緩くしたファイルを作成した場合、アプリケーションによりテンポラリファイルに格納されたデータに対して攻撃者はアクセス、変更、破壊を行うことができます。UNIX ベースのシステムの場合、攻撃者は事前に別の重要なファイルへのリンクとしてファイルを作成しておくことで、さらに露見しにくい攻撃が可能です。この場合、アプリケーションがデータを切り詰めたりファイルに書き込んだりすると、知らずに攻撃者の意図に沿って損傷をもたらす操作を実行することになる可能性があります。昇格した許可でプログラムが動作している場合、これは特に深刻な脅威となります。

最後に、最良のケースでは、O_CREAT フラグや O_EXCL フラグを使用した open() のコールや、CREATE_NEW 属性を使用した CreateFile() のコールでファイルが開かれるのは、ファイルが既に存在する場合に失敗するため、前述のタイプの攻撃は阻止されます。ただし、攻撃者が一連のテンポラリファイル名を正確に予測できる場合、アプリケーションは必要とするテンポラリストレージを開こうとしても阻止され、Denial of Service (DoS) 攻撃が発生する可能性があります。これらの関数によって生成されたファイル名の選択に使用されているランダム度が小さければ、このタイプの攻撃を準備するのは容易です。

グループ 2 - 「一意の」ファイル:

C ライブラリ関数の 2 番目のグループは、一意のファイル名を生成するだけではなく、そのファイルを開くことによって、テンポラリファイルに関連するセキュリティ上の問題の一部を解決しようと試みます。このグループに含まれるのは、tmpfile() などの C ライブラリ関数と、先頭に _ (アンダースコア) が付けられた、それに対応する C++ 関数、および多少動作が優れている C ライブラリ関数 mkstemp() です。

tmpfile() スタイル関数は一意のファイル名を作成して、"wb+" フラグが渡された場合の fopen() と同じ方法、つまり読み書きモードでバイナリ ファイルとしてそのファイルを開きます。ファイルが既に存在する場合、tmpfile() により、サイズがゼロに切り詰められます。これは、一意であるはずのファイル名を選択してから、選択されたファイルをその後で開くまでの間に存在する Race Condition に関する、前述したセキュリティ上の懸念を緩和しようとするものです。ただし、この動作は関数のセキュリティ上の問題を明確に解決するわけではありません。まず、攻撃者は事前にアクセス許可を緩くしたファイルを作成でき、その許可が tmpfile() により開かれるファイルによって変更される可能性はあまりありません。さらに、UNIX ベースのシステムの場合、攻撃者がファイルを別の重要なファイルへのリンクとして事前に作成すると、アプリケーションは昇格した許可を使用してそのファイルを切り詰める可能性があり、結果的に攻撃者の意図した損傷を与えます。最後に、tmpfile() が実際に新しいファイルを作成する場合、そのファイルに適用されるアクセス許可はオペレーティングシステムにより異なります。つまり、攻撃者が事前にファイル名を予測できない場合も、アプリケーションデータは脆弱な状態に保たれる可能性があります。

最後に、mkstemp() は、テンポラリファイルを作成する上で十分に安全性が確保された方法です。ユーザーが提供したファイル名テンプレートに基づき、ランダムに生成した一連の文字を組み合わせて一意のファイルを作成して開こうとします。ファイルを作成できなかった場合は、失敗して -1 を戻します。最近のシステムでは、ファイルはモード 0600 で開かれます。つまり、ユーザーがアクセス許可を明示的に変更しない限り、ファイルは改竄に対して安全です。しかし、mkstemp() は予測可能なファイル名が使用されているため攻撃されやすく、攻撃者が使用されるファイル名を予測して事前に作成することで mkstemp() の失敗を引き起こした場合、アプリケーションは Denial of Service 攻撃にさらされる可能性があります。
References
[1] B. Schneier Yarrow: A secure pseudorandom number generator
[2] CryptLib
[3] Crypto++
[4] BeeCrypt
[5] OpenSSL
[6] CryptoAPI: CryptGenRandom() Microsoft
[7] RtlGenRandom() Microsoft
[8] .NET System.Security.Cryptography: Random Number Generation Microsoft
desc.semantic.cpp.insecure_temporary_file
Abstract
Insecure Temporary File を作成または使用すると、アプリケーションやシステムデータが攻撃に対して脆弱になることがあります。
Explanation
アプリケーションはテンポラリ ファイルを非常に頻繁に必要とするため、テンポラリ ファイルを作成するさまざまなメカニズムが数多く存在します。これらの関数の多くは、さまざまな形態の攻撃に対して脆弱です。
例: 次のコードは、ネットワークから収集された中間データを、処理するまで格納するテンポラリファイルを使用しています。


...
try:
tmp_filename = os.tempnam()
tmp_file = open(tmp_filename, 'w')
data = s.recv(4096)
while True:
more = s.recv(4096)
tmp_file.write(more)
if not more:
break
except socket.timeout:
errMsg = "Connection timed-out while connecting"
self.logger.exception(errMsg)
raise Exception
...


このコードは本来、平凡なコードですが、安全でないメソッドに依存してテンポラリファイルを作成するため、さまざまな攻撃に対して脆弱です。この関数などにより導入される脆弱性について、以降で説明します。テンポラリファイルの作成と関係がある最も顕著なセキュリティ上の問題が UNIX ベースのオペレーティングシステムで発生していますが、Windows アプリケーションにも同様のリスクがあります。

メソッドと動作はシステムにより異なりますが、それぞれで発生する基本的なリスクはほぼ一定です。安全なコア言語関数と、テンポラリファイルの作成に関する安全な手法については「Recommendations」セクションを参照してください。

テンポラリファイルの作成を支援するよう設計された関数は、単にファイル名を提供するだけか、または実際に新しいファイルを開くかどうかによって 2 つ のグループに分類することができます。

グループ 1 - 「一意の」ファイル名:

最初のグループは、新しいテンポラリ ファイルに対して一意のファイル名を生成し、テンポラリ ファイルの作成処理を支援します。このテンポラリ ファイルをプログラムが開きます。このグループの関数は、選択されたファイル名の Race Condition の脆弱性があります。関数は、ファイル名が選択されたときに一意であることを保証しますが、ファイルの選択後、アプリケーションがファイルを開こうと試みる前に別のプロセスまたは攻撃者が同一の名前を持つファイルを作成するのを阻止するメカニズムがありません。同じ関数への別のコールによって発生する正当な衝突の危険のほかに、攻撃者が悪意ある衝突を作成する可能性も十分あります。これらの関数によって生成されたファイル名が十分にランダムでなく、推測が難しくないためです。

選択された名前のファイルが作成されると、ファイルの開き方に応じて、既存のコンテンツまたはファイルのアクセス許可は変更されないままとなります。ファイルの既存のコンテンツが悪意ある性質のものである場合、アプリケーションがテンポラリファイルからデータを読み戻す際に、攻撃者がアプリケーションに危険なデータを挿入できる可能性があります。攻撃者が事前にアクセス許可を緩くしたファイルを作成した場合、アプリケーションによりテンポラリファイルに格納されたデータに対して攻撃者はアクセス、変更、破壊を行うことができます。UNIX ベースのシステムの場合、攻撃者は事前に別の重要なファイルへのリンクとしてファイルを作成しておくことで、さらに露見しにくい攻撃が可能です。この場合、アプリケーションがデータを切り詰めたりファイルに書き込んだりすると、知らずに攻撃者の意図に沿って損傷をもたらす操作を実行することになる可能性があります。昇格した許可でプログラムが動作している場合、これは特に深刻な脅威となります。

最後に、os.O_CREAT フラグや os.O_EXCL フラグを使用した open() のコールでファイルが開かれる最良のケースでは、ファイルがすでに存在する場合は処理が失敗するため、ここで説明したタイプの攻撃は阻止されます。ただし、攻撃者が一連のテンポラリファイル名を正確に予測できる場合、アプリケーションは必要とするテンポラリストレージを開こうとしても阻止され、Denial of Service (DoS) 攻撃が発生する可能性があります。これらの関数によって生成されたファイル名の選択に使用されているランダム度が小さければ、このタイプの攻撃を準備するのは容易です。

グループ 2 - 「一意の」ファイル:

関数の 2 番目のグループは、一意のファイル名を生成するだけではなく、そのファイルを開くことによって、テンポラリ ファイルに関連するセキュリティ上の問題の一部を解決しようと試みます。このグループには tmpfile() のような関数が含まれます。

tmpfile() スタイル関数は一意のファイル名を作成して、"wb+" フラグが渡された場合の open() と同じ方法、つまり読み書きモードでバイナリ ファイルとしてそのファイルを開きます。ファイルが既に存在する場合、tmpfile() により、サイズがゼロに切り詰められます。これは、一意であるはずのファイル名を選択してから、選択されたファイルをその後で開くまでの間に存在する Race Condition に関する、前述したセキュリティ上の懸念を緩和しようとするものです。ただし、この動作は関数のセキュリティ上の問題を明確に解決するわけではありません。まず、攻撃者は事前にアクセス許可を緩くしたファイルを作成でき、その許可が tmpfile() により開かれるファイルによって変更される可能性はあまりありません。さらに、UNIX ベースのシステムの場合、攻撃者がファイルを別の重要なファイルへのリンクとして事前に作成すると、アプリケーションは昇格した許可を使用してそのファイルを切り詰める可能性があり、結果的に攻撃者の意図した損傷を与えます。最後に、tmpfile() が実際に新しいファイルを作成する場合、そのファイルに適用されるアクセス許可はオペレーティングシステムにより異なります。つまり、攻撃者が事前にファイル名を予測できない場合も、アプリケーションデータは脆弱な状態に保たれる可能性があります。
References
[1] B. Schneier Yarrow: A secure pseudorandom number generator
[2] Python Library Reference: os Python
[3] Python Library Reference: tempfile Python
[4] Symlink race WikiPedia
[5] Time of check to time of use WikiPedia
desc.semantic.python.insecure_temporary_file
Abstract
このメソッドは、失効しないセッションを設定します。
Explanation
セッションが開いている時間が長ければ、それだけ、ユーザーアカウントが侵害される機会が長くなります。セッションがアクティブになっていると、攻撃者は、ユーザーのパスワードに Brute-Force 攻撃を仕掛けたり、ユーザーのワイヤレス暗号鍵を解読したり、あるいは開いているブラウザからセッションを乗っ取ったりできるようになる可能性があります。また、セッションタイムアウトを長くしているとメモリが解放されず、大量のセッションが作成される場合に Denial of Service となる場合があります。

例 1: 次の例では、コードが最大非アクティブ間隔に負の値を設定しており、セッションが永続的にアクティブ状態になります。

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 613
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000879, CCI-002361
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-12 Session Termination (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-12 Session Termination
[11] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.8.1 Single or Multi Factor One Time Verifier Requirements (L1 L2 L3), 2.8.6 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.3.1 Session Logout and Timeout Requirements (L1 L2 L3), 3.3.2 Session Logout and Timeout Requirements (L1 L2 L3), 3.3.4 Session Logout and Timeout Requirements (L2 L3), 3.6.1 Re-authentication from a Federation or Assertion (L3), 3.6.2 Re-authentication from a Federation or Assertion (L3)
[17] Standards Mapping - OWASP Mobile 2014 M9 Improper Session Handling
[18] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3, Requirement 8.5.15
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7, Requirement 8.5.15
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8, Requirement 8.5.15
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10, Requirement 8.1.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10, Requirement 8.1.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10, Requirement 8.1.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10, Requirement 8.1.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 8.2.8
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.3 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.3 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.3 - Authentication and Access Control, Control Objective C.2.1.2 - Web Software Access Controls, Control Objective C.2.3.2 - Web Software Access Controls
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3415 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3415 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3415 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3415 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3415 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3415 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3415 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Session Expiration (WASC-47)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Session Expiration
desc.structural.java.j2ee_bad_practices_insufficient_session_expiration
Abstract
Web アプリケーションでコンテナをシャットダウンしないようにしてください。
Explanation
Web アプリケーションでアプリケーションコンテナをシャットダウンすることは決していい方法ではありません。終了メソッドのコールは、おそらく Leftover Debug Code または非 J2EE アプリケーションからインポートされたコードの一部です。
References
[1] ERR09-J. Do not allow untrusted code to terminate the JVM CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 382
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[34] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.semantic.java.j2ee_badpractices_jvm_termination