(1)SQL 注入
原理：所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到后台數據庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。 造成SQL注入漏洞原因有兩個：一個是沒有對輸入的數據進行過濾（過濾輸入），還有一個是沒有對發送到數據庫的數據進行轉義（轉義輸出）。
修復方案：建議在代碼中對數字類型的參數先進行數字類型變換，然后再代入到SQL查詢語句中，這樣任何注入行為都不能成功。並且考慮過濾一些參數，比如get參數和post參數中對於SQL語言查詢的部分。所以防范的時候需要對用戶的輸入進行檢查。特別式一些特殊字符，比如單引號，雙引號，分號，逗號，冒號，連接號等進行轉換或者過濾。
(2)失效的身份認證和會話管理
原理：與認證和會話管理相關的應用程序功能往往得不到正確實施，導致了攻擊者可以破壞密碼，密鑰，會話令牌或實施漏洞冒充其他用戶身份
修復方案：1.使用內置的會話管理功能 2.通過認證的問候 3.使用單一的入口點 4.確保在一開始登錄SSL保護的網頁
(3)跨站腳本攻擊 XSS
原理：跨站腳本攻擊的英文全稱是Cross Site Script，為了和樣式表區分，縮寫為XSS。發生的原因是網站將用戶輸入的內容輸出到頁面上，在這個過程中可能有惡意代碼被瀏覽器執行。跨站腳本攻擊,它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的html代碼會被執行，從而達到惡意用戶的特殊目的。XSS屬於被動式的攻擊，因為其被動且不好利用，所以許多人常呼略其危害性。而本文主要講的是利用XSS得到目標服務器的shell。技術雖然是老技術，但是其思路希望對大家有幫助。已知的跨站腳本攻擊漏洞有三種：1）存儲式；2）反射式；3）基於DOM。
1、 存儲型跨站腳本攻擊涉及的功能點：用戶輸入的文本信息保存到數據庫中，並能夠在頁面展示的功能點，例如用戶留言、發送站內消息、個人信息修改等功能點。
2、 反射型跨站腳本攻擊涉及的功能點：URL參數需要在頁面顯示的功能點都可能存在反射型跨站腳本攻擊，例如站內搜索、查詢功能點。
3、 基於DOM跨站腳本攻擊涉及的功能點：涉及DOM對象的頁面程序，包括（不限這些）：
| document.URL document.URLUnencoded document.location document.referrer window.location |
修復方案： 總體修復方式：驗證所有輸入數據，有效檢測攻擊；對所有輸出數據進行適當的編碼，以防止任何已成功注入的腳本在瀏覽器端運行。具體如下 ：
1、 輸入驗證：某個數據被接受為可被顯示或存儲之前，使用標准輸入驗證機制，驗證所有輸入數據的長度、類型、語法以及業務規則。
2、 輸出編碼：數據輸出前，確保用戶提交的數據已被正確進行entity編碼，建議對所有字符進行編碼而不僅局限於某個子集。
3、 明確指定輸出的編碼方式：不要允許攻擊者為你的用戶選擇編碼方式(如ISO 8859-1或 UTF 8)。
4、 注意黑名單驗證方式的局限性：僅僅查找或替換一些字符(如"<" ">"或類似"script"的關鍵字)，很容易被XSS變種攻擊繞過驗證機制。
5、 警惕規范化錯誤：驗證輸入之前，必須進行解碼及規范化以符合應用程序當前的內部表示方法。請確定應用程序對同一輸入不做兩次解碼。對客戶端提交的數據進行過濾，一般建議過濾掉雙引號（”）、尖括號（<、>）等特殊字符，或者對客戶端提交的數據中包含的特殊字符進行實體轉換，比如將雙引號（”）轉換成其實體形式"，<對應的實體形式是<，<對應的實體形式是>以下為需過濾的常見字符：
| [1] |（豎線符號） [2] & （& 符號） [3];（分號） [4] $（美元符號） [5] %（百分比符號） [6] @（at 符號） [7] '（單引號） [8] "（引號） [9] \'（反斜杠轉義單引號） [10] \"（反斜杠轉義引號） [11] <>（尖括號） [12] ()（括號） [13] +（加號） [14] CR（回車符，ASCII 0x0d） [15] LF（換行，ASCII 0x0a） [16] ,（逗號） [17] \（反斜杠） 2、在請求返回頁面關鍵字符進行轉義； [1] “（雙引號）：" [2] ’ （單引號）：&apos [3] &（&符號）：& [4] <（左尖括號）：< [5] >（右尖括號）：> 在不影響應用的前提下，建議將cookie標記為httpOnly，同時禁用TRACE方法。 |
(4)直接引用不安全的對象
原理：指一個已經授權的用戶通過更改訪問時的參數，從而訪問到原本其並沒有得到授權的對象。
修復方案：
1.使用基於用戶或會話的間接對象訪問，這樣可防止攻擊者直接攻擊為授權資源
2.訪問檢查：對任何來自不受信源所使用的所有對象進行訪問控制檢查
3.避免在url或網頁中直接引用內部文件名或數據庫關鍵字
4.驗證用戶輸入和url請求，拒絕包含./ ../的請求
(5)安全配置錯誤
原理：安全配置錯誤可以發生在一個應用程序堆棧的任何層面，包括平台，web服務器，應用服務器，數據庫，架構和自定義的代碼。攻擊者通過訪問默認賬戶，未使用的網頁，未安裝的補丁的漏洞，未被保護的文件和目錄等，以獲得對系統為授權的訪問
修復方案：
1.自動化安裝部署
2.及時了解並部署每個環節的軟件更新和補丁信息
3.實施漏洞掃描和安全審計
(6)敏感信息泄露
原理：由於管理員或者技術人員等各種原因導致敏感信息泄露
修復方案：1.對信息加密 2.強化安全意識
(7)缺少功能級的訪問控制
原理：這個漏洞也是與認證相關的，這種漏洞具體是指在系統已經對url的訪問做了限制的情況下，但這種限制並沒有生效。常見的例子是系統沒有對用戶進行角色的檢查，以及用戶通過修改URL的action並指向未被授權頁面就能訪問該頁面同樣是個漏洞
修復方案：
1.檢查管理權限的過程並確保能夠容易進行升級和審計
2.默認缺省情況下，應該拒絕所有訪問的執行權限。對於每個功能得訪問，需要明確的角色授權
3.檢查每個功能分配的權限合理有效
(8)跨站請求偽造 CSRF
原理：跨站請求偽造攻擊，Cross-Site Request Forgery（CSRF），攻擊者在用戶瀏覽網頁時，利用頁面元素（例如img的src），強迫受害者的瀏覽器向Web應用服務器發送一個改變用戶信息的HTTP請求。CSRF攻擊可以從站外和站內發起。從站內發起CSRF攻擊，需要利用網站本身的業務，比如“自定義頭像”功能，惡意用戶指定自己的頭像URL是一個修改用戶信息的鏈接，當其他已登錄用戶瀏覽惡意用戶頭像時，會自動向這個鏈接發送修改信息請求。從站外發送請求，則需要惡意用戶在自己的服務器上，放一個自動提交修改個人信息的htm頁面，並把頁面地址發給受害者用戶，受害者用戶打開時，會發起一個請求。威脅描述：攻擊者使用CSRF攻擊能夠強迫用戶向服務器發送請求，導致用戶信息被迫修改，甚至可引發蠕蟲攻擊。如果惡意用戶能夠知道網站管理后台某項功能的URL，就可以直接攻擊管理員，強迫管理員執行惡意用戶定義的操作。
修復方案：
1、 通過referer判斷頁面來源進行CSRF防護，該方式無法防止站內CSRF攻擊及referer字段偽造。
2、 重要功能點使用動態驗證碼進行CSRF防護。
3、 通過token方式進行CSRF防護：
|
1、 在Session中綁定token。如果不能保存到服務器端Session中，則可以替代為保存到Cookie里。 2、 在form表單中自動填入token字段，比如 <input type=hidden name="anti_csrf_token" value="$token" />。 3、 在HTTP請求中自動添加token。 在服務器端對比POST提交參數的token與Session中綁定的token是否一致，以驗證CSRF攻擊 |
(9)使用含有已知漏洞的組件
原理：應用程序使用帶有已知漏洞的組件會破壞應用程序防御系統，可能導致嚴重的數據丟失或服務器接管
修復方案：
1.識別正在使用的組件和版本，包括所有的依賴
2.更新組件或引用的庫文件到最新
3.建立安全策略來管理組件的使用
(10）未驗證的重定向和轉發
原理：在Web應用中重定向是極為普通的，並且通常重定向所引發的目的是帶有用戶輸入參數的目的url，而如果這些重定向未被驗證，那么攻擊者就可以引導用戶訪問他們想要用戶訪問的站點。同樣，轉發也是極為普遍的，本質上轉發是在同一個應用中對一個新頁面發送請求，並且有時是用參數來定義目標頁面的。同樣，如果參數未被驗證，那么攻擊者就可以利用其來繞過認證或是授權檢查
修復方案：
1.避免使用重定向和轉發
2.如果使用了，不要在確定目標時涉及到用戶參數
3.如果無法避免使用用戶參數，則應確保目標參數值對於當前用戶是有效的並已授權
如果是需要登錄的，可以從session當中獲取登錄信息，然后判斷