在此鏈接：http://www.acunetix.com/websitesecurity/cross-site-scripting/根據The Theory of XSS，它說：the hacker infects a legitimate web page with his malicious client-side script。我在閱讀這篇文章時遇到的第一個問題是：如果應用程序部署在安全的服務器上（例如銀行的情況就是如此），那麼黑客怎麼能夠訪問網頁的源代碼呢？或者他能注入惡意腳本而不訪問源jsp？什麼是跨站點腳本
該描述在其措辭方式上有點誤導。服務器在有人請求時提供的頁面不會改變。相反，XSS攻擊利用頁面中的弱點，其中包含在請求中提交的變量，以便在響應中以原始形式顯示。該頁面僅反映該請求中提交的內容......但該請求的內容可能包含突破普通文本內容的字符，並引入開發人員不打算使用的HTML或JavaScript內容。
下面是一個簡單的例子。假設您使用某種模板語言來生成HTML頁面（如PHP，ASP，CGI或Velocity或Freemarker腳本）。它採用以下頁面並將「<？= $ name？>」替換爲「name」查詢參數的非轉義值。
<html>
<head><title>Example</title></head>
<body>Hi, <?=$name?></body>
</html>
有人叫那個頁面有以下網址：
http://example.com/unsafepage?name=Rumplestiltskin
應該會看到這樣一條消息：
Hi, Rumplestiltskin
調用更多的東西惡意同一頁面可以用來改變頁面或用戶體驗很大。
http://example.com/unsafepage?name=Rumplestiltskin<script>alert('Boo!')</script>
而不是隻是說，「嗨，Rumplestiltskin」，這個URL也會導致頁面彈出警告消息，說：「噓！」。當然，這是一個簡單的例子。人們可以提供一個複雜的腳本，捕獲按鍵或要求驗證的名稱和密碼，或者清除屏幕並完全用震驚內容重寫頁面。它仍然看起來像它來自example.com，因爲頁面本身就是這樣做的，但CONTENT正在請求的某處提供，並且只是作爲頁面的一部分反射回來。因此，如果頁面只是吐出請求者提供的內容，並且您正在請求該頁面，那麼黑客如何感染您的請求？通常，這是通過在網頁上提供鏈接或通過電子郵件發送給您的鏈接或URL縮短請求中的鏈接來實現的，因此很難看到URL中的亂七八糟。
<a href="http://example.com?name=<script>alert('Malicious content')</script>">
Click Me!
</a>
服務器上沒有任何東西被「感染」。當服務器的頁面被重複發送時，XSS只是一個讓事情看起來來自服務器的技巧。
感謝您的一個很好的解釋 – Victor
我有一個錯誤的想法，公司內部網，當您嘗試訪問一個網站是在不同的域（在同一公司內）只有XSS出現問題。看起來XSS似乎可以一直髮生。即使我嘗試訪問諸如http：// localhost：8080/someservlet – Victor
之類的東西，您的新理解是正確的。不過，你正在描述一種有效的危險。 XSS最初只會影響您正在訪問的頁面，但是您注入的新內容可以將您重定向到任何地方 - 而且當該地點位於您已經身份驗證的某個位置時，XSS特別危險。 – phatfingers
攻擊者不需要訪問源代碼。
一個簡單的例子就是寫入頁面的URL參數。您可以更改URL參數以包含腳本標記。
另一個例子是評論系統。如果網站沒有正確處理輸入/輸出，攻擊者可以將腳本添加到評論中，然後在評論的任何人的計算機上顯示和執行評論。
這些都是簡單的例子。還有很多不同類型的XSS攻擊。
最好將腳本想象成被注入到糟糕編碼的網頁和客戶端的網頁瀏覽器之間的對話中。它實際上並沒有注入到網頁的代碼中;而是進入客戶端網絡瀏覽器的數據流。
有兩種類型的XSS攻擊：
見一個簡單的例子如下：What Is Cross-Site Scripting (XSS)?
的可能重複[？什麼是跨站點腳本包容（XSSI）（http://stackoverflow.com/questions/8028511/what-is-跨站點腳本包含xssi） –