1は、ApacheのJServプロトコルサービス
説明：
ApacheのJServのプロトコル（AJPは）からのバイナリプロトコル、あるウェブプロキシサーバに配置への着信要求のWeb サーバーアプリケーションの背後にあるサーバー。インターネット上の公共の用に推奨しないAJPのサービス。もしAJPの攻撃者が内部リソースにアクセスする可能性があります設定エラー。
私の修正案： {} tocamatディレクトリには、次の/conf/server.xmlに割り当てられますのコメント：
2、無 CSRFの保護のHTML フォーム
説明：
このアラームは手動で確認が必要です
クロスサイトリクエストフォージェリ（ CSRF またはXSRFが）の脆弱性で、不正行為の犠牲者への要求を提示する攻撃者は何をするつもりはありません。そのため、CSRFは、攻撃者の虐待のWeb アプリケーションとブラウザ被害者の信頼を。
会社のAcunetixは明白な抗見つからないCSRF 保護HTMLのフォームを。詳細については、影響を受けた「攻撃の詳細」の項を参照のHTML 情報フォームを。
影響：
攻撃者は、使用することができます CSRFを被害者がホストしている攻撃者のWebサイトを訪問した欺くために、または含まをクリックしてURL 悪意のあるまたは不正な要求
CSRFがある「混沌副」被害者が偽造されている場合、攻撃、認証および承認要求の使用送信されたWeb サーバー。場合そのため、CSRFの脆弱性が非常に特権ユーザーに影響を与える可能性があり、例えば、管理者がアプリケーションを完全に妥協することができます。
勧告が与えられています。
このフォームは、抗ていることを確認するために必要とされる CSRFの保護、および、必要に応じて、実装CSRFの対策を。
そして、最も広く防ぐために使用をお勧めします CSRFの攻撃手法はまた、抗として知られているCSRFのトークン、時々シンクロナイザトークンと呼ばれます。うまく設計された抗CSRFのシステムは、以下の特性を備えています。
（ 1 ）抗 CSRFの各ユーザセッションのトークンは一意でなければなりません
（ 2 ）セッションは自動的に適切な期間の後に失効すべきです
（ 3 ）抗 CSRF トークンパスワードは、かなりの長さを持つランダムな値であるべきです
（ 4 ）抗 CSRF トークンの暗号化は安全であるべきで、それは強力な乱数発生器によって生成される（PRNG ）アルゴリズム
（ 5 ）抗 CSRFのトークンは、隠しフォームフィールドとして追加され、またはURLは（のみ追加GET 所望の状態の場合に要求の結果を変更、すなわち、GET 要求は冪等されていません）
（ 6 抗場合） CSRF トークンの検証が失敗し、サーバは要求された操作を拒否すべきです
ユーザーがフォームを送信、または一部がクッキーを必要とする場合、他の要求が認証されたときに、抗CSRFのトークンをしなければならない要求に含まれています。 次に、ウェブアプリケーションが処理する前に、トークンの存在と正当性を検証します要求を。 トークンが見つからないか、間違っている場合は、要求が拒否されることがあります。
提案：
提出に追加されたの$ _SESSION [「トークン」]独自の認証値を行います。
これは、最後尾の確率論的パラメータの各要求のバックグラウンドでインターフェイスは、乱数が経過していることを意味します。例えば、フォアグラウンドでランダム番号JSの文字列を生成し、次いで隠蔽方法又はフォームセッション中に入れました。舞台裏行動し、この値を受け入れるかどうかを判断します。