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)
...
services-config.xml
ディスクリプタファイルは "Logging" XML 要素を指定して、ログの各要素を記述します。次のようになります。
<logging>
<target class="flex.messaging.log.ConsoleTarget" level="Debug">
<properties>
<prefix>[BlazeDS]</prefix>
<includeDate>false</includeDate>
<includeTime>false</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>false</includeCategory>
</properties>
<filters>
<pattern>Endpoint.*</pattern>
<pattern>Service.*</pattern>
<pattern>Configuration</pattern>
</filters>
</target>
</logging>
target
タグでは、ログレベルを示す level
と呼ばれる属性をオプションで使用できます。デバッグ レベルが詳細すぎるレベルに設定されている場合、アプリケーションが機密データをログ ファイルに書き込む可能性があります。sprintf()
、FormatMessageW()
、または syslog()
などの関数に渡される場合。snprintf()
を使用してコマンド ライン引数をバッファにコピーしています。
int main(int argc, char **argv){
char buf[128];
...
snprintf(buf,128,argv[1]);
}
%x
など) を入力することでスタックから読み取ることができます(この例では、関数はフォーマットのための引数を取っていません)。%n
書式指定子を使用することで攻撃者はスタックに書き込み、snprintf()
にそこまでの出力バイト数を指定した引数に書き出させることができます (引数から値を読み出すのが本来の動作です)。この攻撃を高度にしたものは、タイミングをずらして 4 回書き込みを行うことで、スタック上のポインタ値を完全に支配下に置きます。
printf("%d %d %1$d %1$d\n", 5, 9);
5 9 5 5
Example 1
で挙げたような、タイミングをずらして 4 回書き込みする手間を大幅に軽減することができます。syslog()
関数は、ときおり次のように使用されます。
...
syslog(LOG_ERR, cmdBuf);
...
syslog()
の 2 番目のパラメーターは Format String なので、cmdBuf
に含まれる書式指定子は Example 1
に記載したのと同様に解釈されます。syslog()
の正しい使用例です。
...
syslog(LOG_ERR, "%s", cmdBuf);
...
sprintf()
、FormatMessageW()
、syslog()
、NSLog
、または NSString.stringWithFormat
などの関数に渡される場合。NSString.stringWithFormat:
で Format String としてコマンド ライン引数を使用しています。
int main(int argc, char **argv){
char buf[128];
...
[NSString stringWithFormat:argv[1], argv[2] ];
}
%x
など) を入力することでスタックから読み取ることができます(この例では、関数はフォーマットのための引数を取っていません)。
printf("%d %d %1$d %1$d\n", 5, 9);
5 9 5 5
Example 1
で挙げたような、タイミングをずらして 4 回書き込みする手間を大幅に軽減することができます。syslog()
関数は、ときおり次のように使用されます。
...
syslog(LOG_ERR, cmdBuf);
...
syslog()
の 2 番目のパラメーターは Format String なので、cmdBuf
に含まれる書式指定子は Example 1
に記載したのと同様に解釈されます。syslog()
の正しい使用例です。例 4: Apple コア クラスは、Format String の脆弱性を悪用するための方法を提供しています。
...
syslog(LOG_ERR, "%s", cmdBuf);
...
String.stringByAppendingFormat()
関数は、ときおり次のように使用されます。
...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:[MyClass
formatInput:inputControl.text]];
...
stringByAppendingFormat()
の正しい使用例です。
...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:@"%@", [MyClass
formatInput:inputControl.text]];
...
strncpy()
など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。
void wrongNumberArgs(char *s, float f, int d) {
char buf[1024];
sprintf(buf, "Wrong number of %.512s");
}
strncpy()
など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。%d
を使用して、浮動小数点数から f
を不正に変換しています。
void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
char buf[1024];
sprintf(buf, "Wrong type of %d", f);
...
}
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
...
...
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
になりすましてそのアカウントに関する情報をさらに取得します。
...
encryptionKey = "".
...
...
var encryptionKey:String = "";
var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
...
var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
...
...
char encryptionKey[] = "";
...
...
<cfset encryptionKey = "" />
<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
...
...
key := []byte("");
block, err := aes.NewCipher(key)
...
...
private static String encryptionKey = "";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...
...
var crypto = require('crypto');
var encryptionKey = "";
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...
...
CCCrypt(kCCEncrypt,
kCCAlgorithmAES,
kCCOptionPKCS7Padding,
"",
0,
iv,
plaintext,
sizeof(plaintext),
ciphertext,
sizeof(ciphertext),
&numBytesEncrypted);
...
...
$encryption_key = '';
$filter = new Zend_Filter_Encrypt($encryption_key);
$filter->setVector('myIV');
$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...
...
from Crypto.Ciphers import AES
cipher = AES.new("", AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...
require 'openssl'
...
dk = OpenSSL::PKCS5::pbkdf2_hmac_sha1(password, salt, 100000, 0) # returns an empty string
...
...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"",
0,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...
...
Dim encryptionKey As String
Set encryptionKey = ""
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...
...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
Input_string type string.
CALL METHOD cl_abap_hmac=>get_instance
EXPORTING
if_algorithm = 'SHA3'
if_key = space
RECEIVING
ro_object = lo_hmac.
" update HMAC with input
lo_hmac->update( if_data = input_string ).
" finalise hmac
lo_digest->final( ).
...
Example 1
に示すコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1
のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。
...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
string hmacKey = "";
byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
hmac.Key = keyBytes;
...
}
...
Example 1
のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1
のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。
import "crypto/hmac"
...
hmac.New(md5.New, []byte(""))
...
Example 1
のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1
のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。
...
private static String hmacKey = "";
byte[] keyBytes = hmacKey.getBytes();
...
SecretKeySpec key = new SecretKeySpec(keyBytes, "SHA1");
Mac hmac = Mac.getInstance("HmacSHA1");
hmac.init(key);
...
Example 1
のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1
のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。
...
let hmacKey = "";
let hmac = crypto.createHmac("SHA256", hmacKey);
hmac.update(data);
...
例 1
のコードは正常に実行される可能性がありますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くかもしれません。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。
...
CCHmac(kCCHmacAlgSHA256, "", 0, plaintext, plaintextLen, &output);
...
Example 1
のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1
のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。
import hmac
...
mac = hmac.new("", plaintext).hexdigest()
...
Example 1
のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1
のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。
...
digest = OpenSSL::HMAC.digest('sha256', '', data)
...
Example 1
のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1
のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。
...
CCHmac(UInt32(kCCHmacAlgSHA256), "", 0, plaintext, plaintextLen, &output)
...
Example 1
のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1
のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。
...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("", salt,100000);
...
...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword("");
...
const pbkdfPassword = "";
crypto.pbkdf2(
pbkdfPassword,
salt,
numIterations,
keyLen,
hashAlg,
function (err, derivedKey) { ... }
)
...
CCKeyDerivationPBKDF(kCCPBKDF2,
"",
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...
...
CCKeyDerivationPBKDF(kCCPBKDF2,
password,
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...
password
に強力で適切に管理されたパスワードの値が含まれる場合でも、パスワードの長さをゼロで渡すと、空パスワード、null
パスワード、または予期せぬ脆弱なパスワード値になります。
...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "");
...
from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', '', salt, 100000)
...
...
key = OpenSSL::PKCS5::pbkdf2_hmac('', salt, 100000, 256, 'SHA256')
...
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"",
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...
password
に強力で適切に管理されたパスワードの値が含まれる場合でも、パスワードの長さをゼロで渡すと、空パスワード、null
パスワード、または予期せぬ脆弱なパスワード値になります。
...
encryptionKey = "lakdsljkalkjlksdfkl".
...
...
var encryptionKey:String = "lakdsljkalkjlksdfkl";
var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
...
var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
...
...
Blob encKey = Blob.valueOf('YELLOW_SUBMARINE');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...
...
using (SymmetricAlgorithm algorithm = SymmetricAlgorithm.Create("AES"))
{
string encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = Encoding.ASCII.GetBytes(encryptionKey);
algorithm.Key = keyBytes;
...
}
...
char encryptionKey[] = "lakdsljkalkjlksdfkl";
...
...
<cfset encryptionKey = "lakdsljkalkjlksdfkl" />
<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
...
...
key := []byte("lakdsljkalkjlksd");
block, err := aes.NewCipher(key)
...
...
private static final String encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...
...
var crypto = require('crypto');
var encryptionKey = "lakdsljkalkjlksdfkl";
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...
...
{
"username":"scott"
"password":"tiger"
}
...
...
NSString encryptionKey = "lakdsljkalkjlksdfkl";
...
...
$encryption_key = 'hardcoded_encryption_key';
//$filter = new Zend_Filter_Encrypt('hardcoded_encryption_key');
$filter = new Zend_Filter_Encrypt($encryption_key);
$filter->setVector('myIV');
$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...
...
from Crypto.Ciphers import AES
encryption_key = b'_hardcoded__key_'
cipher = AES.new(encryption_key, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...
_hardcoded__key_
を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、この暗号化鍵を使用してシステムによって暗号化されているデータを危険な状態におくことがあります。
require 'openssl'
...
encryption_key = 'hardcoded_encryption_key'
...
cipher = OpenSSL::Cipher::AES.new(256, 'GCM')
cipher.encrypt
...
cipher.key=encryption_key
...
例 2: 次のコードは、ハードコーディングされている暗号鍵を使用して AES 暗号化を行っています。
...
let encryptionKey = "YELLOW_SUBMARINE"
...
...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"YELLOW_SUBMARINE",
16,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...
...
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQCtVacMo+w+TFOm0p8MlBWvwXtVRpF28V+o0RNPx5x/1TJTlKEl
...
DiJPJY2LNBQ7jS685mb6650JdvH8uQl6oeJ/aUmq63o2zOw=
-----END RSA PRIVATE KEY-----
...
...
Dim encryptionKey As String
Set encryptionKey = "lakdsljkalkjlksdfkl"
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...
...
production:
secret_key_base: 0ab25e26286c4fb9f7335947994d83f19861354f19702b7bbb84e85310b287ba3cdc348f1f19c8cdc08a7c6c5ad2c20ad31ecda177d2c74aa2d48ec4a346c40e
...
...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
Input_string type string.
CALL METHOD cl_abap_hmac=>get_instance
EXPORTING
if_algorithm = 'SHA3'
if_key = 'secret_key'
RECEIVING
ro_object = lo_hmac.
" update HMAC with input
lo_hmac->update( if_data = input_string ).
" finalise hmac
lo_digest->final( ).
...
...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
string hmacKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
hmac.Key = keyBytes;
...
}
import "crypto/hmac"
...
hmac.New(sha256.New, []byte("secret"))
...
...
private static String hmacKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = hmacKey.getBytes();
...
SecretKeySpec key = new SecretKeySpec(keyBytes, "SHA1");
Mac hmac = Mac.getInstance("HmacSHA1");
hmac.init(key);
...
const hmacKey = "a secret";
const hmac = createHmac('sha256', hmacKey);
hmac.update(data);
...
hmacKey
を変更できないと考えられます。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。
...
CCHmac(kCCHmacAlgSHA256, "secret", 6, plaintext, plaintextLen, &output);
...
import hmac
...
mac = hmac.new("secret", plaintext).hexdigest()
...
...
digest = OpenSSL::HMAC.digest('sha256', 'secret_key', data)
...
...
CCHmac(UInt32(kCCHmacAlgSHA256), "secret", 6, plaintext, plaintextLen, &output)
...
...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("password", salt,100000);
...
...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword("password");
...
const pbkdfPassword = "a secret";
crypto.pbkdf2(
pbkdfPassword,
salt,
numIterations,
keyLen,
hashAlg,
function (err, derivedKey) { ... }
)
...
CCKeyDerivationPBKDF(kCCPBKDF2,
"secret",
6,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...
...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "hardcodedpassword");
...
from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', 'password', salt, 100000)
...
...
key = OpenSSL::PKCS5::pbkdf2_hmac('password', salt, 100000, 256, 'SHA256')
...
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"secret",
6,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...
Null
の暗号鍵はセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。null
暗号鍵を使用することは推奨されません。これにより優れた暗号アルゴリズムによる保護機能が大幅に低下し、問題の修正が極めて困難になるためです。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用して AES 暗号を実行します。
...
var encryptionKey:ByteArray = null;
...
var aes.ICipher = Crypto.getCipher("aes-cbc", encryptionKey, padding);
...
null
暗号鍵を使用していることが誰にでも判別できる上に、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。アプリケーションが頒布された後は、null
暗号鍵を変更するためのソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。Null
の暗号鍵はセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。null
暗号鍵を使用することは推奨されません。null
暗号鍵を使用すると、優れた暗号アルゴリズムによる保護機能が大幅に低下するとともに、問題の修正が極めて困難になります。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用しています。
...
char encryptionKey[] = null;
...
null
暗号鍵を使用していることが誰にでも判別できる上に、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。プログラムが頒布された後で、null
暗号化鍵を変更するためには、ソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
暗号鍵を使用することは推奨されません。これにより優れた暗号アルゴリズムによる保護機能が大幅に低下し、問題の修正が極めて困難になるためです。有害なコードが実運用に入ったら、null
暗号鍵の変更にはソフトウェア パッチを必要とします。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択することになります。null
暗号鍵を使用して AES 暗号を実行します。
...
aes.NewCipher(nil)
...
null
暗号鍵を使用していることが誰にでも判別できます。その上、初歩的なクラッキング技法さえ身につけていれば誰でも、暗号化されたあらゆるデータを完全に解読できる可能性が高まります。アプリケーションが頒布された後は、null
暗号鍵を変更するためのソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
暗号鍵を使用することは推奨されません。これにより優れた暗号アルゴリズムによる保護機能が大幅に低下し、問題の修正が極めて困難になるためです。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用して AES 暗号を実行します。
...
SecretKeySpec key = null;
....
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...
null
暗号鍵を使用していることが誰にでも判別できる上に、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。アプリケーションが頒布された後は、null
暗号鍵を変更するためのソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
暗号鍵を使用することは推奨されません。これにより優れた暗号アルゴリズムによる保護機能が大幅に低下し、問題の修正が極めて困難になるためです。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用して AES 暗号を実行します。
...
var crypto = require('crypto');
var encryptionKey = null;
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...
null
暗号鍵を使用していることが誰にでも判別できる上に、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。アプリケーションが頒布された後は、null
暗号鍵を変更するためのソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
暗号鍵を使用することは推奨されません。これにより優れた暗号アルゴリズムによる保護機能が大幅に低下し、問題の修正が極めて困難になるためです。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用して AES 暗号を実行します。
...
CCCrypt(kCCEncrypt,
kCCAlgorithmAES,
kCCOptionPKCS7Padding,
nil,
0,
iv,
plaintext,
sizeof(plaintext),
ciphertext,
sizeof(ciphertext),
&numBytesEncrypted);
...
null
暗号鍵を使用していることが誰にでも判別できる上に、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。アプリケーションが頒布された後は、null
暗号鍵を変更するためのソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
を割り当てるのは、攻撃者がセンシティブな暗号化された情報にアクセスできるようになるため、適切ではありません。null
暗号鍵を使用すると、優れた暗号アルゴリズムによる保護機能が大幅に低下するとともに、問題の修正が極めて困難になります。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
に設定します。
...
$encryption_key = NULL;
$filter = new Zend_Filter_Encrypt($encryption_key);
$filter->setVector('myIV');
$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...
null
暗号鍵を使用していることが誰にでも判別でき、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。プログラムが頒布された後で、null
暗号化鍵を変更するためには、ソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
暗号鍵を使用することは推奨されません。これにより優れた暗号アルゴリズムによる保護機能が大幅に低下し、問題の修正が極めて困難になるためです。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用していることが誰にでも判別できる上に、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。アプリケーションが頒布された後は、null
暗号鍵を変更するためのソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。None
を割り当てるのは、攻撃者がセンシティブな暗号化された情報にアクセスできるようになるため、適切ではありません。null
暗号鍵を使用すると、優れた暗号アルゴリズムによる保護機能が大幅に低下するとともに、問題の修正が極めて困難になります。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
に設定します。
...
from Crypto.Ciphers import AES
cipher = AES.new(None, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...
null
暗号鍵を使用していることが誰にでも判別でき、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。プログラムが頒布された後で、null
暗号化鍵を変更するためには、ソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
暗号鍵を使用することは推奨されません。null
暗号鍵を使用すると、優れた暗号アルゴリズムによる保護機能が大幅に低下するとともに、問題の修正が極めて困難になります。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用していることが誰にでも判別でき、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。プログラムが頒布された後で、null
暗号化鍵を変更するためには、ソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。Null
の暗号鍵はセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。null
暗号鍵を使用することは推奨されません。null
暗号鍵を使用すると、優れた暗号アルゴリズムによる保護機能が大幅に低下するとともに、問題の修正が極めて困難になります。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用して AES 暗号を実行します。
...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
nil,
0,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...
null
暗号鍵を使用していることが誰にでも判別できる上に、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。プログラムが頒布された後で、null
暗号化鍵を変更するためには、ソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
暗号鍵を使用することは推奨されません。これにより優れた暗号アルゴリズムによる保護機能が大幅に低下し、問題の修正が極めて困難になるためです。有害なコードが実運用に入ったら、null
暗号鍵を変更するためのソフトウェア パッチが必要です。null
暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。null
暗号鍵を使用して AES 暗号を実行します。
...
Dim encryptionKey As String
Set encryptionKey = vbNullString
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...
null
暗号鍵を使用していることが誰にでも判別できる上に、初歩的なクラッキング技法を使えれば暗号化されたあらゆるデータを完全に解読できる可能性が高まります。アプリケーションが頒布された後は、null
暗号鍵を変更するためのソフトウェア パッチが必要です。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
暗号鍵が使われている証拠を割り出すことが可能です。null
パスワードに基づいて暗号鍵を生成し使用すると、システムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。null
値をパスワード引数としてパスワードベースの暗号鍵導出関数に渡すのはよくない発想です。このシナリオでは、導出鍵は指定の salt のみに基づくことになり (鍵は著しく脆弱になる)、その問題を修正することは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り null
パスワードは変更できません。null
パスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。null
値をパスワード引数としてパスワードベースの暗号鍵導出関数に渡します。
...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword(null);
...
null
パスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、null
パスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、null
パスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
パスワードが使われている証拠を割り出すことが可能です。null
パスワードに基づいて暗号鍵を生成し使用すると、システムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。null
値をパスワード引数としてパスワードベースの暗号鍵導出関数に渡すのはよくない発想です。このシナリオでは、導出鍵は指定の salt のみに基づくことになり (鍵は著しく脆弱になる)、その問題を修正することは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り null
パスワードは変更できません。null
パスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。null
値をパスワード引数としてパスワードベースの暗号鍵導出関数に渡します。
...
CCKeyDerivationPBKDF(kCCPBKDF2,
nil,
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...
null
パスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、null
パスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、null
パスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
パスワードが使われている証拠を割り出すことが可能です。null
パスワードに基づいて暗号鍵を生成し使用すると、システムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。null
値をパスワード引数としてパスワードベースの暗号鍵導出関数に渡すのはよくない発想です。このシナリオでは、導出鍵は指定の salt のみに基づくことになり (鍵は著しく脆弱になる)、その問題を修正することは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り null
パスワードは変更できません。null
パスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。null
値をパスワード引数としてパスワードベースの暗号鍵導出関数に渡します。
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
nil,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...
null
パスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、null
パスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、null
パスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、null
パスワードが使われている証拠を割り出すことが可能です。
from Crypto.PublicKey import RSA
key = RSA.generate(2048)
f = open('mykey.pem','w')
f.write(key.exportKey(format='PEM'))
f.close()
require 'openssl'
key = OpenSSL::PKey::RSA.new 2048
File.open('mykey.pem', 'w') do |file|
file.write(key.to_pem)
end
chroot()
などの操作を実行するのに必要な、昇格した権限レベルは、操作を実行したらすぐに降格させます。chroot()
などの権限を持つ関数をコールする場合、先に root
権限を獲得する必要があります。権限付きの操作が完了したら、プログラムは root
権限を降格させ、呼び出したユーザーの権限レベルに戻さなければなりません。chroot()
をコールして、アプリケーションを APP_HOME
配下のファイル システムのサブセットに制限することで、攻撃者がプログラムを使用して他の場所にあるファイルに無許可でアクセスできないようにしています。コードはユーザーが指定したファイルを開き、ファイルの内容を処理しています。
...
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...
setuid()
をコールしない場合、アプリケーションは不必要な root
権限で動作し続けます。悪意ある操作はすべてスーパーユーザーの権限で実行されることになるので、攻撃者によってアプリケーションに対して実行される悪用が成功すると権限昇格攻撃になります。アプリケーションが権限レベルを root
以外のユーザーに降格していれば、被害の可能性は大幅に減少します。