WEB開發中常見漏洞

1、sql注入

sql注入在黑客領域是一種非常常見的攻擊手段，大家應該都聽說過很多資料洩漏的案例，其中大部分都是採用sql注入來獲取資料的。

sql注入一般是前端向後台提交資料的時候，在資料中加入sql語句，改變後台本來要執行的sql語句！例如：

原sql語句為：select * from users where username='name' and password=md5('pwd')

通過sql注入，將使用者名稱設定為：'name' or 1=1#　　sql語句就變成了

select * from users where username='name' or 1=1#' and password=md5('pwd')

對於sql解析器來說，一般認為#後面的內容是被注釋調的，所以實際上執行的 select * from users where username='name' or 1=1

這樣，使用者無需輸入密碼，便可達到擁有密碼的效果。

sql注入的解決方案一般是增加sql過濾器，檢測前端傳過來的內容是否含有非法字元，常見的非法字元：

'
| and |exec|execute|insert|select|delete|update|count|drop|*|chr|mid|master|truncate|char|declare|sitename|net user|xp_cmdshell|;|,|like'|
exec
|execute
|insert
|create
|drop
|table
|from
|grant
|use
|group_concat|column_name|information_schema.columns|table_schema|
union
|where
|select
|delete
|update
|order|by
|count
|*|chr|mid|master|
truncate
|char
|declare|or
|--| + |,| like

2、校驗邏輯放到前端

校驗過程是這樣的，當使用者點選登入之後，去後台請求驗證碼，然後跟使用者輸入的驗證碼比較，如果一致就通過，想想這個邏輯也只能呵呵了。

總結一下經驗就是，所以的校驗邏輯，盡可能的放到後台驗證，前端的任何校驗都是有可能被繞過的。

3、攻擊簡訊驗證碼介面

目前大部分**在註冊時，都需要驗證手機號，或者登入方式提供了使用手機號+簡訊驗證碼登入，於是便有人可以模擬使用者註冊，頻繁的攻擊簡訊傳送介面。解決方案有兩種：對同一手機號，統一ip位址程序請求次數限制。當然，攻擊者可以頻繁的換手機號，也可以使用『肉機』等方式頻繁的換ip位址。這時候，限制ip和手機號的方式似乎就不能奏效了。

另一種方式是在請求傳送驗證碼之前，需要使用者先輸入驗證碼，當驗證碼校驗成功後（切記，要在後台校驗），再傳送簡訊驗證碼，這樣攻擊者可能就需要一定的攻擊成本了。

如果已上方式都不能奏效，好了，從業務角度入手，將手機號的驗證放在登入之後吧。

4、xss跨站指令碼注入

xss跨域請求類似於sql注入，也是向**中注入非法**，不同之處在於這裡注入的一般是js**，攻擊的是客戶端;

例如在乙個可以發文章的**，發布了一片文章，文章裡故意插入一些可執行的js指令碼（如：），這樣，如果客戶端處理不當，就有可能遭受攻擊。

解決辦法是跟防止sql注入類似，對於使用者提交的資料進行檢測，如果部分特殊字元必須保留，也應該進行轉義。

5、大量請求壓力

一般情況是向伺服器傳送大量的非法請求或正常請求，對伺服器造成一定的壓力甚至癱瘓，導致正常的業務不能及時處理。

一般上線的web服務都應該對承受的能力有乙個預估，然後在硬體或者軟體層做併發控制。防止出現此此種情況。

6、驗證碼爆破

一般是通過爆破的方式，碰撞使用者收到的真實手機驗證碼，目前驗證碼一般是4位～5位一般的爆破工具，幾分鐘就可以試完。

解決方案比較簡單，對於同一手機號，嘗試次數大於幾次之後，驗證碼自動失效。

7、csrf漏洞

中文名稱是跨站請求偽造，舉乙個例子，

受害者 bob 在銀行有一筆存款，通過對銀行的**傳送請求可以使 bob 把 1000000 的存款轉到 bob2 的賬號下。通常情況下，該請求傳送到**後，伺服器會先驗證該請求是否來自乙個合法的 session，並且該 session 的使用者 bob 已經成功登陸。

黑客 mallory 自己在該銀行也有賬戶，他知道上文中的 url 可以把錢進行轉帳操作。mallory 可以自己傳送乙個請求給銀行： amount=1000000&for=mallory。但是這個請求來自 mallory 而非 bob，他不能通過安全認證，因此該請求不會起作用。

這時，mallory 想到使用 csrf 的攻擊方式，他先自己做乙個**，在**中放入如下**： src=」amount=1000000&for=mallory 」，並且通過廣告等誘使 bob 來訪問他的**。當 bob 訪問該**時，上述 url 就會從 bob 的瀏覽器發向銀行，而這個請求會附帶 bob 瀏覽器中的 cookie 一起發向銀行伺服器。大多數情況下，該請求會失敗，因為他要求 bob 的認證資訊。但是，如果 bob 當時恰巧剛訪問他的銀行後不久，他的瀏覽器與銀行**之間的 session 尚未過期，瀏覽器的 cookie 之中含有 bob 的認證資訊。這時，悲劇發生了，這個 url 請求就會得到響應，錢將從 bob 的賬號轉移到 mallory 的賬號，而 bob 當時毫不知情。等以後 bob 發現賬戶錢少了，即使他去銀行查詢日誌，他也只能發現確實有乙個來自於他本人的合法請求轉移了資金，沒有任何被攻擊的痕跡。而 mallory 則可以拿到錢後逍遙法外。

8、許可權控制漏洞

一般**需要有乙個完善的許可權管理體系，理論上應該對所有的url路徑都進行許可權控制，千萬不要以為頁面沒有入口，就不能訪問了。

在此，更加建議採用restful風格設計url路徑，這樣更加的便於做許可權控制、監控、統計等工作。　　

WEB開發中常見漏洞

WEB開發中常見錯誤原因

常見WEB漏洞

常見的Web漏洞

WEB開發中常見漏洞

WEB開發中常見錯誤原因

常見WEB漏洞

常見的Web漏洞

相關推薦