0x01
現(xiàn)今WEB安全主要面臨的幾個問題：
- sql 注入
- xss 跨站腳本
- csrf 跨站域請求偽造
0x02
那么如何設(shè)計一個安全的站點呢？
我們先看看原理:
輸入類：sql 注入 和 xss 跨站腳本，一個可能造成非法的數(shù)據(jù)庫請求，一個可能造成非法的js引用，防范方法，我們只需要在用戶輸入時對其輸入的內(nèi)容在前后臺進(jìn)行校驗或轉(zhuǎn)意或使用參數(shù)化sql等手段
那么什么是(CSRF)跨站偽造請求.呢？
舉個例子：假如上面這個表單的頁面地址是http://0x1024.com，黑闊想通過http://hack.com頁面獲取到你http://0x1024.com的用戶信息或者使用你0x1024的cookie訪問你的個人賬戶并轉(zhuǎn)錢1000塊.
偽造其實很簡單，我舉個栗子
假如你恰好登錄了0x1024，那么很有可能你的錢就莫名其妙少了1000塊了。
想想是不是很可怕，有的朋友可能說使用post就安全一點了，我只能說呵呵了，假如黑闊使用iframe元素把你的表單內(nèi)嵌到了hack.com呢？？
然后用某種方式誘導(dǎo)你填入用戶名和密碼，那么你的帳號同樣還是被騙走了。
CSRF可以說是瀏覽器的一個特(que)性(xian), 那么Session這玩意那么容易被csrf，那么怎么防嘛，目前防御的方法有幾種
- 驗證來源 Http請求中的Referer
- Token
- 隱藏表單 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>
- 隱藏頭部 <meta name="csrf-token" content="pa5chCM1n1" />
在理想的情況下，客戶端和服務(wù)端時間永遠(yuǎn)一致，那么可以考慮使用Google兩部驗證的思路來替代token
上面幾招都是通過，這篇文章來的。CSRF 攻擊的應(yīng)對之道
但是這篇文章中少了個同源請求的問題,假如被人使用iframe把整個頁面嵌入了呢？這種就是所謂的clickjacking,其實瀏覽器早就有這類的聲明了。只需要在響應(yīng)頭里加入X-Frame-Options:SAMEORIGIN即可防范，下面是x-frame-options的說明
X-Frame-Options HTTP 響應(yīng)頭是用來給瀏覽器指示允許一個頁面可否在 <frame>, <iframe> 或者 <object> 中展現(xiàn)的標(biāo)記。網(wǎng)站可以使用此功能，來確保自己網(wǎng)站的內(nèi)容沒有被嵌到別人的網(wǎng)站中去，也從而避免了點擊劫持 (clickjacking) 的攻擊。
想必大黑闊們對我這些招都已經(jīng)是過眼云煙了。。。。
