⑴ XSS跨站腳本漏洞怎樣修復
對網站上的XSS跨站漏洞進行修復，對get,post,cookies進行安全效驗，對XSS跨站攻擊代碼進行攔截，或者是對網站安全防護參數進行重新設置，使他符合當時的網站環境。如果不懂如何修復網站漏洞，也可以找專業的網站安全公司來處理，國內也就Sinesafe和綠盟、啟明星辰等安全公司比較專業.
⑵ 下面這段代碼總是檢測到XSS跨站腳本攻擊漏洞找高手求解
是否有漏洞，取決於你輸出的內容是否可信
比如echo $rows["Author"];
如$rows["Author"]裡面是由用戶輸入且入庫未過濾，那麼直接輸出時存在xss漏洞的。
如$rows["Author"]輸入的值為〈script〉 alert( 1 )〈/script 〉
那麼直接輸出存在漏洞，
簡單點修改 echo htmlentities($rows["Author"]),其他echo的類似
如果輸出內容可信（過濾過，或來源可信安全）那麼直接輸出也不存在問題，程序檢測的未必准確。
入庫過濾了或者本身內容來源可靠不存在此漏洞。
⑶ 瀏覽器的Xss過濾器機制是什麼，為什麼有些反射型Xss不會觸發過濾器
首先要說明的是 它是webkit的一個模塊,而非chrome ,所以Safari和360安全瀏覽器極速模式等webkit內核的瀏覽器都有專XSS過濾功能.
過濾方式：
通過模糊匹屬配 輸入參數(GET query| POST form data| Location fragment ) 與 dom樹,如果匹配中的數據中包含跨站腳本則不在輸出到上下文DOM樹中.另外,匹配的規則跟CSP沒有什麼關系,最多是有參考,CSP這種規范類的東西更新速度太慢跟不上現實問題的步伐.
關閉模式：
因為它有可能影響到業務,所以瀏覽器提供了關閉它的HTTP響應頭.
X-XSS-Protection: 0
繞過方式：
因為專門做這方面的原因所以對繞過也有所了解,目前我發布過的一個bypass 0day還可以繼續使用.
<svg><script xlink:href=data:,alert(1)></script></svg>
⑷ 怎麼解決安全掃描 xss跨站腳本攻擊的問題
辨認常見掃描器比如safe3wvs、awvs、appscan的特徵，識別後直接封對方ip，另外還有對連接數進行限制、出錯次數過多則禁止連接等措施，防護xss攻擊則要過濾<>「」等危險字元及其他變形，過濾得越細致越安全。
⑸ 關於XSS 跨站腳本漏洞怎麼修復這個是需要JS過濾掉嗎
可以在騰訊智慧安全頁面申請使用騰訊御點
然後使用這個軟體上面的修復漏洞功能
直接對電腦的漏洞進行檢測和修復就可以了
⑹ XSS（跨站腳本漏洞）誰幫忙修復下，我看著就頭大，一竅不通啊。
對於php你可以用htmlentities()函數
例如這樣:
<?php
echo htmlentities($_POST['abc']);
?>
至於asp，默認就能防xss攻擊，無需任何操作
⑺ 怎樣過濾跨站惡意腳本攻擊
1. 在輸入流中截住form data中的惡意腳本
研究兩種XSS攻擊，如反射型和存儲型XSS攻擊，其惡意腳本都是來自用戶的輸入。因此，可以使用過濾用戶輸入的方法對惡意腳本進行過濾。對簡單的HTTP請求，一般使用GET和POST方法。
2. 在輸入流中檢測濾掉來自其他網站的URL中的惡意腳本
當用戶不小心點擊了被其他黑客提供的假冒URL，則可能在該URL中注入惡意腳本。因此，也需要對這種情況進行處理。因此為確保其他在header中的惡意腳本，需要對request.getHeader進行重寫。以下為例子：
public String getHeader(String name) {
String value = super.getHeader(name);
if (value == null)
return null;
return xssClean(value);
}
3. xssClean函數怎樣實現才可以過濾掉惡意腳本呢？
如果是java語言，推薦使用antisamy。使用antisamy進行XSS清理非常簡單，只需要簡單的幾個步驟即可達到目的。
1『. 在pom.xml文件中加入antisamy的dependency，
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>1.5.3</version>
</dependency>
2』. 加入了dependency之後，就可以在xssClean中加入antisamy對惡意腳本進行清理。其中policy.xml是白名單，policy.xml中規定了各個html元素所必須滿足的條件。antisamy的精髓之處在於，使用policy文件來規定你的過濾條件，若輸入字元串不滿足policy文件中的條件，則會過濾掉字元中的惡意腳本，返回過濾後的結果。具體代碼如下：
private String xssClean(String value) {
AntiSamy antiSamy = new AntiSamy()；
try {
final CleanResults cr = antiSamy.scan(value, Policy.getInstance("policy.xml"), AntiSamy.SAX);
return cr.getCleanHTML();
} catch (ScanException e) {
e.printStackTrace();
} catch (PolicyException e) {
e.printStackTrace();
}
return value;
}
這樣，我們就將client端用戶輸入的request，在server端進行了攔截，並且進行了過濾。
⑻ 解析如何防止XSS跨站腳本攻擊
不可信數據 不可信數據通常是來自HTTP請求的數據，以URL參數、表單欄位、標頭或者Cookie的形式。不過從安全形度來看，來自資料庫、網路伺服器和其他來源的數據往往也是不可信的，也就是說，這些數據可能沒有完全通過驗證。 應該始終對不可信數據保持警惕，將其視為包含攻擊，這意味著在發送不可信數據之前，應該採取措施確定沒有攻擊再發送。由於應用程序之間的關聯不斷深化，下游直譯程序執行的攻擊可以迅速蔓延。 傳統上來看，輸入驗證是處理不可信數據的最好辦法，然而，輸入驗證法並不是注入式攻擊的最佳解決方案。首先，輸入驗證通常是在獲取數據時開始執行的，而此時並不知道目的地所在。這也意味著我們並不知道在目標直譯程序中哪些字元是重要的。其次，可能更加重要的是，應用程序必須允許潛在危害的字元進入，例如，是不是僅僅因為SQL認為Mr. O'Malley名字包含特殊字元他就不能在資料庫中注冊呢? 雖然輸入驗證很重要，但這始終不是解決注入攻擊的完整解決方案，最好將輸入攻擊作為縱深防禦措施，而將escaping作為首要防線。 解碼(又稱為Output Encoding) 「Escaping」解碼技術主要用於確保字元作為數據處理，而不是作為與直譯程序的解析器相關的字元。有很多不同類型的解碼，有時候也被成為輸出「解碼」。有些技術定義特殊的「escape」字元，而其他技術則包含涉及若干字元的更復雜的語法。 不要將輸出解碼與Unicode字元編碼的概念弄混淆了，後者涉及映射Unicode字元到位序列。這種級別的編碼通常是自動解碼，並不能緩解攻擊。但是，如果沒有正確理解伺服器和瀏覽器間的目標字元集，有可能導致與非目標字元產生通信，從而招致跨站XSS腳本攻擊。這也正是為所有通信指定Unicode字元編碼(字元集)(如UTF-8等)的重要所在。 Escaping是重要的工具，能夠確保不可信數據不能被用來傳遞注入攻擊。這樣做並不會對解碼數據造成影響，仍將正確呈現在瀏覽器中，解碼只能阻止運行中發生的攻擊。 注入攻擊理論 注入攻擊是這樣一種攻擊方式，它主要涉及破壞數據結構並通過使用特殊字元(直譯程序正在使用的重要數據)轉換為代碼結構。XSS是一種注入攻擊形式，瀏覽器作為直譯程序，攻擊被隱藏在HTML文件中。HTML一直都是代碼和數據最差的mashup，因為HTML有很多可能的地方放置代碼以及很多不同的有效編碼。HTML是很復雜的，因為它不僅是層次結構的，而且還包含很多不同的解析器(XML、HTML、JavaScript、VBScript、CSS、URL等)。 要想真正明白注入攻擊與XSS的關系，必須認真考慮HTML DOM的層次結構中的注入攻擊。在HTML文件的某個位置(即開發者允許不可信數據列入DOM的位置)插入數據，主要有兩種注入代碼的方式： Injecting UP，上行注入 最常見的方式是關閉現有的context並開始一個新的代碼context，例如，當你關閉HTML屬性時使用">並開始新的 可以終止腳本塊，即使該腳本塊被注入腳本內方法調用內的引用字元，這是因為HTML解析器在JavaScript解析器之前運行。 Injecting DOWN，下行注入 另一種不太常見的執行XSS注入的方式就是，在不關閉當前context的情況下，引入一個subcontext。例如，將改為 ，並不需要躲開HTML屬性context，相反只需要引入允許在src屬性內寫腳本的context即可。另一個例子就是CSS屬性中的expression()功能，雖然你可能無法躲開引用CSS屬性來進行上行注入，你可以採用x ss:expression(document.write(document.cookie))且無需離開現有context。 同樣也有可能直接在現有context內進行注入，例如，可以採用不可信的輸入並把它直接放入JavaScript context。這種方式比你想像的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。從本質上講，如果這樣做，你的應用程序只會成為攻擊者將惡意代碼植入瀏覽器的渠道。 本文介紹的規則旨在防止上行和下行XSS注入攻擊。防止上行注入攻擊，你必須避免那些允許你關閉現有context開始新context的字元;而防止攻擊跳躍DOM層次級別，你必須避免所有可能關閉context的字元;下行注入攻擊，你必須避免任何可以用來在現有context內引入新的sub-context的字元。 積極XSS防禦模式 本文把HTML頁面當作一個模板，模板上有很多插槽，開發者允許在這些插槽處放置不可信數據。在其他地方放置不可信數據是不允許的，這是「白名單」模式，否認所有不允許的事情。 根據瀏覽器解析HTML的方式的不同，每種不同類型的插槽都有不同的安全規則。當你在這些插槽處放置不可信數據時，必須採取某些措施以確保數據不會「逃離」相應插槽並闖入允許代碼執行的context。從某種意義上說，這種方法將HTML文檔當作參數化的資料庫查詢，數據被保存在具體文職並與escaping代碼context相分離。 本文列出了最常見的插槽位置和安全放置數據的規則，基於各種不同的要求、已知的XSS載體和對流行瀏覽器的大量手動測試，我們保證本文提出的規則都是安全的。 定義好插槽位置，開發者們在放置任何數據前，都應該仔細分析以確保安全性。瀏覽器解析是非常棘手的，因為很多看起來無關緊要的字元可能起著重要作用。 為什麼不能對所有不可信數據進行HTML實體編碼? 可以對放入HTML文檔正文的不可行數據進行HTML實體編碼，如 標簽內。也可以對進入屬性的不可行數據進行實體編碼，尤其是當屬性中使用引用符號時。但是HTML實體編碼並不總是有效，例如將不可信數據放入 directlyinascript insideanHTMLcomment inanattributename <...NEVERPUTUNTRUSTEDDATAHERE...href="/test"/> inatagname 更重要的是，不要接受來自不可信任來源的JavaScript代碼然後運行，例如，名為「callback」的參數就包含JavaScript代碼段，沒有解碼能夠解決。 No.2 – 在向HTML元素內容插入不可信數據前對HTML解碼 這條規則適用於當你想把不可信數據直接插入HTML正文某處時，這包括內部正常標簽(div、p、b、td等)。大多數網站框架都有HTML解碼的方法且能夠躲開下列字元。但是，這對於其他HTML context是遠遠不夠的，你需要部署其他規則。 ...... ...... 以及其他的HTML常用元素 使用HTML實體解碼躲開下列字元以避免切換到任何執行內容，如腳本、樣式或者事件處理程序。在這種規格中推薦使用十六進制實體，除了XML中5個重要字元(&、<、 >、 "、 ')外，還加入了斜線符，以幫助結束HTML實體。 &-->& <-->< >-->> "-->" '-->''isnotrecommended /-->/ ESAPI參考實施 Stringsafe=ESAPI.encoder().encodeForHTML(request.getParameter("input")); No.3 – 在向HTML常見屬性插入不可信數據前進行屬性解碼 這條規則是將不可信數據轉化為典型屬性值(如寬度、名稱、值等)，這不能用於復雜屬性(如href、src、style或者其他事件處理程序)。這是及其重要的規則，事件處理器屬性(為HTML JavaScript Data Values)必須遵守該規則。 content insidesinglequotedattribute 除了字母數字字元外，使用小於256的ASCII值&#xHH格式(或者命名的實體)對所有數據進行解碼以防止切換屬性。這條規則應用廣泛的原因是因為開發者常常讓屬性保持未引用，正確引用的屬性只能使用相應的引用進行解碼。未引用屬性可以被很多字元破壞，包括[space] % * + , - / ; < = > ^ 和 |。 ESAPI參考實施 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); No.4 – 在向HTML JavaScript Data Values插入不可信數據前，進行JavaScript解碼 這條規則涉及在不同HTML元素上制定的JavaScript事件處理器。向這些事件處理器放置不可信數據的唯一安全位置就是「data value」。在這些小代碼塊放置不可信數據是相當危險的，因為很容易切換到執行環境，因此請小心使用。 insideaquotedstring onesideofanexpression insideUNquotedeventhandler insidequotedeventhandler insidequotedeventhandler 除了字母數字字元外，使用小於256的ASCII值xHH格式 對所有數據進行解碼以防止將數據值切換至腳本內容或者另一屬性。不要使用任何解碼捷徑(如" )因為引用字元可能被先運行的HTML屬性解析器相匹配。如果事件處理器被引用，則需要相應的引用來解碼。這條規則的廣泛應用是因為開發者經常讓事件處理器保持未引用。正確引用屬性只能使用相應的引用來解碼，未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。同時，由於HTML解析器比JavaScript解析器先運行，關閉標簽能夠關閉腳本塊，即使腳本塊位於引用字元串中。 ESAPI參考實施 Stringsafe=ESAPI.encoder().encodeForJavaScript(request.getParameter("input")); No.5 – 在向HTML 樣式屬性值插入不可信數居前，進行CSS解碼 當你想將不可信數據放入樣式表或者樣式標簽時，可以用此規則。CSS是很強大的，可以用於許多攻擊。因此，只能在屬性值中使用不可信數據而不能在其他樣式數據中使用。不能將不可信數據放入復雜的屬性(如url,、behavior、和custom (-moz-binding))。同樣，不能將不可信數據放入允許JavaScript的IE的expression屬性值。 propertyvalue textpropertyvalue 除了字母數字字元外，使用小於256的ASCII值HH格式對所有數據進行解碼。不要使用任何解碼捷徑(如" )因為引用字元可能被先運行的HTML屬性解析器相匹配，防止將數據值切換至腳本內容或者另一屬性。同時防止切換至expression或者其他允許腳本的屬性值。如果屬性被引用，將需要相應的引用進行解碼，所有的屬性都應該被引用。未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。同時，由於HTML解析器比JavaScript解析器先運行，標簽能夠關閉腳本塊，即使腳本塊位於引用字元串中。 ESAPI參考實施 Stringsafe=ESAPI.encoder().encodeForCSS(request.getParameter("input")); No.6- 在向HTML URL屬性插入不可信數據前，進行URL解碼 當你想將不可信數據放入鏈接到其他位置的link中時需要運用此規則。這包括href和src屬性。還有很多其他位置屬性，不過我們建議不要在這些屬性中使用不可信數據。需要注意的是在javascript中使用不可信數據的問題，不過可以使用上述的HTML JavaScript Data Value規則。 linkanormallink animagesource ascriptsource 除了字母數字字元外，使用小於256的ASCII值%HH 解碼格式對所有數據進行解碼。在數據中保護不可信數據：URL不能夠被允許，因為沒有好方法來通過解碼來切換URL以避免攻擊。所有的屬性都應該被引用。未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。 請注意實體編碼在這方面是沒用的。
⑼ 跨站腳本攻擊xss的原理是什麼有什麼危害如何防範
什麼是XSS攻擊XSS又叫CSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裡面的html代碼會被執行，從而達到惡意攻擊用戶的特殊目的。XSS屬於被動式的攻擊，因為其被動且不好利用，所以許多人常忽略其危害性。而本文主要講的是利用XSS得到目標伺服器的shell。技術雖然是老技術，但是其思路希望對大家有幫助。 [編輯本段]如何尋找XSS漏洞就個人而言，我把XSS攻擊分成兩類，一類是來自內部的攻擊，主要指的是利用程序自身的漏洞，構造跨站語句，如:dvbbs的showerror.asp存在的跨站漏洞。另一類則是來來自外部的攻擊，主要指的自己構造XSS跨站漏洞網頁或者尋找非目標機以外的有跨站漏洞的網頁。如當我們要滲透一個站點，我們自己構造一個有跨站漏洞的網頁，然後構造跨站語句，通過結合其它技術，如社會工程學等，欺騙目標伺服器的管理員打開。
⑽ 如何防止xss攻擊，需要過濾什麼
XSS攻擊通常是指黑客通過"HTML注入"篡改了網頁，插入了惡意的腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊。
一、HttpOnly防止劫取Cookie
HttpOnly最早由微軟提出，至今已經成為一個標准。瀏覽器將禁止頁面的Javascript訪問帶有HttpOnly屬性的Cookie。目前主流瀏覽器都支持，HttpOnly解決是XSS後的Cookie支持攻擊。
我們來看下網路有沒有使用。
未登錄時的Cookie信息
可以看到，所有Cookie都沒有設置HttpOnly，現在我登錄下
發現在個叫BDUSS的Cookie設置了HttpOnly。可以猜測此Cookie用於認證。
下面我用PHP來實現下：
<?php
header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly",false);
setcookie('cookie3','test3',NULL,NULL,NULL,NULL,false);
setcookie('cookie4','test4',NULL,NULL,NULL,NULL,true);
?>
<script>
alert(document.cookie);
</script>
js只能讀到沒有HttpOnly標識的Cookie
二、輸入檢查
輸入檢查一般是檢查用戶輸入的數據中是否包含一些特殊字元，如<、>、'、"等，如果發現存在特殊字元，則將這些字元過濾或者編碼。
例如網站注冊經常用戶名只允許字母和數字的組合，或者郵箱電話，我們會在前端用js進行檢查，但在伺服器端代碼必須再次檢查一次，因為客戶端的檢查很容易繞過。
網上有許多開源的「XSS Filter」的實現，但是它們應該選擇性的使用，因為它們對特殊字元的過濾可能並非數據的本意。比如一款php的lib_filter類：
$filter = new lib_filter();
echo $filter->go('1+1>1');
它輸出的是1，這大大歪曲了數據的語義，因此什麼情況應該對哪些字元進行過濾應該適情況而定。
三、輸出檢查
大多人都知道輸入需要做檢查，但卻忽略了輸出檢查。
1、在HTML標簽中輸出
如代碼：
<?php
$a = "<script>alert(1);</script>";
$b = "<img src=# onerror=alert(2) />";
?>
<div><?=$b?></div>
<a href="#"><?=$a?></a>
這樣客戶端受到xss攻擊，解決方法就是對變數使用htmlEncode,php中的函數是htmlentities
<?php
$a = "<script>alert(1);</script>";
$b = "<img src=# onerror=alert(2) />";
?>
<div><?=htmlentities($b)?></div>
<a href="#"><?=htmlentities($a)?></a>
2、在HTML屬性中輸出
<div id="div" name ="$var"></div>
這種情況防禦也是使用htmlEncode
在owasp-php中實現：
$immune_htmlattr = array(',', '.', '-', '_');
$this->htmlEntityCodec->encode($this->immune_htmlattr, "\"><script>123123;</script><\"");
3、在<script>標簽中輸出
如代碼：
<?php
$c = "1;alert(3)";
?>
<script type="text/javascript">
var c = <?=$c?>;
</script>
這樣xss又生效了。首先js變數輸出一定要在引號內，但是如果我$c = "\"abc;alert(123);//"，你會發現放引號中都沒用，自帶的函數都不能很好的滿足。這時只能使用一個更加嚴格的JavascriptEncode函數來保證安全——除數字、字母外的所有字元，都使用十六進制"\xHH"的方式進行編碼。這里我採用開源的owasp-php方法來實現
$immune = array("");
echo $this->javascriptCodec->encode($immune, "\"abc;alert(123);//");
最後輸出\x22abc\x3Balert\x28123\x29\x3B\x2F\x2F
4、在事件中輸出
<a href="#" onclick="funcA('$var')" >test</a>
可能攻擊方法
<a href="#" onclick="funcA('');alter(/xss/;//')">test</a>
這個其實就是寫在<script>中，所以跟3防禦相同
5、在css中輸出
在owasp-php中實現：
$immune = array("");
$this->cssCodec->encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
6、在地址中輸出
先確保變數是否是"http"開頭，然後再使用js的encodeURI或encodeURIComponent方法。
在owasp-php中實現：
$instance = ESAPI::getEncoder();
$instance->encodeForURL(『url』);
四、處理富文體
就像我寫這篇博客，我幾乎可以隨意輸入任意字元，插入圖片，插入代碼，還可以設置樣式。這個時要做的就是設置好白名單，嚴格控制標簽。能自定義 css件麻煩事，因此最好使用成熟的開源框架來檢查。php可以使用htmlpurify
五、防禦DOM Based XSS
DOM Based XSS是從javascript中輸出數據到HTML頁面里。
<script>
var x = "$var";
document.write("<a href='"+x+"'>test</a>");
</script>
按照三中輸出檢查用到的防禦方法，在x賦值時進行編碼，但是當document.write輸出數據到HTML時，瀏覽器重新渲染了頁面，會將x進行解碼，因此這么一來，相當於沒有編碼，而產生xss。
防禦方法：首先，還是應該做輸出防禦編碼的，但後面如果是輸出到事件或腳本，則要再做一次javascriptEncode編碼，如果是輸出到HTML內容或屬性，則要做一次HTMLEncode。
會觸發DOM Based XSS的地方有很多：
document.write()、document.writeln()、xxx.innerHTML=、xxx.outerHTML=、innerHTML.replace、document.attachEvent()、window.attachEvent()、document.location.replace()、document.location.assign()