一.跨站腳本攻擊(XSS)
跨站腳本攻擊（XSS，Cross-site scripting）是最常見和基本的攻擊WEB網站的方法。攻擊者在網頁上發佈包含攻擊性代碼的數據。當瀏覽者看到此網頁時，特定的腳本就會以瀏覽者用戶的身份和權限來執行。通過XSS可以比較容易地修改用戶數據、竊取用戶信息，以及造成其它類型的攻擊，例如CSRF攻擊
常見解決辦法:確保輸出到HTML頁面的數據以HTML的方式被轉義
出錯的頁面的漏洞也可能造成XSS攻擊.比如頁面/gift/giftList.htm?page=2找不到,出錯頁面直接把該url原樣輸出,如果攻擊者在url後面加上攻擊代碼發給受害者,就有可能出現XSS攻擊
二. 跨站請求僞造攻擊（CSRF)
跨站請求僞造（CSRF，Cross-site request forgery）是另一種常見的攻擊。攻擊者通過各種方法僞造一個請求，模仿用戶提交表單的行爲，從而達到修改用戶的數據，或者執行特定任務的目的。爲了假冒用戶的身份，CSRF攻擊常常和XSS攻擊配合起來做，但也可以通過其它手段，例如誘使用戶點擊一個包含攻擊的鏈接
例子：一個CSRF最簡單的例子就是用戶A登錄了網站A在虛擬賬戶裏轉賬了1000塊錢，用戶A在本地生成了網站A的cookie，用戶A在沒有關閉網站A的情況下有訪問了惡意網站B，惡意網站B包含請求A網站的代碼，利用了本地的cookie經過身份驗證的身份又向網站A發送了一次請求，這時你就會發現你在網站A的賬戶又少了1000塊。這就是基本的CSRF攻擊方式。
解決的思路有:
1.採用POST請求,增加攻擊的難度.用戶點擊一個鏈接就可以發起GET類型的請求。而POST請求相對比較難，攻擊者往往需要藉助javascript才能實現
2.對請求進行認證，確保該請求確實是用戶本人填寫表單並提交的，而不是第三者僞造的.具體可以在會話中增加token,確保看到信息和提交信息的是同一個人
三.Http Heads攻擊
凡是用瀏覽器查看任何WEB網站，無論你的WEB網站採用何種技術和框架，都用到了HTTP協議.HTTP協議在Response header和content之間，有一個空行，即兩組CRLF（0x0D 0A）字符。這個空行標誌着headers的結束和content的開始。“聰明”的攻擊者可以利用這一點。只要攻擊者有辦法將任意字符“注入”到headers中，這種攻擊就可以發生。
以登陸爲例:有這樣一個url:
http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex
當登錄成功以後，需要重定向回page參數所指定的頁面。下面是重定向發生時的response headers.
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/index假如把URL修改一下，變成這個樣子：
那麼重定向發生時的reponse會變成下面的樣子：
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/checkout<CRLF>
<CRLF>
<script>alert('hello')</script>這個頁面可能會意外地執行隱藏在URL中的javascript。類似的情況不僅發生在重定向（Location header）上，也有可能發生在其它headers中，如Set-Cookie header。這種攻擊如果成功的話，可以做很多事，例如：執行腳本、設置額外的cookie（Set-Cookie: evil=value）等。
避免這種攻擊的方法，就是過濾所有的response headers，除去header中出現的非法字符，尤其是CRLF。
服務器一般會限制request headers的大小。例如Apache server默認限制request header爲8K。如果超過8K，Aapche Server將會返回400 Bad Request響應：
對於大多數情況，8K是足夠大的。假設應用程序把用戶輸入的某內容保存在cookie中,就有可能超過8K.攻擊者把超過8k的header鏈接發給受害者,就會被服務器拒絕訪問.解決辦法就是檢查cookie的大小,限制新cookie的總大寫，減少因header過大而產生的拒絕訪問攻擊
四.Cookie攻擊
通過Java Script非常容易訪問到當前網站的cookie。你可以打開任何網站，然後在瀏覽器地址欄中輸入：javascript:alert(doucment.cookie),立刻就可以看到當前站點的cookie（如果有的話）。攻擊者可以利用這個特性來取得你的關鍵信息。例如，和XSS攻擊相配合，攻擊者在你的瀏覽器上執行特定的Java Script腳本，取得你的cookie。假設這個網站僅依賴cookie來驗證用戶身份，那麼攻擊者就可以假冒你的身份來做一些事情。
現在多數瀏覽器都支持在cookie上打上HttpOnly的標記,凡有這個標誌的cookie就無法通過Java Script來取得,如果能在關鍵cookie上打上這個標記，就會大大增強cookie的安全性
五.重定向攻擊
一種常用的攻擊手段是“釣魚”。釣魚攻擊者，通常會發送給受害者一個合法鏈接，當鏈接被點擊時，用戶被導向一個似是而非的非法網站，從而達到騙取用戶信任、竊取用戶資料的目的。爲防止這種行爲,我們必須對所有的重定向操作進行審覈,以避免重定向到一個危險的地方.常見解決方案是白名單,將合法的要重定向的url加到白名單中,非白名單上的域名重定向時拒之,第二種解決方案是重定向token,在合法的url上加上token,重定向時進行驗證.
六.上傳文件攻擊
1.文件名攻擊,上傳的文件採用上傳之前的文件名,可能造成:客戶端和服務端字符碼不兼容,導致文件名亂碼問題;文件名包含腳本,從而造成攻擊.
2.文件後綴攻擊.上傳的文件的後綴可能是exe可執行程序,js腳本等文件,這些程序可能被執行於受害者的客戶端,甚至可能執行於服務器上.因此我們必須過濾文件名後綴,排除那些不被許可的文件名後綴.
3.文件內容攻擊.IE6有一個很嚴重的問題 , 它不信任服務器所發送的content type，而是自動根據文件內容來識別文件的類型，並根據所識別的類型來顯示或執行文件.如果上傳一個gif文件,在文件末尾放一段js攻擊腳本,就有可能被執行.這種攻擊,它的文件名和content type看起來都是合法的gif圖片,然而其內容卻包含腳本,這樣的攻擊無法用文件名過濾來排除，而是必須掃描其文件內容，才能識別。
七、Dos攻擊
是一種針對服務器的能夠讓服務器呈現靜止狀態的攻擊方式。有時候也加服務停止攻擊或拒絕服務攻擊。其原理就是發送大量的合法請求到服務器，服務器無法分辨這些請求是正常請求還是攻擊請求，所以都會照單全收。海量的請求會造成服務器停止工作或拒絕服務的狀態。這就是Dos攻擊。
八、SQL注入
是指通過對web連接的數據庫發送惡意的SQL語句而產生的攻擊，從而產生安全隱患和對網站的威脅，可以造成逃過驗證或者私密信息泄露等危害。
SQL注入的原理是通過在對SQL語句調用方式上的疏漏，惡意注入SQL語句。
例子：私密信息泄露
假如一個出版書籍的網站，具有根據作者姓名查詢已出版書籍的功能，作者未出版的書籍不能被普通用戶看到，因爲版權屬於隱私的問題。那麼假設請求是用HTTP的GET請求來完成的，其地址欄請求內容爲：www.book.com?serach=echo
完成此功能的SQL語句爲簡單的根據條件查找：select * from book where author = ‘echo’ and flag = 1; flag等於1代表書籍已出版。
這時如果有的用戶直接地址欄裏輸入www.book.com?serach=echo’– 這樣請求會發生什麼？？
這樣的請求傳到服務器裏的狀態會是這樣子的 select * from book where author = ‘echo’ – and flag = 1;在SQL語句中–代表註釋，會自動忽略掉後面的內容，所以這個請求是騙過服務器把作者爲echo的已出版和未出版的書籍全部顯示在網頁上。造成網站違背開發者的意圖，造成信息泄露。