API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルート ディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の API を悪用します。また、相手側から、呼び出し元と呼び出し先のコントラクトを違反することもできます。例えば、コーダーが SecureRandom をサブクラス化し、ランダムではない値を返した場合、コントラクトに違反することになります。
root 権限を使って実行するプログラムが原因で無数のセキュリティ被害が発生しています。多種のセキュリティ問題に対して、権限を必要とするプログラムを注意深く調べることは非常に大切です。しかし、それ以上に重要なのは、見逃された脆弱性によって発生する被害の拡大を防ぐために、権限を持ったプログラムを権限のない状態になるべく早く戻すことです。root 以外のユーザー間で移動する場合にとりわけ顕著に現れます。 root としてプロセスを実行している場合は、シグナルハンドラまたはサブプロセスはルート権限で動作します。攻撃者はこの昇格された権限を利用して、さらに大きな打撃を与える可能性があります。root 権限で実行されるプログラムは、数え切れないほどの Unix セキュリティ災害を引き起こしてきました。権限が必要なプログラムにあらゆる種類のセキュリティ上の問題がないか慎重に検討することは必要ですが、見落とされた脆弱性が引き起こす被害を最小限に抑えるために、権限が必要なプログラムの権限をできるだけ早く降格することも同様に重要です。root ユーザーから別のユーザーに移行する場合に特に顕著になります。root として実行されている場合、シグナル ハンドラーやサブプロセスは root 権限で動作します。攻撃者は、これらの昇格された特権を利用して、さらなる損害を与えることができる可能性があります。root 権限を使って実行するプログラムが原因で無数のセキュリティ被害が発生しています。 多種のセキュリティ問題に対して、権限を必要とするプログラムを注意深く調べることは非常に大切です。しかし、それ以上に重要なのは、見逃された脆弱性によって発生する被害の拡大を防ぐために、権限を持ったプログラムを権限のない状態になるべく早く戻すことです。root 以外のユーザー間で移動する場合にとりわけ顕著に現れます。root としてプロセスを実行している場合は、シグナルハンドラまたはサブプロセスはルート権限で動作します。攻撃者はこの昇格された権限を利用して、さらに大きな打撃を与える可能性があります。root 権限を使って実行するプログラムが原因で無数のセキュリティ被害が発生しています。多種のセキュリティ問題に対して、権限を必要とするプログラムを注意深く調べることは非常に大切です。しかし、それ以上に重要なのは、見逃された脆弱性によって発生する被害の拡大を防ぐために、権限を持ったプログラムを権限のない状態になるべく早く戻すことです。root 以外のユーザー間で移動する場合にとりわけ顕著に現れます。root としてプロセスを実行している場合は、シグナルハンドラまたはサブプロセスはルート権限で動作します。攻撃者はこの昇格された権限を利用して、さらに大きな打撃を与える可能性があります。...
Device.OpenUri("sms:+12345678910");
...
...
[[CTMessageCenter sharedMessageCenter] sendSMSWithText:@"Hello world!" serviceCenter:nil toAddress:@"+12345678910"];
...
// or
...
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"sms:+12345678910"]];
...
// or
...
MFMessageComposeViewController *messageComposerVC = [[MFMessageComposeViewController alloc] init];
[messageComposerVC setMessageComposeDelegate:self];
[messageComposerVC setBody:@"Hello World!"];
[messageComposerVC setRecipients:[NSArray arrayWithObject:@"+12345678910"]];
[self presentViewController:messageComposerVC animated:YES completion:nil];
...
...
UIApplication.sharedApplication().openURL(NSURL(string: "sms:+12345678910"))
...
...
let messageComposeVC = MFMessageComposeViewController()
messageComposeVC.messageComposeDelegate = self
messageComposeVC.body = "Hello World!"
messageComposeVC.recipients = ["+12345678910"]
presentViewController(messageComposeVC, animated: true, completion: nil)
...
MultiByteToWideChar()、WideCharToMultiByte()、UnicodeToBytes()、および BytesToUnicode() といった関数で任意のマルチバイト文字列 (通常ANSI) と Unicode 文字列 (ワイド文字) を変換します。こうした関数へ渡すサイズ引数は、1 つの関数ではバイト数、他方では文字数と異なる単位で指定されるため、エラーが発生しやすくなります。マルチバイト文字列では各文字のバイト数が異なるため、文字列の長さはバイトの合計サイズを使うと簡単に指定できます。一方 Unicode では、文字は常に固定サイズであるため、文字列の長さは通常、含まれる文字数で決まります。サイズ引数を間違った単位で指定すると、Buffer Overflow の原因となる可能性があります。
void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
MultiByteToWideChar(CP_ACP, 0, username, -1,
unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}
unicodeUser のサイズを、文字数でなく、誤ってバイト単位で渡しています。このため、MultiByteToWideChar() へのコールにより最大で (UNLEN+1)*sizeof(WCHAR) 個のワイド文字、または (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) バイトを unicodeUser 配列に書き込むことが可能ですが、この配列には (UNLEN+1)*sizeof(WCHAR) バイトしか割り当てられていません。username 文字列に含まれる文字数が UNLEN 字を超えている場合、MultiByteToWideChar() のコールにより、バッファ unicodeUser はオーバーフローします。sun.misc.Unsafe の機能を使用します。このクラスのすべての機能は本質的に安全に使用できず、リフレクション経由でのみアクセスできます。sun.misc.Unsafe クラスは、安全でない低レベルの操作を実行するためのものであり、開発者による使用を目的としていません。Unsafe クラスは信頼できるコードによってのみ取得でき、通常はリフレクションを通じて取得されます。これは、このクラスがシステムの破損やヒープ メモリの手動割り当てに使用される可能性があり、適切に処理しないとシステムに悪影響を及ぼす可能性があるためです。sun.misc.Unsafe に関するすべての機能を慎重にレビューし、問題がないことをテストすることが不可欠です。
String password=request.getParameter("password");
...
DefaultUser user = (DefaultUser) ESAPI.authenticator().createUser(username, password, password);