界: API Abuse

API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルートディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の API を悪用します。また、相手側から、呼び出し元と呼び出し先のコントラクトを違反することもできます。例えば、コーダーが SecureRandom をサブクラス化し、ランダムではない値を返した場合、コントラクトに違反することになります。

Often Misused: Authentication

Abstract

攻撃者は DNS エントリを偽装できます。セキュリティを考慮する場合は DNS 名を信頼しないようにします。

Explanation

多くの DNS サーバーが偽装攻撃にさらされているので、危険な状態の DNS サーバーの環境でソフトウェアが使用される可能性も想定してください。攻撃者が DNS を更新できる場合 (DNS キャッシュポイズニングとも呼ばれます)、攻撃者はネットワークトラフィックが自分のマシンを経由するようにしたり、攻撃者の IP アドレスが攻撃対象のドメインの一部であるかのように見せかけたりすることができます。システムのセキュリティが DNS 名に依存することがないようにしてください。
例: 次のコードサンプルは、DNS ルックアップを使用して、着信リクエストが信頼できるホストからのものかどうかを判断します。攻撃者が DNS キャッシュをポイズニングできる場合、信頼できるというステータスを取得できます。


 IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
 IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
 if (hostInfo.HostName.EndsWith("trustme.com")) {
   trusted = true;
 }

IP アドレスは DNS 名よりは信頼できますが、偽装可能であることに変わりはありません。攻撃者は、送信するパケットのソース IP アドレスを容易に偽装できますが、レスポンスパケットは偽装された IP アドレスに戻されます。攻撃者はレスポンスパケットを参照するため、攻撃対象のマシンと偽装 IP アドレスの間のトラフィックを盗聴する必要があります。攻撃者は必要な盗聴を実行するため、攻撃対象のマシンと同じサブネットに入り込もうとします。攻撃者はソースルーティングを使用してこの要件を回避できる場合がありますが、今日ではインターネットでのソースルーティングは多くの場合、無効にされています。つまり、IP アドレス検証は Authentication 方式の有用な部分とすることができます。しかし、Authentication に必要な唯一の要素ではありません。

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000877

[3] Standards Mapping - FIPS200 IA

[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)

[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-23 Session Authenticity

[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication

[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization

[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1

[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management

[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management

[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management

[13] Standards Mapping - OWASP Top 10 2013 A2 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 - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 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 3.2 Requirement 6.5.10

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection

[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection

[27] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807

[28] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807

[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I

[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I

[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II

[37] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)

[38] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication

desc.semantic.dotnet.often_misused_authentication

Abstract

getlogin() 関数を偽装するのは簡単です。このため、関数によって戻された名前を信頼しないようにします。

Explanation

通常、getlogin() 関数は、ターミナルで現在ログオン中のユーザー名を含む文字列を戻しますが、攻撃者は getlogin() を操作し、そのマシンにログオンした任意のユーザー名を戻すことができます。このため、セキュリティに関する決定を行う際に、getlogin() 関数によって戻された名前を信頼しないようにします。
例 1: 次のコードでは、getlogin() の結果を信頼し、信頼できるユーザーかどうかを判断しています。しかし、これは全く当てになりません。


 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }