IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーション サーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーに設定します。
...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
author として送信された値に CR 文字や LF 文字が含まれていない場合のみです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは次の形式で 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーション サーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合のみです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは次の形式で 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
Example 1 を応用しています。クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、2 つのレスポンスを作成させる単一のリクエストを行います。その 2 番目のレスポンスは、別のリクエスト、おそらくはサーバーとの TCP 接続を共有している別のユーザーが行ったリクエストに対する回答と誤って解釈される可能性があります。この攻撃は、攻撃者とユーザーがサーバー (共通のプロキシサーバーなど) との TCP 接続を共有している状況で、悪意あるリクエストをユーザー自身で、またはリモートから送信するよう誘導します。最も良心的な場合でも、攻撃者はこの能力を活用して、ユーザーにアプリケーションがハッキングされていると思わせ、アプリケーションのセキュリティに対する信頼を失わせる可能性があります。最悪の場合、攻撃者はアプリケーションの動作を模倣し、口座番号やパスワードなどの個人情報を攻撃者にリダイレクトするよう設計されたコンテンツを用意しています。
...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「index.html\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。 使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。 しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
CC や BCC などの任意のヘッダーを追加し、それを使用して、メールの内容を自身に漏らしたり、メール サーバーをスパム ボットとして悪用したりできます。CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。
func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}
...
subject: [Contact us query] Page not working
...
subject として送信された値に CR 文字や LF 文字が含まれていない場合のみです。攻撃者が、悪意のある文字列として "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..." などを送信した場合、SMTP ヘッダーは次のような形式になります。
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC や BCC など任意のヘッダーを追加して電子メールの内容を盗み見たり、メール サーバーをスパム ボットとして使用したりできます。CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。
String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);
...
subject: [Contact us query] Page not working
...
subject として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が "Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..." といった悪意のある文字列を送信すると、SMTP ヘッダーは次の形式になります。
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC や BCC など任意のヘッダーを追加して電子メールの内容を盗み見たり、メール サーバーをスパム ボットとして使用したりできます。CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。
$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);
...
subject: [Contact us query] Page not working
...
subject として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が "Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..." といった悪意のある文字列を送信すると、SMTP ヘッダーは次の形式になります。
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC や BCC など任意のヘッダーを追加して電子メールの内容を盗み見たり、メール サーバーをスパム ボットとして使用したりできます。CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。
body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)
...
subject: [Contact us query] Page not working
...
subject として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が "Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..." といった悪意のある文字列を送信すると、SMTP ヘッダーは次の形式になります。
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
HtmlInputHidden hidden = new HtmlInputHidden();
Hidden hidden = new Hidden(element);
hidden タイプの <input> タグは、非表示フィールドが使用されていることを示します。
<input type="hidden">
X-XSS-Protection ヘッダーは通常、最新のブラウザーではデフォルトで有効になっています。このヘッダーの値が false (0) に設定されると、Cross-Site Scripting に対する保護が無効化されます。X-XSS-Protection ヘッダーが明示的に無効化されるため、Cross-Site Scripting 攻撃のリスクが高まる可能性があります。X-XSS-Protection ヘッダーは通常、最新のブラウザーではデフォルトで有効になっています。このヘッダーの値が false (0) に設定されると、Cross-Site Scripting に対する保護が無効化されます。
<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
X-XSS-Protection ヘッダーを明示的に無効化すると、Cross-Site Scripting 攻撃のリスクが高まる可能性があります。X-XSS-Protection ヘッダーは通常、最新のブラウザーではデフォルトで有効になっています。このヘッダーの値が false (0) に設定されると、Cross-Site Scripting に対する保護が無効化されます。X-XSS-Protection ヘッダーを明示的に無効化すると、Cross-Site Scripting 攻撃のリスクが高まる可能性があります。X-XSS-Protection ヘッダーは通常、最新のブラウザーではデフォルトで有効になっています。このヘッダーの値が false (0) に設定されると、Cross-Site Scripting に対する保護が無効化されます。Application_BeginRequest が空であるか、X-Content-Type-Options を nosniff に設定する関数コールを含んでいないか、そのヘッダーを削除しようとしています。X-Content-Type-Options: nosniff を使用する必要があります。X-Content-Type-Options を nosniff に設定しないでおきます。X-Content-Type-Options: nosniff を各ページで使用して、ユーザーが制御できるコンテンツが含まれるようにしてください。net.http.DetectContentType() を使用してレスポンス Content-Type を判断します。
...
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
content_type := DetectContentType(body)
...
X-Content-Type-Options が nosniff に設定されないか、このセキュリティ ヘッダーが明示的に無効化されます。X-Content-Type-Options: nosniff を使用する必要があります。
<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
X-Content-Type-Options が nosniff に設定されないか、このセキュリティ ヘッダーは明示的に無効になります。X-Content-Type-Options: nosniff を使用する必要があります。X-Content-Type-Options が nosniff に設定されないか、このセキュリティ ヘッダーは明示的に無効になります。X-Content-Type-Options: nosniff を使用する必要があります。X-Frame-Options ヘッダーが含まれます。このヘッダーが無効化されているか設定されていないと、クロスフレーム関連の脆弱性につながります。X-Frame-Options ヘッダーを無効化するよう設定します。
<http auto-config="true">
...
<headers>
...
<frame-options disabled="true"/>
</headers>
</http>
script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src はリソース アクセスを制御します。この 8 つのディレクティブでは、そのディレクティブで処理される機能にサイトがアクセスできるドメインを指定する値として、ソース一覧を受け取ります。開発者はワイルドカード * を使用するとソースの全部または一部を指示できます。ソース一覧キーワード、'unsafe-inline' や 'unsafe-eval' などを追加すると、スクリプト実行に対する制御の精度が高くなりますが、有害となる可能性があります。いずれのディレクティブも必須ではありません。ブラウザーは一覧にないディレクティブにもすべてのソースを許可するか、任意の default-src ディレクティブからその値を導出します。また、このヘッダーの仕様は時間の経過とともに発展しています。Firefox ではバージョン 23 まで、IE ではバージョン 10 まで、X-Content-Security-Policy として実装されていました。Chrome ではバージョン 25 まで X-Webkit-CSP として実装されていました。こうした名前はいずれも廃止となり、現在は標準名 Content Security Policyに取って代わられました。ディレクティブの数、廃止となった 2 つの代替名、同じヘッダーが複数回発生し 1 つのヘッダー内でディレクティブが繰り返される処理方法が指示される場合、開発者が誤ってこのヘッダーを設定する確率が高くなります。default-src ディレクティブを設定します。
<http auto-config="true">
...
<headers>
...
<content-security-policy policy-directives="default-src '*'" />
</headers>
</http>
script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src はリソース アクセスを制御します。この 8 つのディレクティブでは、そのディレクティブで処理される機能にサイトがアクセスできるドメインを指定する値として、ソース一覧を受け取ります。開発者はワイルドカード * を使用するとソースの全部または一部を指示できます。ソース一覧キーワード、'unsafe-inline' や 'unsafe-eval' などを追加すると、スクリプト実行に対する制御の精度が高くなりますが、有害となる可能性があります。いずれのディレクティブも必須ではありません。ブラウザーは一覧にないディレクティブにもすべてのソースを許可するか、任意の default-src ディレクティブからその値を導出します。また、このヘッダーの仕様は時間の経過とともに発展しています。Firefox ではバージョン 23 まで、IE ではバージョン 10 まで、X-Content-Security-Policy として実装されていました。Chrome ではバージョン 25 まで X-Webkit-CSP として実装されていました。こうした名前はいずれも廃止となり、現在は標準名 Content Security Policyに取って代わられました。ディレクティブの数、廃止となった 2 つの代替名、同じヘッダーが複数回発生し 1 つのヘッダー内でディレクティブが繰り返される処理方法が指示される場合、開発者が誤ってこのヘッダーを設定する確率が高くなります。*-src ディレクティブは * のような過度に許容的なポリシーで構成されています。django-csp 設定は過度に許容的で安全ではない default-src ディレクティブを設定します。
...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...
Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
Response.AppendHeader("Access-Control-Allow-Origin", "*");
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、任意のドメインで実行されている JavaScript がアプリケーションのデータにアクセスできます。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
<?php
header('Access-Control-Allow-Origin: *');
?>
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
response.addHeader("Access-Control-Allow-Origin", "*")
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
Response.AddHeader "Access-Control-Allow-Origin", "*"
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。
WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
webview.postWebMessage(message, Uri.parse("*"));
* を使用するということは、このスクリプトが生成元に関係なくウィンドウにメッセージを送信していることを示します。
o.contentWindow.postMessage(message, '*');
* を使用するということは、このスクリプトが生成元に関係なくウィンドウにメッセージを送信していることを示します。Unsafe-URL に設定すると、アプリケーションで機密性の高いサイトやユーザー データ (セッション トークン、ユーザー名とパスワードを含む) が第三者サイトに開示されてしまう可能性があります。Referrer-Policy ヘッダーは、リファラー ヘッダーに関連するブラウザーの動作を制御するために導入されました。Unsafe-URL オプションはすべての制限を解除し、リクエストごとにリファラー ヘッダーを送信します。
<http auto-config="true">
...
<headers>
...
<referrer-policy policy="unsafe-url"/>
</headers>
</http>
Content-Security-Policy-Report-Only ヘッダーにより、Web アプリケーションの作成者や管理者はセキュリティ ポリシーを強制適用するのではなく監視することができます。このヘッダーは通常、サイトのセキュリティ ポリシーを試用および/または開発する際に使用されます。ポリシーが有効であると判断された場合、代わりに Content-Security-Policy ヘッダー フィールドを使用すると強制適用できます。Report-Only モードに設定します。
<http auto-config="true">
...
<headers>
...
<content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
</headers>
</http>
Content-Security-Policy-Report-Only ヘッダーにより、Web アプリケーションの作成者や管理者はセキュリティ ポリシーを強制適用するのではなく監視することができます。このヘッダーは通常、サイトのセキュリティ ポリシーを試用および/または開発する際に使用されます。ポリシーが有効であると判断された場合、代わりに Content-Security-Policy ヘッダーを使用して強制適用できます。Report-Only モードに設定します。
response.content_security_policy_report_only = "*"
...
String lang = Request.Form["lang"];
WebClient client = new WebClient();
client.BaseAddress = url;
NameValueCollection myQueryStringCollection = new NameValueCollection();
myQueryStringCollection.Add("q", lang);
client.QueryString = myQueryStringCollection;
Stream data = client.OpenRead(url);
...
en&poll_id=1 のような lang を指定できる可能性を考慮しておらず、攻撃者が思いのままに poll_id を変更できます。
...
String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.example.com");
get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
get.execute();
...
en&poll_id=1 のような lang を指定できる可能性を考慮しておらず、攻撃者が思いのままに poll_id を変更できます。
<%
...
$id = $_GET["id"];
header("Location: http://www.host.com/election.php?poll_id=" . $id);
...
%>
name=alice を指定していますが、さらに name=alice& を追加しています。これが最初に出現するサーバーで使用されると、alice になりすましてそのアカウントに関する情報をさらに取得します。
<authorization>
<allow verbs="GET,POST" users="admin"/>
<deny verbs="GET,POST"users="*" />
</authorization>
<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<http-method> タグで明示的に定義されていないため、GET または POST リクエストを HEAD リクエストに置き換えることで、管理機能を実行できてしまう場合があります。HEAD リクエストが管理機能を実行するには、条件 3 (アプリケーションは POST 以外の動詞に基づいてコマンドを実行する必要がある) が成立する必要があります。一部の Web サーバーまたはアプリケーション サーバーは、任意の非標準 HTTP 動詞を受け入れ、GET リクエストを受け取ったかのように応答します。こうなると、攻撃者が、リクエスト内の任意の動詞を使用して管理ページを表示できてしまいます。
GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com
FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com
private および final と宣言し、Set を変更するメソッドを誤って作成しています。
@Immutable
public final class ThreeStooges {
private final Set stooges = new HashSet>();
...
public void addStooge(String name) {
stooges.add(name);
}
...
}
final ではありません。Immutable が付けられています。final 以外のフィールドは、値が変更されるのを許可するため、クラスの不変性が侵害されます。final と宣言するのではなく、誤って public に宣言しています。
@Immutable
public class ImmutableInteger {
public int value;
}
public および final と宣言しています。
@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
DATA: r TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i,
var3 TYPE n.
GET TIME.
var1 = sy-uzeit.
r = cl_abap_random=>create( seed = var1 ).
r->int31( RECEIVING value = var2 ).
var3 = var2.
CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.
CL_ABAP_RANDOM->INT31 関数を使用して、領収書ページの一意の識別子を生成します。CL_ABAP_RANDOM は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
string GenerateReceiptURL(string baseUrl) {
Random Gen = new Random();
return (baseUrl + Gen.Next().toString() + ".html");
}
Random.Next() 関数を使用して、領収書ページの一意の識別子を生成します。Random.Next() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
char* CreateReceiptURL() {
int num;
time_t t1;
char *URL = (char*) malloc(MAX_URL);
if (URL) {
(void) time(&t1);
srand48((long) t1); /* use time to set seed */
sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
}
return URL;
}
lrand48() 関数を使用して、領収書ページの一意の識別子を生成します。lrand48() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>
Rand() 関数を使用して、領収書ページの一意の識別子を生成します。Rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)
rand.New() 関数を使用して、RSA 鍵の乱数を生成します。rand.New() は統計的 PRNG なので、生成される値の推測は攻撃者にとってはたやすいことです。
String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return (baseUrl + ranGen.nextInt(400000000) + ".html");
}
Random.nextInt() 関数を使用して、領収書ページの一意の識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
function genReceiptURL (baseURL){
var randNum = Math.random();
var receiptURL = baseURL + randNum + ".html";
return receiptURL;
}
Math.random() 関数を使用して、領収書ページの一意の識別子を生成します。Math.random() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
fun GenerateReceiptURL(baseUrl: String): String {
val ranGen = Random(Date().getTime())
return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}
Random.nextInt() 関数を使用して、領収書ページの「一意の」識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
function genReceiptURL($baseURL) {
$randNum = rand();
$receiptURL = $baseURL . $randNum . ".html";
return $receiptURL;
}
rand() 関数を使用して、領収書ページの一意の識別子を生成します。rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
RETURN VARCHAR2
AS
rnum VARCHAR2(48);
time TIMESTAMP;
url VARCHAR2(MAX_URL)
BEGIN
time := SYSTIMESTAMP;
DBMS_RANDOM.SEED(time);
rnum := DBMS_RANDOM.STRING('x', 48);
url := 'http://test.com/' || rnum || '.html';
RETURN url;
END
DBMS_RANDOM.SEED() 関数を使用して、領収書ページの一意の識別子を生成します。DBMS_RANDOM.SEED() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
def genReceiptURL(self,baseURL):
randNum = random.random()
receiptURL = baseURL + randNum + ".html"
return receiptURL
rand() 関数を使用して、領収書ページの一意の識別子を生成します。rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
def generateReceiptURL(baseUrl) {
randNum = rand(400000000)
return ("#{baseUrl}#{randNum}.html");
}
Kernel.rand() 関数を使用して、領収書ページの一意の識別子を生成します。Kernel.rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。
def GenerateReceiptURL(baseUrl : String) : String {
val ranGen = new scala.util.Random()
ranGen.setSeed((new Date()).getTime())
return (baseUrl + ranGen.nextInt(400000000) + ".html")
}
Random.nextInt() 関数を使用して、領収書ページの一意の識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
sqlite3_randomness(10, &reset_token)
...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...
Rnd() 関数を使用して、領収書ページの一意の識別子を生成します。Rnd() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。CL_ABAP_RANDOM クラスまたはそのバリアントなど) が特定の定数値を使用してシードされると、値を返すかまたは割り当てる GET_NEXT、INT および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。random_gen2 で生成される値は、オブジェクト random_gen1 から予想できます。
DATA: random_gen1 TYPE REF TO cl_abap_random,
random_gen2 TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i.
random_gen1 = cl_abap_random=>create( seed = '1234' ).
DO 10 TIMES.
CALL METHOD random_gen1->int
RECEIVING
value = var1.
WRITE:/ var1.
ENDDO.
random_gen2 = cl_abap_random=>create( seed = '1234' ).
DO 10 TIMES.
CALL METHOD random_gen2->int
RECEIVING
value = var2.
WRITE:/ var2.
ENDDO.
random_gen1 と random_gen2 が同じようにシードされたため、var1 = var2 となりますsrand(unsigned int) のような関数を使用) 疑似ランダム数値の生成機能 (rand() など) をシードすると、値を返すかまたは割り当てる rand() および類似のメソッドによって返される値は、攻撃者にとって予想可能になり、攻撃者が複数の PRNG 出力を収集できるようになります。
srand(2223333);
float randomNum = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum);
randomNum = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum);
srand(2223333);
float randomNum2 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum2);
randomNum2 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum2);
srand(1231234);
float randomNum3 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum3);
randomNum3 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum3);
randomNum1 と randomNum2 の結果は同一の方法でシードされているので、擬似ランダム数値の生成機能 srand(2223333) をシードするコール後の rand() への各コールは、結果的に同じコール実行順序で同じ出力になります。たとえば、出力は以下のようになります。
Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00
math.Rand.New(Source) のような関数を使用) してシードされると、値を返すかまたは割り当てる math.Rand.Int() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。
randomGen := rand.New(rand.NewSource(12345))
randomInt1 := randomGen.nextInt()
randomGen.Seed(12345)
randomInt2 := randomGen.nextInt()
randomGen.Seed(12345)) の後に nextInt() をコールすると、同じ出力が同じ順序で得られます。Random など) が特定の値を使用 (Random.setSeed() のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。
Random randomGen1 = new Random();
randomGen1.setSeed(12345);
int randomInt1 = randomGen1.nextInt();
byte[] bytes1 = new byte[4];
randomGen1.nextBytes(bytes1);
Random randomGen2 = new Random();
randomGen2.setSeed(12345);
int randomInt2 = randomGen2.nextInt();
byte[] bytes2 = new byte[4];
randomGen2.nextBytes(bytes2);
randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 bytes1[] と bytes2[] の値は等しくなります。Random など) が特定の値を使用 (Random(Int) のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。
val randomGen1 = Random(12345)
val randomInt1 = randomGen1.nextInt()
val byteArray1 = ByteArray(4)
randomGen1.nextBytes(byteArray1)
val randomGen2 = Random(12345)
val randomInt2 = randomGen2.nextInt()
val byteArray2 = ByteArray(4)
randomGen2.nextBytes(byteArray2)
randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 byteArray1 と byteArray2 の値は等しくなります。
...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...
random.seed(123456)) をシードするコールの後の randint() への各コールの結果、同じものが同じ順序で出力されます。たとえば、出力は以下のようになります。
Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3
Random など) が特定の値を使用 (Random.setSeed() のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。
val randomGen1 = new Random()
randomGen1.setSeed(12345)
val randomInt1 = randomGen1.nextInt()
val bytes1 = new byte[4]
randomGen1.nextBytes(bytes1)
val randomGen2 = new Random()
randomGen2.setSeed(12345)
val randomInt2 = randomGen2.nextInt()
val bytes2 = new byte[4]
randomGen2.nextBytes(bytes2)
randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 bytes1[] と bytes2[] の値は等しくなります。CL_ABAP_RANDOM (またはそのバリアント) を、汚染された引数を使用して初期化しないでください。そのような初期化を行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、以下のようなメソッド (これらに限りません) へのコールによって作成された値のシーケンスを攻撃者が予測できるようになります。 GET_NEXT, INT, FLOAT, PACKED.rand() など) を生成する関数 (シード (srand() など) が渡される) を、汚染された引数を使用してコールしないでください。このようなコールを行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、擬似乱数生成機能へのコールによって作成された値のシーケンス (通常は整数) を攻撃者が予測できるようになります。ed25519.NewKeyFromSeed()) を、汚染された引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似乱数ジェネレータのシードに使用する値を制御できるようになるため、疑似乱数ジェネレータを呼び出したときに生成される一連の値を予測することができるようになります。Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は擬似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextShort()、Random.nextLong() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(byte[]) で設定される値 (通常は整数) のシーケンスを予想できるようになります。Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextLong()、Random.nextDouble() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(ByteArray) で設定される値 (通常は整数) のシーケンスを予想できるようになります。random.randint() など) を、汚染された引数を使用してコールしないでください。このようなコールを行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、疑似ランダム数値生成機能へのコールによって作成された値のシーケンス (通常は整数) を攻撃者が予測できるようになります。Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextShort()、Random.nextLong() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(byte[]) で設定される値 (通常は整数) のシーケンスを予想できるようになります。