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("*");
NameNode
、DataNode
、JobTraker
などの、Hadoop クラスターのコアコンポーネントで使用され、Hadoop クラスターの状態が変更された。Job
サブミッションを示しています。
public static void run(String args[]) throws IOException {
String path = "/path/to/a/file";
DFSclient client = new DFSClient(arg[1], new Configuration());
ClientProtocol nNode = client.getNameNode();
/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
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
にユーザーの機密情報を盗むコードが追加される可能性があります。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">
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 に対する保護が無効化されます。
...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...
'mydb'
と推測できればだれでもアクセスできます。required
属性を使用します。フィールドタイプを指定することで、入力はタイプと照合されます。さらに、カスタマイズ可能な pattern
属性を指定すれば、入力を正規表現と照合することもできます。ただし、form タグに novalidate
属性を追加し、submit 入力タグに formnovalidate
属性を追加した場合には、この検証方法は無効化されます。novalidate
属性を介してフォームの検証を無効にしています。例 2: 次のサンプルコードは、
<form action="demo_form.asp" novalidate="novalidate">
E-mail: <input type="email" name="user_email" />
<input type="submit" />
</form>
formnovalidate
属性を介してフォームの検証を無効にしています。
<form action="demo_form.asp" >
E-mail: <input type="email" name="user_email" />
<input type="submit" formnovalidate="formnovalidate"/>
</form>
SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'
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
を使用する必要があります。script-src
、img-src
、object-src
、style_src
、font-src
、media-src
、frame-src
、connect-src
はリソース アクセスを制御します。*
を使用し、全部または一部のソースを指示できます。いずれのディレクティブも必須ではありません。ブラウザは一覧にないディレクティブにすべてのソースを許可するか、任意の default-src
ディレクティブからその値を導出します。また、このヘッダーの仕様は時間の経過とともに発展しています。Firefox の場合はバージョン 23 まで、IE の場合はバージョン 10 まで X-Content-Security-Policy
として実装されていました。Chrome の場合はバージョン 25 まで X-Webkit-CSP
として実装されていました。いずれの名前も廃止となり、新しい標準名の Content Security Policy
に取って代わられました。ディレクティブの数、2 つの廃止となった代替名、1 つのヘッダーで複数回発生する同じヘッダーと繰り返しディレクティブの処理方法が指示される場合、開発者がこのヘッダーを間違って構成する可能性が高くなります。unsafe-inline
または unsafe-eval
のディレクティブは CSP の目的を無効にします。script-src
ディレクティブは設定されていますが、スクリプト nonce
は設定されていません。frame-src
は設定されていますが、sandbox
は設定されていません。django-csp
設定では、安全でないディレクティブ、unsafe-inline
と unsafe-eval
が使用され、インライン スクリプトとコード評価が許可されます。
...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...
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 にアクセスできることになります。