1、Apache JServ協議服務
描述：
Apache JServ協議（AJP）是一種二進制協議，可以將來自Web服務器的入站請求代理到 位于Web服務器后面的應用程序服務器。不建議在互聯網上公開使用AJP服務。 如果AJP配置錯誤，可能會允許攻擊者訪問內部資源。
我的修復建議：{tocamat目錄}/conf/server.xml中將下面的配置給注釋掉：
?
2、沒有CSRF保護的HTML表單
描述：
此警報需要手動確認
跨站點請求偽造（CSRF或XSRF）是一種漏洞，其中攻擊者將欺騙者向受害者提出請求沒有打算做。因此，使用CSRF，攻擊者濫用Web應用程序與受害者瀏覽器的信任。
Acunetix發現一個沒有明顯的反CSRF保護的HTML表單。有關詳細信息，請參閱“攻擊詳細信息”部分有關受影響的HTML表單的信息。
影響：
攻擊者可以使用CSRF欺騙受害者訪問攻擊者托管的網站，或點擊包含的URL惡意或未經授權的請求
CSRF是一種“混亂的副手”攻擊，在偽造時利用受害者的認證和授權 請求正在發送到Web服務器。因此，如果CSRF漏洞可能會影響高度特權的用戶，例如 管理員可以全面的應用程序妥協。
?
報告給出的建議是：
驗證此表單是否需要反CSRF保護，并在必要時實施CSRF對策。
推薦和最廣泛使用的防止CSRF攻擊的技術也被稱為反CSRF令牌，有時稱為同步器令牌。設計良好的反CSRF系統的特點如下屬性。
（1）反CSRF令牌對于每個用戶會話應該是唯一的
（2）會話應該在適當的時間段之后自動過期
（3）反CSRF令牌應該是具有顯著長度的密碼隨機值
（4）反CSRF令牌應該是加密安全的，也就是由強偽隨機數生成器生成的（PRNG）算法
（5）反CSRF令牌被添加為表單的隱藏字段，或者在URL內添加（僅當GET請求導致狀態時才需要更改，即GET請求不是冪等）
（6）如果反CSRF令牌驗證失敗，服務器應拒絕所請求的操作
當用戶提交表單或進行一些需要Cookie的其他經過身份驗證的請求時，反CSRF令牌應該是包含在請求中。?然后，Web應用程序將在處理之前驗證此令牌的存在和正確性請求。?如果令牌丟失或不正確，請求可以被拒絕。
建議：
在提交中加入一個$_SESSION['token']唯一值做驗證。
意思就是在每次請求后臺接口時在最后面在隨機加個參數，傳入一個隨機的數。比如在前臺js中隨機生成一串數字，然后以隱藏的方式放入表單中或session中。后臺action在接受后再判斷是否有這個值。
?
 stopImmediatePropagation() 區別)
 方法)
