界: API Abuse

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

Often Misused: Encoding

Abstract
.NET フレームワークでクラスを不適切に上書きすると、サーバーでの任意のコード実行、アプリケーション ロジックの悪用、またはサービス拒否を引き起こす可能性があります。
Explanation
プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。.NET フレームワークの Decoder および Encoding クラスの GetChars メソッドと Encoder および Encoding クラスの GetBytes メソッドは、char および byte 配列に対して内部的にポインタ算術を実行し、文字の範囲をバイトの範囲に (およびその逆に) 変換します。
ポインタ算術操作の実行時、開発者が上記のメソッドを不適切な方法で上書きすることで、任意のコード実行、アプリケーション ロジックの悪用、サービス拒否などの脆弱性が生じることがあります。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 176
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[3] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[4] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[5] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.structural.dotnet.often_misused_encoding
Abstract
このメソッドを正しく使用することは困難です。
Explanation
このエンコードメソッドにより挿入攻撃から保護されるように思えますが、このメソッドが正しく使用されないと、その保護効果が非常に低くなります。

例 1: 次のエンコードコールを指定すると、悪意のある JavaScript が挿入される可能性があります。

out.println("x = " + encoder.encodeForJavaScript(input) + ";");
References
[1] OWASP ESAPI Secure Coding Guideline
[2] Standards Mapping - Common Weakness Enumeration CWE ID 176
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[5] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.structural.java.often_misused_encoding
Abstract
この特定のコールは、ベストフィット文字である場合があります。デフォルトの API メソッドに渡されるサポート対象外の文字は、危険な文字にベストフィットマッピングできます。
Explanation
文字セットがオペレーティングシステムとオペレーティングシステム上のアプリケーションで一致していない場合、デフォルトの API メソッドに渡されたサポート対象外の文字を危険な文字にベストフィットマッピングすることができます。

例 1:Objective-C の場合、次の例は UTF-8 文字を含んだ NSString オブジェクトを ASCII データに変換し、その後戻します。


...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...


出力を注意深く見ると、「...」という文字は 3 つの連続するピリオドに変換されています入力バッファに基づいて出力バッファのサイジングを行った場合、アプリケーションが Buffer Overflow に対して脆弱である可能性があります。その他の文字は、1 文字から 2 文字にマッピングすることができます。ギリシャ文字の「fi」という文字は、「f」と「i」にマッピングされます。攻撃者は、これらの文字を使用してバッファをフロントローディングすることによって、バッファをオーバーフローさせるのに使用される文字の数を完全に制御できます。
References
[1] Apple Secure Coding Guide Apple
[2] String Programming Guide Apple
[3] Standards Mapping - Common Weakness Enumeration CWE ID 176
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[6] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[7] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.semantic.objc.method_may_best_fit_map_characters
Abstract
この特定のコールは、ベストフィット文字である場合があります。デフォルトの API メソッドに渡されるサポート対象外の文字は、危険な文字にベストフィットマッピングできます。
Explanation
文字セットがオペレーティングシステムとオペレーティングシステム上のアプリケーションで一致していない場合、デフォルトの API メソッドに渡されたサポート対象外の文字を危険な文字にベストフィットマッピングすることができます。

例 1: Swift の場合、次の例は UTF-8 文字を含んだ NSString オブジェクトを ASCII データに変換し、その後戻します。


...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...


出力を注意深く見ると、「...」という文字は 3 つの連続するピリオドに変換されています入力バッファに基づいて出力バッファのサイジングを行った場合、アプリケーションが Buffer Overflow に対して脆弱である可能性があります。その他の文字は、1 文字から 2 文字にマッピングすることができます。ギリシャ文字の「fi」という文字は、「f」と「i」にマッピングされます。攻撃者は、これらの文字を使用してバッファをフロントローディングすることによって、バッファをオーバーフローさせるのに使用される文字の数を完全に制御できます。
References
[1] Apple Secure Coding Guide Apple
[2] String Programming Guide Apple
[3] Standards Mapping - Common Weakness Enumeration CWE ID 176
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[6] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[7] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.semantic.swift.method_may_best_fit_map_characters