API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルート ディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の API を悪用します。また、相手側から、呼び出し元と呼び出し先のコントラクトを違反することもできます。例えば、コーダーが SecureRandom をサブクラス化し、ランダムではない値を返した場合、コントラクトに違反することになります。
DBMS_UTILITY.EXEC_DDL_STATEMENT
は、DDL (Data Definition Language) の一部に分類されているステートメントのみを実行します。埋め込み SQL でサポートされていないその他のステートメントは、自動的に無視されます。この動作が原因となって、プロシージャー使用時のエラー検出が困難になります。http://www.example.com/index.php?param=...
の場合、index.php
内の PHP の次のスニペットは、「ゼロ以上の英数字」を示す POSIX 正規表現 '^[[:alnum:]]*$'
と一致した場合に、(「...」の適切な位置に渡される) URL パラメーター param
の値を画面に出力します。
<?php
$pattern = '^[[:alnum:]]*$';
$string = $_GET['param'];
if (ereg($pattern, $string)) {
echo($string);
}
?>
Example 1
が英数字入力で想定通りに動作しているときには、安全でない ereg()
関数が汚染された入力の検証に使用されているので、null
バイト インジェクションを経由した Cross-site Scripting (XSS) 攻撃が実行される可能性があります。有効な英数字の直後に null
バイトが続く文字列が含まれる param
に値を渡すことにより、ereg()
関数が入力文字列を (左から右に) 読み込むときに null
バイト文字に続くすべてを無視するため、<script>
タグ (例: "Hello123%00<script>alert("XSS")</script>"
)、ereg($pattern, $string)
は引き続き true
を返します。この例では、null
バイトの後に挿入された <script>
タグがユーザーに表示されて評価されることになります。xp_cmdshell
は安全に使用することはできません。この関数は使用してはいけません。xp_cmdshell
は、Windows コマンドシェルを起動して、指定されたコマンド文字列を実行します。コマンドは、デフォルトのシステムまたは指定されたプロキシコンテキストで実行されます。しかし、ユーザーが実行可能な権限付きの一連の操作を事前に制限することはできないため、権限が付与されたユーザーは、任意のコマンド文字列を実行できてしまいます。chroot()
システムコールを不適切に使用すると、攻撃者が chroot jail を回避できてしまうことがあります。chroot()
システムコールを使い、File System のルートディレクトリに関するプロセスの認識方法を変更することができます。chroot()
を適切に呼び出すと、プロセスは、新しいルートディレクトリにより定義されたディレクトリツリーの外部のファイルにアクセスできません。このような環境は chroot jail と呼ばれ、プロセスが侵犯されて未承認のファイルへのアクセスに利用される可能性を阻止するために広く使用されています。たとえば、多くの FTP サーバーで chroot jail を実行しており、サーバーの新しい脆弱性を発見した攻撃者がパスワードファイルなどの機密性が高いファイルをシステムからダウンロードできないようにしています。chroot()
を不適切に使用すると、攻撃者が chroot jail を回避できてしまうことがあります。chroot()
関数をコールしてもプロセスの現在の作業ディレクトリは変更されないため、chroot()
がコールされた後も相対パスが chroot jail 外の File System リソースを参照したままになることがあります。
chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);
GET
コマンドを実装するために使用される可能性があります。FTP サーバーは、/var/ftproot
外部のファイルへのアクセスを阻止するために、初期化ルーチンで chroot()
をコールします。しかし、サーバーが chdir("/")
をコールしても現在の作業ディレクトリを変更できないため、攻撃者はファイル "../../../../../etc/passwd
" をリクエストしてシステムのパスワードファイルのコピーを入手できる可能性があります。java.io
パッケージを使用しているので、Enterprise JavaBeans 仕様に違反しています。FileResponse
インスタンスを作成すると、攻撃者がアプリケーション バイナリをダウンロードしたり、保護されているディレクトリ内にある任意のファイルを表示したりできる場合があります。
from django.http import FileResponse
...
def file_disclosure(request):
path = request.GET['returnURL']
return FileResponse(open(path, 'rb'))
...
例 2: 次のコードは、信頼できないデータを受け取って、サーバーサイド転送で使用されるパスの構築にそのデータを使用しています。
...
String returnURL = request.getParameter("returnURL");
RequestDispatcher rd = request.getRequestDispatcher(returnURL);
rd.forward();
...
...
<% String returnURL = request.getParameter("returnURL"); %>
<jsp:include page="<%=returnURL%>" />
...
...
String returnURL = request.getParameter("returnURL");
return new ModelAndView(returnURL);
...
<webflow:end-state id="finalStep" view="${requestParameters.url}"/>
<webflow:view-state id="showView" view="${requestParameters.test}">
<bean class="org.springframework.web.servlet.view.
InternalResourceViewResolver">
<property name="prefix" value="/WEB-INF/views/" />
<property name="suffix" value=".jsp" />
</bean>
InternalResourceViewResolver
は、設定されているプレフィックスを取得し、ビュー属性で渡された値を連結し、最後にサフィックスを追加します。
...
String returnURL = request.getParameter("returnURL");
return new ActionForward(returnURL);
...
realloc()
を使用してはいけません。この関数によって、上書きが不可能なメモリ内に機密情報のコピーが取り残される可能性があります。realloc()
関数は、割り当てられたメモリのブロックサイズを増やす際によく使用されます。この操作は多くの場合、古いメモリブロックの内容を新しい大きなブロックにコピーする操作を必要とします。この操作は、元のブロックの内容をそのまま保持してプログラムからアクセスできないようにするため、プログラムは機密性が高いデータをメモリから消し去ることができません。攻撃者が後でメモリダンプの内容をチェックできる場合、機密性が高いデータが攻撃者の目に触れる可能性があります。realloc()
をコールしています。
plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);
realloc()
が使用されているため、最初に plaintext_buffer
に割り当てられたメモリにデータのコピーが残り、人目に触れる危険があります。VirtualLock
を使用しないでください。この関数は実装されないことがあります。VirtualLock
関数は、メモリ内のページをロックしてディスクにページングされるのを防止するために使用されます。しかし、Windows 95/98/ME では、この関数はスタブとしてのみ実装されており効果がありません。