XSS跨站腳本***問題和原理詳解

跨站腳本***(XSS,Cross-site scripting)是最常見和基本的***Web網站的方法。***者可以在網頁上發佈包含***性代碼的數據,當瀏覽者看到此網頁時,特定的腳本就會以瀏覽者用戶的身份和權限來執行。通過XSS可以比較容易地修改用戶數據、竊取用戶信息以及造成其它類型的***,例如:CSRF***。惡意***者往Web頁面裏插入惡意html代碼,當用戶瀏覽該頁之時,嵌入其中Web裏面的html代碼會被執行,從而達到惡意***用戶的特殊目的。

跨站腳本***的解決思路

預防XSS***的基本方法是:確保任何被輸出到HTML頁面中的數據以HTML的方式進行轉義(HTML escape)。例如PHP輸出:

PHP Code複製內容到剪貼板

  1. <textarea><?php echo $articleText; ?></textarea>   

如果這個articleText是由用戶自行輸入的,那麼***者很有可能輸入一段包含javascript惡意***代碼的文本,使得最終輸出變成:

PHP Code複製內容到剪貼板

  1. <textarea>   

  2. </textarea><script>alert('hello')'</script>   

  3. </textarea>  

上述代碼,在瀏覽器中渲染,將會執行JavaScript代碼並在屏幕上alert hello。當然這個代碼是無害的,但***者完全可以創建一個JavaScript來修改用戶資料或者竊取cookie數據。
解決方法很簡單,就是將輸出的值的值進行html escape,轉義後的輸出代碼如下

PHP Code複製內容到剪貼板

  1. <textarea>   

  2. </textarea><script>alert("hello!")</script>   

  3. </textarea>   

這樣就不會有任何危害了。

XSS危害

XSS其實是一門小衆但是熱門的***技術,之所以小衆,是由於費時間、很難成功、***無法自動化和需要紮實的htmljs功底,但是由於漏洞存在廣泛,即使是大型互聯網公司的站點也很容易由於疏忽存在此漏洞,這就是最大的熱門。
其實無論是哪一種xss***手段,其原理都是使用了“xss就是在頁面執行你想要的js”,也就是說,只要遵循一個原則——後端永遠不信任前端輸入的任何信息,無論是輸入還是輸出,都對其進行html字符的轉義,那麼漏洞就基本不存在了。

跨站請求僞造***(CSRF)

跨站請求僞造(CSRF,Cross-site request forgery)是另一種常見的***。***者通過各種方法僞造一個請求,模仿用戶提交表單的行爲,從而達到修改用戶的數據或執行特定任務的目的。
通常情況下CSRF***都配合XSS來實現用戶身份的模仿。

解決思路

1、增加***的難度。GET請求是很容易創建的,用戶點擊一個鏈接就可以發起GET類型的請求,而POST請求相對比較難,***者往往需要藉助JavaScript才能實現;因此,確保form表單或者服務端接口只接受POST類型的提交請求,可以增加系統的安全性。

2、對請求進行認證,確保該請求確實是用戶本人填寫表單或者發起請求並提交的,而不是第三者僞造的。
正常情況下一個用戶提交表單的步驟如下:

1)、用戶點擊鏈接(1) -> 網站顯示錶單(2) -> 用戶填寫信息並提交(3) -> 網站接受用戶的數據並保存(4)
而一個CSRF***則不會走這條路線,而是直接僞造第2步用戶提交信息

2)、直接跳到第2步(1) -> 僞造要修改的信息並提交(2) -> 網站接受***者修改參數數據並保存(3)
只要能夠區分這兩種情況,就能夠預防CSRF***。那麼如何區分呢? 就是對第2步所提交的信息進行驗證,確保數據源自第一步的表單。具體的驗證過程如下:

3)、用戶點擊鏈接(1) -> 網站顯示錶單,表單中包含特殊的token同時把token保存在session中(2) -> 用戶填寫信息並提交,同時發回token信息到服務端(3) -> 網站比對用戶發回的token和session中的token,應該一致,則接受數據,並保存

這樣,如果***者僞造要修改的信息並提交,是沒辦法直接訪問到session的,所以也沒辦法拿到實際的token值;請求發送到服務端,服務端進行token校驗的時候,發現不一致,則直接拒絕此次請求。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章