xss(cross sitescript)跨站指令碼攻擊,是web程式中常見的漏洞,xss屬於被動式且用於客戶端的攻擊方式,所以容易被忽略其危害性。其原理是攻擊者向有xss漏洞的**中輸入(傳入)惡意的html**,當其它使用者瀏覽該**時,這段html**會自動執行,從而達到攻擊的目的。如,盜取使用者cookie、破壞頁面結構、重定向到其它**等。
xss攻擊類似於sql注入攻擊,攻擊之前,我們先找到乙個存在xss漏洞的**,xss漏洞分為兩種,一種是dom based xss漏洞,另一種是stored xss漏洞。理論上,所有可輸入的地方沒有對輸入資料進行處理的話,都會存在xss漏洞,漏洞的危害取決於攻擊**的威力,攻擊**也不侷限於script。
(1). dom based xss
dom based xss是一種基於網頁dom結構的攻擊,該攻擊特點是中招的人是少數人。
場景一
當我登入a.com後,我發現它的頁面某些內容是根據url中的乙個叫content引數直接顯示的,猜測它測頁面處理可能是這樣,其它語言類似:
頁面內容:
我知道了tom也註冊了該**,並且知道了他的郵箱(或者其它能接收資訊的****),我做乙個超連結發給他,超連結位址為:瀏覽器展示頁面內容的過程中,就會執行我的指令碼,頁面輸出xss字樣,這是攻擊了我自己,那我如何攻擊別人並且獲利呢?
(2). stored xss
stored xss是儲存式xss漏洞,由於其攻擊**已經儲存到伺服器上或者資料庫中,所以受害者是很多人。
場景二:
a.com可以發文章,我登入後在a.com中發布了一篇文章,文章中包含了惡意**,,儲存文章。這時tom和jack看到了我發布的文章,當在檢視我的文章時就都中招了,他們的cookie資訊都傳送到了我的伺服器上,攻擊成功!這個過程中,受害者是多個人。
stored xss漏洞危害性更大,危害面更廣。
(3). xss防禦
xss防禦有如下方式。
* 完善的過濾體系
永遠不相信使用者的輸入。需要對使用者的輸入進行處理,只允許輸入合法的值,其它值一概過濾掉。
html encode
假如某些情況下,我們不能對使用者資料進行嚴格的過濾,那我們也需要對標籤進行轉換。
less-than character<
「greater-than character<
「>」;
ampersand character&
「&」;
double-quote character」
「"」;
space character()
「 」;
csrf(cross-site request forgery跨站請求偽造,也被稱為「one click attack」或者session riding,通常縮寫為csrf或者xsrf,是一種對**的惡意利用。儘管聽起來像跨站指令碼(xss),但它與xss非常不同,並且攻擊方式幾乎相左。xss利用站點內的信任使用者,而csrf則通過偽裝來自受信任使用者的請求來利用受信任的**。與xss攻擊相比,csrf攻擊往往不大流行(因此對其進行防範的資源也相當稀少)和難以防範,所以被認為比xss更具危險性。
你這可以這麼理解csrf攻擊:攻擊者盜用了你的身份,以你的名義傳送惡意請求。csrf能夠做的事情包括:以你名義傳送郵件,發訊息,盜取你的賬號,甚至於購買商品,虛擬貨幣轉賬……造成的問題包括:個人隱私洩露以及財產安全。
從上圖可以看出,要完成一次csrf攻擊,受害者必須依次完成兩個步驟:
1.登入受信任**a,並在本地生成cookie。
2.在不登出a的情況下,訪問危險**b。
csrf的防禦可以從服務端和客戶端兩方面著手,防禦效果是從服務端著手效果比較好,現在一般的csrf防禦也都在服務端進行。
(1). 服務端進行csrf防禦
服務端的csrf方式方法很多樣,但總的思想都是一致的,就是在客戶端頁面增加偽隨機數。
(1).cookie hashing(所有表單都包含同乙個偽隨機值):
這可能是最簡單的解決方案了,因為攻擊者不能獲得第三方的cookie(理論上),所以表單中的資料也就構造失敗了:
<?php
//構造加密的cookie資訊
$value = 「defensescrf」;
setcookie(」cookie」, $value, time()+3600);
?>
在表單裡增加hash值,以認證這確實是使用者傳送的請求。
複製**
<?php
$hash = md5($_cookie['cookie']);
?>
然後在伺服器端進行hash值驗證
<?php
if(isset($_post['check'])) else
} else
?>
這個方法個人覺得已經可以杜絕99%的csrf攻擊了,那還有1%呢….由於使用者的cookie很容易由於**的xss漏洞而被盜取,這就另外的1%。一般的攻擊者看到有需要算hash值,基本都會放棄了,某些除外,所以如果需要100%的杜絕,這個不是最好的方法。
(2).驗證碼
這個方案的思路是:每次的使用者提交都需要使用者在表單中填寫乙個上的隨機字串,這個方案可以完全解決csrf,但個人覺得在易用性方面似乎不是太好,還有聽聞是驗證碼的使用涉及了乙個被稱為mhtml的bug,可能在某些版本的微軟ie中受影響。
(3).one-time tokens(不同的表單包含乙個不同的偽隨機值)
在實現one-time tokens時,需要注意一點:就是「並行會話的相容」。如果使用者在乙個站點上同時開啟了兩個不同的表單,csrf保護措施不應該影響到他對任何表單的提交。考慮一下如果每次表單被裝入時站點生成乙個偽隨機值來覆蓋以前的偽隨機值將會發生什麼情況:使用者只能成功地提交他最後開啟的表單,因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保csrf保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器視窗瀏覽乙個站點。
以下我的實現:
1).先是令牌生成函式(gen_token()):
<?php
function gen_token()
2).然後是session令牌生成函式(gen_stoken()):
<?php
function gen_stoken()
else
}?>
3).web表單生成隱藏輸入域的函式:
<?php
function gen_input()
?>
4).web表單結構:
<?php
session_start();
include(」functions.php」);
?>
5).服務端核對令牌:
這個很簡單,這裡就不再囉嗦了。
上面這個其實不完全符合「並行會話的相容」的規則,大家可以在此基礎上修改。
**csrf攻擊方式
XSS攻擊與CSRF攻擊與防禦
csrf 跨站點請求偽造 cross site request forgery 使用者在自己電腦瀏覽乙個站點a,進行登入動作後,瀏覽完後沒有退出站點。在新的tab頁面開啟乙個站點b 加入站點b是乙個釣魚 其中有乙個連線是跳到站點a,這時候站點a的登入資訊你並沒退出,站點a認為是使用者操作行為,站點b...
XSS攻擊,SQL注入,CSRF攻擊入門
跨站指令碼攻擊 cross site scripting 為了不和層疊樣式表 cascading style sheets,css 的縮寫混淆,故將跨站指令碼攻擊縮寫為xss。惡意攻擊者往web頁面裡或url中插入惡意script 當使用者瀏覽該頁之時,嵌入其中web裡面的script 會被執行,從...
web安全(xss攻擊和csrf攻擊)
1 csrf攻擊 csrf cross site request forgery 跨站請求偽造。1 攻擊原理 如上圖,在b 引誘使用者訪問a 使用者之前登入過a 瀏覽器 cookie 快取了身份驗證資訊 通過呼叫a 的介面攻擊a 2 防禦措施 1 token驗證 登陸成功後伺服器下發token令牌存...