API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルート ディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の API を悪用します。また、相手側から、呼び出し元と呼び出し先のコントラクトを違反することもできます。例えば、コーダーが SecureRandom をサブクラス化し、ランダムではない値を返した場合、コントラクトに違反することになります。
finalize()
メソッドは、オブジェクトがガベージコレクトされた後に JVM にコールされるようにします。finalize()
メソッドを finalizer 外部からコールすることができます。通常は、これは良い考えではありません。たとえば、finalize()
をコールすることは、finalize()
が 2 回以上コールされることを明示的に意味しています。一回目は明示的なコールで、最後はオブジェクトがガベージコレクトされた後に行われるコールです。finalize()
を明示的にコールします。
// time to clean up
widget.finalize();
dangerouslySetInnerHTML
属性は、不必要にコードから HTML を設定します。dangerouslySetInnerHTML
属性は、ブラウザー DOM での innerHTML の使用に代わるものです。API 名は、これを使用することによる潜在的な危険性を伝えるために変更されています。一般に、コードから HTML を設定することは危険です。ユーザーを誤って Cross-Site Scripting (XSS) 攻撃にさらす可能性が高いためです。dangerouslySetInnerHTML
属性に設定します。
function MyComponent(data) {
return (
<div
dangerouslySetInnerHTML={{__html: data.innerHTML}}
/>
);
}
AUTHID CURRENT_USER
パッケージでは、現在のユーザースキーマに対して識別子が最初に解決されます。その結果、識別子がどのスキーマに属しているのかをコードの定義が明示していない場合、予期せぬ動作が引き起こされる可能性があります。SYS.PERMISSIONS
に対してのみ読み取りアクセスが許可されるようになり、定義済みの権限を変更できません。
CREATE or REPLACE FUNCTION check_permissions(
p_name IN VARCHAR2, p_action IN VARCHAR2)
RETURN BOOLEAN
AUTHID CURRENT_USER
IS
r_count NUMBER;
perm BOOLEAN := FALSE;
BEGIN
SELECT count(*) INTO r_count FROM PERMISSIONS
WHERE name = p_name AND action = p_action;
IF r_count > 0 THEN
perm := TRUE;
END IF;
RETURN perm;
END check_permissions
check_permissions
関数をコールするユーザーがスキーマで PERMISSIONS
テーブルを定義する場合、データベースが識別子を解決して、ローカルテーブルを参照します。ユーザーは新しいテーブルに対する書き込み権限を付与されるため、データベースを変更することによって本来付与されないはずの権限を取得できるようになります。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
execute()
メソッドを上書きするエンドユーザーによって呼び出すことのできる public メソッドを開示します。execute()
以外のメソッドを開示できます。!
(感嘆符) 文字または method:
プレフィックスを Action URL に使用して、「Dynamic Method Invocation」が有効に設定されていれば Action でどの public メソッドでも呼び出すことができます。この機能を知らない開発者は、内部のビジネスロジックを攻撃者に対して無防備に開示してしまう可能性があります。http://server/app/recoverpassword!getPassword.action
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