permissions := strconv.Atoi(os.Getenv("filePermissions"));
fMode := os.FileMode(permissions)
os.chmod(filePath, fMode);
...
String permissionMask = System.getProperty("defaultFileMask");
Path filePath = userFile.toPath();
...
Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
Files.setPosixFilePermissions(filePath, perms);
...
$rName = $_GET['publicReport'];
chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...
publicReport
に悪意のある値 (../../localuser/public_html/.htpasswd
など) を指定した場合、指定されたファイルは攻撃者から読み取り可能となります。
...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...
permissions = os.getenv("filePermissions");
os.chmod(filePath, permissions);
...
...
rName = req['publicReport']
File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...
publicReport
に悪意のある値 (../../localuser/public_html/.htpasswd
など) を指定した場合、指定されたファイルは攻撃者から読み取り可能となります。
...
mask = config_params['perms']
File.chmod(filename, mask)
...
crossdomain.xml
設定ファイルの該当する設定によりこのポリシーを変更することを開発者に許可しています。しかし、この設定を変更する場合には、注意が必要です。クロスドメインポリシーが過度に許容的であると、悪意のあるアプリケーションが不正な方法で攻撃対象のアプリケーションとやりとりし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
flash.system.Security.allowDomain("*");
*
を allowDomain()
への引数として使用すると、アプリケーションのデータが、任意のドメインにある他の SWF アプリケーションにアクセスできることになります。crossdomain.xml
設定ファイルの該当する設定によりこのポリシーを変更することを開発者に許可しています。Flash Player 9,0,124,0 以降、Adobe は Flash Player がドメイン間で送信できるカスタム ヘッダーを定義する機能も導入しました。ただし、これらの設定を定義するときには注意が必要です。過度に許容的なカスタム ヘッダー ポリシーを、過度に許容的なクロスドメイン ポリシーと一緒に適用すると、悪意のあるアプリケーションが任意のヘッダーをターゲット アプリケーションに送信できるようになります。その結果、さまざまな攻撃の対象となったり、受信したヘッダーの処理方法がわからない、アプリケーションの実行エラーが発生したりする可能性があります。
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
*
を headers
属性の値として使用すると、任意のヘッダーがドメイン間で送信できてしまいます。crossdomain.xml
設定ファイルの該当する設定によりこのポリシーを変更することを開発者に許可しています。しかし、この設定に影響を与えるユーザーを決定する場合には、注意が必要です。クロスドメインポリシーが過度に許容的であると、悪意のあるアプリケーションが不正な方法で攻撃対象のアプリケーションとやりとりし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。ポリシー制約の回避の脆弱性は次のように発生します。例 2: 次のコードは、ロードされた SWF ファイルへのパラメーターの 1 つの値を使用して、信頼されるドメインのリストを定義しています。
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var url:String = String(params["url"]);
flash.system.Security.loadPolicyFile(url);
...
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var domain:String = String(params["domain"]);
flash.system.Security.allowDomain(domain);
...
crossdomain.xml
設定ファイルの該当する設定によりこの制約を変更することを開発者に許可しています。しかし、HTTP を介してロードされたアプリケーションは、中間者攻撃を受ける可能性があり、信頼するべきではないため、これらの設定を定義するときには、注意が必要です。allowInsecureDomain()
をコールしています。これは、HTTP でロードされた SWF アプリケーションが HTTPS でロードされた SWF アプリケーションのデータにアクセスすることを禁止する制約を解除するものです。
flash.system.Security.allowInsecureDomain("*");
script
タグについて考えてみましょう。
<script src="http://www.example.com/js/fancyWidget.js"></script>
www.example.com
以外の Web サイトでこのタグが表示される場合、このサイトは www.example.com
に依存し、正しい悪意のないコードが提供されます。攻撃者が www.example.com
を乗っ取っている場合、fancyWidget.js
の内容を改変して、サイトのセキュリティが侵害される場合があります。たとえば、fancyWidget.js
にユーザーの機密情報を盗むコードが追加される可能性があります。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 ヘッダーを設定するときには、注意が必要となります。
@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();
RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}
author
と Jane Smith
で構成されると想定した場合、このヘッダーを含む HTTP レスポンスは次のような形式になります。
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
や bar
などの悪意のある名前と値のペアを送信し、HTTP レスポンスが次の形式の 2 つのレスポンスに分割される場合があります。
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
HttpResponse.AddHeader()
メソッドに送信されるときに、CR、LF、および NULL 文字が %0d、%0a、および %00 に変換されます。最新の .NET フレームワークを使用しており、改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは 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.Text
として送信された値に 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
...
author
を HTML フォームから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.
EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...
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
を Web フォームから読み取り、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 ヘッダーを設定するときには、注意が必要となります。
final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});
author
を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
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
...
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 ヘッダーを設定するときには、注意が必要となります。name
と value
が攻撃者によって制御される可能性がある場合を想定します。このコードは、名前と値が攻撃者によって制御される可能性のある HTTP ヘッダーを設定します。
...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...
author
と Jane Smith
で構成されると想定すると、このヘッダーを含む HTTP レスポンスは次の形式をとります。
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
や bar
などの悪意のある名前/値のペアを送信する可能性があり、その場合 HTTP レスポンスは次の形式の 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
header()
関数に渡されると、警告を生成し、ヘッダーの作成を中止します。使用している PHP のバージョンが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。
<?php
$location = $_GET['some_location'];
...
header("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
...
author
を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...
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 ヘッダーを設定するときには、注意が必要となります。author
を HTTP リクエストから読み取り、サイトの別の部分への get リクエストに使用します。
author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...
AUTHOR_PARAM
として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...」といった悪意のある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker
POST /index.php HTTP/1.1
...
IllegalArgumentException
が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。name
と value
が攻撃者によって制御される可能性がある場合を想定します。このコードは、名前と値が攻撃者によって制御される可能性のある HTTP ヘッダーを設定します。
...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...
author
と Jane Smith
で構成されると想定すると、このヘッダーを含む HTTP レスポンスは次の形式をとります。
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
や bar
などの悪意のある名前/値のペアを送信する可能性があり、その場合 HTTP レスポンスは次の形式の 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
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
...
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
...
realloc()
を使用してはいけません。この関数によって、上書きが不可能なメモリ内に機密情報のコピーが取り残される可能性があります。realloc()
関数は、割り当てられたメモリのブロックサイズを増やす際によく使用されます。この操作は多くの場合、古いメモリブロックの内容を新しい大きなブロックにコピーする操作を必要とします。この操作は、元のブロックの内容をそのまま保持してプログラムからアクセスできないようにするため、プログラムは機密性が高いデータをメモリから消し去ることができません。攻撃者が後でメモリダンプの内容をチェックできる場合、機密性が高いデータが攻撃者の目に触れる可能性があります。realloc()
をコールしています。
plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);
realloc()
が使用されているため、最初に plaintext_buffer
に割り当てられたメモリにデータのコピーが残り、人目に触れる危険があります。VirtualLock
を使用しないでください。この関数は実装されないことがあります。VirtualLock
関数は、メモリ内のページをロックしてディスクにページングされるのを防止するために使用されます。しかし、Windows 95/98/ME では、この関数はスタブとしてのみ実装されており効果がありません。
HtmlInputHidden hidden = new HtmlInputHidden();
Hidden hidden = new Hidden(element);
hidden
タイプの <input>
タグは、非表示フィールドが使用されていることを示します。
<input type="hidden">
...
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
になりすましてそのアカウントに関する情報をさらに取得します。rawmemchr()
への呼び出しで、信頼できないコマンドライン引数を検索バッファーとして使用しています。
int main(int argc, char** argv) {
char* ret = rawmemchr(argv[0], 'x');
printf("%s\n", ret);
}
argv[0]
のサブ文字列を出力するためのものですが、最終的に argv[0]
より上位にあるメモリの一部を出力してしまうことがあります。static files
アプリケーションの serve
ビューを開示します。Django のマニュアルには次のように記載されています。static files
ツールは、大部分において、実運用に静的ファイルを配置する作業を支援する目的で設計されています。これは多くの場合、ローカルで展開するときに大変な経費となる別個の専用静的ファイル サーバーを意味します。そのため、静的ファイル アプリに簡易ヘルパー ビューが付属します。これを利用し、開発にローカルにファイルを提供できます。DEBUG
が True
の場合にのみ機能します。admin
アプリケーションが予測可能な URL に配置されます。
from django.conf.urls import patterns
from django.contrib import admin
admin.autodiscover()
urlpatterns = patterns('',
...
url(r'^admin/', include(admin.site.urls)),
...
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[])
で設定される値 (通常は整数) のシーケンスを予想できるようになります。