API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルート ディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の API を悪用します。また、相手側から、呼び出し元と呼び出し先のコントラクトを違反することもできます。例えば、コーダーが SecureRandom をサブクラス化し、ランダムではない値を返した場合、コントラクトに違反することになります。
org.apache.struts2.interceptor.ApplicationtAware、org.apache.struts2.interceptor.SessionAware、org.apache.struts2.interceptor.RequestAware があります。Actions コードに挿入されたこれらのデータマップのいずれかを取得するには、開発者は、インターフェイスで指定されたセッター (たとえば SessionAware インターフェイスでは setSession) を実装する必要があります。
public class VulnerableAction extends ActionSupport implements SessionAware {
protected Map<String, Object> session;
@Override
public void setSession(Map<String, Object> session) {
this.session = session;
}
SessionAware、RequestAware、ApplicationAware のインターフェイスで示したように、影響を受けたインターフェイスを実装しているアプリケーションに対する巧妙なパラメーターを使用して、リモートの攻撃者が実行環境のデータ値を修正する可能性があります。
http://server/VulnerableAction?session.roles=admin
Read() や System.IO クラスの一部である関連メソッドを誤解することはよくあります.NET では、エラーや異常イベントが発生すると、通常例外が発生します(これは .NET が C のような言語より優れている点の 1 つです。例外は、何が起こり得るのかについてプログラマが考える際に役立ちます。)しかし、少量のデータさえ利用可能であれば、ストリームや Reader クラスでは異常である、あるいは例外的であるとは見なされません。これらのクラスは戻りバッファに少量のデータを追加し、読み込まれたバイト数または文字数を戻り値にセットします。戻されるデータ量がリクエストされるデータ量と等しいという保証はありません。Read() やその他の IO メソッドからの戻り値を確認して、想定どおりの量のデータを確実に受け取ることが重要な意味を持ちます。Read() からの戻り値を無視します。攻撃者がこれより小さいファイルを作成できる場合、プログラムは前のユーザーからのデータの残りをリサイクルし、それが攻撃者のデータであるかのように処理します。
char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {
string userName = (string) i.Current();
string pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);
}
char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);
fgets() が返された時点で、buf には NULL ターミネートする 9 文字以下の文字列が格納されていると予測します。ところが入出力エラーが発生した場合、fgets() で処理された buf は NULL ターミネートしません。さらに、文字が全く読まれないうちにファイルの終端に到達した場合は、buf には何も書き込まれていない状態で fgets() が返されます。この 2 つの状況では、fgets() によって返される NULL により異常が発生したことがわかりますが、このコードの中では警告されません。buf が NULL ターミネートされていないと、次の strcpy() がコールされた場合に Buffer Overflow の原因となります。read() と多くの java.io クラスの関連メソッドを誤解してしまうのは珍しいことではありません。Java のほとんどのエラーと異常イベントは例外を発生させます。(これは Java が C などの言語に対して持つメリットです:例外は、何が起こり得るのかについてプログラマが考える際に役立ちます。)しかし、少量のデータしか利用できないようになっている場合、stream クラスと reader クラスは異常または例外とはみなされません。これらのクラスは戻りバッファに少量のデータを追加し、読み込まれたバイト数または文字数を戻り値にセットします。戻されるデータ量がリクエストされるデータ量と等しいという保証はありません。read() およびその他の IO メソッドからの戻り値を調べることが重要です。read() からの戻り値を無視します。攻撃者がこれより小さいファイルを作成できる場合、プログラムは前のユーザーからのデータの残りをリサイクルし、それが攻撃者のデータであるかのように処理します。
FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {
String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);
}
read() からの戻り値を無視します。攻撃者がこれより小さいファイルを作成できる場合、プログラムは前のユーザーからのデータの残りをリサイクルし、それが攻撃者のデータであるかのように処理します。
var fis: FileInputStream
val byteArray = ByteArray(1023)
val i: Iterator<*> = users.iterator()
while (i.hasNext()) {
val userName = i.next() as String
val pFileName: String = PFILE_ROOT.toString() + "/" + userName
val fis = FileInputStream(pFileName)
fis.read(byteArray) // the file is always 0k bytes
fis.close()
processPFile(userName, byteArray)
}
function callnotchecked(address callee) public {
callee.call();
}