From 1b71fcf123b06aa1f9d61747b4058b5b5d8f6d5d Mon Sep 17 00:00:00 2001 From: orihalcon128 Date: Wed, 13 Nov 2019 19:48:44 +0900 Subject: [PATCH] Update Japanese messages. --- .../main/resources/metadata/messages_ja.xml | 3279 ++++++++++------- 1 file changed, 2046 insertions(+), 1233 deletions(-) diff --git a/findsecbugs-plugin/src/main/resources/metadata/messages_ja.xml b/findsecbugs-plugin/src/main/resources/metadata/messages_ja.xml index 981220a5e..3412c517b 100644 --- a/findsecbugs-plugin/src/main/resources/metadata/messages_ja.xml +++ b/findsecbugs-plugin/src/main/resources/metadata/messages_ja.xml @@ -1,12 +1,12 @@ + xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/spotbugs/spotbugs/master/spotbugs/etc/messagecollection.xsd"> Find Security Bugs
Find Security Bugs は，セキュリティ監査の支援を目的としたプラグインです。
- http://h3xstream.github.io/find-sec-bugs/bugs_ja.htm - http://h3xstream.github.io/find-sec-bugs/bugs_ja.htm + https://find-sec-bugs.github.io/bugs.htm + https://find-sec-bugs.github.io/bugs.htm @@ -17,20 +17,20 @@ 予測可能な擬似乱数生成器 - {3} の使用は予測可能です。 + 乱数生成器 ({3}) は予測可能です。
セキュリティが重要であるコンテキストで，予測可能な乱数が使用されると脆弱性につながることがあります。たとえば，その乱数が次のように使用されたときです。

+

セキュリティ上重要なコンテキストで，予測可能な乱数が使用されると脆弱性につながることがあります。たとえば，その乱数が次のように使用されたときです。

    -
  • CSRF トークン:予測可能なトークンは CSRF 攻撃につながり，攻撃者はトークンの価値を知ることになります
    • -
  • パスワードリセットトークン(電子メールで送信)：予測可能なパスワードトークンは，アカウントの奪取につながる可能性があります。これは，攻撃者がパスワード変更フォームのURLを推測するためです
    • +
  • CSRF トークン:予測可能なトークンは，攻撃者がトークンの価値を知ることになるので，CSRF 攻撃につながる可能性がある
    • +
  • パスワードリセットトークン(電子メールで送信):予測可能なパスワードトークンは，攻撃者が「パスワード変更」フォームのURLを推測するため，アカウントの乗っ取りにつながる可能性がある
  • その他の秘密の値

-手っ取り早い解決策は java.util.Random の使用を java.security.SecureRandom などのより強固なものに置き換えてください。 +手っ取り早い解決策は java.util.Random の使用を java.security.SecureRandom などのより強固なものに置き換えることです。

-脆弱なコード:
+脆弱なコード:

String generateSecretToken() {
     Random r = new Random();
     return Long.toHexString(r.nextLong());
@@ -48,13 +48,13 @@ String generateSecretToken() {
     return Hex.encodeHexString(result);
 }

-
+

-参考文献
-Cracking Random Number Generators - Part 1 (http://jazzy.id.au)
-CERT: MSC02-J. Generate strong random numbers
-CWE-330: Use of Insufficiently Random Values
-Predicting Struts CSRF Token (Example of real-life vulnerability and exploitation) +参考文献
+Cracking Random Number Generators - Part 1 (https://jazzy.id.au)
+CERT: MSC02-J. Generate strong random numbers
+CWE-330: Use of Insufficiently Random Values
+Predicting Struts CSRF Token (Example of real-life vulnerability and exploitation)

]]>
@@ -63,20 +63,20 @@ String generateSecretToken() { 予測可能な擬似乱数生成器 (Scala) - {3} の使用は予測可能です。 + Scalaの乱数生成器 ({3}) は予測可能です。
セキュリティが重要であるコンテキストで，予測可能な乱数が使用されると脆弱性につながることがあります。たとえば，その乱数が次のように使用されたときです。

+

セキュリティ上重要なコンテキストで，予測可能な乱数が使用されると脆弱性につながることがあります。たとえば，その乱数が次のように使用されたときです。

    -
  • CSRF トークン:予測可能なトークンは CSRF 攻撃につながり，攻撃者はトークンの価値を知ることになります
    • -
  • パスワードリセットトークン(電子メールで送信)：予測可能なパスワードトークンは，アカウントの奪取につながる可能性があります。これは，攻撃者がパスワード変更フォームのURLを推測するためです
    • +
  • CSRF トークン:予測可能なトークンは，攻撃者がトークンの価値を知ることになるので，CSRF 攻撃につながる可能性がある
    • +
  • パスワードリセットトークン(電子メールで送信):予測可能なパスワードトークンは，攻撃者が「パスワード変更」フォームのURLを推測するため，アカウントの乗っ取りにつながる可能性がある
  • その他の秘密の値

-手っ取り早い解決策は java.util.Random の使用を java.security.SecureRandom などのより強固なものに置き換えてください。 +手っ取り早い解決策は java.util.Random の使用を java.security.SecureRandom などのより強固なものに置き換えることです。

-脆弱なコード:
+脆弱なコード:

import scala.util.Random
 
 def generateSecretToken() {
@@ -106,13 +106,13 @@ def generateSecretToken() {
     return result.map("%02x" format _).mkString
 }

--> -
+

-参考文献
-Cracking Random Number Generators - Part 1 (http://jazzy.id.au)
-CERT: MSC02-J. Generate strong random numbers
-CWE-330: Use of Insufficiently Random Values
-Predicting Struts CSRF Token (Example of real-life vulnerability and exploitation) +参考文献
+Cracking Random Number Generators - Part 1 (http://jazzy.id.au)
+CERT: MSC02-J. Generate strong random numbers
+CWE-330: Use of Insufficiently Random Values
+Predicting Struts CSRF Token (Example of real-life vulnerability and exploitation)

]]>
@@ -130,7 +130,7 @@ def generateSecretToken() {
サーブレットは，さまざまなメソッドから GET と POST のパラメーターを読むことができます。取得した値は安全でないと考えるべきです。 -次のようなセンシティブな API に渡す前に，それらの値を検証したりエスケープする必要があるかもしれません。

+次のような気密性の高い API に値を渡す前に，値を検証またはエスケープする必要があるかもしれません。

  • SQL クエリー (SQL インジェクションにつながる可能性)
  • ファイルオープン (パストラバーサルにつながる可能性)
    • @@ -139,10 +139,10 @@ def generateSecretToken() {
  • など...
-
+

-参考文献
-CWE-20: Improper Input Validation +参考文献
+CWE-20: Improper Input Validation

]]>
@@ -158,10 +158,10 @@ def generateSecretToken() {

HTTP ヘッダー Content-Type は，クライアントによって操作可能です。したがって，その値をセキュリティ上重要な決定では使用しないでください。

-
+

-参考文献
-CWE-807: Untrusted Inputs in a Security Decision +参考文献
+CWE-807: Untrusted Inputs in a Security Decision

]]> @@ -174,7 +174,7 @@ HTTP ヘッダー Content-Type は，クライアントによって操作可能 受信されるホスト名は，多くの場合，クライアントによって操作が可能です。
Host ヘッダーは，クライアントによって操作可能です。したがって，その値をセキュリティ上重要な決定では使用しないでください。 +

Hostname ヘッダーは，クライアントによって操作可能です。したがって，その値をセキュリティ上重要な決定では使用しないでください。 ServletRequest.getServerName() と HttpServletRequest.getHeader("Host") は，どちらも Host ヘッダーを抽出するという同じ動作をします。

 GET /testpage HTTP/1.1
@@ -185,10 +185,10 @@ Host: www.example.com
 これにより，悪意のあるユーザーが Host ヘッダーで任意の値を配置できるようになります。
 リクエストに関して行うセキュリティ上の決定において，この値を信頼しないことをお勧めします。
 

-

+

 

-参考文献

-CWE-807: Untrusted Inputs in a Security Decision
+参考文献

+CWE-807: Untrusted Inputs in a Security Decision
 

 ]]>
@@ -197,16 +197,16 @@ Host: www.example.com - 信頼できないセッションクッキーの値 + 信頼できないセッション Cookie の値 セッション ID への直接アクセスは避けるべきです。
-メソッド HttpServletRequest.getRequestedSessionId() は， -通常，クッキー JSESSIONID の値を返します。この値は通常，セッション管理ロジックと正常でない開発者コードだけがアクセスします。 +メソッド HttpServletRequest.getRequestedSessionId() は， +通常，Cookie JSESSIONID の値を返します。この値は通常，セッション管理ロジックと正常でない開発者コードだけがアクセスします。

-クライアントに渡される値は一般的に英数字の値です (例えば JSESSIONID=jp6q31lq2myn)。しかし，この値はクライアントによって改ざんできます。 +クライアントに渡される値は一般的に英数字の値です (たとえば JSESSIONID=jp6q31lq2myn)。しかし，この値はクライアントによって改ざんできます。 次の HTTP リクエストは変更の可能性を示しています。 

 GET /somePage HTTP/1.1
@@ -217,19 +217,19 @@ Cookie: JSESSIONID=Any value of the user's choice!!??'''">
 

 
そのため，JSESSIONID は，その値が既存のセッション ID と一致するかどうかを確認するためだけに使用されるべきです。
 そうでない場合，そのユーザーは認証されていないユーザーであると考えるべきです。加えて，セッション ID の値をログに記録してはいけません。
-その場合，ログファイルには有効なアクティブセッション ID を含むことができ，ID がログに記録されかつアクティブなままであるすべてのセッションを内部者がハイジャックすることを許してしまいます。
+その場合，ログファイルに有効なアクティブセッション ID が含まれている可能性があり，インサイダーは ID がログに記録されていてアクティブな状態のセッションをハイジャックできます。
 

-

+

 

-参考文献

-OWASP: Session Management Cheat Sheet

-CWE-20: Improper Input Validation
+参考文献

+OWASP: Session Management Cheat Sheet

+CWE-20: Improper Input Validation
 
 

 ]]>
- セッションクッキーの値 + セッション Cookie の値 @@ -240,12 +240,12 @@ Cookie: JSESSIONID=Any value of the user's choice!!??'''">

クエリー文字列は，GET パラメーターの名前と値を連結したものです。意図したパラメーター以外を渡すことができます。

URL リクエストが /app/servlet.htm?a=1&b=2 のときは，クエリー文字列を抜き出すと a=1&b=2 になります。

HttpServletRequest.getParameter() のようなメソッドで取得した個々のパラメーター値と同じように，HttpServletRequest.getQueryString() から取得した値は安全でないと見なすべきです。 -センシティブな API に渡す前に，クエリー文字列から取得したものを検証またはエスケープする必要があります。 +気密性の高い API に渡す前に，クエリー文字列から取得したものを検証またはエスケープする必要があります。

-
+

-参考文献
-CWE-20: Improper Input Validation +参考文献
+CWE-20: Improper Input Validation

]]> @@ -259,12 +259,12 @@ Cookie: JSESSIONID=Any value of the user's choice!!??'''">
リクエストヘッダーはリクエストしているユーザーによって容易に改ざんできます。 -一般的には，ブラウザーから攻撃者による変更がないリクエストが来ることを仮定すべきではありません。 -このように，リクエストに関して行うあらゆるセキュリティ上の決定において，その値を信頼しないでください。

-
+一般的には，ブラウザーからリクエストが攻撃者によって変更されることなく来ることを仮定すべきではありません。 +このように，リクエストに関して行うあらゆるセキュリティ上の決定において，その値を信頼しないことをお勧めします。

+

-参考文献
-CWE-807: Untrusted Inputs in a Security Decision +参考文献
+CWE-807: Untrusted Inputs in a Security Decision

]]>
@@ -280,21 +280,21 @@ Cookie: JSESSIONID=Any value of the user's choice!!??'''">

動作:

    -
  • リクエストが悪意のあるユーザーから来ているなら，任意の値をこのヘッダーに割り当てられます。
    • -
  • リクエストが安全 (https) である別のオリジンから開始されたときは，"Referer" は存在しません。
    • +
  • リクエストが悪意のあるユーザーから来ているなら，任意の値をこのヘッダーに割り当てられる
    • +
  • リクエストが安全 (HTTPS) である別のオリジンから開始されたときは，"Referer" は存在しない

推奨:

    -
  • このヘッダーの値に基づいてアクセス制御を行うべきではありません。
    • -
  • CSRF 保護は，この値にだけ基づいて行われるべきではありません (オプションなので)。
    • +
  • このヘッダーの値に基づいてアクセス制御を行うべきではない
    • +
  • CSRF 保護は，この値にだけ基づいて行われるべきではない (オプションなので)

-
+

-参考文献
-CWE-807: Untrusted Inputs in a Security Decision +参考文献
+CWE-807: Untrusted Inputs in a Security Decision

]]> @@ -308,10 +308,10 @@ Cookie: JSESSIONID=Any value of the user's choice!!??'''">
ヘッダー "User-Agent" は，クライアントによって容易に偽装できます。User-Agent に基づいて (クローラー UA に対して) 異なった動作をすることは推奨できません。

-
+

-参考文献
-CWE-807: Untrusted Inputs in a Security Decision +参考文献
+CWE-807: Untrusted Inputs in a Security Decision

]]>
@@ -321,26 +321,26 @@ Cookie: JSESSIONID=Any value of the user's choice!!??'''"> -
直接的なクッキーの使用を特定します。
+
直接的な Cookie の使用を特定します。
 - クッキー内に機密データの可能性 - アプリケーションによって機密データがクッキーに格納されている可能性があります。 + Cookie 内に機密データの可能性 + アプリケーションによって機密データが Cookie に格納されている可能性があります。
カスタムクッキーに格納する情報は，機密やセッションに関連してはいけません。ほとんどの場合，機密データはセッションだけに格納して，ユーザーのセッションクッキーによってだけ参照されるべきです。 -HttpSession (HttpServletRequest.getSession()) を参照してください。

-

カスタムクッキーは，特定のセッションから独立した，より長く存続する必要がある情報のために使用できます。

-
+

カスタム Cookie に格納する情報は，機密やセッションに関連してはいけません。ほとんどの場合，機密データはセッションだけに格納して，ユーザーのセッション Cookie によってだけ参照されるべきです。 +HttpSession (HttpServletRequest.getSession()) を参照してください。

+

カスタム Cookie は，特定のセッションから独立した，より長く存続する必要がある情報のために使用できます。

+

-参考文献
-CWE-315: Cleartext Storage of Sensitive Information in a Cookie +参考文献
+CWE-315: Cleartext Storage of Sensitive Information in a Cookie

]]>
- クッキー内に機密データの可能性 + Cookie 内に機密データの可能性 @@ -350,17 +350,17 @@ HttpSession (HttpServletRequest.getSession()) を参照してください。

潜在的なパストラバーサル (ファイル読み出し) - メソッド {3} は，ユーザー入力によって指定された場所のファイルを読み出します。 + API ({3}) は，ユーザー入力によって指定された場所のファイルを読み出します。
内容を読むためにファイルが開かれています。ファイル名は 入力 パラメーターに由来しています。 フィルターされていないパラメーターがこのファイル API に渡されると，ファイルシステムの任意の場所からファイルを読み出せるかもしれません。

このルールは 潜在的な パストラバーサルの脆弱性を特定します。多くの場合，構築されたファイルパスはユーザーが制御できません。 その場合，報告された事例は誤検出です。

-
+

- 脆弱なコード:
+ 脆弱なコード:

@GET
 @Path("/images/{image}")
 @Produces("images/*")
@@ -374,10 +374,10 @@ public Response getImage(@javax.ws.rs.PathParam("image") String image) {
     return Response.ok().entity(new FileInputStream(file)).build();
 }

-
+

- 解決策:
+ 解決策:

import org.apache.commons.io.FilenameUtils;
 
 @GET
@@ -393,13 +393,13 @@ public Response getImage(@javax.ws.rs.PathParam("image") String image) {
     return Response.ok().entity(new FileInputStream(file)).build();
 }

-
+

-参考文献
-WASC: Path Traversal
-OWASP: Path Traversal
-CAPEC-126: Path Traversal
-CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') +参考文献
+WASC: Path Traversal
+OWASP: Path Traversal
+CAPEC-126: Path Traversal
+CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

]]>
@@ -409,20 +409,20 @@ public Response getImage(@javax.ws.rs.PathParam("image") String image) { 潜在的なパストラバーサル (ファイル書き込み) - メソッド {3} は，ユーザー入力によって指定された場所のファイルに書き込みます。 + API ({3}) は，ユーザー入力によって指定された場所のファイルに書き込みます。
内容を書くためにファイルが開かれています。ファイル名は 入力 パラメーターに由来しています。 フィルターされていないパラメーターがこのファイル API に渡されると，ファイルシステムの任意の場所からファイルを変更できるかもしれません。

このルールは 潜在的な パストラバーサルの脆弱性を特定します。多くの場合，構築されたファイルパスはユーザーが制御できません。 その場合，報告された事例は誤検出です。

-
+

-参考文献
-WASC-33: Path Traversal
-OWASP: Path Traversal
-CAPEC-126: Path Traversal
-CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') +参考文献
+WASC-33: Path Traversal
+OWASP: Path Traversal
+CAPEC-126: Path Traversal
+CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

]]>
@@ -431,31 +431,31 @@ public Response getImage(@javax.ws.rs.PathParam("image") String image) { - 潜在的なパストラバーサル (ファイル読み出し) - メソッド {3} は，ユーザー入力によって指定された場所のファイルを読み出します。 + Scala API を使用した潜在的なパストラバーサル (ファイル読み出し) + Scala API ({3}) は，ユーザー入力によって指定された場所のファイルを読み出します。
内容を読むためにファイルが開かれています。ファイル名は 入力 パラメーターに由来しています。 フィルターされていないパラメーターがこのファイル API に渡されると，ファイルシステムの任意の場所からファイルを読み出せるかもしれません。

このルールは 潜在的な パストラバーサルの脆弱性を特定します。多くの場合，構築されたファイルパスはユーザーが制御できません。 その場合，報告された事例は誤検出です。

-
+

- 脆弱なコード:
+ 脆弱なコード:

def getWordList(value:String) = Action {
   if (!Files.exists(Paths.get("public/lists/" + value))) {
     NotFound("File not found")
   } else {
-    val result = Source.fromFile("public/lists/" + value).getLines().mkString // Weak point
+    val result = Source.fromFile("public/lists/" + value).getLines().mkString // 弱点
     Ok(result)
   }
 }

-
+

- 解決策:
+ 解決策:

import org.apache.commons.io.FilenameUtils;
 
 def getWordList(value:String) = Action {
@@ -464,23 +464,23 @@ def getWordList(value:String) = Action {
   if (!Files.exists(Paths.get(filename))) {
     NotFound("File not found")
   } else {
-    val result = Source.fromFile(filename).getLines().mkString // Fix
+    val result = Source.fromFile(filename).getLines().mkString // 修正
     Ok(result)
   }
 }

-
+

-参考文献
-WASC: Path Traversal
-OWASP: Path Traversal
-CAPEC-126: Path Traversal
-CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') +参考文献
+WASC: Path Traversal
+OWASP: Path Traversal
+CAPEC-126: Path Traversal
+CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

]]>
- 潜在的なパストラバーサル (ファイル読み出し) + Scala API を使用した潜在的なパストラバーサル (ファイル読み出し) @@ -493,20 +493,20 @@ def getWordList(value:String) = Action {
強調表示された API は，システムコマンドを実行するために使用されています。 -フィルタリングされていない入力がこの API に渡されると，任意のコマンド実行につながる可能性があります。

-
+フィルタされていない入力がこの API に渡されると，任意のコマンド実行につながる可能性があります。

+

- 脆弱なコード:
+ 脆弱なコード:

import java.lang.Runtime;
 
 Runtime r = Runtime.getRuntime();
 r.exec("/bin/sh -c some_tool" + input);

-参考文献
-OWASP: Command Injection
-OWASP: Top 10 2013-A1-Injection
-CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') +参考文献
+OWASP: Command Injection
+OWASP: Top 10 2013-A1-Injection
+CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

]]>
@@ -520,20 +520,20 @@ r.exec("/bin/sh -c some_tool" + input);
強調表示された API は，システムコマンドを実行するために使用されています。 -フィルタリングされていない入力がこの API に渡されると，任意のコマンド実行につながる可能性があります。

-
+フィルタされていない入力がこの API に渡されると，任意のコマンド実行につながる可能性があります。

+

- 脆弱なコード:
+ 脆弱なコード:

def executeCommand(value:String) = Action {
     val result = value.!
     Ok("Result:\n"+result)
 }

-参考文献
-OWASP: Command Injection
-OWASP: Top 10 2013-A1-Injection
-CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') +参考文献
+OWASP: Command Injection
+OWASP: Top 10 2013-A1-Injection
+CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

]]>
@@ -550,23 +550,23 @@ r.exec("/bin/sh -c some_tool" + input); FilenameUtils.{3} は，NULL バイトをフィルタリングしません。
FilenameUtils のいくつかのメソッドは NULL バイト (0x00) をフィルターしません。

+

FilenameUtils' メソッドの中には，NULLバイト (0x00) をフィルタしないものもあります。

NULL バイトがファイル名に挿入され，そのファイル名が OS に渡されると取得されるファイルは NULL バイトより前に指定されたファイル名になります。 OS レベルであるので，たとえ Java 自体が NULLl バイトを気にしたり特別扱いをしなくても，すべての文字列が NULL バイトで終了するためです。 -この OS の動作は，ファイル名の検証を「ファイル名の末尾 (たとえば，末尾が ".log" であるか) を調べ，アクセスしても安全なファイルであるかを確認」といった具合にしていると回避されてしまうことがあります。

+この OS の動作は，ファイル名の検証を「ファイル名の末尾 (たとえば，末尾が ".log" であるか) を調べ，アクセスしても安全なファイルであるかを確認」といった具合にしていると回避されてしまうことがあります。

これを修正するためには，次の2つのことが推奨されています:

NULL バイトインジェクションの影響を受けない最新版の Java を使用していることがわかっているなら，このルールを無効にできます。

-
+

-参考文献
-WASC-28: Null Byte Injection
-CWE-158: Improper Neutralization of Null Byte or NUL Character +参考文献
+WASC-28: Null Byte Injection
+CWE-158: Improper Neutralization of Null Byte or NUL Character

]]>
@@ -590,19 +590,19 @@ OS レベルであるので，たとえ Java 自体が NULLl バイトを気に
空の TrustManager 実装は，多くの場合， -ルート 認証局 によって署名されていないホストに簡単に接続するために使用されます。 +ルート 認証局 によって署名されていないホストに簡単に接続するために使用されます。 結果として，クライアントがどの証明書も信頼してしまうので， -これは 中間者攻撃 (Man-in-the-middle attacks) に対して脆弱です。 +中間者攻撃 (Man-in-the-middle attacks) に対して脆弱です。

-(たとえば，truststore に基づいて) 特定の証明書を許可する TrustManager を構築すべきです。 +(たとえば，TrustStore に基づいて) 特定の証明書を許可する TrustManager を構築すべきです。 適切な実装の詳細については: -[1] -[2] +[1] +[2]

-
+

- 脆弱なコード:
+ 脆弱なコード:

class TrustAllManager implements X509TrustManager {
 
     @Override
@@ -621,9 +621,9 @@ OS レベルであるので，たとえ Java 自体が NULLl バイトを気に
     }
 }

-
+

- 解決策 (キーストアに基づく TrustMangager):
+ 解決策 (キーストアに基づく TrustMangager):

KeyStore ks = //Load keystore containing the certificates trusted
 
 SSLContext sc = SSLContext.getInstance("TLS");
@@ -634,11 +634,11 @@ tmf.init(ks);
 sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null);

-
+

-参考文献
-WASC-04: Insufficient Transport Layer Protection
-CWE-295: Improper Certificate Validation +参考文献
+WASC-04: Insufficient Transport Layer Protection
+CWE-295: Improper Certificate Validation

]]>
@@ -651,27 +651,27 @@ sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null);
任意のホストを受け入れる HostnameVerifier は，多くのホストで証明書を再利用するためによく使用されます。 -結果として，クライアントがどの証明書も信頼してしまうので，これは 中間者攻撃 (Man-in-the-middle attacks) に対して脆弱です。 +結果として，クライアントがどの証明書も信頼してしまうので，これは 中間者攻撃 (Man-in-the-middle attacks) に対して脆弱です。

-(たとえば，truststore に基づいて) 特定の証明書を許可する TrustManager を構築すべきです。 +(たとえば，TrustStore に基づいて) 特定の証明書を許可する TrustManager を構築すべきです。 複数のサブドメインで再利用するためのワイルドカード証明書を作成すべきです。 適切な実装の詳細については: -[1] -[2] +[1] +[2]

-
+

- 脆弱なコード:
+ 脆弱なコード:

public class AllHosts implements HostnameVerifier {
     public boolean verify(final String hostname, final SSLSession session) {
         return true;
     }
 }

-
+

- 解決策 (キーストアに基づく TrustMangager):
+ 解決策 (キーストアに基づく TrustMangager):

KeyStore ks = //Load keystore containing the certificates trusted
 
 SSLContext sc = SSLContext.getInstance("TLS");
@@ -682,16 +682,16 @@ tmf.init(ks);
 sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null);

-
+

-参考文献
-WASC-04: Insufficient Transport Layer Protection
-CWE-295: Improper Certificate Validation +参考文献
+WASC-04: Insufficient Transport Layer Protection
+CWE-295: Improper Certificate Validation

]]>
- 弱い TrustManager 実装 + 弱い HostVerifier 実装 @@ -707,19 +707,19 @@ sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null); このメソッドは，SOAP Web サービス (JSR224) の一部です。

-この Web サービスの安全性を分析する必要があります。たとえば: +この Web サービスの安全性を分析するべきです。たとえば:

    -
  • 認証を強制したときはテストすべきです。
    • -
  • アクセス制御を強制したときはテストすべきです。
    • -
  • 潜在的な脆弱性のために入力を追跡すべきです。
    • -
  • 通信は理想的には SSL の上で行うべきです。
    • +
  • 認証を強制したときはテストすべき
    • +
  • アクセス制御を強制したときはテストすべき
    • +
  • 潜在的な脆弱性のために入力を追跡すべき
    • +
  • 通信は理想的には SSL の上で行うべき

-
+

-参考文献
-OWASP: Web Service Security Cheat Sheet
-CWE-20: Improper Input Validation +参考文献
+OWASP: Web Service Security Cheat Sheet
+CWE-20: Improper Input Validation

]]> @@ -739,24 +739,24 @@ sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null); このメソッドは REST Web サービス (JSR311) の一部です。

-この Web サービスの安全性を分析する必要があります。たとえば: +この Web サービスの安全性を分析するべきです。たとえば:

    -
  • 認証を強制したときはテストすべきです。
    • -
  • アクセス制御を強制したときはテストすべきです。
    • -
  • 潜在的な脆弱性のために入力を追跡すべきです。
    • -
  • 通信は理想的には SSL の上で行うべきです。
    • -
  • サービスが書き込み (POSTなど) をサポートしているときは，CSRF に対する脆弱性を調査すべきです。
    • +
  • 認証を強制したときはテストすべき
    • +
  • アクセス制御を強制したときはテストすべき
    • +
  • 潜在的な脆弱性のために入力を追跡すべき
    • +
  • 通信は理想的には SSL の上で行うべき
    • +
  • サービスが書き込み (POSTなど) をサポートしているときは，CSRF に対する脆弱性を調査すべき

-
+

-参考文献
-OWASP: REST Assessment Cheat Sheet
-OWASP: REST Security Cheat Sheet
-OWASP: Web Service Security Cheat Sheet
-1. OWASP: Cross-Site Request Forgery
-OWASP: CSRF Prevention Cheat Sheet
-CWE-20: Improper Input Validation +参考文献
+OWASP: REST Assessment Cheat Sheet
+OWASP: REST Security Cheat Sheet
+OWASP: Web Service Security Cheat Sheet
+1. OWASP: Cross-Site Request Forgery
+OWASP: CSRF Prevention Cheat Sheet
+CWE-20: Improper Input Validation

]]> @@ -775,9 +775,9 @@ sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null);
アプリケーション起動時に Tapestry エンドポイントが検出されました。 -Tapestry アプリケーションは，各ページのバッキング Java クラスと対応する Tapestry マークアップ言語ページ (.tml ファイル) で構成されます。 +Tapestry アプリケーションは，各ページのバッキング Java クラスと対応する Tapestry マークアップ言語ページ (.tml ファイル) で構成されます。 リクエストが受信されると，GET/POST パラメーターはバッキング Java クラス内の特定の入力にマッピングされます。 -マッピングはいずれかで行われます。
フィールド名で:

+マッピングはいずれかで行われます。フィールド名で:


     [...]
     protected String input;
@@ -794,13 +794,13 @@ Tapestry アプリケーションは，各ページのバッキング Java ク
     private PasswordField passwordField;
     [...]
-

ページは，ビュー [/resources/package/PageName].tml にマッピングされます。

+

ページは，ビュー /resources/package/PageName.tml にマッピングされます。

このアプリケーションの各 Tapestry ページは，このように自動的にマッピングされるすべての入力が使用される前に適切に検証されているか調査すべきです。

-
+

-参考文献
-Apache Tapestry Home Page
-CWE-20: Improper Input Validation +参考文献
+Apache Tapestry Home Page
+CWE-20: Improper Input Validation

]]>
@@ -817,14 +817,14 @@ Tapestry アプリケーションは，各ページのバッキング Java ク {0} は Wicket WebPage です。
このクラスは，Wicket の WebPage を表します。入力はコンストラクターに渡された PageParameters インスタンスから自動的に読み出されます。 -現在のページは， ビュー [/package/WebPageName].html にマッピングされます。

+

このクラスは，Wicket WebPage を表します。入力はコンストラクターに渡された PageParameters インスタンスから自動的に読み出されます。 +現在のページは，ビュー /package/WebPageName.html にマッピングされます。

このアプリケーションの各 Wicket ページは，このように自動的にマッピングされるすべての入力を使用される前に適切に検証されているか調査すべきです。

-
+

-参考文献
-Apache Wicket Home Page
-CWE-20: Improper Input Validation +参考文献
+Apache Wicket Home Page
+CWE-20: Improper Input Validation

]]>
@@ -839,7 +839,7 @@ Tapestry アプリケーションは，各ページのバッキング Java ク MD2，MD4，MD5 は弱いハッシュ関数 - {3} は推奨される暗号化ハッシュ関数ではありません。 + API {3} (MDX) は推奨される暗号化ハッシュ関数ではありません。
アルゴリズム MD2，MD4，MD5 は推奨されているメッセージダイジェストではありません。 @@ -848,56 +848,56 @@ Tapestry アプリケーションは，各ページのバッキング Java ク
「MD5 ハッシュ関数のセキュリティは深刻に損なわれています。 2.6 GHz Pentium 4 プロセッサー (複雑さは 224.1) のコンピューターで数秒で衝突を見つけられる衝突攻撃が存在します。[1] - さらに，既製のコンピューティングハードウェア (複雑さは 239) を使用して，数時間以内に指定されたプレフィックスを持つ2つの入力の衝突を生成する選択プリフィックス衝突攻撃もあります。[2]」
+ さらに，既製のコンピューティングハードウェア (複雑さは 239) を使用して，数時間以内に指定されたプレフィックスを持つ2つの入力の衝突を生成する選択プリフィックス衝突攻撃もあります。[2]」
- Wikipedia: MD5 - Security
- 「SHA-224，SHA-256，SHA-384，SHA-512，SHA-512/224，SHA-512/256:
- これらのハッシュ関数の使用は，すべてのハッシュ関数アプリケーションで許容されています。」
- - NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15 + 「SHA-224，SHA-256，SHA-384，SHA-512，SHA-512/224，SHA-512/256:
+ これらのハッシュ関数の使用は，すべてのハッシュ関数アプリケーションで許容されています。」
+ - NIST: Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15
「PBKDF (Password-Based Key Derivation Function) の主な考え方は，各パスワードをテストするために必要な時間を増やすことによって，パスワードに対する辞書攻撃またはブルートフォース攻撃を遅延させることです。 もっともらしいパスワードのリストを持つ攻撃者は，既知の反復カウンタと salt を使用して PBKDF を評価できます。 - 攻撃者は試行ごとにかなりの計算時間を費やさなければならないので，辞書攻撃やブルートフォース攻撃を適用するのが難しくなります。」
-- NIST: Recommendation for Password-Based Key Derivation p.12 + 攻撃者は試行ごとにかなりの計算時間を費やさなければならないので，辞書攻撃やブルートフォース攻撃を適用するのが難しくなります。」
+- NIST: Recommendation for Password-Based Key Derivation p.12
-
+

- 脆弱なコード:
+ 脆弱なコード:

MessageDigest md5Digest = MessageDigest.getInstance("MD5");
     md5Digest.update(password.getBytes());
     byte[] hashValue = md5Digest.digest();
-
+ 
byte[] hashValue = DigestUtils.getMd5Digest().digest(password.getBytes());

-
+

- 解決策 (Bouncy Castle を使う):
+ 解決策 (Bouncy Castle を使う):

public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
     PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
     gen.init(password.getBytes("UTF-8"), salt.getBytes(), 4096);
     return ((KeyParameter) gen.generateDerivedParameters(256)).getKey();
 }
-
- 解決策 (Java 8 以降):
+
+ 解決策 (Java 8 以降):
public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
     KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 4096, 256 * 8);
     SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
     return f.generateSecret(spec).getEncoded();
 }

-
+

-参考文献
-[1] On Collisions for MD5: Master Thesis by M.M.J. Stevens
-[2] Chosen-prefix collisions for MD5 and applications: Paper written by Marc Stevens
-Wikipedia: MD5
-NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
-NIST: Recommendation for Password-Based Key Derivation
-Stackoverflow: Reliable implementation of PBKDF2-HMAC-SHA256 for Java
-CWE-327: Use of a Broken or Risky Cryptographic Algorithm +参考文献
+[1] On Collisions for MD5: Master Thesis by M.M.J. Stevens
+[2] Chosen-prefix collisions for MD5 and applications: Paper written by Marc Stevens
+Wikipedia: MD5
+NIST: Transitioning the Use of Cryptographic Algorithms and Key Lengths
+NIST: Recommendation for Password-Based Key Derivation
+Stackoverflow: Reliable implementation of PBKDF2-HMAC-SHA256 for Java
+CWE-327: Use of a Broken or Risky Cryptographic Algorithm

]]>
@@ -914,57 +914,57 @@ Tapestry アプリケーションは，各ページのバッキング Java ク PBKDF2 (Password-Based Key Derivation Function 2) は，たとえばパスワードをハッシュ化するために使用すべきです。

- 「デジタル署名生成用の SHA-1:
+ 「デジタル署名生成用の SHA-1:
SHA-1は，NIST プロトコル仕様ガイダンスで特に許可されているデジタル署名の生成にだけ使用できます。 - 他のすべてのアプリケーションでは，SHA-1 をデジタル署名の生成に使用してはいけません。
- デジタル署名検証用の SHA-1:
- デジタル署名検証では，SHA-1 は従来の使用が許可されています。
- [...]
- SHA-224，SHA-256，SHA-384，SHA-512，SHA-512/224，SHA-512/256:
- これらのハッシュ関数の使用は，すべてのハッシュ関数アプリケーションで許容されています。」
- - NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15 + 他のすべてのアプリケーションでは，SHA-1 をデジタル署名の生成に使用してはいけません。
+ デジタル署名検証用の SHA-1:
+ デジタル署名検証では，SHA-1 は従来の使用が許可されています。
+ [...]
+ SHA-224，SHA-256，SHA-384，SHA-512，SHA-512/224，SHA-512/256:
+ これらのハッシュ関数の使用は，すべてのハッシュ関数アプリケーションで許容されています。」
+ - NIST: Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15
「PBKDF (Password-Based Key Derivation Function) の主な考え方は，各パスワードをテストするために必要な時間を増やすことによって，パスワードに対する辞書攻撃またはブルートフォース攻撃を遅延させることです。 もっともらしいパスワードのリストを持つ攻撃者は，既知の反復カウンタと salt を使用して PBKDF を評価できます。 - 攻撃者は試行ごとにかなりの計算時間を費やさなければならないので，辞書攻撃やブルートフォース攻撃を適用するのが難しくなります。」
-- NIST: Recommendation for Password-Based Key Derivation p.12 + 攻撃者は試行ごとにかなりの計算時間を費やさなければならないので，辞書攻撃やブルートフォース攻撃を適用するのが難しくなります。」
+- NIST: Recommendation for Password-Based Key Derivation p.12
-
+

- 脆弱なコード:
+ 脆弱なコード:

MessageDigest sha1Digest = MessageDigest.getInstance("SHA1");
     sha1Digest.update(password.getBytes());
     byte[] hashValue = sha1Digest.digest();
-
+ 
byte[] hashValue = DigestUtils.getSha1Digest().digest(password.getBytes());

-
+

- 解決策 (Bouncy Castle を使う):
+ 解決策 (Bouncy Castle を使う):

public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
     PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
     gen.init(password.getBytes("UTF-8"), salt.getBytes(), 4096);
     return ((KeyParameter) gen.generateDerivedParameters(256)).getKey();
 }
-
- 解決策 (Java 8 以降):
+
+ 解決策 (Java 8 以降):
public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
     KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 4096, 256 * 8);
     SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
     return f.generateSecret(spec).getEncoded();
 }

-
+

-参考文献
-Qualys blog: SHA1 Deprecation: What You Need to Know
-Google Online Security Blog: Gradually sunsetting SHA-1
-NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
-NIST: Recommendation for Password-Based Key Derivation
-Stackoverflow: Reliable implementation of PBKDF2-HMAC-SHA256 for Java
-CWE-327: Use of a Broken or Risky Cryptographic Algorithm +参考文献
+Qualys blog: SHA1 Deprecation: What You Need to Know
+Google Online Security Blog: Gradually sunsetting SHA-1
+NIST: Transitioning the Use of Cryptographic Algorithms and Key Lengths
+NIST: Recommendation for Password-Based Key Derivation
+Stackoverflow: Reliable implementation of PBKDF2-HMAC-SHA256 for Java
+CWE-327: Use of a Broken or Risky Cryptographic Algorithm

]]> @@ -983,45 +983,37 @@ Tapestry アプリケーションは，各ページのバッキング Java ク
- 脆弱なコード:
-
-    HttpClient client = new DefaultHttpClient();
-
+ 脆弱なコード:
+
HttpClient client = new DefaultHttpClient();

-

解決策:
-推奨構成の1つを使用して，https.protocols JVM オプションを TLSv1.2 を含むように設定して，実装を改良します:

+

解決策:
+推奨構成の1つを使用して，https.protocols JVM オプションを TLSv1.2 を含むように設定して，実装を改良します:

    -
  • 代わりに SystemDefaultHttpClient を使用します。
    • +
  • 代わりに SystemDefaultHttpClient を使用する

    • - サンプルコード:
    -

    -    HttpClient client = new SystemDefaultHttpClient();
-
    + サンプルコード:
    +
    HttpClient client = new SystemDefaultHttpClient();

    -
  • SSLSocketFactory に基づいて HttpClient を作成します - getSystemSocketFactory() で SSLSocketFactory のインスタンスを取得して，HttpClient の作成に使用します。
    • -
  • SSLConnectionSocketFactory に基づいて HttpClient を作成する - getSystemSocketFactory() でインスタンスを取得して，HttpClient の作成に使用します。
    • -
  • HttpClientBuilder を使用します - build() を呼び出す前に useSystemProperties() を呼び出します。
    • +
  • SSLSocketFactory に基づいて HttpClient を作成する - getSystemSocketFactory() で SSLSocketFactory のインスタンスを取得して，HttpClient の作成に使用する
    • +
  • SSLConnectionSocketFactory に基づいて HttpClient を作成する - getSystemSocketFactory() でインスタンスを取得して，HttpClient の作成に使用する
    • +
  • HttpClientBuilder を使用する - build() を呼び出す前に useSystemProperties() を呼び出す

    • - サンプルコード:
    -

    -    HttpClient client = HttpClientBuilder.create().useSystemProperties().build();
-
    + サンプルコード:
    +
    HttpClient client = HttpClientBuilder.create().useSystemProperties().build();

    -
  • HttpClients - createSystem() を呼び出してインスタンスを作成します。
    • +
  • HttpClients - createSystem() を呼び出してインスタンスを作成する

    • - サンプルコード:
    -

    -    HttpClient client = HttpClients.createSystem();
-
    + サンプルコード:
    +
    HttpClient client = HttpClients.createSystem();

-
+

-参考文献
+参考文献
Diagnosing TLS, SSL, and HTTPS

]]> @@ -1035,23 +1027,20 @@ Tapestry アプリケーションは，各ページのバッキング Java ク
- 脆弱なコード:
-
-    SSLContext.getInstance("SSL");
-
+ 脆弱なコード:
+ + 
SSLContext.getInstance("SSL");

-

解決策:
+

解決策:
-https.protocols JVM オプションを TLSv1.2を含むように設定して，実装を改良します:

-
-    SSLContext.getInstance("TLS");
-
+https.protocols JVM オプションを TLSv1.2を含むように設定して，実装を改良します:

+
SSLContext.getInstance("TLS");

-
+

-参考文献
+参考文献
Diagnosing TLS, SSL, and HTTPS

]]> @@ -1065,25 +1054,25 @@ https.protocols JVM オプションを TLSv1.2を含むように設定して， - メッセージダイジェストが独自 + 独自メッセージダイジェスト {0} は独自暗号化ハッシュ関数の実装です。
独自メッセージダイジェストの実装は間違いの元になりやすいです

-

NIST は，SHA-224，SHA-256，SHA-384，SHA-512，SHA-512/224，SHA-512/256 の使用を推奨しています。

+

独自メッセージダイジェストの実装は間違いの元になりやすいです。

+

NIST は，SHA-224，SHA-256，SHA-384，SHA-512，SHA-512/224，SHA-512/256 の使用を推奨しています。

- 「デジタル署名生成用の SHA-1:
+ 「デジタル署名生成用の SHA-1:
SHA-1は，NIST プロトコル仕様ガイダンスで特に許可されているデジタル署名の生成にだけ使用できます。 - 他のすべてのアプリケーションでは，SHA-1 をデジタル署名の生成に使用してはいけません。
- デジタル署名検証用の SHA-1:
- デジタル署名検証では，SHA-1 は従来の使用が許可されています。
- [...]
- SHA-224，SHA-256，SHA-384，SHA-512，SHA-512/224，SHA-512/256:
- これらのハッシュ関数の使用は，すべてのハッシュ関数アプリケーションで許容されています。」
- - NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15 + 他のすべてのアプリケーションでは，SHA-1 をデジタル署名の生成に使用してはいけません。
+ デジタル署名検証用の SHA-1:
+ デジタル署名検証では，SHA-1 は従来の使用が許可されています。
+ [...]
+ SHA-224，SHA-256，SHA-384，SHA-512，SHA-512/224，SHA-512/256:
+ これらのハッシュ関数の使用は，すべてのハッシュ関数アプリケーションで許容されています。」
+ - NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15

- 脆弱なコード:
+ 脆弱なコード:

MyProprietaryMessageDigest extends MessageDigest {
     @Override
     protected byte[] engineDigest() {
@@ -1096,25 +1085,25 @@ https.protocols JVM オプションを TLSv1.2を含むように設定して，
 

 
承認されたアルゴリズムの1つを使用するように実装を改良します。セキュリティニーズを満たす十分に強いアルゴリズムを使用します。

 

-    解決例:

+    解決例:

 
MessageDigest sha256Digest = MessageDigest.getInstance("SHA256");
 sha256Digest.update(password.getBytes());

 

-

+

 

-参考文献

-NIST Approved Hashing Algorithms

-CWE-327: Use of a Broken or Risky Cryptographic Algorithm
+参考文献

+NIST Approved Hash Functions

+CWE-327: Use of a Broken or Risky Cryptographic Algorithm
 

 ]]>
- メッセージダイジェストが独自 + 独自メッセージダイジェスト -
ファイルアップロード API によって与えられたファイル名は，クライアントによって改ざんされる可能性があります。
+
FileUpload API によって与えられたファイル名は，クライアントによって改ざんされる可能性があります。
 @@ -1122,7 +1111,7 @@ sha256Digest.update(password.getBytes()); 読み取られたファイル名は，クライアントによって改ざんされている可能性があります。
ファイルアップロード API によって与えられたファイル名は，権限のないファイルを参照するためにクライアントによって改ざんされる可能性があります。

+

FileUpload API によって与えられたファイル名は，権限のないファイルを参照するためにクライアントによって改ざんされる可能性があります。

たとえば:

  • "../../../config/overide_file"
    • @@ -1130,15 +1119,15 @@ sha256Digest.update(password.getBytes());

したがって，そのような値を直接ファイルシステム API に渡すべきではありません。可能であれば，アプリケーションは独自のファイル名を生成して使用すべきです。 そうでなければ与えられたファイル名を「不正なパス文字 (たとえば/ \) が含まれていない」や「許可されたファイルを参照している」というように，正しく構成されているか検証すべきです。

-
+

-参考文献
-Securiteam: File upload security recommendations
-CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
-WASC-33: Path Traversal
-OWASP: Path Traversal
-CAPEC-126: Path Traversal
-CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') +参考文献
+Securiteam: File upload security recommendations
+CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
+WASC-33: Path Traversal
+OWASP: Path Traversal
+CAPEC-126: Path Traversal
+CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

]]>
@@ -1157,24 +1146,24 @@ sha256Digest.update(password.getBytes());
-正規表現 (regexs) は，DoS攻撃 (ReDoS と呼ばれる) の対象となることがよくあります。 +正規表現 (Regex) は，DoS攻撃 (ReDoS と呼ばれる) の対象となることがよくあります。 これは，正規表現がどのように定義されているかに応じて，正規表現エンジンが特定の文字列を解析するときに長い時間がかかることが原因です。

-たとえば， 次の正規表現の場合: ^(a+)+$，"aaaaaaaaaaaaaaaaX" を入力すると正規表現エンジンは 65536 通りの異なるパスを解析します。 +たとえば，次の正規表現の場合: ^(a+)+$，"aaaaaaaaaaaaaaaaX" を入力すると正規表現エンジンは 65536 通りの異なるパスを解析します。 [1] OWASP リファレンスから抜粋した例

したがって，1回のリクエストでサーバー側で大量の計算が発生する可能性があります。 -この正規表現 (およびその他同様のもの) に関連する問題は，括弧の内側にある + (または *) と括弧の外側にある + (または *) によって，同じ入力文字を2つの異なる方法で受け入れられるということです。 -この書き方は，どちらの + でも文字 'a' を消費します。これを修正するためには，曖昧さを取り除くために正規表現を書き直す必要があります。 -例えば，^a+$ のようにたやすく書き直すことができます。それは，おそらく作者の意図していることです (a がいくつあっても)。 +この正規表現 (およびその他同様のもの) に関連する問題は，括弧の内側にある + (または *) と括弧の外側にある + (または *) によって，同じ入力文字を2つの異なる方法で受け入れられるということです。 +この書き方は，どちらの + でも文字 'a' を消費します。これを修正するには，曖昧さを解消するように正規表現を書き直すべきです。 +たとえば，^a+$ のようにたやすく書き直すことができます。それは，おそらく作者の意図していることです (a がいくつあっても)。 これが元の正規表現を意図しているなら，この新しい正規表現はすぐに評価されるので，ReDoS の対象とはなりません。

-
+

-参考文献
-Sebastian Kubeck's Weblog: Detecting and Preventing ReDoS Vulnerabilities
-[1] OWASP: Regular expression Denial of Service
-CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion') +参考文献
+Sebastian Kubeck's Weblog: Detecting and Preventing ReDoS Vulnerabilities
+[1] OWASP: Regular expression Denial of Service
+CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')

]]>
@@ -1183,7 +1172,7 @@ sha256Digest.update(password.getBytes()); -
XML 外部エンティティ (XXE:XML External Entities) 攻撃に脆弱な XMLStreamReader の使用を特定します。
+
XML 外部エンティティ (XXE:XML External Entity) 攻撃に脆弱な XMLStreamReader の使用を特定します。
 @@ -1193,8 +1182,8 @@ sha256Digest.update(password.getBytes());

攻撃

-

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XML 外部エンティティ (XXE:XML External Entities) 攻撃が発生する可能性があります。

-

リスク 1: ローカルファイルの内容の暴露 (XXE: XML eXternal Entity)

+

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XML 外部エンティティ (XXE:XML External Entity) 攻撃が発生する可能性があります。

+

リスク 1: ローカルファイルの内容の暴露 (XXE: XML External Entity)

 <?xml version="1.0" encoding="ISO-8859-1"?>
@@ -1202,7 +1191,7 @@ sha256Digest.update(password.getBytes());
<!ENTITY xxe SYSTEM "file:///etc/passwd" > ]> <foo>&xxe;</foo>

-リスク 2: サービス拒否 (XEE: Xml Entity Expansion) +リスク 2: サービス拒否 (XEE: XML Entity Expansion) 

 <?xml version="1.0"?>
@@ -1233,9 +1222,9 @@ XML パーサーの危険な機能が公開されないようにするために
     [...]
 }

-
+

-次のスニペットでは，利用可能な2つの解決策を示しています。1つまはた両方のプロパティーを設定できます。 +次のスニペットでは，利用可能な2つの解決策を示しています。1つまたは両方の機能を設定します。

外部エンティティーを無効にする解決策:

@@ -1259,19 +1248,19 @@ XML パーサーの危険な機能が公開されないようにするために [...] }

-
+

-参考文献
+参考文献
-CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
-CERT: IDS10-J. Prevent XML external entity attacks
-OWASP.org: XML External Entity (XXE) Processing
-WS-Attacks.org: XML Entity Expansion
-WS-Attacks.org: XML External Entity DOS
-WS-Attacks.org: XML Entity Reference Attack
-Identifying Xml eXternal Entity vulnerability (XXE)
+CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
+CERT: IDS10-J. Prevent XML external entity attacks
+OWASP.org: XML External Entity (XXE) Processing
+WS-Attacks.org: XML Entity Expansion
+WS-Attacks.org: XML External Entity DOS
+WS-Attacks.org: XML Entity Reference Attack
+Identifying XML External Entity vulnerability (XXE)
-JEP 185: Restrict Fetching of External XML Resources +JEP 185: Restrict Fetching of External XML Resources

]]>
@@ -1280,17 +1269,114 @@ XML パーサーの危険な機能が公開されないようにするために -
XML 外部エンティティ (XXE:XML External Entities) 攻撃に脆弱な XML パーサーの使用を特定します。
+
XML 外部エンティティ (XXE:XML External Entity) 攻撃に脆弱な XML パーサーの使用を特定します。
 + + XXE に脆弱な XML 解析 (XPathExpression) + {3} (XPath API) の使用は，XXE 攻撃に対して脆弱です。 +
+ +

攻撃

+

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XXE (XML External Entity) 攻撃が発生する可能性があります。

+

リスク 1: ローカルファイルの内容の暴露 (XXE: XML External Entity)

+

+

+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE foo [
+   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
+<foo>&xxe;</foo>
+

+リスク 2: サービス拒否 (XEE: XML Entity Expansion) +

+

+<?xml version="1.0"?>
+<!DOCTYPE lolz [
+ <!ENTITY lol "lol">
+ <!ELEMENT lolz (#PCDATA)>
+ <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
+ <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
+ <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
+[...]
+ <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
+]>
+<lolz>&lol9;</lolz>
+

+ +

解決策

+

+XML パーサーの危険な機能が公開されないようにするためには，コードを次のように変更します。 +

+ + +

脆弱なコード:

+

+

DocumentBuilder builder = df.newDocumentBuilder();
+
+XPathFactory xPathFactory = XPathFactory.newInstance();
+XPath xpath = xPathFactory.newXPath();
+XPathExpression xPathExpr = xpath.compile("/somepath/text()");
+
+xPathExpr.evaluate(new InputSource(inputStream));
+

+
+

+次のスニペットでは，利用可能な2つの解決策を示しています。1つまたは両方の機能を設定します。 +

+ +

"Secure processing" モードを使用した解決策:

+

+この設定により，サービス拒否攻撃とリモートファイルアクセスから保護されます。 +

+DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
+df.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
+DocumentBuilder builder = df.newDocumentBuilder();
+
+[...]
+
+xPathExpr.evaluate( builder.parse(inputStream) );
+

+ +

DTD を無効にする解決策:

+

+DTD を無効にすることによって，ほとんどすべての XXE 攻撃 が防止されます。 +

+DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
+spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
+DocumentBuilder builder = df.newDocumentBuilder();
+
+[...]
+
+xPathExpr.evaluate( builder.parse(inputStream) );
+

+
+

+参考文献
+ +CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
+CERT: IDS10-J. Prevent XML external entity attacks
+OWASP.org: XML External Entity (XXE) Processing
+WS-Attacks.org: XML Entity Expansion
+WS-Attacks.org: XML External Entity DOS
+WS-Attacks.org: XML Entity Reference Attack
+Identifying XML External Entity vulnerability (XXE)
+ +XML External Entity (XXE) Prevention Cheat Sheet +

+]]> +
+ + XPathExpression を使用した XXE 脆弱性 + XXE に脆弱な XML 解析 (SAXParser) - {3} の使用は，XXE 攻撃に対して脆弱です。 + {3} (SAXParser) の使用は，XXE 攻撃に対して脆弱です。

攻撃

-

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XML 外部エンティティ (XXE:XML External Entities) 攻撃が発生する可能性があります。

+

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XML 外部エンティティ (XXE:XML External Entity) 攻撃が発生する可能性があります。

リスク 1: ローカルファイルの内容の暴露 (XXE: XML eXternal Entity)

@@ -1328,9 +1414,9 @@ SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
 
 parser.parse(inputStream, customHandler);

-
+

-次のスニペットでは，利用可能な2つの解決策を示しています。1つまはた両方のプロパティーを設定できます。 +次のスニペットでは，利用可能な2つの解決策を示しています。1つまたは両方の機能を設定します。

"Secure processing" モードを使用した解決策:

@@ -1354,33 +1440,33 @@ SAXParser parser = spf.newSAXParser(); parser.parse(inputStream, customHandler);

-
+

-参考文献
+参考文献
-CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
-CERT: IDS10-J. Prevent XML external entity attacks
-OWASP.org: XML External Entity (XXE) Processing
-WS-Attacks.org: XML Entity Expansion
-WS-Attacks.org: XML External Entity DOS
-WS-Attacks.org: XML Entity Reference Attack
-Identifying Xml eXternal Entity vulnerability (XXE)
+CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
+CERT: IDS10-J. Prevent XML external entity attacks
+OWASP.org: XML External Entity (XXE) Processing
+WS-Attacks.org: XML Entity Expansion
+WS-Attacks.org: XML External Entity DOS
+WS-Attacks.org: XML Entity Reference Attack
+Identifying XML External Entity vulnerability (XXE)
-Xerces complete features list +Xerces complete features list

]]>
- SAXParser を使用した XXE の脆弱性 + SAXParser を使用した XXE 脆弱性 XXE に脆弱な XML 解析 (XMLReader) - {3} の使用は，XXE 攻撃に対して脆弱です。 + {3} (XMLReader) の使用は，XXE 攻撃に対して脆弱です。

攻撃

-

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XML 外部エンティティ (XXE:XML External Entities) 攻撃が発生する可能性があります。

+

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XML 外部エンティティ (XXE:XML External Entity) 攻撃が発生する可能性があります。

リスク 1: ローカルファイルの内容の暴露 (XXE: XML eXternal Entity)

@@ -1405,7 +1491,7 @@ parser.parse(inputStream, customHandler);
<lolz>&lol9;</lolz>

-

Solution

+

解決策

XML パーサーの危険な機能が公開されないようにするためには，コードを次のように変更します。

@@ -1418,9 +1504,9 @@ XMLReader reader = XMLReaderFactory.createXMLReader(); reader.setContentHandler(customHandler); reader.parse(new InputSource(inputStream));

-
+

-次のスニペットでは，利用可能な2つの解決策を示しています。1つまはた両方のプロパティーを設定できます。 +次のスニペットでは，利用可能な2つの解決策を示しています。1つまたは両方の機能を設定します。

"Secure processing" モードを使用した解決策:

@@ -1444,33 +1530,33 @@ reader.setContentHandler(customHandler); reader.parse(new InputSource(inputStream));

-
+

-参考文献
+参考文献
-CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
-CERT: IDS10-J. Prevent XML external entity attacks
-OWASP.org: XML External Entity (XXE) Processing
-WS-Attacks.org: XML Entity Expansion
-WS-Attacks.org: XML External Entity DOS
-WS-Attacks.org: XML Entity Reference Attack
-Identifying Xml eXternal Entity vulnerability (XXE)
+CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
+CERT: IDS10-J. Prevent XML external entity attacks
+OWASP.org: XML External Entity (XXE) Processing
+WS-Attacks.org: XML Entity Expansion
+WS-Attacks.org: XML External Entity DOS
+WS-Attacks.org: XML Entity Reference Attack
+Identifying XML External Entity vulnerability (XXE)
-Xerces complete features list +Xerces complete features list

]]>
- XMLReader を使用した XXE の脆弱性 + XMLReader を使用した XXE 脆弱性 XXE に脆弱な XML 解析 (DocumentBuilder) - {3} の使用は，XXE 攻撃に対して脆弱です。 + {3} (DocumentBuilder) の使用は，XXE 攻撃に対して脆弱です。

攻撃

-

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XML 外部エンティティ (XXE:XML External Entities) 攻撃が発生する可能性があります。

+

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XML 外部エンティティ (XXE:XML External Entity) 攻撃が発生する可能性があります。

リスク 1: ローカルファイルの内容の暴露 (XXE: XML eXternal Entity)

@@ -1495,7 +1581,7 @@ reader.parse(new InputSource(inputStream));
<lolz>&lol9;</lolz>

-

Solution

+

解決策

XML パーサーの危険な機能が公開されないようにするためには，コードを次のように変更します。

@@ -1508,9 +1594,9 @@ DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder(); Document doc = db.parse(input);

-
+

-次のスニペットでは，利用可能な2つの解決策を示しています。1つまはた両方のプロパティーを設定できます。 +次のスニペットでは，利用可能な2つの解決策を示しています。1つまたは両方の機能を設定します。

"Secure processing" モードを使用した解決策:

@@ -1534,28 +1620,204 @@ DocumentBuilder db = dbf.newDocumentBuilder(); Document doc = db.parse(input);

-
+

-参考文献
+参考文献
-CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
-CERT: IDS10-J. Prevent XML external entity attacks
-OWASP.org: XML External Entity (XXE) Processing
-WS-Attacks.org: XML Entity Expansion
-WS-Attacks.org: XML External Entity DOS
-WS-Attacks.org: XML Entity Reference Attack
-Identifying Xml eXternal Entity vulnerability (XXE)
+CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
+CERT: IDS10-J. Prevent XML external entity attacks
+OWASP.org: XML External Entity (XXE) Processing
+WS-Attacks.org: XML Entity Expansion
+WS-Attacks.org: XML External Entity DOS
+WS-Attacks.org: XML Entity Reference Attack
+Identifying XML External Entity vulnerability (XXE)
Xerces2 complete features list

]]>
- DocumentBuilder を使用した XXE の脆弱性 + DocumentBuilder を使用した XXE 脆弱性 + + + +
XML 外部エンティティ (XXE:XML External Entity) 攻撃に脆弱な TransformerFactory XML パーサーの使用を特定します。
+ + + + XXE に脆弱な XML 解析 (TransformerFactory) + {3} (TransformerFactory) の使用は，XXE 攻撃に対して脆弱です。 +
+ +

攻撃

+

信頼されていないソースから受け取った XML を処理しているときに，XML パーサーが XML エンティティをサポートしていると XXE (XML External Entity) 攻撃が発生する可能性があります。

+

リスク 1: ローカルファイルの内容の暴露 (XXE: XML External Entity)

+

+

+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE foo [
+   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
+<foo>&xxe;</foo>
+

+リスク 2: サービス拒否 (XEE: XML Entity Expansion) +

+

+<?xml version="1.0"?>
+<!DOCTYPE lolz [
+ <!ENTITY lol "lol">
+ <!ELEMENT lolz (#PCDATA)>
+ <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
+ <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
+ <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
+[...]
+ <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
+]>
+<lolz>&lol9;</lolz>
+

+ +

解決策

+

+XML パーサーの危険な機能が公開されないようにするためには，コードを次のように変更します。 +

+ + +

脆弱なコード:

+

+

+Transformer transformer = TransformerFactory.newInstance().newTransformer();
+transformer.transform(input, result);
+

+
+

+次のスニペットでは，利用可能な2つの解決策を示しています。1つまたは両方の機能を設定します。 +

+ +

"Secure processing" モードを使用した解決策:

+

+This setting will protect you against remote file access but not denial of service. +

+TransformerFactory factory = TransformerFactory.newInstance();
+factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "all");
+factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "all");
+
+Transformer transformer = factory.newTransformer();
+transformer.setOutputProperty(OutputKeys.INDENT, "yes");
+
+transformer.transform(input, result);
+

+ +

DTD を無効にする解決策:

+

+This setting will protect you against remote file access but not denial of service. +

+TransformerFactory factory = TransformerFactory.newInstance();
+factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
+
+Transformer transformer = factory.newTransformer();
+transformer.setOutputProperty(OutputKeys.INDENT, "yes");
+
+transformer.transform(input, result);
+

+
+

+参考文献
+ +CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
+CERT: IDS10-J. Prevent XML external entity attacks
+OWASP.org: XML External Entity (XXE) Processing
+WS-Attacks.org: XML Entity Expansion
+WS-Attacks.org: XML External Entity DOS
+WS-Attacks.org: XML Entity Reference Attack
+Identifying XML External Entity vulnerability (XXE)
+ +

+]]> +
+ + TransformerFactory を使用した XXE 脆弱性 + + + XXE に脆弱な XSLT 解析 (TransformerFactory) + {3} の使用は XXE 攻撃に対して脆弱です。 +
+ +

攻撃

+

信頼されていないソースから受け取った XSLT を処理しているときに，XSLT パーサーが 外部エンティティをサポートしていると XXE (XSLT External Entity) 攻撃が発生する可能性があります。

+

リスク: ローカルファイルの内容の暴露 (XXE: XML External Entity)

+

+

+<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+   <xsl:template match="/">
+       <xsl:value-of select="document('/etc/passwd')">
+   </xsl:value-of></xsl:template>
+</xsl:stylesheet>
+

+ +

解決策

+

+XML パーサーの危険な機能が公開されないようにするためには，コードを次のように変更します。 +

+ + +

脆弱なコード:

+

+

+Transformer transformer = TransformerFactory.newInstance().newTransformer();
+transformer.transform(input, result);
+

+
+

+次のスニペットでは，利用可能な2つの解決策を示しています。1つまたは両方の機能を設定します。 +

+

"Secure processing" モードを使用した解決策:

+

+この設定により，リモートファイルアクセスから保護されますが，サービス拒否は保護されません。 +

+TransformerFactory factory = TransformerFactory.newInstance();
+factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "all");
+factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "all");
+
+Transformer transformer = factory.newTransformer();
+transformer.setOutputProperty(OutputKeys.INDENT, "yes");
+
+transformer.transform(input, result);
+

+ +

DTD を無効にする解決策:

+

+この設定により，リモートファイルアクセスから保護されますが，サービス拒否は保護されません。 +

+TransformerFactory factory = TransformerFactory.newInstance();
+factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
+
+Transformer transformer = factory.newTransformer();
+transformer.setOutputProperty(OutputKeys.INDENT, "yes");
+
+transformer.transform(input, result);
+

+
+

+参考文献
+ +CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
+CERT: IDS10-J. Prevent XML external entity attacks
+OWASP.org: XML External Entity (XXE) Processing
+WS-Attacks.org: XML Entity Expansion
+WS-Attacks.org: XML External Entity DOS
+WS-Attacks.org: XML Entity Reference Attack
+Identifying XML External Entity vulnerability (XXE)
+ +

+]]> +
+ + TransformerFactory の XSLT を使用した XXE 脆弱性 -
汚染された入力を使用する XPath クエリを発見します。
+
汚染された入力を使用する XPath クエリーを発見します。
 @@ -1565,17 +1827,17 @@ Document doc = db.parse(input); XPath インジェクションのリスクは，SQL インジェクションに似ています。XPath クエリーに信頼できないユーザー入力が含まれていると，完全なデータソースが暴露される可能性があります。 -これにより，攻撃者は権限のないデータにアクセスしたり，標的の XML を悪意をもって改ざんする可能性があります。 +これにより，攻撃者は権限のないデータにアクセスしたり，標的の XML を悪意をもって改ざんできます。

-
+

-参考文献
-WASC-39: XPath Injection
-OWASP: Top 10 2013-A1-Injection
-CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')
-CERT: IDS09-J. Prevent XPath Injection (archive)
-Black Hat Europe 2012: Hacking XPath 2.0
-Balisage: XQuery Injection +参考文献
+WASC-39: XPath Injection
+OWASP: Top 10 2013-A1-Injection
+CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')
+CERT: IDS09-J. Prevent XPath Injection (archive)
+Black Hat Europe 2012: Hacking XPath 2.0
+Balisage.net: XQuery Injection

]]>
@@ -1609,7 +1871,7 @@ XPath インジェクションのリスクは，SQL インジェクションに {0} は Struts 2 のエンドポイントです。
Struts 2 では，エンドポイントは Plain Old Java Object (POJO) です。つまり，インターフェース/クラスを実装/継承する必要がないということです。

+

Struts 2 では，エンドポイントは Plain Old Java Objects (POJO) です。つまり，インタフェース/クラスを実装/継承する必要がないということです。

リクエストがそのコントローラー (選択されたクラス) にルーティングされると与えられた HTTP パラメーターが自動的にクラスのセッターにマッピングされます。 そのため，フォームにそれらの値が含まれていなくても，このクラスのすべてのセッターは信頼できない入力として見なすべきです。 オブジェクトにそのようなセッターがあるかぎり，攻撃者はリクエストに追加の値を与えるだけで，オブジェクトに設定できます。 @@ -1632,7 +1894,7 @@ XPath インジェクションのリスクは，SQL インジェクションに

このクラスは Spring コントローラーです。 RequestMapping (そのショートカットアノテーション GetMapping，PostMapping，PutMapping， DeleteMapping，PatchMapping) というアノテーションが付けられたすべてのメソッドは，リモートから到達可能です。 -リモートに公開したメソッドが潜在的な攻撃者に公開しても安全であるかを確認するために，このクラスを分析する必要があります。

+リモートに公開したメソッドが潜在的な攻撃者に公開しても安全であるかを確認するために，このクラスを分析するべきです。

]]>
@@ -1650,9 +1912,9 @@ XPath インジェクションのリスクは，SQL インジェクションに
Spring Security の CSRF 保護を無効にすることは，標準の Web アプリケーションでは安全ではありません。

-

この保護を無効にすることが有効なユースケースは，ブラウザ以外のクライアントによってだけ使用されることが保証されている状態変更操作を公開するサービスです。

+

この保護を無効にすることが有効なユースケースは，ブラウザー以外のクライアントによってだけ使用されることが保証されている状態変更操作を公開するサービスです。

- 安全でない設定:
+ 安全でない設定:

@EnableWebSecurity
 public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
 
@@ -1663,10 +1925,10 @@ public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
 }

-参考文献
-Spring Security Official Documentation: When to use CSRF protection
-OWASP: Cross-Site Request Forgery
-OWASP: CSRF Prevention Cheat Sheet
+参考文献
+Spring Security Official Documentation: When to use CSRF protection
+OWASP: Cross-Site Request Forgery
+OWASP: CSRF Prevention Cheat Sheet
CWE-352: Cross-Site Request Forgery (CSRF)

]]> @@ -1691,18 +1953,18 @@ public class WebSecurityConfig extends WebSecurityConfigurerAdapter { したがって，RequestMapping でアノテーションされ，マッピングを絞り込まない状態変更メソッド POST，PUT，DELETE，PATCH は CSRF 攻撃に対して脆弱です。

- 脆弱なコード:
+ 脆弱なコード:

@Controller
 public class UnsafeController {
 
     @RequestMapping("/path")
     public void writeData() {
-        // State-changing operations performed within this method.
+        // このメソッド内で実行される状態変更操作
     }
 }

- 解決策 (Spring Framework 4.3 以降):
+ 解決策 (Spring Framework 4.3 以降):

@Controller
 public class SafeController {
 
@@ -1711,7 +1973,7 @@ public class SafeController {
      */
     @GetMapping("/path")
     public String readData() {
-        // No state-changing operations performed within this method.
+        // このメソッド内で状態変更操作は実行されない
         return "";
     }
 
@@ -1720,12 +1982,12 @@ public class SafeController {
      */
     @PostMapping("/path")
     public void writeData() {
-        // State-changing operations performed within this method.
+        // このメソッド内で実行される状態変更操作
     }
 }

- 解決策 (Spring Framework 4.3 以前):
+ 解決策 (Spring Framework 4.3 以前):

@Controller
 public class SafeController {
 
@@ -1735,7 +1997,7 @@ public class SafeController {
      */
     @RequestMapping(value = "/path", method = RequestMethod.GET)
     public String readData() {
-        // No state-changing operations performed within this method.
+        // このメソッド内で状態変更操作は実行されない
         return "";
     }
 
@@ -1745,15 +2007,15 @@ public class SafeController {
      */
     @RequestMapping(value = "/path", method = RequestMethod.POST)
     public void writeData() {
-        // State-changing operations performed within this method.
+        // このメソッド内で実行される状態変更操作
     }
 }

-参考文献
-Spring Security Official Documentation: Use proper HTTP verbs (CSRF protection)
-OWASP: Cross-Site Request Forgery
-OWASP: CSRF Prevention Cheat Sheet
+参考文献
+Spring Security Official Documentation: Use proper HTTP verbs (CSRF protection)
+OWASP: Cross-Site Request Forgery
+OWASP: CSRF Prevention Cheat Sheet
CWE-352: Cross-Site Request Forgery (CSRF)

]]> @@ -1764,7 +2026,7 @@ public class SafeController { -
独自メソッドに対するインジェクションを発見するディテクタです。
+
独自メソッドに対するインジェクションを発見するディテクターです。
 @@ -1773,24 +2035,24 @@ public class SafeController {
-特定されたメソッドはインジェクションの影響を受けやすいです。入力を検証して，適切にエスケープする必要があります。 +特定されたメソッドはインジェクションの影響を受けやすいです。入力を検証して，適切にエスケープするべきです。

- 脆弱なコード:
+ 脆弱なコード:

SqlUtil.execQuery("select * from UserEntity t where id = " + parameterInput);

-カスタムシグネチャを設定する方法 の詳細については，オンラインウィキを参照してください。 +カスタムシグネチャを設定する方法 の詳細な手順についてはオンライン wiki を参照してください。

-参考文献
-WASC-19: SQL Injection
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') +参考文献
+WASC-19: SQL Injection
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

]]>
@@ -1812,16 +2074,16 @@ public class SafeController { SQL クエリーに含まれる入力値は安全に渡す必要があります。プリペアードステートメントのバインド変数を使用すると SQL インジェクションのリスクを容易に軽減できます。 -プリペアードステートメントの代わりに，各パラメーターを手動でエスケープすることもできます。 +プリペアードステートメントの代わりに各パラメーターを手動でエスケープすることもできます。

- 脆弱なコード:
+ 脆弱なコード:

 createQuery("select * from User where id = '"+inputId+"'");

- 解決策:
+ 解決策:

 import org.owasp.esapi.Encoder;
@@ -1829,15 +2091,15 @@ import org.owasp.esapi.Encoder;
 createQuery("select * from User where id = '"+Encoder.encodeForSQL(inputId)+"'");

-
+

-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -1847,7 +2109,7 @@ createQuery("select * from User where id = '"+Encoder.encodeForSQL(inputId)+"'") Turbine による潜在的な SQL インジェクション - {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。(Turbine)
@@ -1855,13 +2117,13 @@ SQL クエリーに含まれる入力値は安全に渡す必要があります Turbine API は，Java コードを使用してクエリーを作成する DSL を提供します。

- 脆弱なコード:
+ 脆弱なコード:

 List<Record> BasePeer.executeQuery( "select * from Customer where id=" + inputId );

- 解決策 (Criteria DSL を使用):
+ 解決策 (Criteria DSL を使用):

 Criteria c = new Criteria();
@@ -1870,13 +2132,13 @@ c.add( CustomerPeer.ID, inputId );
 List<Customer> customers = CustomerPeer.doSelect( c );
- 解決策 (特殊なメソッドを使用):
+ 解決策 (特殊なメソッドを使用):
 Customer customer = CustomerPeer.retrieveByPK( new NumberKey( inputId ) );
- 解決策 (OWASP Encoder を使用):
+ 解決策 (OWASP Encoder を使用):
 import org.owasp.esapi.Encoder;
@@ -1884,17 +2146,17 @@ import org.owasp.esapi.Encoder;
 BasePeer.executeQuery("select * from Customer where id = '"+Encoder.encodeForSQL(inputId)+"'");

-
+

-参考文献 (Turbine)
-Turbine Documentation: Criteria Howto
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (Turbine)
+Turbine Documentation: Criteria Howto
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -1904,22 +2166,22 @@ BasePeer.executeQuery("select * from Customer where id = '"+Encoder.encodeForSQL 潜在的な SQL/HQL インジェクション (Hibernate) - {3} の使用は，SQL/HQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL/HQL インジェクションに対して脆弱である可能性があります。(Hibernate)
SQL クエリーに含まれる入力値は安全に渡す必要があります。プリペアードステートメントのバインド変数を使用すると SQL インジェクションのリスクを容易に軽減できます。 -プリペアードステートメントの代わりに， Hibernate Criteria を使用することもできます。 +プリペアードステートメントの代わりに Hibernate Criteria を使用することもできます。

- 脆弱なコード:
+ 脆弱なコード:

 Session session = sessionFactory.openSession();
 Query q = session.createQuery("select t from UserEntity t where id = " + input);
 q.execute();

- 解決策:
+ 解決策:

 Session session = sessionFactory.openSession();
 Query q = session.createQuery("select t from UserEntity t where id = :userId");
@@ -1927,7 +2189,7 @@ q.setString("userId",input);
 q.execute();

- 動的クエリーの解決策 (Hibernate Criteria を使用):
+ 動的クエリーの解決策 (Hibernate Criteria を使用):

 Session session = sessionFactory.openSession();
 Query q = session.createCriteria(UserEntity.class)
@@ -1935,19 +2197,21 @@ Query q = session.createCriteria(UserEntity.class)
     .list();
 q.execute();

-
+

-参考文献 (Hibernate)
-Hibernate Documentation: Query Criteria
-Hibernate Javadoc: Query Object
-HQL for pentesters: Guideline to test if the suspected code is exploitable.
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (Hibernate)
+CWE-564: SQL Injection: Hibernate
+Hibernate Documentation: Query Criteria
+Hibernate Javadoc: Query Object
+HQL for pentesters: Guideline to test if the suspected code is exploitable.
+ +参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -1957,14 +2221,14 @@ q.execute(); 潜在的な SQL/JDOQL インジェクション (JDO) - {3} の使用は，SQL/JDOQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL/JDOQL インジェクションに対して脆弱である可能性があります。(JDO)
SQL クエリーに含まれる入力値は安全に渡す必要があります。プリペアードステートメントのバインド変数を使用すると SQL インジェクションのリスクを容易に軽減できます。

- 脆弱なコード:
+ 脆弱なコード:

 PersistenceManager pm = getPM();
 
@@ -1972,7 +2236,7 @@ Query q = pm.newQuery("select * from Users where name = " + input);
 q.execute();

- 解決策:
+ 解決策:

 PersistenceManager pm = getPM();
 
@@ -1980,17 +2244,17 @@ Query q = pm.newQuery("select * from Users where name = nameParam");
 q.declareParameters("String nameParam");
 q.execute(input);

-
+

-参考文献 (JDO)
-JDO: Object Retrieval
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (JDO)
+JDO: Object Retrieval
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -2000,14 +2264,14 @@ q.execute(input); 潜在的な SQL/JPQL インジェクション (JPA) - {3} の使用は，SQL/JPQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL/JPQL インジェクションに対して脆弱である可能性があります。(JPA)
SQL クエリーに含まれる入力値は安全に渡す必要があります。プリペアードステートメントのバインド変数を使用すると SQL インジェクションのリスクを容易に軽減できます。

- 脆弱なコード:
+ 脆弱なコード:

 EntityManager pm = getEM();
 
@@ -2018,7 +2282,7 @@ TypedQuery<UserEntity> q = em.createQuery(
 UserEntity res = q.getSingleResult();

- 解決策:
+ 解決策:

 TypedQuery<UserEntity> q = em.createQuery(
     "select * from Users where name = usernameParam",UserEntity.class)
@@ -2026,17 +2290,17 @@ TypedQuery<UserEntity> q = em.createQuery(
 
 UserEntity res = q.getSingleResult();

-
+

-参考文献 (JPA)
-The Java EE 6 Tutorial: Creating Queries Using the Java Persistence Query Language
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (JPA)
+The Java EE 6 Tutorial: Creating Queries Using the Java Persistence Query Language
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -2047,7 +2311,7 @@ UserEntity res = q.getSingleResult(); 潜在的な JDBC インジェクション (Spring JDBC) - {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。(Spring JDBC)
@@ -2055,27 +2319,27 @@ SQL クエリーに含まれる入力値は安全に渡す必要があります

- 脆弱なコード:
+ 脆弱なコード:

JdbcTemplate jdbc = new JdbcTemplate();
 int count = jdbc.queryForObject("select count(*) from Users where name = '"+paramName+"'", Integer.class);

- 解決策:
+ 解決策:

JdbcTemplate jdbc = new JdbcTemplate();
 int count = jdbc.queryForObject("select count(*) from Users where name = ?", Integer.class, paramName);

-
+
-参考文献 (Spring JDBC)
-Spring Official Documentation: Data access with JDBC
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (Spring JDBC)
+Spring Official Documentation: Data access with JDBC
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -2085,7 +2349,7 @@ int count = jdbc.queryForObject("select count(*) from Users where name = ?", Int 潜在的な JDBC インジェクション - {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。(JDBC)
@@ -2093,29 +2357,29 @@ SQL クエリーに含まれる入力値は安全に渡す必要があります

- 脆弱なコード:
+ 脆弱なコード:

Connection conn = [...];
 Statement stmt = con.createStatement();
 ResultSet rs = stmt.executeQuery("update COFFEES set SALES = "+nbSales+" where COF_NAME = '"+coffeeName+"'");

- 解決策:
+ 解決策:

Connection conn = [...];
 conn.prepareStatement("update COFFEES set SALES = ? where COF_NAME = ?");
 updateSales.setInt(1, nbSales);
 updateSales.setString(2, coffeeName);

-
+
-参考文献 (JDBC)
-Oracle Documentation: The Java Tutorials > Prepared Statements
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (JDBC)
+Oracle Documentation: The Java Tutorials > Prepared Statements
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -2125,7 +2389,7 @@ updateSales.setString(2, coffeeName); 潜在的な Scala Slick インジェクション - {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。(Slick)
@@ -2133,26 +2397,26 @@ SQL クエリーに含まれる入力値は安全に渡す必要があります

- 脆弱なコード:
+ 脆弱なコード:

db.run {
   sql"select * from people where name = '#$value'".as[Person]
 }

- 解決策:
+ 解決策:

db.run {
   sql"select * from people where name = $value".as[Person]
 }

-
+
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -2162,7 +2426,7 @@ SQL クエリーに含まれる入力値は安全に渡す必要があります 潜在的な Scala Anorm インジェクション - {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。(Anorm)
@@ -2170,7 +2434,7 @@ SQL クエリーに含まれる入力値は安全に渡す必要があります

- 脆弱なコード:
+ 脆弱なコード:

val peopleParser = Macro.parser[Person]("id", "name", "age")
 
 DB.withConnection { implicit c =>
@@ -2178,22 +2442,22 @@ DB.withConnection { implicit c =>
 }

- 解決策:
+ 解決策:

val peopleParser = Macro.parser[Person]("id", "name", "age")
 
 DB.withConnection { implicit c =>
   val people: List[Person] = SQL"select * from people where name = $value".as(peopleParser.*)
 }

-
+
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -2209,7 +2473,7 @@ DB.withConnection { implicit c => 潜在的な Android SQL インジェクション - {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。 + {3} の使用は，SQL インジェクションに対して脆弱である可能性があります。(Android SQL)
@@ -2217,30 +2481,30 @@ SQL クエリーに含まれる入力値は安全に渡す必要があります

- 脆弱なコード:
+ 脆弱なコード:

String query = "SELECT * FROM  messages WHERE uid= '"+userInput+"'" ;
 Cursor cursor = this.getReadableDatabase().rawQuery(query,null);

- 解決策:
+ 解決策:

String query = "SELECT * FROM  messages WHERE uid= ?" ;
 Cursor cursor = this.getReadableDatabase().rawQuery(query,new String[] {userInput});

-
+
-参考文献 (Android SQLite)
-InformIT.com: Practical Advice for Building Secure Android Databases in SQLite
-Packtpub.com: Knowing the SQL-injection attacks and securing our Android applications from them
-Android Database Support (Enterprise Android: Programming Android Database Applications for the Enterprise)
-Safe example of Insert, Select, Update and Delete queryies provided by Suragch
+参考文献 (Android SQLite)
+InformIT.com: Practical Advice for Building Secure Android Databases in SQLite
+Packtpub.com: Knowing the SQL-injection attacks and securing our Android applications from them
+Android Database Support (Enterprise Android: Programming Android Database Applications for the Enterprise)
+Safe example of Insert, Select, Update and Delete queries provided by Suragch
-参考文献 (SQL インジェクション)
-WASC-19: SQL Injection
-CAPEC-66: SQL Injection
-CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
-OWASP: Top 10 2013-A1-Injection
-OWASP: SQL Injection Prevention Cheat Sheet
-OWASP: Query Parameterization Cheat Sheet
+参考文献 (SQL インジェクション)
+WASC-19: SQL Injection
+CAPEC-66: SQL Injection
+CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+OWASP: Top 10 2013-A1-Injection
+OWASP: SQL Injection Prevention Cheat Sheet
+OWASP: Query Parameterization Cheat Sheet

]]>
@@ -2259,21 +2523,21 @@ Cursor cursor = this.getReadableDatabase().rawQuery(query,new String[] {userInpu
-SQL と同様に，LDAP クエリーに渡されるすべての入力は安全に渡す必要があります。残念ながら，LDAP には SQL のようなプリペアードステートメントインターフェースがありません。 +SQL と同様に，LDAP クエリーに渡されるすべての入力は安全に渡す必要があります。残念ながら，LDAP には SQL のようなプリペアードステートメントインタフェースがありません。 そのため，LDAP インジェクションに対する一次防御は，LDAP クエリーに含める前に信頼できないデータを十分に検証することです。

- リスクのあるコード:
+ リスクのあるコード:

NamingEnumeration<SearchResult> answers = context.search("dc=People,dc=example,dc=com",
         "(uid=" + username + ")", ctrls);

-
+

-参考文献
-WASC-29: LDAP Injection
-OWASP: Top 10 2013-A1-Injection
-CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
-LDAP Injection Guide: Learn How to Detect LDAP Injections and Improve LDAP Security +参考文献
+WASC-29: LDAP Injection
+OWASP: Top 10 2013-A1-Injection
+CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
+LDAP Injection Guide: Learn How to Detect LDAP Injections and Improve LDAP Security

]]>
@@ -2292,11 +2556,10 @@ SQL と同様に，LDAP クエリーに渡されるすべての入力は安全
-動的なコードが評価されています。コードの構築を慎重に分析すべきです。悪意のあるコードの実行は，データ漏洩やオペレーティングシステムが危険にさらされる可能性があります。 -ユーザーコードの評価を意図しているなら，適切なサンドボックスを用意すべきです (参考文献を参照)。 +動的なコードが評価されています。コードの構築を慎重に分析するべきです。悪意のあるコードの実行は，データ漏洩やオペレーティングシステムが危険にさらされる可能性があります。

- If the evaluation of user code is intended, a proper sandboxing should be applied (see references). +ユーザーコードの評価を意図しているなら，適切なサンドボックスを用意すべきです (参考文献を参照)。

リスクのあるコード:

@@ -2312,7 +2575,7 @@ public void runCustomTrigger(String script) {

解決策:

-Cloudbees Rhino Sandbox ライブラリを使用した Javascript コードの安全な評価。
+Cloudbees Rhino Sandbox ライブラリーを使用した Javascript コードの安全な評価。

 public void runCustomTrigger(String script) {
     SandboxContextFactory contextFactory = new SandboxContextFactory();
@@ -2330,28 +2593,32 @@ public void runCustomTrigger(String script) {
     }
 }

-
+

-参考文献
-Cloudbees Rhino Sandbox: Utility to create sandbox with Rhino (block access to all classes)
-CodeUtopia.net: Sandboxing Rhino in Java
-Remote Code Execution .. by design: 悪意のあるペイロードの例です。示したサンプルは，サンドボックスのルールをテストするために使用される可能性があります。
-CWE-94: Improper Control of Generation of Code ('Code Injection')
-CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
+参考文献
+Cloudbees Rhino Sandbox: Utility to create sandbox with Rhino (block access to all classes)
+CodeUtopia.net: Sandboxing Rhino in Java
+Remote Code Execution .. by design: Example of malicious payload. The samples given could be used to test sandboxing rules.
+CWE-94: Improper Control of Generation of Code ('Code Injection')
+CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

]]>
スクリプトエンジンインジェクション + +
Spring コンポーネント内の SpelView パターンを特定する。
+ + - SpEL 使用時の潜在的なコードインジェクション - {3} の使用は，コードインジェクションに対して脆弱である可能性があります。 + Spring 式使用時の潜在的なコードインジェクション + {3} の使用は，コードインジェクションに対して脆弱である可能性があります。(Spring 式)
-Spring 式は，動的な値で構築されています。フィルタリングされていない値が危険なコード評価になることを避けるために値の発生源を検証すべきです。 +Spring 式は，動的な値で構築されています。フィルタされていない値が危険なコード評価になることを避けるために値の発生源を検証すべきです。

リスクのあるコード:

@@ -2367,29 +2634,31 @@ public void parseExpressionInterface(Person personObj,String property) { boolean result = exp.getValue(testContext, Boolean.class); [...]

-
+

- 参考文献
- CWE-94: Improper Control of Generation of Code ('Code Injection')
- CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
- Spring Expression Language (SpEL) - Official Documentation
- Minded Security: Expression Language Injection
- Remote Code Execution .. by design: 悪意のあるペイロードの例です。示したサンプルは，サンドボックスのルールをテストするために使用される可能性があります。
+ 参考文献
+ CWE-94: Improper Control of Generation of Code ('Code Injection')
+ CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
+ Spring Expression Language (SpEL) - Official Documentation
+ Minded Security: Expression Language Injection
+ Remote Code Execution .. by design: Example of malicious payload. The samples given could be used to test sandboxing rules.
+ Spring Data-Commons: (CVE-2018-1273)
+ Spring OAuth2: CVE-2018-1260

]]>
- SpEL インジェクション + Spring 式インジェクション 式言語 (EL) 使用時の潜在的なコードインジェクション - {3} の使用は，コードインジェクションに対して脆弱である可能性があります。 + {3} の使用は，コードインジェクションに対して脆弱である可能性があります。(式言語)
-式は動的な値で構築されています。フィルタリングされていない値が危険なコード評価になることを避けるために値の発生源を検証すべきです。 +式は動的な値で構築されています。フィルタされていない値が危険なコード評価になることを避けるために値の発生源を検証すべきです。

リスクのあるコード:

@@ -2401,16 +2670,16 @@ public void parseExpressionInterface(Person personObj,String property) { return (String) vex.getValue(elContext); }

-
+

- 参考文献
- Minded Security: Abusing EL for executing OS commands
- The Java EE 6 Tutorial: Expression Language
- CWE-94: Improper Control of Generation of Code ('Code Injection')
- CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
- Minded Security: Expression Language Injection
- Dan Amodio's blog: Remote Code with Expression Language Injection
- Remote Code Execution .. by design: 悪意のあるペイロードの例です。示したサンプルは，サンドボックスのルールをテストするために使用される可能性があります。
+ 参考文献
+ Minded Security: Abusing EL for executing OS commands
+ The Java EE 6 Tutorial: Expression Language
+ CWE-94: Improper Control of Generation of Code ('Code Injection')
+ CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
+ Minded Security: Expression Language Injection
+ Dan Amodio's blog: Remote Code with Expression Language Injection
+ Remote Code Execution .. by design: Example of malicious payload. The samples given could be used to test sandboxing rules.

]]>
@@ -2428,7 +2697,7 @@ Seam Logging API は，ログメッセージに Bean プロパティを取り込 式言語は望まれていないコードの実行元になることもあります。

-このコンテキストでは，式は動的な値で構築されています。フィルタリングされていない値が危険なコード評価になることを避けるために値の発生源を検証すべきです。 +このコンテキストでは，式は動的な値で構築されています。フィルタされていない値が危険なコード評価になることを避けるために値の発生源を検証すべきです。

リスクのあるコード:

@@ -2444,14 +2713,14 @@ Seam Logging API は，ログメッセージに Bean プロパティを取り込 //... }

-
+

- 参考文献
- JBSEAM-5130: Issue documenting the risk
- JBoss Seam: Logging (Official documentation)
- The Java EE 6 Tutorial: Expression Language
- CWE-94: Improper Control of Generation of Code ('Code Injection')
- CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
+ 参考文献
+ JBSEAM-5130: Issue documenting the risk
+ JBoss Seam: Logging (Official documentation)
+ The Java EE 6 Tutorial: Expression Language
+ CWE-94: Improper Control of Generation of Code ('Code Injection')
+ CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

]]> @@ -2470,7 +2739,7 @@ Seam Logging API は，ログメッセージに Bean プロパティを取り込
-式は動的な値で構築されています。フィルタリングされていない値が危険なコード評価になることを避けるために値の発生源を検証すべきです。 +式は動的な値で構築されています。フィルタされていない値が危険なコード評価になることを避けるために値の発生源を検証すべきです。

リスクのあるコード:

@@ -2486,18 +2755,18 @@ public void getUserProperty(String property) {

一般に，OGNL 式を評価するメソッドは，ユーザー入力を受け取るべきではありません。静的構成と JSP で使用することを意図しています。

-
+

- 参考文献
- HP Enterprise: Struts 2 OGNL Expression Injections by Alvaro Muñoz
- Gotham Digital Science: An Analysis Of CVE-2017-5638
- Apache Struts2: Vulnerability S2-016
- Apache Struts 2 Documentation: OGNL
+ 参考文献
+ HP Enterprise: Struts 2 OGNL Expression Injections by Alvaro Muñoz
+ Gotham Digital Science: An Analysis Of CVE-2017-5638
+ Apache Struts2: Vulnerability S2-016
+ Apache Struts 2 Documentation: OGNL

]]>
- 式言語 (EL) インジェクション + OGNL 式インジェクション @@ -2511,26 +2780,26 @@ public void getUserProperty(String property) {
-HTTP リクエストに予期しない CR 文字と LF 文字が含まれていると，サーバーは2つの異なる HTTP レスポンス (1つではなく) として解釈される出力ストリームで応答することがあります。 +HTTP リクエストに予期しない CR と LF 文字が含まれていると，サーバーは2つの異なる HTTP レスポンス (1つではなく) として解釈される出力ストリームで応答することがあります。 攻撃者は，2番目のレスポンスを制御し，クロスサイトスクリプティングやキャッシュポイズニング攻撃などの攻撃をしかけることができます。 OWASP によると，この問題はほぼすべての今の Java EE アプリケーションサーバーで修正されていますが，入力を検証することは依然として有効です。 -このリスクが懸念されるときは，問題のプラットフォームでテストして，基礎となるプラットフォームが CR または LF 文字をヘッダーに挿入できるかどうかを確認する必要があります。 +このリスクが懸念されるときは，問題のプラットフォームでテストして，基礎となるプラットフォームが CR または LF 文字をヘッダーに挿入できるかどうかを確認すべきです。 この弱点は SQL インジェクションなどの優先順位よりも低いと報告されています。脆弱なプラットフォームを使用しているときは，優先度の低い警告もチェックしてください。

-
+

-リスクのあるコード:
+リスクのあるコード:

String author = request.getParameter(AUTHOR_PARAMETER);
 // ...
 Cookie cookie = new Cookie("author", author);
 response.addCookie(cookie);

-
+

- 参考文献
- OWASP: HTTP Response Splitting
- CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') - CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
+ 参考文献
+ OWASP: HTTP Response Splitting
+ CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') + CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

]]> @@ -2551,13 +2820,13 @@ response.addCookie(cookie); 信頼できないソースからのデータがロガーに入れられ，正しく無力化されていないと，攻撃者はログエントリーを偽造したり，悪意のあるコンテンツを含めることができます。 -挿入された誤ったエントリは，統計を歪めたり，管理者の気を散らしたり，悪意のある行為を委託するときに他の当事者を巻き込むために使用される可能性があります。 -ログファイルが自動的に処理されていると，攻撃者はファイルの形式を破損させたり予期しない文字を挿入してファイルを使用できなくすることができます。 -攻撃者は，コードやその他のコマンドをログファイルに挿入したり，ログ処理ユーティリティの脆弱性 (コマンドインジェクションや XSS など) を利用することもできます。 +挿入された偽のエントリーは，統計を歪めたり，管理者を混乱させたり，悪意のある行為を委託するときに他の当事者を巻き込むために使用される可能性があります。 +ログファイルが自動的に処理されていると，攻撃者はファイルの形式を破壊したり予期しない文字を注入してファイルを使用できなくすることができます。 +攻撃者は，コードやその他のコマンドをログファイルに注入し，ログ処理ユーティリティの脆弱性 (コマンドインジェクションや XSS など) を利用することもできます。

-
+

-リスクのあるコード:
+リスクのあるコード:

String val = request.getParameter("user");
 String metadata = request.getParameter("metadata");
 [...]
@@ -2572,7 +2841,7 @@ else {
 悪意のあるユーザーがメタデータパラメーターに値を送信する可能性があります: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer"。
 

 
-解決策:

+解決策:

 

 手動で各パラメーターをエスケープします。
 
@@ -2581,18 +2850,24 @@ log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\
 

 
 

-すべてのメッセージイベントの改行を置き換えるようにロガーサービスを設定することもできます。replace 関数を使用した LogBack の設定例を示します。。
+すべてのメッセージイベントの改行を置き換えるようにロガーサービスを設定することもできます。replace 関数を使用した LogBack の設定例を示します。
 
 <pattern>%-5level - %replace(%msg){'[\r\n]', ''}%n</pattern>
 

 

 
-

 

-    参考文献

-    CWE-117: Improper Output Neutralization for Logs

-    CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

-    CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

+最後に，改行をスペースで書き換えるロガー実装を使用することができます。
+OWASP Security Logging プロジェクトには，LogBack と Log4j の実装があります。
+

+
+

+

+    参考文献

+    CWE-117: Improper Output Neutralization for Logs

+    CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

+    CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

+    OWASP Security Logging

 

 
 ]]>
@@ -2613,17 +2888,17 @@ log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\
             
 システム設定の外部制御を許可するとサービスが中断されたり，アプリケーションが予期せぬ悪意のある方法で動作させられたりする可能性があります。
-攻撃者は，存在しないカタログ名を指定したり，データベースの権限のない部分に接続することによってエラーを引き起こす可能性があります。
+攻撃者は，存在しないカタログ名を指定したり，データベースの権限のない部分に接続することによってエラーを引き起こすことができます。
 

-

+

 

-リスクのあるコード:

+リスクのあるコード:

 
conn.setCatalog(request.getParameter("catalog"));

 

-

+

 

-    参考文献

-    CWE-15: External Control of System or Configuration Setting

+    参考文献

+    CWE-15: External Control of System or Configuration Setting

 

 ]]>
@@ -2659,13 +2934,13 @@ return stringBuilder.toString();

-このような状況では，toHexString() を次のように String.format() に置き換えるべきです: +このような状況では，Integer.toHexString() メソッドを次のように String.format() に置き換えるべきです: 

stringBuilder.append( String.format( "%02X", b ) );

-
+

-参考文献
-CWE-704: Incorrect Type Conversion or Cast +参考文献
+CWE-704: Incorrect Type Conversion or Cast

]]> @@ -2683,13 +2958,13 @@ return stringBuilder.toString();
Hazelcast のネットワーク通信は，対称暗号 (おそらく DES または blowfish) を使用するように構成されています。

-

これらの暗号だけでは，完全性や安全な認証が提供されません。非対称暗号を使用することが望ましいです。

-
+

これらの暗号だけでは完全性や安全な認証が提供されません。非対称暗号を使用することが望ましいです。

+

-参考文献
-WASC-04: Insufficient Transport Layer Protection
-Hazelcast Documentation: Encryption
-CWE-326: Inadequate Encryption Strength +参考文献
+WASC-04: Insufficient Transport Layer Protection
+Hazelcast Documentation: Encryption
+CWE-326: Inadequate Encryption Strength

]]>
@@ -2707,24 +2982,25 @@ return stringBuilder.toString();
-NullCipher は，本番アプリケーションで意図的に使用されることはほとんどありません。NullCipher は，与えられた平文と同じ暗号文を返すように Cipher インターフェースを実装しています。 -テストなどのいくつかのコンテキストでは，NullCipher が適切なときがあります。 +NullCipher は，本番アプリケーションで意図的に使用されることはほとんどありません。 +Cipher インタフェースは，与えられた平文と同一の暗号文を返すように実装されています。 +テストなどのいくつかのコンテキストでは NullCipher が適切なときがあります。

- 脆弱なコード:
+ 脆弱なコード:

Cipher doNothingCihper = new NullCipher();
 [...]
 //The ciphertext produced will be identical to the plaintext.
 byte[] cipherText = c.doFinal(plainText);

- 解決策:
-NullCipher を使用しないでください。不慮の使用は重大な機密性リスクを招く可能性があります。 + 解決策:
+ NullCipher を使用しないでください。誤って使用すると重大な機密性リスクが生じる可能性があります。

-
+

-参考文献
-CWE-327: Use of a Broken or Risky Cryptographic Algorithm +参考文献
+CWE-327: Use of a Broken or Risky Cryptographic Algorithm

]]>
@@ -2745,26 +3021,26 @@ byte[] cipherText = c.doFinal(plainText); 使用される通信チャネルは暗号化されていません。攻撃者がネットワークトラフィックを傍受して，トラフィックが読み取られる可能性があります。

-脆弱なコード:
+脆弱なコード:
プレーンソケット (平文通信): 

Socket soc = new Socket("www.google.com",80);

-解決策:
+解決策:
SSL ソケット (安全な通信): 

Socket soc = SSLSocketFactory.getDefault().createSocket("www.google.com", 443);

SSL ソケットを使用する以外に，SSLSocketFactory を使用して，中間者攻撃の対象にならないように，すべての適切な証明書検証チェックを実行する必要があります。 チェックを正しく行う方法の詳細については，OWASP Transport Layer Protection Cheat Sheet をお読みください。

-
+

-参考文献
-OWASP: Top 10 2010-A9-Insufficient Transport Layer Protection
-OWASP: Top 10 2013-A6-Sensitive Data Exposure
-OWASP: Transport Layer Protection Cheat Sheet
-WASC-04: Insufficient Transport Layer Protection
-CWE-319: Cleartext Transmission of Sensitive Information +参考文献
+OWASP: Top 10 2010-A9-Insufficient Transport Layer Protection
+OWASP: Top 10 2013-A6-Sensitive Data Exposure
+OWASP: Transport Layer Protection Cheat Sheet
+WASC-04: Insufficient Transport Layer Protection
+CWE-319: Cleartext Transmission of Sensitive Information

]]> @@ -2783,26 +3059,26 @@ SSL ソケット (安全な通信): 使用される通信チャネルは暗号化されていません。攻撃者がネットワークトラフィックを傍受して，トラフィックが読み取られる可能性があります。

-脆弱なコード:
+脆弱なコード:
プレーンサーバーソケット (平文通信): 

ServerSocket soc = new ServerSocket(1234);

-解決策:
+解決策:
SSL サーバーソケット (安全な通信): 

ServerSocket soc = SSLServerSocketFactory.getDefault().createServerSocket(1234);

SSL サーバーソケットを使用する以外に，SSLServerSocketFactory を使用することで，中間者攻撃の対象にならないように，すべての適切な証明書検証チェックを実行する必要があります。 チェックを正しく行う方法の詳細については，OWASP Transport Layer Protection Cheat Sheet をお読みください。

-
+

-参考文献
-OWASP: Top 10 2010-A9-Insufficient Transport Layer Protection
-OWASP: Top 10 2013-A6-Sensitive Data Exposure
-OWASP: Transport Layer Protection Cheat Sheet
-WASC-04: Insufficient Transport Layer Protection
-CWE-319: Cleartext Transmission of Sensitive Information +参考文献
+OWASP: Top 10 2010-A9-Insufficient Transport Layer Protection
+OWASP: Top 10 2013-A6-Sensitive Data Exposure
+OWASP: Transport Layer Protection Cheat Sheet
+WASC-04: Insufficient Transport Layer Protection
+CWE-319: Cleartext Transmission of Sensitive Information

]]> @@ -2811,19 +3087,19 @@ SSL サーバーソケット (安全な通信): -
DES/DESede は AES に置き換えるべきです。
+
DES は AES に置き換えるべきです。
 - DES/DESede は安全でない - DES/DESede は AES に置き換えるべきです。 + DES は安全でない + DES は AES に置き換えるべきです。
-DES と DESede (3DES) は，今のアプリケーションでは強固な暗号とは見なされていません。現在，NIST は DES/3DES の代わりに AES ブロック暗号の使用を推奨しています。 +DES は，今のアプリケーションでは強固な暗号とは見なされていません。現在，NIST は DES の代わりに AES ブロック暗号の使用を推奨しています。

弱いコードの例: -

Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
+
Cipher c = Cipher.getInstance("DES/ECB/PKCS5Padding");
 c.init(Cipher.ENCRYPT_MODE, k, iv);
 byte[] cipherText = c.doFinal(plainText);

 

@@ -2833,17 +3109,52 @@ byte[] cipherText = c.doFinal(plainText);
c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText);

-
+

-参考文献
-NIST Withdraws Outdated Data Encryption Standard
-CWE-326: Inadequate Encryption Strength +参考文献
+NIST Withdraws Outdated Data Encryption Standard
+CWE-326: Inadequate Encryption Strength

]]>
- DES / DESede + DES + + +
DESede は AES に置き換えるべきです。
+ + + DESede は安全でない + DESede は AES に置き換えるべきです。 +
+ +トリプル DES (3DES または DESede としても知られている) は，今のアプリケーションでは強固な暗号とは見なされていません。 +現在，NIST は 3DES の代わりに AES ブロック暗号の使用を推奨しています。 +

+

+ 弱いコードの例: +

Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
+c.init(Cipher.ENCRYPT_MODE, k, iv);
+byte[] cipherText = c.doFinal(plainText);
+

+

+ 解決策の例: + 

Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
+c.init(Cipher.ENCRYPT_MODE, k, iv);
+byte[] cipherText = c.doFinal(plainText);
+

+
+

+参考文献
+NIST Withdraws Outdated Data Encryption Standard
+CWE-326: Inadequate Encryption Strength +

+]]> +
+ + DESede @@ -2858,19 +3169,19 @@ byte[] cipherText = c.doFinal(plainText); ソフトウェアは RSA アルゴリズムを使用していますが，最適非対称暗号化パディング (OAEP:Optimal Asymmetric Encryption Padding) を組み込んでいないので，暗号を弱めるかもしれません。

-脆弱なコード:
+脆弱なコード:

Cipher.getInstance("RSA/NONE/NoPadding")

-解決策:
-コードは次のように置き換えるべきです:
+解決策:
+コードは次のように置き換えるべきです:

Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding")

-
+

-参考文献
-CWE-780: Use of RSA Algorithm without OAEP
-Root Labs: Why RSA encryption padding is critical +参考文献
+CWE-780: Use of RSA Algorithm without OAEP
+Root Labs: Why RSA encryption padding is critical

]]> @@ -2911,17 +3222,17 @@ byte[] cipherText = c.doFinal(plainText); (ハードコードされた鍵は ハードコードされた鍵 パターンで別々に報告されます)

-

脆弱なコード:
+

脆弱なコード:

private String SECRET_PASSWORD = "letMeIn!";
 
 Properties props = new Properties();
 props.put(Context.SECURITY_CREDENTIALS, "p@ssw0rd");

-
+

-参考文献
-CWE-259: Use of Hard-coded Password +参考文献
+CWE-259: Use of Hard-coded Password

]]> @@ -2939,7 +3250,7 @@ props.put(Context.SECURITY_CREDENTIALS, "p@ssw0rd"); (ハードコードされたパスワードは ハードコードされたパスワード パターンで別々に報告されます)

-

脆弱なコード:
+

脆弱なコード:

byte[] key = {1, 2, 3, 4, 5, 6, 7, 8};
 SecretKeySpec spec = new SecretKeySpec(key, "AES");
@@ -2947,10 +3258,10 @@ Cipher aes = Cipher.getInstance("AES");
 aes.init(Cipher.ENCRYPT_MODE, spec);
 return aesCipher.doFinal(secretData);

-
+

-参考文献
-CWE-321: Use of Hard-coded Cryptographic Key
+参考文献
+CWE-321: Use of Hard-coded Cryptographic Key

]]> @@ -2968,28 +3279,30 @@ return aesCipher.doFinal(secretData);
-攻撃者は，比較タイミングの暴露による秘密ハッシュ値を検出できる可能性があります。 -関数 Arrays.equals() または String.equals() が呼び出されると一致するバイト数が少なければ早く終了します。 +攻撃者は，比較タイミングの暴露による秘密ハッシュ値を検出できます。 +関数 Arrays.equals() または String.equals() が呼び出されると一致するバイト数が少ないと早く終了します。

-

脆弱なコード:
+

脆弱なコード:

 String actualHash = ...
+
 if(userInput.equals(actualHash)) {
     ...
 }

-

解決策:
+

解決策:

 String actualHash = ...
+
 if(MessageDigest.isEqual(userInput.getBytes(),actualHash.getBytes())) {
     ...
 }

-
+

-参考文献
-CWE-203: Information Exposure Through DiscrepancyKey
+参考文献
+CWE-203: Information Exposure Through DiscrepancyKey

]]>
@@ -3025,11 +3338,11 @@ public class RegistrationForm extends ValidatorForm { }

-
+

-参考文献
-CWE-20: Improper Input Validation
-CWE-106: Struts: Plug-in Framework not in Use +参考文献
+CWE-20: Improper Input Validation
+CWE-106: Struts: Plug-in Framework not in Use

]]> @@ -3048,19 +3361,19 @@ public class RegistrationForm extends ValidatorForm { XSSRequestWrapper と呼ばれる HttpServletRequestWrapper の実装は，さまざまなブログサイトで公開されていました。 -[1] -[2] +[1] +[2]

フィルタリングはいくつかの理由から弱いです:

  • カバーしているのはパラメーターだけで，ヘッダーやサイドチャネル入力はカバーしていない
    • -
  • 置換チェーンは簡単に迂回できる (下の例を参照)
    • +
  • 置換機能のチェーンは簡単に迂回できる (下の例を参照)
  • 非常に特殊な悪いパターンのブラックリスト (良い/有効な入力のホワイトリストではなく)

-迂回の例:
+迂回の例:

<scrivbscript:pt>alert(1)</scrivbscript:pt>

@@ -3068,16 +3381,15 @@ public class RegistrationForm extends ValidatorForm { "vbscript:" の除去は，"<script>.*</script>" の置換が行われた後です。

-強力な保護のために，OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに従って，view (template, jsp, ...) -で文字を自動的にエンコードする解決策を選択してください。 +強力な保護のために，OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに従って，view (template, jsp, ...) で文字を自動的にエンコードする解決策を選択してください。

-
+

-参考文献
-WASC-8: Cross Site Scripting
-OWASP: XSS Prevention Cheat Sheet
-OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
-CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') +参考文献
+WASC-8: Cross Site Scripting
+OWASP: XSS Prevention Cheat Sheet
+OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
+CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

]]> @@ -3102,20 +3414,20 @@ Blowfish の使用が必要なときは，鍵を生成するときに少なく アルゴリズムを変更できるときは，代わりに AES ブロック暗号を使用すべきです。

-

脆弱なコード:
+

脆弱なコード:

KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish");
 keyGen.init(64);

-

解決策:
+

解決策:

KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish");
 keyGen.init(128);

-
+

-参考文献
-Blowfish (cipher)
-CWE-326: Inadequate Encryption Strength +参考文献
+Blowfish (cipher)
+CWE-326: Inadequate Encryption Strength

]]> @@ -3136,34 +3448,33 @@ keyGen.init(128); NISTは，RSA アルゴリズムに 2048ビット以上 の鍵を使用することを推奨しています。

- "Digital Signature Verification | RSA: 1024 ≤ len(n) < 2048 | Legacy-use"
- "Digital Signature Verification | RSA: len(n) ≥ 2048 | Acceptable"
- - NIST: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.7 + "Digital Signature Verification | RSA: 1024 ≤ len(n) < 2048 | Legacy-use"
+ "Digital Signature Verification | RSA: len(n) ≥ 2048 | Acceptable"
+ - NIST: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.7
-

脆弱なコード:
+

脆弱なコード:

 KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
 keyGen.initialize(512);

-

解決策:
+

解決策:
KeyPairGenerator の作成は，次のように少なくとも2048ビットの鍵長にすべきです。 

 KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
 keyGen.initialize(2048);

-
+

-参考文献
-NIST: Latest publication on key management
-NIST: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.7
-RSA Laboratories: 3.1.5 How large a key should be used in the RSA cryptosystem?
-Wikipedia: Asymmetric algorithm key lengths
-CWE-326: Inadequate Encryption Strength
-Keylength.com (BlueKrypt): Aggregate key length recommendations. +参考文献
+NIST: Latest publication on key management
+NIST: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.7
+Wikipedia: Asymmetric algorithm key lengths
+CWE-326: Inadequate Encryption Strength
+Keylength.com (BlueKrypt): Aggregate key length recommendations.

]]> @@ -3192,13 +3503,13 @@ keyGen.initialize(2048); このような脆弱性を利用して，フィッシング攻撃を容易にすることができます。

- シナリオ
- 1. ユーザーは，悪意のある URL にアクセスするようにだまされる: http://website.com/login?redirect=http://evil.vvebsite.com/fake/login
- 2. ユーザーは，信頼できるサイトのように見える偽のログインページにリダイレクトされる。(http://evil.vvebsite.com/fake/login)
- 3. ユーザーは自分の認証情報を入力する。
- 4. 悪意のあるサイトはユーザーの認証情報を盗み，元の Web サイトにリダイレクトする。
-
- ほとんどのユーザーがリダイレクト後に URL をダブルチェックしないため，この攻撃はもっともらしく思われます。また，認証ページへのリダイレクトもよくあります。 + シナリオ
+ 1. ユーザーは，悪意のある URL にアクセスするようにだまされる: http://website.com/login?redirect=http://evil.vvebsite.com/fake/login
+ 2. ユーザーは，信頼できるサイトのように見える偽のログインページにリダイレクトされる (http://evil.vvebsite.com/fake/login)
+ 3. ユーザーは自分の認証情報を入力する
+ 4. 悪意のあるサイトはユーザーの認証情報を盗み，元の Web サイトにリダイレクトする
+
+ ほとんどのユーザーがリダイレクト後に URL をダブルチェックしないため，この攻撃は最もらしく思われます。また，認証ページへのリダイレクトもよくあります。

脆弱なコード:
@@ -3209,7 +3520,7 @@ keyGen.initialize(2048); }

- 解決策/対策:
+ 解決策/対策:

  • ユーザーからリダイレクト先を受け入れない
  • 宛先キーを受け入れ，それを使用して対象 (合法) の宛先をルックアップする
    • @@ -3218,13 +3529,13 @@ keyGen.initialize(2048);
  • URL の先頭がホワイトリストの一部であることを検証する

-
+

-参考文献
-WASC-38: URL Redirector Abuse
-OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards
-OWASP: Unvalidated Redirects and Forwards Cheat Sheet
-CWE-601: URL Redirection to Untrusted Site ('Open Redirect') +参考文献
+WASC-38: URL Redirector Abuse
+OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards
+OWASP: Unvalidated Redirects and Forwards Cheat Sheet
+CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

]]> @@ -3233,7 +3544,7 @@ keyGen.initialize(2048); 未検証のリダイレクト (Play Framework) - 攻撃者は，次のリダイレクトを使用してユーザーをフィッシング Web サイトにリダイレクトできます。 + 攻撃者は，次のリダイレクトを使用してユーザーをフィッシング Web サイトにリダイレクトできます。(Play Framework のコンテキストで)
@@ -3241,13 +3552,13 @@ keyGen.initialize(2048); このような脆弱性を利用して，フィッシング攻撃を容易にすることができます。

- シナリオ
- 1. ユーザーは，悪意のある URL にアクセスするようにだまされる: http://website.com/login?redirect=http://evil.vvebsite.com/fake/login
- 2. ユーザーは，信頼できるサイトのように見える偽のログインページにリダイレクトされる。(http://evil.vvebsite.com/fake/login)
- 3. ユーザーは自分の認証情報を入力する。
- 4. 悪意のあるサイトはユーザーの認証情報を盗み，元の Web サイトにリダイレクトする。
-
- ほとんどのユーザーがリダイレクト後に URL をダブルチェックしないため，この攻撃はもっともらしく思われます。また，認証ページへのリダイレクトもよくあります。 + シナリオ
+ 1. ユーザーは，悪意のある URL にアクセスするようにだまされる: http://website.com/login?redirect=http://evil.vvebsite.com/fake/login
+ 2. ユーザーは，信頼できるサイトのように見える偽のログインページにリダイレクトされる (http://evil.vvebsite.com/fake/login)
+ 3. ユーザーは自分の認証情報を入力する
+ 4. 悪意のあるサイトはユーザーの認証情報を盗み，元の Web サイトにリダイレクトする
+
+ ほとんどのユーザーがリダイレクト後に URL をダブルチェックしないため，この攻撃は最もらしく思われます。また，認証ページへのリダイレクトもよくあります。

脆弱なコード:
@@ -3257,7 +3568,7 @@ keyGen.initialize(2048); }

- 解決策/対策:
+ 解決策/対策:

  • ユーザーからリダイレクト先を受け入れない
  • 宛先キーを受け入れ，それを使用して対象 (合法) の宛先をルックアップする
    • @@ -3266,13 +3577,13 @@ keyGen.initialize(2048);
  • URL の先頭がホワイトリストの一部であることを検証する

-
+

-参考文献
-WASC-38: URL Redirector Abuse
-OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards
-OWASP: Unvalidated Redirects and Forwards Cheat Sheet
-CWE-601: URL Redirection to Untrusted Site ('Open Redirect') +参考文献
+WASC-38: URL Redirector Abuse
+OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards
+OWASP: Unvalidated Redirects and Forwards Cheat Sheet
+CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

]]>
@@ -3280,8 +3591,8 @@ keyGen.initialize(2048); 未検証のリダイレクト (Play Framewok) - 未検証のリダイレクト (Spring Freamework) - 攻撃者は，次のリダイレクトを使用してユーザーをフィッシング Web サイトにリダイレクトできます。 + 未検証のリダイレクト (Spring アプリケーション) + 攻撃者は，次のリダイレクトを使用してユーザーをフィッシング Web サイトにリダイレクトできます。(Spring アプリケーションのコンテキストで)
@@ -3289,13 +3600,13 @@ keyGen.initialize(2048); このような脆弱性を利用して，フィッシング攻撃を容易にすることができます。

- シナリオ
- 1. ユーザーは，悪意のある URL にアクセスするようにだまされる: http://website.com/login?redirect=http://evil.vvebsite.com/fake/login
- 2. ユーザーは，信頼できるサイトのように見える偽のログインページにリダイレクトされる。(http://evil.vvebsite.com/fake/login)
- 3. ユーザーは自分の認証情報を入力する。
- 4. 悪意のあるサイトはユーザーの認証情報を盗み，元の Web サイトにリダイレクトする。
-
- ほとんどのユーザーがリダイレクト後に URL をダブルチェックしないため，この攻撃はもっともらしく思われます。また，認証ページへのリダイレクトもよくあります。 + シナリオ
+ 1. ユーザーは，悪意のある URL にアクセスするようにだまされる: http://website.com/login?redirect=http://evil.vvebsite.com/fake/login
+ 2. ユーザーは，信頼できるサイトのように見える偽のログインページにリダイレクトされる (http://evil.vvebsite.com/fake/login)
+ 3. ユーザーは自分の認証情報を入力する
+ 4. 悪意のあるサイトはユーザーの認証情報を盗み，元の Web サイトにリダイレクトする
+
+ ほとんどのユーザーがリダイレクト後に URL をダブルチェックしないため，この攻撃は最もらしく思われます。また，認証ページへのリダイレクトもよくあります。

脆弱なコード:
@@ -3306,7 +3617,7 @@ public String redirect(@RequestParam("url") String url) { }

- 解決策/対策:
+ 解決策/対策:

  • ユーザーからリダイレクト先を受け入れない
  • 宛先キーを受け入れ，それを使用して対象 (合法) の宛先をルックアップする
    • @@ -3315,19 +3626,193 @@ public String redirect(@RequestParam("url") String url) {
  • URL の先頭がホワイトリストの一部であることを検証する

-
+

-参考文献
-WASC-38: URL Redirector Abuse
-OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards
-OWASP: Unvalidated Redirects and Forwards Cheat Sheet
-CWE-601: URL Redirection to Untrusted Site ('Open Redirect') +参考文献
+WASC-38: URL Redirector Abuse
+OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards
+OWASP: Unvalidated Redirects and Forwards Cheat Sheet
+CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

]]>
- 未検証のリダイレクト (Spring Freamework) + 未検証のリダイレクト (Spring アプリケーション) + + + +
Spring REST エンドポイント内の永続オブジェクトの漏洩を特定する。
+ + + + 予期しないプロパティ漏洩 + 永続クラスがクライアントに直接公開されているため，予期しないプロパティが漏洩する可能性があります。 +
+ +永続オブジェクトは，APIによって返されるべきではありません。 +UIを介してビジネスロジックが漏洩したり，データベース内の永続オブジェクトが不正に改ざんされたりする可能性があります。 +

+

+ 脆弱なコード:
+

+@javax.persistence.Entity
+class UserEntity {
 
+    @Id
+    @GeneratedValue(strategy = GenerationType.IDENTITY)
+    private Long id;
+
+    private String username;
+
+    private String password;
+}
+
+[...]
+@Controller
+class UserController {
+
+    @GetMapping("/user/{id}")
+    public UserEntity getUser(@PathVariable("id") String id) {
+
+        return userService.findById(id).get(); //Return the user entity with ALL fields.
+    }
+
+}
+
+

+

+ 解決策/対策:
+

    +
  • データ転送オブジェクトは，API への入力/応答として必要なパラメーターだけを含めて，代わりに使用する必要がある
    • +
  • 機密パラメーターは，UI に転送する前に適切に削除する必要がある
    • +
  • データは，適切なサニタイズチェックの後にだけデータベースに保存されるべきである
    • +
+

+

+ Spring MVC 解決策:
+ 特に Spring では，次の解決策を適用して特定のフィールドを許可または禁止にできます。 + + 

+@Controller
+class UserController {
+
+   @InitBinder
+   public void initBinder(WebDataBinder binder, WebRequest request)
+   {
+      binder.setAllowedFields(["username","firstname","lastname"]);
+   }
+
+}
+
+

+ +

+参考文献
+OWASP Top 10-2017 A3: Sensitive Data Exposure
+OWASP Cheat Sheet: Mass Assignment
+CWE-212: Improper Cross-boundary Removal of Sensitive Data
+CWE-213: Intentional Information Exposure
+ + +

+ + ]]> +
+ + 予期しないプロパティ漏洩 + + + + 一括割り当て + 永続オブジェクトは，攻撃者が密情報を読み取るために悪用される可能性があります。 +
+ +永続オブジェクトは，APIによって返されるべきではありません。 +UIを介してビジネスロジックが漏洩したり，データベース内の永続オブジェクトが不正に改ざんされたりする可能性があります。 +

+

+ 脆弱なコード:
+

+@javax.persistence.Entity
+class UserEntity {
+
+    @Id
+    @GeneratedValue(strategy = GenerationType.IDENTITY)
+    private Long id;
+
+    private String username;
+
+    private String password;
+
+    private Long role;
+}
+
+[...]
+@Controller
+class UserController {
+
+    @PutMapping("/user/")
+    @ResponseStatus(value = HttpStatus.OK)
+    public void update(UserEntity user) {
+
+        userService.save(user); //ALL fields from the user can be altered
+    }
+
+}
+
+

+

+ 一般的なガイドライン:
+

    +
  • データ転送オブジェクトは，API への入力/応答として必要なパラメーターだけを含めて，代わりに使用する必要がある
    • +
  • 機密パラメーターは，UI に転送する前に適切に削除する必要がある
    • +
  • データは，適切なサニタイズチェックの後にだけデータベースに保存されるべきである
    • +
+

+

+ Spring MVC 解決策:
+ 特に Spring では，次の解決策を適用して特定のフィールドを許可または禁止にできます。
+
+With whitelist:
+ 

+@Controller
+class UserController {
+
+   @InitBinder
+   public void initBinder(WebDataBinder binder, WebRequest request)
+   {
+      binder.setAllowedFields(["username","password"]);
+   }
+
+}
+
+
+With a blacklist:
+ 
+@Controller
+class UserController {
+
+   @InitBinder
+   public void initBinder(WebDataBinder binder, WebRequest request)
+   {
+      binder.setDisallowedFields(["role"]);
+   }
+
+}
+
+

+ +

+参考文献
+OWASP Cheat Sheet: Mass Assignment
+CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
+

+ ]]> +
+ + Mass assignment @@ -3351,11 +3836,11 @@ public String redirect(@RequestParam("url") String url) { <jsp:include page="page1.jsp" /> </c:if>

-
+

-参考文献
-InfosecInstitute: File Inclusion Attacks
-WASC-05: Remote File Inclusion
+参考文献
+InfosecInstitute: File Inclusion Attacks
+WASC-05: Remote File Inclusion

]]> @@ -3371,14 +3856,14 @@ public String redirect(@RequestParam("url") String url) { Spring 式の動的変数によって任意のコードが実行されます。
Spring 式は，動的な値で構築されています。フィルタリングされていない値がこの危険なコード評価になることを避けるために値の発生源を検証すべきです。 +

Spring 式は，動的な値で構築されています。フィルタされていない値がこの危険なコード評価になることを避けるために値の発生源を検証すべきです。

脆弱なコード: 

<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
 
 <spring:eval expression="${param.lang}" var="lang" />
-
+ 
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
 
 <spring:eval expression="'${param.lang}'=='fr'" var="languageIsFrench" />
@@ -3386,14 +3871,14 @@ public String redirect(@RequestParam("url") String url) {

解決策: 

<c:set var="lang" value="${param.lang}"/>
-
+ 
<c:set var="languageIsFrench" value="${param.lang == 'fr'}"/>

-
+

-参考文献
- CWE-94: Improper Control of Generation of Code ('Code Injection')
- CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
+参考文献
+ CWE-94: Improper Control of Generation of Code ('Code Injection')
+ CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

]]>
@@ -3406,12 +3891,12 @@ public String redirect(@RequestParam("url") String url) {
特殊な XML 文字のエスケープが無効になっている出力を検出します。
 - 特別な XML 文字のエスケープが無効です。 + 特別な XML 文字のエスケープが無効 特殊な XML 文字のエスケープを無効にすると XSS 脆弱性が発生する可能性があります。
-潜在的な XSS を発見しました。クライアントのブラウザで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照) +潜在的な XSS を発見しました。クライアントのブラウザーで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照)

脆弱なコード: @@ -3425,14 +3910,14 @@ public String redirect(@RequestParam("url") String url) { <c:out value="${param.test_param}"/>

-
+

-参考文献
-WASC-8: Cross Site Scripting
-OWASP: XSS Prevention Cheat Sheet
-OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
-CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
-JSTL Javadoc: Out tag
+参考文献
+WASC-8: Cross Site Scripting
+OWASP: XSS Prevention Cheat Sheet
+OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
+CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+JSTL Javadoc: Out tag

]]>
@@ -3449,7 +3934,7 @@ public String redirect(@RequestParam("url") String url) {
-潜在的な XSS を発見しました。クライアントのブラウザで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照) +潜在的な XSS を発見しました。クライアントのブラウザーで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照)

脆弱なコード: @@ -3474,14 +3959,14 @@ XSS に対する最善の防御は，上記の例のような特定の状況で 考慮すべきコンテキストは4つあります: HTML，JavaScript，CSS (スタイル)，URL です。 OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに従ってください。これらの防御について詳細に説明しています。

-
+

-参考文献
-WASC-8: Cross Site Scripting
-OWASP: XSS Prevention Cheat Sheet
-OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
-CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
-OWASP Java Encoder
+参考文献
+WASC-8: Cross Site Scripting
+OWASP: XSS Prevention Cheat Sheet
+OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
+CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+OWASP Java Encoder

]]>
@@ -3494,11 +3979,11 @@ OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに サーブレット内の潜在的な XSS - {3} の使用は，XSS に対して脆弱である可能性があります。 + サーブレット内で {3} の使用は，XSS に対して脆弱である可能性があります。
-潜在的な XSS を発見しました。クライアントのブラウザで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照) +潜在的な XSS を発見しました。クライアントのブラウザーで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照)

脆弱なコード: @@ -3524,14 +4009,14 @@ OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに

サーブレット XSS ルールは類似の問題を探しますが，既存の SpotBugs のルール「XSS:型クロスサイトスクリプティング脆弱性があるサーブレット」と 「XSS:反射型クロスサイトスクリプティング脆弱性がエラーページにあるサーブレット」とは異なる方法で探します。

-
+

-参考文献
-WASC-8: Cross Site Scripting
-OWASP: XSS Prevention Cheat Sheet
-OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
-CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
-OWASP Java Encoder
+参考文献
+WASC-8: Cross Site Scripting
+OWASP: XSS Prevention Cheat Sheet
+OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
+CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+OWASP Java Encoder

]]>
@@ -3568,7 +4053,7 @@ OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに </java>

-上記の XML コードはコンテンツ "Hello World！" を持つファイルが作成されます。 +上記の XML コードはコンテンツ "Hello World!" を持つファイルが作成されます。

脆弱なコード:
@@ -3582,12 +4067,12 @@ try { 解決策:
解決策は，信頼できないソースからのコンテンツの解析に XMLDecoder を使用しないようにすることです。

-
+

-参考文献
-Dinis Cruz Blog: Using XMLDecoder to execute server-side Java Code on an Restlet application
-RedHat blog : Java deserialization flaws: Part 2, XML deserialization
-CWE-20: Improper Input Validation +参考文献
+Dinis Cruz Blog: Using XMLDecoder to execute server-side Java Code on an Restlet application
+RedHat blog : Java deserialization flaws: Part 2, XML deserialization
+CWE-20: Improper Input Validation

]]> @@ -3605,7 +4090,7 @@ try {
-暗号化するメッセージごとに初期化ベクトル (IV:Initialization vector) を再生成する必要があります。 +暗号化するメッセージごとに初期化ベクトル (IV:Initialization vector) を再生成しなければなりません。

脆弱なコード:

@@ -3629,11 +4114,11 @@ public void encrypt(String message) throws Exception { [...]

-
+

-参考文献
-Wikipedia: Initialization vector
-CWE-329: Not Using a Random IV with CBC Mode
+参考文献
+Wikipedia: Initialization vector
+CWE-329: Not Using a Random IV with CBC Mode
Encryption - CBC Mode IV: Secret or Not?

]]> @@ -3653,7 +4138,7 @@ public void encrypt(String message) throws Exception { 暗号は，暗号化されたデータの機密性が低い ECB モードを使用しています。
守秘義務のない Electronic Codebook (ECB) モードの代わりに暗号化されたデータのより良い機密性を提供する認証暗号モードを使用すべきです。 +

守秘義務のない Electronic Code Book (ECB) モードの代わりに暗号化されたデータのより良い機密性を提供する認証暗号モードを使用すべきです。 特に，ECB モードは毎回同じ入力に対して同じ出力を生成します。たとえば，ユーザーがパスワードを送信するとき，暗号化された値は毎回同じです。 これにより，攻撃者はデータを傍受して再生することができます。

@@ -3671,13 +4156,13 @@ byte[] cipherText = c.doFinal(plainText); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText);

-
+

-参考文献
-Wikipedia: Authenticated encryption
-NIST: Authenticated Encryption Modes
-Wikipedia: Block cipher modes of operation
-NIST: Recommendation for Block Cipher Modes of Operation +参考文献
+Wikipedia: Authenticated encryption
+NIST: Authenticated Encryption Modes
+Wikipedia: Block cipher modes of operation
+NIST: Recommendation for Block Cipher Modes of Operation

]]>
@@ -3693,7 +4178,7 @@ byte[] cipherText = c.doFinal(plainText); この特定のモード (PKCS5Padding を使った CBC) は，パッディングオラクル攻撃の影響を受けやすいです。 -システムが無効または有効なパディングによって平文の違いを暴露すると敵はメッセージを解読できるかもしれません。 +システムが無効または有効なパディングによって平文の違いを暴露すると，攻撃者はメッセージを解読できるかもしれません。 有効なパディングと無効なパディングの違いは，通常，各条件に対して返されるエラーメッセージによって明らかにされます。

@@ -3708,14 +4193,14 @@ byte[] cipherText = c.doFinal(plainText); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText);

-
+

- 参考文献
- Padding Oracles for the masses (by Matias Soler)
- Wikipedia: Authenticated encryption
- NIST: Authenticated Encryption Modes
- CAPEC: Padding Oracle Crypto Attack
- CWE-696: Incorrect Behavior Order + 参考文献
+ Padding Oracles for the masses (by Matias Soler)
+ Wikipedia: Authenticated encryption
+ NIST: Authenticated Encryption Modes
+ CAPEC: Padding Oracle Crypto Attack
+ CWE-696: Incorrect Behavior Order

]]>
@@ -3735,23 +4220,23 @@ byte[] cipherText = c.doFinal(plainText);

解決策は，データに署名するためのハッシュベースのメッセージ認証コード (HMAC:Hash-based Message Authentication Code) を含む暗号を使用することです。 -HMAC 関数を既存の暗号と組み合わせると，エラーが発生しやすくなります [1]。 +HMAC 関数を既存の暗号と組み合わせると，エラーが発生しやすくなります [1]。 具体的には，常に HMAC を最初に検証できることが推奨されます。データが変更されていないときに限り，データに対して暗号化関数を実行します。

-

次のモードは，HMAC を提供しないため脆弱です。
- - CBC
- - OFB
- - CTR
- - ECB

- 次のスニペットコードは，脆弱なコードの例です。

- リスクのあるコード:
- CBC モードで AES
+

次のモードは，HMAC を提供しないため脆弱です。
+ - CBC
+ - OFB
+ - CTR
+ - ECB

+ 次のスニペットコードは，脆弱なコードの例です。

+ リスクのあるコード:
+ CBC モードで AES

Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
 c.init(Cipher.ENCRYPT_MODE, k, iv);
 byte[] cipherText = c.doFinal(plainText);
-
- ECB モードのトリプル DES
+
+ ECB モードのトリプル DES
Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
 c.init(Cipher.ENCRYPT_MODE, k, iv);
@@ -3766,13 +4251,13 @@ byte[] cipherText = c.doFinal(plainText);

上記の解決例では，GCM モードは結果の暗号化されたデータに HMAC を導入し，結果の完全性を提供します。

-
+

- 参考文献
- Wikipedia: Authenticated encryption
- NIST: Authenticated Encryption Modes
- Moxie Marlinspike's blog: The Cryptographic Doom Principle
- CWE-353: Missing Support for Integrity Check + 参考文献
+ Wikipedia: Authenticated encryption
+ NIST: Authenticated Encryption Modes
+ Moxie Marlinspike's blog: The Cryptographic Doom Principle
+ CWE-353: Missing Support for Integrity Check

]]> @@ -3793,15 +4278,15 @@ byte[] cipherText = c.doFinal(plainText); ESAPI には，暗号化コンポーネント内にちょっとした脆弱性の前歴があります。 ここでは，認証付き暗号 (Authenticated Encryption) が期待どおりに機能しているかどうかを確認する簡単な検証リストを示します。

-

1. ライブラリのバージョン

+

1. ライブラリーのバージョン

-この問題は，ESAPI のバージョン 2.1.0 で修正されています。バージョン 2.0.1 以前は，MAC バイパスに対して脆弱です (CVE-2013-5679)。
+この問題は，ESAPI のバージョン 2.1.0 で修正されています。バージョン 2.0.1 以前は，MAC バイパスに対して脆弱です (CVE-2013-5679)。

- Maven ユーザーならプラグイン versions を次のコマンドを使用して呼び出せます。 - ESAPI の有効なバージョンは，その出力から入手できます。
+ Maven ユーザーならプラグイン versions を次のコマンドを使用して呼び出せます。 + ESAPI の有効なバージョンは，その出力から入手できます。

$ mvn versions:display-dependency-updates
-
出力:
+
出力:
 [...]
 [INFO] The following dependencies in Dependencies have newer versions:
@@ -3811,7 +4296,7 @@ ESAPI には，暗号化コンポーネント内にちょっとした脆弱性

- または，直接設定を見ることによって.
+ または，直接設定を見ることによって.

 <dependency>
     <groupId>org.owasp.esapi</groupId>
@@ -3820,14 +4305,14 @@ ESAPI には，暗号化コンポーネント内にちょっとした脆弱性
 </dependency>

-Ant ユーザーなら使用する jar は esapi-2.1.0.jar でなければなりません。 +Ant ユーザーなら使用する jar は esapi-2.1.0.jar でなければなりません。

2. 設定:

- ライブラリバージョン 2.1.0 は，いまだに暗号文定義で鍵長が変更されると脆弱です (CVE-2013-5960)。いくつかの予防措置を講ずる必要があります。
-
-

これらの要素のいずれかが存在すると ESAPI の暗号化設定も脆弱になる可能性があります:
- 安全でない設定:
+ ライブラリーバージョン2.1.0は，暗号文定義で変更さる鍵長に対して依然として脆弱です (CVE-2013-5960)。いくつかの予防措置を講ずる必要があります。
+
+
これらの要素のいずれかが存在すると ESAPI の暗号化設定も脆弱になる可能性があります:
+ 安全でない設定:
 Encryptor.CipherText.useMAC=false
 
@@ -3839,7 +4324,7 @@ Encryptor.cipher_modes.additional_allowed=CBC

- Secure configuration:
+ Secure configuration:
 #必要
 Encryptor.CipherText.useMAC=true
@@ -3852,14 +4337,14 @@ Encryptor.CipherTransformation=AES/GCM/NoPadding
 Encryptor.cipher_modes.additional_allowed=

-
+

- 参考文献
- ESAPI Security bulletin 1 (CVE-2013-5679)
- Vulnerability Summary for CVE-2013-5679
- Synactiv: Bypassing HMAC validation in OWASP ESAPI symmetric encryption
- CWE-310: Cryptographic Issues
- ESAPI-dev mailing list: Status of CVE-2013-5960
+ 参考文献
+ ESAPI Security bulletin 1 (CVE-2013-5679)
+ Vulnerability Summary for CVE-2013-5679
+ Synactiv: Bypassing HMAC validation in OWASP ESAPI symmetric encryption
+ CWE-310: Cryptographic Issues
+ ESAPI-dev mailing list: Status of CVE-2013-5960

]]> @@ -3878,12 +4363,12 @@ Encryptor.cipher_modes.additional_allowed= アプリケーションは外部ストレージ (SD カード) にデータを書き込みます。このアクションには複数のセキュリティの影響があります。 -まず，SD カード上のファイルストアは，READ_EXTERNAL_STORAGE +まず，SD カード上のファイルストアは，READ_EXTERNAL_STORAGE 権限を持つアプリケーションからアクセスできるようになります。 また，永続化されたデータにユーザーに関する機密情報が含まれているときは，暗号化が必要になります。

- リスクのあるコード:
+ リスクのあるコード:

 file file = new File(getExternalFilesDir(TARGET_TYPE), filename);
 fos = new FileOutputStream(file);
@@ -3892,19 +4377,19 @@ fos.flush();

- より良い代替手段:
+ より良い代替手段:

 fos = openFileOutput(filename, Context.MODE_PRIVATE);
 fos.write(string.getBytes());

-
+

- 参考文献
- Android Official Doc: Security Tips
- CERT: DRD00-J: Do not store sensitive information on external storage [...]
- Android Official Doc: Using the External Storage
- OWASP Mobile Top 10 2014-M2: Insecure Data Storage
+ 参考文献
+ Android Official Doc: Security Tips
+ CERT: DRD00-J: Do not store sensitive information on external storage [...]
+ Android Official Doc: Using the External Storage
+ OWASP Mobile Top 10 2014-M2: Insecure Data Storage
CWE-312: Cleartext Storage of Sensitive Information

]]> @@ -3924,10 +4409,10 @@ fos.write(string.getBytes());
-ブロードキャストインテントは，適切な権限を持つ任意のアプリケーションで受け取ることができます。可能であれば機密情報を送信しないようにすることをお勧めします。 +ブロードキャストインテントは，適切なパーミッションがあれば，どのアプリケーションでも受け取ることができます。可能であれば機密情報を送信しないようにすることをお勧めします。

- リスクのあるコード:
+ リスクのあるコード:

 Intent i = new Intent();
 i.setAction("com.insecure.action.UserConnected");
@@ -3938,9 +4423,9 @@ i.putExtra("session", newSessionId);
 this.sendBroadcast(v1);

-
+

- 解決策 (可能なら):
+ 解決策 (可能なら):

 Intent i = new Intent();
 i.setAction("com.secure.action.UserConnected");
@@ -3948,9 +4433,9 @@ i.setAction("com.secure.action.UserConnected");
 sendBroadcast(v1);

-
+

- 設定 (receiver)[1] Source: StackOverflow:
+ 設定 (receiver)[1] Source: StackOverflow:

 <manifest ...>
 
@@ -3970,7 +4455,7 @@ sendBroadcast(v1);

- 設定 (sender)[1] Source: StackOverflow:
+ 設定 (sender)[1] Source: StackOverflow:

 <manifest>
     <!-- We declare we own the permission to send broadcast to the above receiver -->
@@ -3981,14 +4466,14 @@ sendBroadcast(v1);
 </manifest>

-
+

- 参考文献
- CERT: DRD03-J. Do not broadcast sensitive information using an implicit intent
- Android Official Doc: BroadcastReceiver (Security)
- Android Official Doc: Receiver configuration (see android:permission)
- [1] StackOverflow: How to set permissions in broadcast sender and receiver in android
- CWE-925: Improper Verification of Intent by Broadcast Receiver
+ 参考文献
+ CERT: DRD03-J. Do not broadcast sensitive information using an implicit intent
+ Android Official Doc: BroadcastReceiver (Security)
+ Android Official Doc: Receiver configuration (see android:permission)
+ [1] StackOverflow: How to set permissions in broadcast sender and receiver in android
+ CWE-925: Improper Verification of Intent by Broadcast Receiver
CWE-927: Use of Implicit Intent for Sensitive Communication

]]> @@ -3999,44 +4484,45 @@ sendBroadcast(v1); -
作成モード MODE_WORLD_READABLE で書き込まれたファイルを特定します。
+
作成モード MODE_WORLD_READABLE で記述されたファイルを特定します。
 ワールドライタブルファイル (Android) - 書き込まれたコンテンツは，任意のアプリケーションで見ることができます。 + 作成されたコンテンツは，どのアプリケーションでも見ることができます。
-このコンテキストで書き込まれたファイルは，作成モード MODE_WORLD_READABLE を使用しています。 +このコンテキストで記述されたファイルは，作成モード MODE_WORLD_READABLE を使用しています。 書き込まれたコンテンツが暴露されることは期待した動作ではないかもしれません。

- リスクのあるコード:
+ リスクのあるコード:

 fos = openFileOutput(filename, MODE_WORLD_READABLE);
 fos.write(userInfo.getBytes());

-
+

- 解決策 (MODE_PRIVATE の使用):
+ 解決策 (MODE_PRIVATE の使用):

 fos = openFileOutput(filename, MODE_PRIVATE);

- 解決策 (ローカル SQLite データベースの使用):
+ 解決策 (ローカル SQLite データベースの使用):
おそらく構造化されたデータを格納するための最良の解決策は，ローカルの SQLite データベースを使用することです。 データベースファイルが外部ストレージに作成されていないことを確認してください。実装ガイドラインについては，次の参考文献を参照してください。

-
+

- 参考文献
- CERT: DRD11-J. Ensure that sensitive data is kept secure
- Android Official Doc: Security Tips
- Android Official Doc: Context.MODE_PRIVATE
- vogella.com: Android SQLite database and content provider - Tutorial
- OWASP Mobile Top 10 2014-M2: Insecure Data Storage
+ 参考文献
+ CERT: DRD11-J. Ensure that sensitive data is kept secure
+ Android Official Doc: Security Tips
+ Android Official Doc: Context.MODE_PRIVATE
+ vogella.com: Android SQLite database and content provider - Tutorial
+ vogella.com: Android SQLite database and content provider - Tutorial
+ OWASP Mobile Top 10 2014-M2: Insecure Data Storage
CWE-312: Cleartext Storage of Sensitive Information

]]> @@ -4058,7 +4544,7 @@ fos = openFileOutput(filename, MODE_PRIVATE); ジオロケーションの取得についてユーザーに確認を求めることをお勧めします。

- リスクのあるコード:
+ リスクのあるコード:

 webView.setWebChromeClient(new WebChromeClient() {
     @Override
@@ -4069,7 +4555,7 @@ webView.setWebChromeClient(new WebChromeClient() {

- Suggested code:
+ Suggested code:
ジオロケーションのサンプリングを制限し，ユーザーに確認を求めます。 

@@ -4083,12 +4569,12 @@ webView.setWebChromeClient(new WebChromeClient() {
 });

-
+

- 参考文献
- CERT: DRD15-J. Consider privacy concerns when using Geolocation API
- Wikipedia: W3C Geolocation API
- W3C: Geolocation Specification
+ 参考文献
+ CERT: DRD15-J. Consider privacy concerns when using Geolocation API
+ Wikipedia: W3C Geolocation API
+ W3C: Geolocation Specification

]]>
@@ -4106,7 +4592,7 @@ webView.setWebChromeClient(new WebChromeClient() {
-WebView で JavaScript を有効にすると XSS の影響を受けやすくなります。潜在的な反映型 XSS，格納型 XSS，DOM XSS についてページレンダリングを検査すべきです。
+WebView で JavaScript を有効にすると XSS の影響を受けやすくなります。潜在的な反映型 XSS，格納型 XSS，DOM XSS についてページレンダリングを検査すべきです。
 WebView myWebView = (WebView) findViewById(R.id.webView);
 WebSettings webSettings = myWebView.getSettings();
@@ -4115,7 +4601,7 @@ webSettings.setJavaScriptEnabled(true);
 

 
 

-    リスクのあるコード:

+    リスクのあるコード:

 JavaScript を有効にすることは悪いことではありません。潜在的な XSS に対してバックエンドコードを監査する必要があることを意味します。
 XSS は，クライアント側に DOM XSS を導入することもできます。
 
@@ -4124,15 +4610,15 @@ function updateDescription(newDescription) {
 }
 

 

-

+

 

-    参考文献

-    Issue: Using setJavaScriptEnabled can introduce XSS vulnerabilities

-    Android Official Doc: WebView

-    WASC-8: Cross Site Scripting

-    OWASP: XSS Prevention Cheat Sheet

-    OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)

-    CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+    参考文献

+    Issue: Using setJavaScriptEnabled can introduce XSS vulnerabilities

+    Android Official Doc: WebView

+    WASC-8: Cross Site Scripting

+    OWASP: XSS Prevention Cheat Sheet

+    OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)

+    CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
 

 ]]>
@@ -4142,20 +4628,20 @@ function updateDescription(newDescription) { -
Java ブリッジがある WebView (JavaScript インターフェース).
+
Java ブリッジがある WebView (JavaScript インタフェース).
 - JavaScript インターフェースがある WebView (Android) - JavaScript インターフェースがある WebView + JavaScript インタフェースがある WebView (Android) + JavaScript インタフェースがある WebView
-JavaScript インターフェースを使用すると WebView が危険な API にさらされる可能性があります。 +JavaScript インタフェースを使用すると WebView が危険な API にさらされる可能性があります。 WebView で XSS が引き起こされると，そのクラスは悪質な JavaScript コードによって呼び出される可能性があります。

- リスクのあるコード:
+ リスクのあるコード:

 WebView myWebView = (WebView) findViewById(R.id.webView);
 
@@ -4178,34 +4664,34 @@ class FileWriteUtil {
 }

-
+

- 参考文献
- Android Official Doc: WebView.addJavascriptInterface()
+ 参考文献
+ Android Official Doc: WebView.addJavascriptInterface()
CWE-749: Exposed Dangerous Method or Function

]]>
- Java ブリッジがある WebView (Javascript インターフェース) (Android) + Java ブリッジがある WebView (Javascript インタフェース) (Android) -
Secure フラグが設定されていないクッキーを特定します。
+
Secure フラグが設定されていない Cookie を特定します。
 - Secure フラグがないクッキー - HTTP URL にアクセスすると Secure フラグが設定されていないクッキーを平文で送信できる可能性があります。 + Secure フラグがない Cookie + HTTP URL にアクセスすると Secure フラグが設定されていない Cookie を平文で送信できる可能性があります。
-Secure フラグが設定されていない新しいクッキーが作成されています。 -Secure フラグは安全でない通信 (http://) のためにクッキーが送信されないようにするためのブラウザへの指示です。 +Secure フラグが設定されていない新しい Cookie が作成されています。 +Secure フラグは安全でない通信 (http://) のために Cookie が送信されないようにするためのブラウザーへの指示です。

-リスクのあるコード:
+リスクのあるコード:

 Cookie cookie = new Cookie("userName",userName);
 response.addCookie(cookie);
@@ -4213,16 +4699,16 @@ response.addCookie(cookie);
 

 
 

-解決策 (具体的な設定):

+解決策 (具体的な設定):

 
 Cookie cookie = new Cookie("userName",userName);
-cookie.setSecure(true); // Secure flag
+cookie.setSecure(true); // セキュアフラグ
 cookie.setHttpOnly(true);
 

 

 
 

-解決策 (Servlet 3.0 の設定):

+解決策 (Servlet 3.0 の設定):

 
 <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="3.0">
 [...]
@@ -4235,34 +4721,34 @@ cookie.setHttpOnly(true);
 </web-app>
 

 

-

+

 

-Reference

-CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

-CWE-315: Cleartext Storage of Sensitive Information in a Cookie

-CWE-311: Missing Encryption of Sensitive Data

-OWASP: Secure Flag

+Reference

+CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

+CWE-315: Cleartext Storage of Sensitive Information in a Cookie

+CWE-311: Missing Encryption of Sensitive Data

+OWASP: Secure Flag

 Rapid7: Missing Secure Flag From SSL Cookie
 

 ]]>
- Secure フラグがないクッキー + Secure フラグがない Cookie - HttpOnly フラグがないクッキー - HttpOnly フラグが設定されていないクッキーは，ブラウザの悪意のあるスクリプトによって赤色になる可能性があります。 + HttpOnly フラグがない Cookie + HttpOnly フラグのない Cookie は，ブラウザー内の悪意のあるスクリプトによって読み取られる可能性があります。
-HttpOnly が設定されていない新しいクッキーが作成されています。 -HttpOnly フラグは，悪意のあるスクリプトによってクッキーが赤色にならないようにするためのブラウザへの指示です。 -ユーザーが XSS の対象になっていると，攻撃者はセッション ID を取得するなどの利益を得ます。 +HttpOnly が設定されていない新しい Cookie が作成されています。 +HttpOnly フラグは，悪意のあるスクリプトによって Cookie が読み取られないようにするためのブラウザーへの指示です。 +ユーザーが XSS の対象になっていると，攻撃者はセッション ID を取得するなどの恩恵を得ます。

-リスクのあるコード:
+リスクのあるコード:

 Cookie cookie = new Cookie("email",userName);
 response.addCookie(cookie);
@@ -4270,7 +4756,7 @@ response.addCookie(cookie);
 

 
 

-解決策 (具体的な設定):

+解決策 (具体的な設定):

 
 Cookie cookie = new Cookie("email",userName);
 cookie.setSecure(true);
@@ -4279,7 +4765,7 @@ cookie.setHttpOnly(true); //HttpOnly flag
 

 
 

-解決策 (Servlet 3.0 の設定):

+解決策 (Servlet 3.0 の設定):

 
 <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="3.0">
 [...]
@@ -4292,33 +4778,33 @@ cookie.setHttpOnly(true); //HttpOnly flag
 </web-app>
 

 

-

+

 

-Reference

-Coding Horror blog: Protecting Your Cookies: HttpOnly

-OWASP: HttpOnly

+Reference

+Coding Horror blog: Protecting Your Cookies: HttpOnly

+OWASP: HttpOnly

 Rapid7: Missing HttpOnly Flag From Cookie
 

 ]]>
- HttpOnly フラグがないクッキー + HttpOnly フラグがない Cookie -
オブジェクトデシリアライズを検出します。
+
オブジェクトのデシリアライズを検出します。
 - オブジェクトのデシリアライズが使用されている + オブジェクトデシリアライズの使用 オブジェクトのデシリアライズが使用されています。{1}
-悪意のある操作のきっかけを許すクラスパスにクラスが存在すると信頼できないデータのオブジェクトのデシリアライズにより，リモートでコードが実行される可能性があります。 +悪意のある操作のきっかけを許すクラスパスにクラスが存在すると信頼できないデータのオブジェクトのデシリアライズにより，リモートコード実行を引き起こす可能性があります。

-ライブラリ開発者は，潜在的な悪意のあるトリガーを提供するクラスを修正する傾向があります。 +ライブラリー開発者は，潜在的な悪意のあるトリガーを提供するクラスを修正する傾向があります。 サービス拒否 [1] をもたらすことが知られているクラスはまだあります。

@@ -4327,7 +4813,7 @@ Java 仮想マシン [2] [3] に新しい脆弱性が見つかると

-リスクのあるコード:
+リスクのあるコード:

 public UserData deserializeObject(InputStream receivedFile) throws IOException, ClassNotFoundException {
 
@@ -4339,25 +4825,25 @@ public UserData deserializeObject(InputStream receivedFile) throws IOException,
 

 
 

-解決策:

+解決策:

 

 リモートユーザーが提供するオブジェクトのデシリアライズをしない。
 

-

+

 

-参考文献

-CWE-502: Deserialization of Untrusted Data

-Deserialization of untrusted data

-Serialization and Deserialization 

-A tool for generating payloads that exploit unsafe Java object deserialization

-[1] Example of Denial of Service using the class java.util.HashSet

-[2] OpenJDK: Deserialization issue in ObjectInputStream.readSerialData() (CVE-2015-2590)

+参考文献

+CWE-502: Deserialization of Untrusted Data

+Deserialization of untrusted data

+Serialization and Deserialization 

+A tool for generating payloads that exploit unsafe Java object deserialization

+[1] Example of Denial of Service using the class java.util.HashSet

+[2] OpenJDK: Deserialization issue in ObjectInputStream.readSerialData() (CVE-2015-2590)

 [3] Rapid7: Sun Java Calendar Deserialization Privilege Escalation (CVE-2008-5353)
 

 ]]>
- オブジェクトのデシリアライズが使用されています。 + オブジェクトのデシリアライズが使用されている @@ -4369,17 +4855,17 @@ public UserData deserializeObject(InputStream receivedFile) throws IOException, 安全でない Jackson のデシリアライズ設定が使用されています。{1} {2} {3}
Jackson のデータバインドライブラリが不正に使用され，悪意のある操作のトリガ-を可能にするクラスパスにクラスがあると -信頼できないデータのデシリアライズによりリモートコードが実行される可能性があります。

+

Jackson のデータバインドライブラリーが不正に使用され，悪意のある操作のトリガ-を可能にするクラスパスにクラスがあると +信頼できないデータのデシリアライズによりリモートコード実行を引き起こす可能性があります。

-解決策:
+解決策:

JsonTypeInfo.Id.NAME を介して多態性を使用するときに使用できるタイプとサブタイプを明示的に定義します。 -また，ObjectMapper を決して呼び出さないでください。enableDefaultTyping (それと，readValue は Object，Serializable，Comparable，または既知のデシリアライズ型を保持する型です)。 +また，ObjectMapper.enableDefaultTyping を決して呼び出さないでください。(そして，readValue は Object，Serializable，Comparable，または既知のデシリアライズ型を保持します)。

-リスクのあるコード:
+リスクのあるコード:

 public class Example {
     static class ABean {
@@ -4408,7 +4894,7 @@ public class Example {
 

 
 

-参考文献

+参考文献

 Jackson Deserializer security vulnerability

 Java Unmarshaller Security - Turning your data into code execution

 

@@ -4423,26 +4909,26 @@ public class Example {
     
 
     
-        このクラスは，デシリアライゼーションガジェットとして使用できる
+        デシリアライゼーションガジェットとして使用できるクラス
         このクラスは，シリアライズを使用するアプリケーションを脆弱にする可能性があります。
         

             
-デシリアライゼーションガジェットは，ネイティブシリアライゼーションを使ってリモート API を利用するため，攻撃者によって使用されるクラスです。
-このクラスは，readObject メソッド (シリアライズ可能) を使用してデシリアライズにカスタム動作を追加するかシリアライズされたオブジェクト (InvocationHandler) から呼び出されます。
+デシリアライゼーションガジェットは，攻撃者がネイティブシリアライゼーションを使用してリモート API を利用するために使用できるクラスです。
+このクラスは，readObject メソッド (シリアライズ可能) を使用してデシリアライズにカスタム動作を追加するかシリアライズされたオブジェクト (InvocationHandler) から呼び出されます。
 

 

-このディテクタは，主に研究者によって使用されることを意図しています。本当に問題なのは，リモート操作にデシリアライズを使用することです。
+このディテクターは，主に研究者によって使用されることを意図しています。本当に問題なのは，リモート操作にデシリアライズを使用することです。
 ガジェットを除去することは，悪用されるリスクを減らすための堅牢な方法です。
 

 

-参考文献

-CWE-502: Deserialization of Untrusted Data

-Deserialization of untrusted data

-Serialization and Deserialization 

-A tool for generating payloads that exploit unsafe Java object deserialization

-[1] Example of Denial of Service using the class java.util.HashSet

-[2] OpenJDK: Deserialization issue in ObjectInputStream.readSerialData() (CVE-2015-2590)

+参考文献

+CWE-502: Deserialization of Untrusted Data

+Deserialization of untrusted data

+Serialization and Deserialization 

+A tool for generating payloads that exploit unsafe Java object deserialization

+[1] Example of Denial of Service using the class java.util.HashSet

+[2] OpenJDK: Deserialization issue in ObjectInputStream.readSerialData() (CVE-2015-2590)

 [3] Rapid7: Sun Java Calendar Deserialization Privilege Escalation (CVE-2008-5353)
 

 ]]>
@@ -4461,7 +4947,7 @@ public class Example {
 
     
         Trust Boundary Violation
-        アプリケーションは，信頼できるデータと信頼できないデータをセッション属性で混合しています。
+        アプリケーションは，セッション属性で信頼できるデータと信頼できないデータを混在させています。
         

             
@@ -4472,7 +4958,7 @@ public class Example {
 

 
 

-リスクのあるコード:

+リスクのあるコード:

 
 public void doSomething(HttpServletRequest req, String activateProperty) {
     //..
@@ -4481,7 +4967,7 @@ public void doSomething(HttpServletRequest req, String activateProperty) {
 
 }
 

-

+

 
 public void loginEvent(HttpServletRequest req, String userSubmitted) {
     //..
@@ -4492,14 +4978,14 @@ public void loginEvent(HttpServletRequest req, String userSubmitted) {
 

 
 

-解決策:

+解決策:

 

 解決策は，新しいセッション属性を設定する前に検証を追加することです。可能であれば，ダイレクトユーザー入力の使用よりも安全な場所からのデータを選びます。
 

-

+

 

-参考文献

-[1] CWE-501: Trust Boundary Violation

+参考文献

+[1] CWE-501: Trust Boundary Violation

 OWASP : Trust Boundary Violation
 

 ]]>
@@ -4512,60 +4998,60 @@ public void loginEvent(HttpServletRequest req, String userSubmitted) {
         
JSP で行われた XSL 変換を特定します。

     
     
-        悪意のある XSLT が提供される可能性があります。
-        悪意のある XSLT を提供して，リモートでコードを実行させることができます。
+        悪意のある XSLT が JSP タグに提供される可能性
+        悪意のある XSLT を JSP タグに提供して，リモートコード実行を引き起こすことができます。
         

             
-「XSLT (Extensible Stylesheet Language Transformations) は，XML 文書を他のXML文書に変換するための言語です。」[1]

+「XSLT (Extensible Stylesheet Language Transformations) は，XML 文書を他のXML文書に変換するための言語です。」[1]

 スタイルシートに悪意のある振る舞いを付けることは可能です。
-したがって，攻撃者がスタイルシートの内容やソースを制御できると，攻撃者はリモートでコードの実行をトリガーできる可能性があります。[2]
+したがって，攻撃者がスタイルシートの内容やソースを制御できると，リモートコード実行を引き起こすことができます。[2]
 

 

-リスクのあるコード:

+リスクのあるコード:

 
 <x:transform xml="${xmlData}" xslt="${xsltControlledByUser}" />
 

 

 

-解決策:

+解決策:

 

 解決策は，スタイルシートが安全なソースからロードされていることを確認し，パストラバーサル [3] [4] のような脆弱性が確実に起こらないようにすることです。
 

 

-参考文献

-[1] Wikipedia: XSLT (Extensible Stylesheet Language Transformations)

-Offensive XSLT by Nicolas Gregoire

-[2] From XSLT code execution to Meterpreter shells by Nicolas Gregoire

-XSLT Hacking Encyclopedia by Nicolas Gregoire

-Acunetix.com : The hidden dangers of XSLTProcessor - Remote XSL injection

-w3.org XSL Transformations (XSLT) Version 1.0 : w3c specification

-[3] WASC: Path Traversal

-[4] OWASP: Path Traversal

+参考文献

+[1] Wikipedia: XSLT (Extensible Stylesheet Language Transformations)

+Offensive XSLT by Nicolas Gregoire

+[2] From XSLT code execution to Meterpreter shells by Nicolas Gregoire

+XSLT Hacking Encyclopedia by Nicolas Gregoire

+Acunetix.com : The hidden dangers of XSLTProcessor - Remote XSL injection

+w3.org XSL Transformations (XSLT) Version 1.0 : w3c specification

+[3] WASC: Path Traversal

+[4] OWASP: Path Traversal

 

             ]]>
         

     
-    悪意のある XSLT が提供される可能性があります。
+    悪意のある XSLT が JSP タグで提供される可能性がある
 
     
     
         
XSL 変換を特定します。

     
     
-        悪意のある XSLT が提供される可能性があります。
-        悪意のある XSLT を提供して，リモートでコードを実行させることができます。
+        悪意のある XSLT が提供される可能性
+        悪意のある XSLT を提供して，リモートコード実行を引き起こすことができます。
         

             
-「XSLT (Extensible Stylesheet Language Transformations) は，XML 文書を他のXML文書に変換するための言語です。」[1]

+「XSLT (Extensible Stylesheet Language Transformations) は，XML 文書を他のXML文書に変換するための言語です。」[1]

 スタイルシートに悪意のある振る舞いを付けることは可能です。
-したがって，攻撃者がスタイルシートの内容やソースを制御できると，攻撃者はリモートでコードの実行をトリガーできる可能性があります。[2]
+したがって，攻撃者がスタイルシートの内容やソースを制御できると，リモートコード実行を引き起こせすことができます。[2]
 

 

-リスクのあるコード:

+リスクのあるコード:

 
-Source xslt = new StreamSource(new FileInputStream(inputUserFile)); //Dangerous source to validate
+Source xslt = new StreamSource(new FileInputStream(inputUserFile)); // 危険なソース
 
 Transformer transformer = TransformerFactory.newInstance().newTransformer(xslt);
 
@@ -4574,25 +5060,36 @@ transformer.transform(text, new StreamResult(...));
 

 

 

-解決策:

+解決策:

+
+
解決策は，java.lang.Runtime などの Java クラスへの潜在的な参照をブロックする安全な処理モードを有効にすることです。

+
+
+TransformerFactory factory = TransformerFactory.newInstance();
+factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
+Source xslt  = new StreamSource(new FileInputStream(inputUserFile));
+
+Transformer transformer = factory.newTransformer(xslt);
+

+
 

-解決策は，スタイルシートが安全なソースからロードされていることを確認し，パストラバーサル [3] [4] のような脆弱性が確実に起こらないようにすることです。
+または，スタイルシートが安全なソースからロードされていることを確認し，パストラバーサル [3] [4] のような脆弱性が確実に起こらないようにすることです。
 

 

-参考文献

-[1] Wikipedia: XSLT (Extensible Stylesheet Language Transformations)

-Offensive XSLT by Nicolas Gregoire

-[2] From XSLT code execution to Meterpreter shells by Nicolas Gregoire

-XSLT Hacking Encyclopedia by Nicolas Gregoire

-Acunetix.com : The hidden dangers of XSLTProcessor - Remote XSL injection

-w3.org XSL Transformations (XSLT) Version 1.0 : w3c specification

-[3] WASC: Path Traversal

-[4] OWASP: Path Traversal

+参考文献

+[1] Wikipedia: XSLT (Extensible Stylesheet Language Transformations)

+Offensive XSLT by Nicolas Gregoire

+[2] From XSLT code execution to Meterpreter shells by Nicolas Gregoire

+XSLT Hacking Encyclopedia by Nicolas Gregoire

+Acunetix.com : The hidden dangers of XSLTProcessor - Remote XSL injection

+w3.org XSL Transformations (XSLT) Version 1.0 : w3c specification

+[3] WASC: Path Traversal

+[4] OWASP: Path Traversal

 

             ]]>
         

     
-    悪意のある XSLT が提供される可能性があります。
+    悪意のある XSLT が提供される可能性がある
 
     
     
@@ -4611,7 +5108,7 @@ transformer.transform(text, new StreamResult(...));
 機密データの例には，API キー，パスワード，製品バージョン，環境設定が含まれます (ただしこれに限定されません)。
 

 

-リスクのあるコード:

+リスクのあるコード:

 
def doGet(value:String) = Action {
   val configElement = configuration.underlying.getString(value)
 
@@ -4619,13 +5116,13 @@ transformer.transform(text, new StreamResult(...));
 }

 

 

-アプリケーションの構成要素を応答コンテンツに送信しないでください。また，コードによって使用される構成要素をユーザーが制御できないようにすべきです。
+アプリケーション構成要素を応答コンテンツで送信しないでください。また，ユーザーがコードで使用する構成要素を制御できないようにすべきです。
 

-参考文献

-OWASP: Top 10 2013-A6-Sensitive Data Exposure

-[1] OWASP: Top 10 2007-Information Leakage and Improper Error Handling

-[2] WASC-13: Information Leakage

-CWE-200: Information Exposure

+参考文献

+OWASP: Top 10 2013-A6-Sensitive Data Exposure

+[1] OWASP: Top 10 2007-Information Leakage and Improper Error Handling

+[2] WASC-13: Information Leakage

+CWE-200: Information Exposure

 

             ]]>
         

@@ -4643,7 +5140,7 @@ transformer.transform(text, new StreamResult(...));
             
 Server-Side Request Forgery (SSRF) は，Web サーバーがユーザーが指定した検証されていない宛先パラメーターへの要求を実行するときに発生します。
-このような脆弱性により，攻撃者は内部サービスにアクセスしたり，Web サーバーから攻撃を開始する可能性があります。
+このような脆弱性により，攻撃者は内部サービスにアクセスしたり，Web サーバーから攻撃を開始できます。
 

 

     脆弱なコード:
@@ -4654,19 +5151,19 @@ Server-Side Request Forgery (SSRF) は，Web サーバーがユーザーが指
 }

- 解決策/対策:
+ 解決策/対策:

  • ユーザーからリクエスト先を受け入れない
    • -
  • 宛先キーを受け入れ，それを使用して対象 (合法) の宛先をルックアップする
    • +
  • 宛先キーを受け入れ，それを使用して対象の宛先をルックアップする
  • URL のホワイトリスト (可能な場合)
  • URL の先頭がホワイトリストの一部であることを検証する

-
+

-参考文献
-CWE-918: Server-Side Request Forgery (SSRF)
-Understanding Server-Side Request Forgery
+参考文献
+CWE-918: Server-Side Request Forgery (SSRF)
+Understanding Server-Side Request Forgery

]]>
 @@ -4678,20 +5175,26 @@ Server-Side Request Forgery (SSRF) は，Web サーバーがユーザーが指 Server-Side Request Forgery (SSRF) は，Web サーバーがユーザーが指定した検証されていない宛先パラメーターへの要求を実行するときに発生します。 -このような脆弱性により，攻撃者は内部サービスにアクセスしたり，Web サーバーから攻撃を開始する可能性があります。 +このような脆弱性により，攻撃者は内部サービスにアクセスしたり，Web サーバーから攻撃を開始できます。

-URLConnection は，file：// プロトコルまたは他のプロトコルと共に使用して，ローカルファイルシステムやその他のサービスにアクセスできます。 +URLConnection は，file：// プロトコルまたは他のプロトコルと共に使用して，ローカルファイルシステムやその他のサービスにアクセスできます。

脆弱なコード: 

 new URL(String url).openConnection()
+
+ +
 new URL(String url).openStream()
+
+ +
 new URL(String url).getContent()

- 解決策/対策:
+ 解決策/対策:

  • ユーザーから URL 宛先を受け入れない
  • 宛先キーを受け入れ，それを使用して対象 (合法) の宛先をルックアップする
    • @@ -4699,13 +5202,13 @@ new URL(String url).getContent()
  • URL の先頭がホワイトリストの一部であることを検証する

-
+

-参考文献
-CWE-918: Server-Side Request Forgery (SSRF)
-Understanding Server-Side Request Forgery
-CWE-73: External Control of File Name or Path
-Abusing jar:// downloads
+参考文献
+CWE-918: Server-Side Request Forgery (SSRF)
+Understanding Server-Side Request Forgery
+CWE-73: External Control of File Name or Path
+Abusing jar:// downloads

]]>
@@ -4717,11 +5220,11 @@ new URL(String url).getContent() Scala Twirl テンプレートエンジンの潜在的な XSS - {3} の使用は，XSS に対して脆弱である可能性があります。 + Twirl テンプレート内で {3} の使用は，XSS に対して脆弱である可能性があります。
-潜在的な XSS を発見しました。クライアントのブラウザで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照) +潜在的な XSS を発見しました。クライアントのブラウザーで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照)

脆弱なコード: @@ -4736,17 +5239,17 @@ new URL(String url).getContent() @value

-XSSに対する最善の防御は，上記の例のような特定の状況で使える出力エンコーディングです。考慮すべきコンテキストは，HTML，JavaScript，CSS (スタイル)，URL の4つです。 +XSS に対する最善の防御は，上記の例のような特定の状況で使える出力エンコーディングです。考慮すべきコンテキストは4つあります: HTML，JavaScript，CSS (スタイル)，URL です。 OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに従ってください。これらの防御について詳細に説明しています。

-
+

-参考文献
-WASC-8: Cross Site Scripting
-OWASP: XSS Prevention Cheat Sheet
-OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
-CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
-OWASP Java Encoder
+参考文献
+WASC-8: Cross Site Scripting
+OWASP: XSS Prevention Cheat Sheet
+OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
+CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+OWASP Java Encoder

]]>
@@ -4763,7 +5266,7 @@ OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに
-潜在的な XSS を発見しました。クライアントのブラウザで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照) +潜在的な XSS を発見しました。クライアントのブラウザーで望まれていない JavaScript を実行するために使用される可能性があります。(参考文献を参照)

脆弱なコード: @@ -4778,17 +5281,17 @@ OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに }

-XSSに対する最善の防御は，上記の例のような特定の状況で使える出力エンコーディングです。考慮すべきコンテキストは，HTML，JavaScript，CSS (スタイル)，URL の4つです。 +XSSに対する最善の防御は，上記の例のような特定の状況で使える出力エンコーディングです。考慮すべきコンテキストは4つあります: HTML，JavaScript，CSS (スタイル)，URL です。 OWASP XSS Prevention Cheat Sheet で定義されている XSS 保護ルールに従ってください。これらの防御について詳細に説明しています。

-
+

-参考文献
-WASC-8: Cross Site Scripting
-OWASP: XSS Prevention Cheat Sheet
-OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
-CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
-OWASP Java Encoder
+参考文献
+WASC-8: Cross Site Scripting
+OWASP: XSS Prevention Cheat Sheet
+OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
+CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+OWASP Java Encoder

]]>
@@ -4817,15 +5320,15 @@ Velocity.evaluate(context, swOut, "test", userInput);

解決策: -
+
エンドユーザーが Velocity を使用してテンプレートを操作できないようにします。 テンプレート編集をユーザーに公開する必要があるときは，Handlebars や Mustache などのロジックレステンプレートエンジンを使用することをお勧めします。(参考文献を参照)

-
+

-参考文献
-PortSwigger: Server-Side Template Injection
-Handlebars.java
+参考文献
+PortSwigger: Server-Side Template Injection
+Handlebars.java

]]> @@ -4854,15 +5357,15 @@ template.process(data, swOut);

解決策: -
+
エンドユーザーが Freemarker を使用してテンプレートを操作できないようにします。 テンプレート編集をユーザーに公開する必要があるときは，Handlebars や Mustache などのロジックレステンプレートエンジンを使用することをお勧めします。(参考文献を参照)

-
+

-参考文献
-PortSwigger: Server-Side Template Injection
-Handlebars.java
+参考文献
+PortSwigger: Server-Side Template Injection
+Handlebars.java

]]> @@ -4891,37 +5394,38 @@ compiledTemplate.evaluate(writer, context);

解決策: -
+
エンドユーザーが Pebble を使用してテンプレートを操作できないようにします。 テンプレート編集をユーザーに公開する必要があるときは，Handlebars や Mustache などのロジックレステンプレートエンジンを使用することをお勧めします。(参考文献を参照)

-
+

-参考文献
-PortSwigger: Server-Side Template Injection
-Handlebars.java
+参考文献
+Server Side Template Injection ? on the example of Pebble by Micha? Bentkowski
+PortSwigger: Server-Side Template Injection
+Handlebars.java

]]> - Freemarker の潜在的なテンプレートインジェクション + Pebble の潜在的なテンプレートインジェクション -
過度に許可される CORS ポリシーを検出します。
+
過剰に許可された CORS ポリシーを検出します。
 - 過剰に許可される CORS ポリシー - このプログラムでは，過剰に許可される クロスオリジンのリソース共有 (CORS:Cross-Origin Resource Sharing) ポリシーを定義しています。 + 過剰に許可された CORS ポリシー + このプログラムでは，クロスオリジンのリソース共有 (CORS:Cross-Origin Resource Sharing) ポリシーを過剰に許可して定義しています。
-HTML5 以前の Web ブラウザでは，同一生成元ポリシーが強制されます。このポリシーは，JavaScript が Web ページのコンテンツにアクセスするために，JavaScript と Web ページの両方が同じドメインを由来としている必要があります。 +HTML5 以前の Web ブラウザーでは，同一生成元ポリシーが強制されます。このポリシーは，JavaScript が Web ページのコンテンツにアクセスするために，JavaScript と Web ページの両方が同じドメインを由来としていなければなりません。 同一生成元ポリシーが適用されないと，悪意のある Web サイトはクライアントの認証情報を使用して他の Web サイトから機密情報をロードする JavaScript を仕込むことができ，選び取った情報を攻撃者に返します。 -Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されていると，HTML5 では，JavaScript はドメイン間でデータにアクセスすることが可能です。 +Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されていると，HTML5 では，JavaScript はドメイン間でデータにアクセスすることが可能です。 生成元間のリクエストを使用してドメインにアクセスすることを許可する他のドメインを，Web サーバーはこのヘッダーを使用して定義します。 -しかし，このヘッダーを定義する場合には，注意が必要です。過度に許可された CORS ポリシーは，悪意のあるアプリケーションが不正な方法で攻撃対象のアプリケーションとやりとりをして，偽装，データの盗み出し，リレー，およびその他の攻撃が実行される恐れがあります。 +しかし，このヘッダーを定義する場合には，注意が必要です。過剰に許可された CORS ポリシーは，悪意のあるアプリケーションが不正な方法で攻撃対象のアプリケーションとやりとりをして，偽装，データの盗み出し，リレー，およびその他の攻撃が実行される恐れがあります。

脆弱なコード: @@ -4929,18 +5433,23 @@ HTML5 以前の Web ブラウザでは，同一生成元ポリシーが強制さ

解決策: -
-Access Control-Allow-Origin ヘッダーの値としてワイルドカード (*) を使用しないでください。アプリケーションのデータが，任意のドメインで実行される JavaScript にアクセスできることになります。 +
+Access Control-Allow-Origin ヘッダーの値としてワイルドカード (*) を使用しないでください。アプリケーションのデータが，任意のドメインで実行される JavaScript にアクセスできることになります。

-
+

-参考文献
-W3C Cross-Origin Resource Sharing
-Enable Cross-Origin Resource Sharing
+参考文献
+W3C Cross-Origin Resource Sharing
+Enable Cross-Origin Resource Sharing

]]>
- 過剰に許可される CORS ポリシー + 過剰に許可された CORS ポリシー + + + +
CorsRegistry の CORS ポリシーを検出します。
+ @@ -4952,9 +5461,9 @@ HTML5 以前の Web ブラウザでは，同一生成元ポリシーが強制さ
-適切なアクセス制御がなく，ユーザーの制御下にある値を含む LDAP ステートメントを実行すると，攻撃者は不適切な設定となっている LDAP 環境を悪用する可能性があります。 -ctx に対するすべての LDAP クエリは，認証とアクセス制御なしで実行されます。 -攻撃者は予期しない方法でこれらのクエリーのいずれかを操作して，ディレクトリのアクセス制御メカニズムにより保護されているレコードにアクセスする可能性があります。 +適切なアクセス制御がなく，ユーザーの制御下にある値を含む LDAP ステートメントを実行すると，攻撃者は不適切な設定となっている LDAP コンテキストを悪用できます。 +コンテキストに対するすべての LDAP クエリーは，認証とアクセス制御なしで実行されます。 +攻撃者は，これらのクエリーのいずれかを予期せぬ方法で操作して，ディレクトリーのアクセス制御メカニズムにより保護されているレコードにアクセスすることができます。

脆弱なコード: @@ -4965,13 +5474,13 @@ DirContext ctx = new InitialDirContext(env);

解決策: -
+
LDAP に対する他の認証モードを検討し，適切なアクセス制御メカニズムを確保してください。

-
+

-参考文献
-Ldap Authentication Mechanisms
+参考文献
+Ldap Authentication Mechanisms

]]>
@@ -4988,12 +5497,12 @@ LDAP に対する他の認証モードを検討し，適切なアクセス制御
-JNDI API は，LDAP ディレクトリ内のシリアライズオブジェクトのバインディングをサポートします。 -特定の属性が提示されていると，オブジェクトのデシリアライズは，ディレクトリを照会するアプリケーションで行われます (詳細は Black Hat USA 2016ホワイトペーパーを参照)。 -オブジェクトのデシリアライズは，リモートでコードが実行される危険な操作として扱うべきです。 +JNDI API は，LDAP ディレクトリー内のシリアライズオブジェクトのバインディングをサポートします。 +特定の属性が提示されていると，オブジェクトのデシリアライズは，ディレクトリーを照会するアプリケーションで行われます (詳細は Black Hat USA 2016ホワイトペーパーを参照)。 +オブジェクトのデシリアライズは，リモートコード実行につながる可能性のある危険な操作であることを考慮すべきです。

-LDAP ベースクエリにエントリポイントを持っていると，攻撃者が既存の LDAP エントリに属性を追加するか，悪意のある LDAP サーバーを使用するようにアプリケーションを構成することにより，この脆弱性が悪用される可能性があります。 +LDAP ベースクエリーにエントリポイントを持っていると，攻撃者が既存の LDAP エントリに属性を追加するか，悪意のある LDAP サーバーを使用するようにアプリケーションを構成することにより，この脆弱性が悪用される可能性があります。

脆弱なコード: @@ -5019,12 +5528,12 @@ ctx.search(query, filter, deref));

-
+

-参考文献
+参考文献
Black Hat USA 2016: A Journey From JNDI/LDAP Manipulation to Remote Code Execution Dream Land -(slides & video) by Alvaro Muñoz and Oleksandr Mirosh
-HP Enterprise: Introducing JNDI Injection and LDAP Entry Poisoning by Alvaro Muñoz
+(slides & video) by Alvaro Muñoz and Oleksandr Mirosh
+HP Enterprise: Introducing JNDI Injection and LDAP Entry Poisoning by Alvaro Muñoz
TrendMicro: How The Pawn Storm Zero-Day Evaded Java's Click-to-Play Protection by Jack Tang

]]> @@ -5034,47 +5543,47 @@ ctx.search(query, filter, -
永続的なクッキーの使用を特定します。
+
永続的 Cookie の使用を特定します。
 - 永続的クッキーの使用 - 1年以上経過したクッキーセット + 永続的 Cookie の使用 + 1年以上経過した Cookie セット
-永続的なクッキーに機密データを長時間保管すると，機密性が損なわれたり，アカウントが悪用される可能性があります。 +永続的 Cookie に機密データーを長期間保管すると，機密性が損なわれたり，アカウントが悪用される可能性があります。

- 説明:
-永続的クッキーでは有効期限がずっと先に設定されることが多いため，永続的クッキーに個人情報が保管されていると，攻撃者が情報を盗み出すことのできる時間が長くなります。 -永続的クッキーは通常，クライアント上のテキストファイルに保存され，被害者のマシンにアクセスできる攻撃者はこの情報を盗む可能性があります。
-永続的クッキーは，サイトとやり取りするときのユーザープロファイルとして使用されます。 -この追跡データに対して実行される操作によっては，ユーザーの個人情報を盗み出すのに永続的クッキーが使用される可能性があります。 + 説明:
+永続的 Cookie では有効期限がずっと先に設定されることが多いため，永続的 Cookie に個人情報が保管されていると，攻撃者が情報を盗み出すことのできる時間が長くなります。 +永続的 Cookie は通常，クライアント上のテキストファイルに保存され，被害者のマシンにアクセスできる攻撃者はこの情報を盗むことができます。
+永続的 Cookie は，サイトとやり取りするときのユーザープロファイルとして使用されます。 +この追跡データに対して実行される操作によっては，ユーザーの個人情報を盗み出すのに永続的 Cookie が使用される可能性があります。

- 脆弱なコード: 次のコードは，クッキーが1年間で期限切れになるよう設定します。
+ 脆弱なコード: 次のコードは，Cookie が1年間で期限切れになるよう設定します。

[...]
 Cookie cookie = new Cookie("email", email);
 cookie.setMaxAge(60*60*24*365);
 [...]

- 解決策:
+ 解決策:

    -
  • 永続的クッキーは，必要なときにだけ使用し，最高年齢を制限する
    • -
  • 重要なデータに永続的クッキーを使用しない
    • +
  • 永続的 Cookie は，必要なときにだけ使用し，最大有効期間を制限する
    • +
  • 重要なデータに永続的 Cookie を使用しない

-
+

-参考文献
-Class Cookie setMaxAge documentation
-CWE-539: Information Exposure Through Persistent Cookies
+参考文献
+Class Cookie setMaxAge documentation
+CWE-539: Information Exposure Through Persistent Cookies

]]>
- 永続的クッキーの使用 + 永続的 Cookie の使用 @@ -5088,30 +5597,30 @@ cookie.setMaxAge(60*60*24*365);
-このメソッドの実装には，セッション ID を URL にエンコードする必要があるかどうかを判断するロジックが含まれています。
+このメソッドの実装には，セッション ID を URL にエンコードする必要があるかどうかを判断するロジックが含まれています。
URL の書き換えには，セキュリティ上の重大なリスクがあります。セッション ID が URL に表示されるので，第三者が容易に見ることができます。 -URL のセッション ID は，さまざまな方法で公開できます。たとえば，次のようになります。
+URL のセッション ID は，さまざまな方法で公開できます。たとえば，次のようになります。
  • ログファイル
    • -
  • ブラウザの履歴
    • +
  • ブラウザーの履歴
  • 電子メールや投稿にコピーアンドペーストすることにより
    • -
  • HTTP のリファラ
    • +
  • HTTP のリファラー

- 脆弱なコード:
+ 脆弱なコード:

out.println("Click <a href=" +
                 res.encodeURL(HttpUtils.getRequestURL(req).toString()) +
                 ">here</a>");

- 解決策:
-これらのメソッドを使用しないでください。URL 文字列またはフォームパラメータをエンコードするときは，URL を書き換えるメソッドと URLEncoder クラスを混同しないでください。 + 解決策:
+これらのメソッドを使用しないでください。URL 文字列またはフォームパラメーターをエンコードするときは，URL を書き換えるメソッドと URLEncoder クラスを混同しないでください。

-
+

-参考文献
-OWASP Top 10 2010-A3-Broken Authentication and Session Management
+参考文献
+OWASP Top 10 2010-A3-Broken Authentication and Session Management

]]>
@@ -5130,12 +5639,12 @@ URL のセッション ID は，さまざまな方法で公開できます。た
-SSL 接続を確立すると，サーバー ID の確認は無効になります。SSL 接続を有効にする電子メールライブラリによっては，デフォルトでサーバー証明書を検証しません。 -これは，すべての証明書を信頼することと同じです。サーバーに接続しようとすると，このアプリケーションは "hackedserver.com" に対して発行された証明書をすぐに受け入れます。 -アプリケーションは，ハッキングされているサーバーへの不正な SSL 接続によって，ユーザー機密情報を漏洩させる可能性があります。 +SSL 接続を確立すると，サーバー ID の確認は無効になります。SSL 接続を有効にする電子メールライブラリーによっては，デフォルトでサーバー証明書を検証しません。 +これは，すべての証明書を信頼することと同じです。サーバーに接続しようとすると，このアプリケーションは "victim.com" に対して発行された証明書をすぐに受け入れます。 +アプリケーションは，victim サーバーへの不正な SSL接続によって，ユーザー機密情報を漏洩させる可能性があります。

- 脆弱なコード:
+ 脆弱なコード:

...
 Email email = new SimpleEmail();
 email.setHostName("smtp.servermail.com");
@@ -5150,14 +5659,14 @@ email.send();
 ...

- 解決策:
-次のチェックを追加して，サーバ証明書を確認してください: + 解決策:
+次のチェックを追加してサーバ証明書を確認してください: 

email.setSSLCheckServerIdentity(true);

-
+

-参考文献
-CWE-297: Improper Validation of Certificate with Host Mismatch
+参考文献
+CWE-297: Improper Validation of Certificate with Host Mismatch

]]>
@@ -5176,12 +5685,12 @@ email.send();
-ユーザー入力を含む SimpleDB クエリを構築することにより，攻撃者は権限のないレコードを閲覧できます。
-次の例では，ユーザーが productCategory を指定できるようにする SimpleDB select() クエリーを動的に構築して実行します。 -攻撃者は，クエリーを変更し，顧客 ID に必要な認証をバイパスし，任意の顧客に一致するレコードを表示できます。 +ユーザー入力を含む SimpleDB クエリーを構築すると，攻撃者が権限のないレコードを閲覧できます。
+次の例では，ユーザーが productCategory を指定できるようにする SimpleDB SELECT クエリーを動的に構築して実行します。 +攻撃者は，クエリーを変更し，customerID に必要な認証を回避し，任意の顧客に一致するレコードを表示できます。

- 脆弱なコード:
+ 脆弱なコード:

...
 String customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
 String productCategory = request.getParameter("productCategory");
@@ -5195,13 +5704,13 @@ SelectResult sdbResult = sdbc.select(new SelectRequest(query));

- 解決策:
+ 解決策:
この問題は SQL インジェクションに似ています。SimpleDB クエリーを使用する前にユーザー入力をエスケープします。

-
+

-参考文献
-CWE-943: Improper Neutralization of Special Elements in Data Query Logic
+参考文献
+CWE-943: Improper Neutralization of Special Elements in Data Query Logic

]]>
@@ -5216,15 +5725,15 @@ SelectResult sdbResult = sdbc.select(new SelectRequest(query)); JavaBeans プロパティインジェクション - JavaBeans プロパティ名には，ユーザーが制御するパラメータが設定されています。 + JavaBeans プロパティ名には，ユーザーが制御するパラメーターが設定されています。
-攻撃者は，システムの完全性を損なう任意の Bean プロパティを設定できます。Bean population 機能は，Bean プロパティまたはネストされたプロパティを設定できます。 -攻撃者は，この機能を利用して，class.classLoader のような特別な Bean プロパティにアクセスし，システムプロパティを無効にし，任意のコードを実行させる可能性があります。 +攻撃者は，システムの整合性を損なう任意の Bean プロパティを設定できます。Bean 入力機能は，Bean プロパティまたはネストされたプロパティを設定できます。 +攻撃者がこの機能を利用して，システムプロパティを上書きして任意のコードを実行できるようにする class.classLoader のような特殊な Bean プロパティにアクセスする可能性があります。

- 脆弱なコード:
+ 脆弱なコード:

MyBean bean = ...;
 HashMap map = new HashMap();
 Enumeration names = request.getParameterNames();
@@ -5235,13 +5744,13 @@ while (names.hasMoreElements()) {
 BeanUtils.populate(bean, map);

- 解決策:
-ユーザーが制御する値を使用して Bean のプロパティ名を設定しないでください。 + 解決策:
+ユーザーが制御する値を使用して Bean プロパティ名を設定しないでください。

-
+

-参考文献
-CWE-15: External Control of System or Configuration Setting
+参考文献
+CWE-15: External Control of System or Configuration Setting

]]>
@@ -5261,26 +5770,26 @@ BeanUtils.populate(bean, map);
-ユーザー入力を使用してサーバー側のリダイレクトパスを作成すると，攻撃者はアプリケーションバイナリ (アプリケーションクラスまたはjarファイルを含む) をダウンロードしたり保護されたディレクトリ内の任意のファイルを表示できます。
+ユーザー入力を使用してサーバーサイドリダイレクトパスを作成すると，攻撃者にアプリケーションのバイナリ (アプリケーションクラスや jar ファイルを含む) をダウンロードされたり保護されているディレクトリ内の任意のファイルを表示されたりする可能性があります。
攻撃者は，重要なファイルの場所と一致するリクエストパラメーターを偽造できます。 -たとえば， "http://example.com/?returnURL=WEB-INF/applicationContext.xml" を要求すると，アプリケーションの applicationContext.xml ファイルが表示されます。 -攻撃者は，他の設定ファイル，クラスファイル，jar ファイルで参照されている applicationContext.xml を見つけてダウンロードし，機密情報を取得して他の種類の攻撃を開始できます。 +たとえば，"http://example.com/?returnURL=WEB-INF/applicationContext.xml" を要求すると，アプリケーションの applicationContext.xml ファイルが表示されます。 +攻撃者は，他の構成ファイル，クラスファイル，jar ファイルで参照されている applicationContext.xml を見つけてダウンロードし，機密情報を取得して他の種類の攻撃を開始できます。

- 脆弱なコード:
+ 脆弱なコード:

...
 String returnURL = request.getParameter("returnURL");
 Return new ActionForward(returnURL);
 ...

- 解決策:
+ 解決策:
ユーザーが制御する入力を使用してサーバーサイドリダイレクトを構成しないでください。

-
+

-参考文献
-CWE-552: Files or Directories Accessible to External Parties
+参考文献
+CWE-552: Files or Directories Accessible to External Parties

]]>
@@ -5290,30 +5799,30 @@ Return new ActionForward(returnURL); Spring File Disclosure - ModelAndView にユーザーが制御するパラメータが設定されています + ModelAndView にユーザーが制御するパラメーターが設定されています
-ユーザー入力を使用してサーバー側のリダイレクトパスを作成すると，攻撃者はアプリケーションバイナリ (アプリケーションクラスまたはjarファイルを含む) をダウンロードしたり保護されたディレクトリ内の任意のファイルを表示できます。
+ユーザー入力を使用してサーバーサイドリダイレクトパスを作成すると，攻撃者にアプリケーションのバイナリ (アプリケーションクラスや jar ファイルを含む) をダウンロードされたり保護されているディレクトリ内の任意のファイルを表示されたりする可能性があります。
攻撃者は，重要なファイルの場所と一致するリクエストパラメーターを偽造できます。 -たとえば， "http://example.com/?returnURL=WEB-INF/applicationContext.xml" を要求すると，アプリケーションの applicationContext.xml ファイルが表示されます。 -攻撃者は，他の設定ファイル，クラスファイル，jar ファイルで参照されている applicationContext.xml を見つけてダウンロードし，機密情報を取得して他の種類の攻撃を開始できます。 +たとえば，"http://example.com/?jspFile=../applicationContext.xml%3F" を要求すると，アプリケーションの applicationContext.xml ファイルが表示されます。 +攻撃者は，他の構成ファイル，クラスファイル，jar ファイルで参照されている applicationContext.xml を見つけてダウンロードし，機密情報を取得して他の種類の攻撃を開始できます。

- 脆弱なコード:
+ 脆弱なコード:

...
 String returnURL = request.getParameter("returnURL");
 return new ModelAndView(returnURL);
 ...

- 解決策:
+ 解決策:
ユーザーが制御する入力を使用してサーバーサイドリダイレクトを構成しないでください。

-
+

-参考文献
-CWE-552: Files or Directories Accessible to External Parties
+参考文献
+CWE-552: Files or Directories Accessible to External Parties

]]>
@@ -5327,26 +5836,26 @@ return new ModelAndView(returnURL);
-ユーザー入力を使用してサーバー側のリダイレクトパスを作成すると，攻撃者はアプリケーションバイナリ (アプリケーションクラスまたはjarファイルを含む) をダウンロードしたり保護されたディレクトリ内の任意のファイルを表示できます。
+ユーザー入力を使用してサーバーサイドリダイレクトパスを作成すると，攻撃者にアプリケーションのバイナリ (アプリケーションクラスや jar ファイルを含む) をダウンロードされたり保護されているディレクトリ内の任意のファイルを表示されたりする可能性があります。
攻撃者は，重要なファイルの場所と一致するリクエストパラメーターを偽造できます。 -たとえば， "http://example.com/?returnURL=WEB-INF/applicationContext.xml" を要求すると，アプリケーションの applicationContext.xml ファイルが表示されます。 -攻撃者は，他の設定ファイル，クラスファイル，jar ファイルで参照されている applicationContext.xml を見つけてダウンロードし，機密情報を取得して他の種類の攻撃を開始できます。 +たとえば，"http://example.com/?jspFile=../applicationContext.xml%3F" を要求すると，アプリケーションの applicationContext.xml ファイルが表示されます。 +攻撃者は，他の構成ファイル，クラスファイル，jar ファイルで参照されている applicationContext.xml を見つけてダウンロードし，機密情報を取得して他の種類の攻撃を開始できます。

- 脆弱なコード:
+ 脆弱なコード:

...
 String jspFile = request.getParameter("jspFile");
 request.getRequestDispatcher("/WEB-INF/jsps/" + jspFile + ".jsp").include(request, response);
 ...

- 解決策:
+ 解決策:
ユーザーが制御する入力を使用してサーバーサイドリダイレクトを構成しないでください。

-
+

-参考文献
-CWE-552: Files or Directories Accessible to External Parties
+参考文献
+CWE-552: Files or Directories Accessible to External Parties

]]>
@@ -5359,37 +5868,37 @@ request.getRequestDispatcher("/WEB-INF/jsps/" + jspFile + ".jsp").include(reques - Format String Manipulation + 書式文字列操作 パラメーターのユーザー制御を可能にする書式文字列引数です。
-ユーザー入力で書式パラメーターが制御できるようになっていると，攻撃者が例外を投げたり情報を漏らしたりする可能性があります。
+ユーザー入力で書式パラメーターが制御できるようになっていると，攻撃者が例外を投げたり情報を漏洩させたりすることができます。
攻撃者は，書式文字列の引数を変更して，例外がスローされるようにすることができます。この例外がキャッチされなかった場合，アプリケーションがクラッシュする可能性があります。 -あるいは，未使用の引数内で機密情報が使用されると，攻撃者はこの情報を暴露するために書式文字列を変更できます。
-次のサンプルコードでは，残高を示す小数点をユーザーが指定できます。実際には，例外がスローされる原因となるものを指定することができ，アプリケーションの障害を引き起こす可能性があります。 -この例ではさらに重要なことに，攻撃者がユーザー入力 "2f %3$s %4$.2" を指定できると，書式文字列は "The customer: %s %s has the balance %4$.2f %3$s %4$.2" となります。 +あるいは，未使用の引数内で機密情報が使用されると，攻撃者はこの情報を暴露するために書式文字列を変更できます。
+次のコード例では，残高を示す小数点をユーザーが指定できます。実際には，例外がスローされる原因となるものを指定することができ，アプリケーションの障害を引き起こす可能性があります。 +この例ではさらに重要なことに，攻撃者がユーザー入力 "2f %3$s %4$.2" を指定できると，書式文字列は "The customer: %s %s has the balance %4$.2f %3$s %4$.2" となります。 これにより，結果文字列に機密の accountNo が含まれることになります。

- 脆弱なコード:
+ 脆弱なコード:

Formatter formatter = new Formatter(Locale.US);
 String format = "The customer: %s %s has the balance %4$." + userInput + "f";
 formatter.format(format, firstName, lastName, accountNo, balance);

- 解決策:
+ 解決策:
書式文字列引数にユーザーが制御する値を使用しないでください。

-
+

-参考文献
-CWE-134: Use of Externally-Controlled Format String
+参考文献
+CWE-134: Use of Externally-Controlled Format String

]]>
- Format String Manipulation + 書式文字列操作 @@ -5405,23 +5914,23 @@ formatter.format(format, firstName, lastName, accountNo, balance);

未検証のユーザー入力を URL に連結すると，攻撃者にリクエストパラメーターの値の上書きを許します。 攻撃者が，既存のパラメーターの値を上書きしたり，新しいパラメーターを挿入したり，直接到達できない変数を利用したりすることができます。 -HTTP Parameter Pollution (HPP) 攻撃は，エンコードしたクエリ文字列区切り文字を他の既存のパラメーターに挿入することで成り立ちます。 -Web アプリケーションがユーザー入力を適切にエスケープしていないと，悪意のあるユーザーがアプリケーションのロジックを侵害して，クライアント側またはサーバー側の攻撃を実行する可能性があります。
+HTTP Parameter Pollution (HPP) 攻撃は，エンコードしたクエリー文字列区切り文字を他の既存のパラメーターに挿入することで成り立ちます。 +Web アプリケーションがユーザー入力を適切にエスケープしていないと，悪意のあるユーザーがアプリケーションのロジックを侵害して，クライアント側またはサーバー側の攻撃を実行する可能性があります。
次の例では，プログラマは，攻撃者が en&user_id=1 のような lang を指定できる可能性を考慮していないため，攻撃者が思いのままに user_id を変更できます。

- 脆弱なコード:
+ 脆弱なコード:

String lang = request.getParameter("lang");
 GetMethod get = new GetMethod("http://www.host.com");
 get.setQueryString("lang=" + lang + "&user_id=" + user_id);
 get.execute();

- 解決策:
-HTTP パラメータで使用する前にユーザー入力をエスケープします。 + 解決策:
+HTTP パラメーターで使用する前にユーザー入力をエスケープします。

-
+

-参考文献
+参考文献
CAPEC-460: HTTP Parameter Pollution (HPP)

]]> @@ -5429,4 +5938,308 @@ HTTP パラメータで使用する前にユーザー入力をエスケープし HTTP Parameter Pollution + +
動的パラメーターが null の場合に使用されるハードコードされた値を見つけるために他のディテクターを支援します。
+ + + +
JSTL 式 (JSP) で一般的に使用される安全な式としてマークします。
+ + + + +
エラーメッセージによる情報漏洩の可能性を検出します。
+ + + + エラーメッセージによる情報漏洩 + エラーメッセージによる情報漏洩の可能性があります。 +
+ +機密情報は，それ自体で貴重な情報（パスワードなど）である場合もあれば他のより致命的な攻撃を仕かけるのに役立つ場合もあります。 +攻撃が失敗した場合，攻撃者はサーバーから提供されたエラー情報を使用して，より焦点を絞った別の攻撃を開始できます。 +たとえば，パストラバーサルの弱点 (CWE-22) を悪用しようとするとインストールされているアプリケーションの完全パス名が得られる可能性があります。 +次に，これを使用して，適切な数の「..」シーケンスを選択し，ターゲットファイルに移動します。 +SQLインジェクション (CWE-89) を使用した攻撃は，最初は成功しないかもしれませんが，エラーメッセージによって不正なクエリが明らかになり，クエリロジック，さらにはクエリ内で使用されるパスワードやその他の機密情報が明らかになる可能性があります。 +

+

+ 脆弱なコード:
+

try {
+  out = httpResponse.getOutputStream()
+} catch (Exception e) {
+  e.printStackTrace(out);
+}
+

+

+参考文献
+CWE-209: Information Exposure Through an Error Message
+CWE-211: Information Exposure Through Externally-Generated Error Message
+

+ ]]> +
+ + エラーメッセージによる情報漏洩 + + + +
SMTP ヘッダーで起こり得るインジェクションを検出します。(Email)
+ + + + SMTP ヘッダーインジェクション + ソーススプーフィング，ヘッダーオーバーライド，電子メール本文インジェクションにつながる可能性のあるインジェクション。 +
+ +Simple Mail Transfer Protocol (SMTP) は，電子メール配信に使用されるテキストベースのプロトコルです。 +HTTP と同様に，ヘッダーは改行で区切られます。 +ユーザ入力がヘッダー行にある場合，アプリケーションは改行文字 (CR / LF) を削除または置換すべきです。 +Apache Common Email や Simple Java Mail などの安全なラッパーを使用して，ヘッダーインジェクションにつながる特殊文字をフィルタすべきです。 +

+ 脆弱なコード:
+

+

+Message message = new MimeMessage(session);
+message.setFrom(new InternetAddress("noreply@your-organisation.com"));
+message.setRecipients(Message.RecipientType.TO, new InternetAddress[] {new InternetAddress("target@gmail.com")});
+message.setSubject(usernameDisplay + " has sent you notification"); //Injectable API
+message.setText("Visit your ACME Corp profile for more info.");
+Transport.send(message);
+
+

+ 解決策
+

Use Apache Common Email or Simple Java Mail.

+ +

+参考文献
+OWASP SMTP Injection
+CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
+Commons Email: User Guide
+Simple Java Mail Website
+StackExchange InfoSec: What threats come from CRLF in email generation?
+

+ ]]> +
+ + SMTP ヘッダーインジェクション + + +
password という名前の変数を定数値と比較しているハードコードされた認証情報を特定します。
+ + + +
password という名前の変数がマップに提供されたときにハードコードされた認証情報を特定します。
+ + + + +
Apache XML RPC サーバーまたはクライアントで有効な拡張機能を特定します。
+ + + 有効なApache XML RPC サーバーまたはクライアントの拡張機能 + Apache XML RPCサーバーまたはクライアントで拡張機能を有効にすることは安全ではありません。 +
+ +Apache XML RPCサーバーまたはクライアントで拡張機能を有効にすると，デシリアライズの脆弱性が発生する可能性があります。 +これにより，攻撃者が任意のコードを実行することができるようになります。 +
+org.apache.xmlrpc.client.XmlRpcClientConfigImpl または org.apache.xmlrpc.XmlRpcConfigImpl の setEnabledForExtensions メソッドを使用しないことをお勧めします。 +デフォルトでは，拡張機能はクライアントとサーバーの両方で無効になっています。 +

+ +

+参考文献
+ +0ang3el's Blog: Beware of WS-XMLRPC library in your Java App
+CVE-2016-5003 vulnerability reference
+

+ ]]> +
+ + 有効な Apache RPC XML サーバーまたはクライアントの使用 + + + + +
Wicket Web ページで HTML エスケープを無効にするコードを特定します。
+ + + HTMLエスケープを無効にすると，アプリケーションが XSS の危険にさらされる + HTMLエスケープを無効にすると，アプリケーションが XSS の危険にさらされます。 +
+ +HTMLエスケープを無効にすると，アプリケーションがクロスサイトスクリプティング (XSS) の危険にさらされます。 +

+

+脆弱なコード:
+

+add(new Label("someLabel").setEscapeModelStrings(false));
+
+

+ +

+参考文献
+ +Wicket models and forms - Reference Documentation
+WASC-8: Cross Site Scripting
+OWASP: XSS Prevention Cheat Sheet
+OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)
+CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') +

+ + + ]]> +
+ + HTMLエスケープを無効にすると，アプリケーションが XSS の危険にさらされる + + + + +
SAML でコメントを無視する弱い SAML 構成を特定します。
+ + + SAML で XML コメントを無視すると，認証バイパスが発生する可能性がある + Security Assertion Markup Language (SAML) で XML コメントを無視すると，認証バイパスが発生する可能性がります。 +
+ +Security Assertion Markup Language (SAML) は，XML を使用したシングルサインオンプロトコルです。 +SAMLResponse メッセージには，認証されたユーザーを記述するステートメントが含まています +ユーザーが XML コメント (<!-- -->) を配置すると，パーサーがリテラル値を抽出する方法で問題が発生する可能性があります。 +

+ +

+ たとえば，次の XML セクションを見てみましょう: + 

<saml:Subject><saml:NameID>admin@domain.com<!---->.evil.com</saml:NameID></saml:Subject>
+ + ユーザー ID は，"admin@domain.com<!---->.evil.com" ですが，実際にはテキストノード "admin@domain.com"，コメント ""，テキストノード ".evil.com" です。 + NameID を抽出すると，サービスプロバイダーの実装は，最初のノードまたは最後のノードとなることがあります。 +

+ +

+脆弱なコード:
+

+@Bean
+ParserPool parserPool1() {
+    BasicParserPool pool = new BasicParserPool();
+    pool.setIgnoreComments(false);
+    return pool;
+}
+
+

+ +

+解決策:
+

+@Bean
+ParserPool parserPool1() {
+    BasicParserPool pool = new BasicParserPool();
+    pool.setIgnoreComments(true);
+    return pool;
+}
+
+

+ + +

+参考文献
+Duo Finds SAML Vulnerabilities Affecting Multiple Implementations
+Spring Security SAML and this week's SAML Vulnerability
+ +

+ + + ]]> +
+ + SAML で XML コメントを無視すると，認証バイパスが発生する可能性がある + + + +
ハードコードされたコマンドとフラグが付けられた疑わしいコマンドを解析します。
+ + + + +
ローカルファイルに適用される過度に許容されたファイルパーミッションを特定します。
+ + + 過剰に許可されたファイルパーミッション + 過剰に許可されたファイルパーミッションは，権限昇格または情報漏洩につながる可能性があります。 +
+ +一般に，すべてのユーザーに read+write+exec などの過剰に許可されたファイルパーミッションを設定することは悪い習慣です。 +影響を受けるファイルが構成，バイナリ，スクリプト，または機密データである場合，権限昇格または情報漏洩につながる可能性があります。 +

+

+アプリケーションと同じホストで実行されている別のサービスが危険にさらされる可能性があります。 +通常，サービスは別のユーザーで実行されます。 +侵害されたサービスアカウントは，構成の読み取り，スクリプトへの実行命令の追加，データファイルの変更に使用される可能性があります。 +他のサービスやローカルユーザーからのダメージを制限するには，アプリケーションファイルのパーミッションに制限するべきです。 +

+ +

+脆弱なコード 1 (シンボリック表記):
+

+Files.setPosixFilePermissions(configPath, PosixFilePermissions.fromString("rw-rw-rw-"));
+
+

+ +

+解決策 1 (シンボリック表記):
+

+Files.setPosixFilePermissions(configPath, PosixFilePermissions.fromString("rw-rw----"));
+
+

+ + +

+脆弱なコード 2 (オブジェクト指向実装):
+

+Set<PosixFilePermission> perms = new HashSet<>();
+perms.add(PosixFilePermission.OWNER_READ);
+perms.add(PosixFilePermission.OWNER_WRITE);
+perms.add(PosixFilePermission.OWNER_EXECUTE);
+
+perms.add(PosixFilePermission.GROUP_READ);
+perms.add(PosixFilePermission.GROUP_WRITE);
+perms.add(PosixFilePermission.GROUP_EXECUTE);
+
+perms.add(PosixFilePermission.OTHERS_READ);
+perms.add(PosixFilePermission.OTHERS_WRITE);
+perms.add(PosixFilePermission.OTHERS_EXECUTE);
+
+

+ +

+解決策 2 (オブジェクト指向実装):
+

+Set<PosixFilePermission> perms = new HashSet<>();
+perms.add(PosixFilePermission.OWNER_READ);
+perms.add(PosixFilePermission.OWNER_WRITE);
+perms.add(PosixFilePermission.OWNER_EXECUTE);
+
+perms.add(PosixFilePermission.GROUP_READ);
+perms.add(PosixFilePermission.GROUP_WRITE);
+perms.add(PosixFilePermission.GROUP_EXECUTE);
+
+

+ +

+参考文献
+CWE-732: Incorrect Permission Assignment for Critical Resource
+A guide to Linux Privilege Escalation
+File system permissions
+

+ + ]]> +
+ + 過剰に許可されたファイルパーミッション +