XSS攻擊通常是指黑客通過(guò)"HTML注入"篡改了網(wǎng)頁(yè)，插入了惡意的腳本，從而在用戶瀏覽網(wǎng)頁(yè)時(shí)，控制用戶瀏覽器的一種攻擊。
我們提供的服務(wù)有：網(wǎng)站設(shè)計(jì)制作、做網(wǎng)站、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、左云ssl等。為上千企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的左云網(wǎng)站制作公司
一、HttpOnly防止劫取Cookie
HttpOnly最早由微軟提出，至今已經(jīng)成為一個(gè)標(biāo)準(zhǔn)。瀏覽器將禁止頁(yè)面的Javascript訪問(wèn)帶有HttpOnly屬性的Cookie。目前主流瀏覽器都支持，HttpOnly解決是XSS后的Cookie支持攻擊。
我們來(lái)看下百度有沒(méi)有使用。
未登錄時(shí)的Cookie信息
可以看到，所有Cookie都沒(méi)有設(shè)置HttpOnly，現(xiàn)在我登錄下
發(fā)現(xiàn)在個(gè)叫BDUSS的Cookie設(shè)置了HttpOnly?？梢圆聹y(cè)此Cookie用于認(rèn)證。
下面我用PHP來(lái)實(shí)現(xiàn)下：
?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只能讀到?jīng)]有HttpOnly標(biāo)識(shí)的Cookie
二、輸入檢查
輸入檢查一般是檢查用戶輸入的數(shù)據(jù)中是否包含一些特殊字符，如、、'、"等，如果發(fā)現(xiàn)存在特殊字符，則將這些字符過(guò)濾或者編碼。
例如網(wǎng)站注冊(cè)經(jīng)常用戶名只允許字母和數(shù)字的組合，或者郵箱電話，我們會(huì)在前端用js進(jìn)行檢查，但在服務(wù)器端代碼必須再次檢查一次，因?yàn)榭蛻舳说臋z查很容易繞過(guò)。
網(wǎng)上有許多開(kāi)源的“XSS Filter”的實(shí)現(xiàn)，但是它們應(yīng)該選擇性的使用，因?yàn)樗鼈儗?duì)特殊字符的過(guò)濾可能并非數(shù)據(jù)的本意。比如一款php的lib_filter類：
$filter = new lib_filter();
echo $filter-go('1+11');
它輸出的是1，這大大歪曲了數(shù)據(jù)的語(yǔ)義，因此什么情況應(yīng)該對(duì)哪些字符進(jìn)行過(guò)濾應(yīng)該適情況而定。
三、輸出檢查
大多人都知道輸入需要做檢查，但卻忽略了輸出檢查。
1、在HTML標(biāo)簽中輸出
如代碼：
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=$b?/div
a href="#"?=$a?/a
這樣客戶端受到xss攻擊，解決方法就是對(duì)變量使用htmlEncode,php中的函數(shù)是htmlentities
?php
$a = "scriptalert(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中實(shí)現(xiàn)：
$immune_htmlattr = array(',', '.', '-', '_');
$this-htmlEntityCodec-encode($this-immune_htmlattr, "\"script123123;/script\"");
3、在script標(biāo)簽中輸出
如代碼：
?php
$c = "1;alert(3)";
?
script type="text/javascript"
var c = ?=$c?;
/script
這樣xss又生效了。首先js變量輸出一定要在引號(hào)內(nèi)，但是如果我$c = "\"abc;alert(123);//"，你會(huì)發(fā)現(xiàn)放引號(hào)中都沒(méi)用，自帶的函數(shù)都不能很好的滿足。這時(shí)只能使用一個(gè)更加嚴(yán)格的JavascriptEncode函數(shù)來(lái)保證安全——除數(shù)字、字母外的所有字符，都使用十六進(jìn)制"\xHH"的方式進(jìn)行編碼。這里我采用開(kāi)源的owasp-php方法來(lái)實(shí)現(xiàn)
$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
這個(gè)其實(shí)就是寫在script中，所以跟3防御相同
5、在css中輸出
在owasp-php中實(shí)現(xiàn)：
$immune = array("");
$this-cssCodec-encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
6、在地址中輸出
先確保變量是否是"http"開(kāi)頭，然后再使用js的encodeURI或encodeURIComponent方法。
在owasp-php中實(shí)現(xiàn)：
$instance = ESAPI::getEncoder();
$instance-encodeForURL(‘url’);
四、處理富文體
就像我寫這篇博客，我?guī)缀蹩梢噪S意輸入任意字符，插入圖片，插入代碼，還可以設(shè)置樣式。這個(gè)時(shí)要做的就是設(shè)置好白名單，嚴(yán)格控制標(biāo)簽。能自定義 css件麻煩事，因此最好使用成熟的開(kāi)源框架來(lái)檢查。php可以使用htmlpurify
五、防御DOM Based XSS
DOM Based XSS是從javascript中輸出數(shù)據(jù)到HTML頁(yè)面里。
script
var x = "$var";
document.write("a href='"+x+"'test/a");
/script
按照三中輸出檢查用到的防御方法，在x賦值時(shí)進(jìn)行編碼，但是當(dāng)document.write輸出數(shù)據(jù)到HTML時(shí)，瀏覽器重新渲染了頁(yè)面，會(huì)將x進(jìn)行解碼，因此這么一來(lái)，相當(dāng)于沒(méi)有編碼，而產(chǎn)生xss。
防御方法：首先，還是應(yīng)該做輸出防御編碼的，但后面如果是輸出到事件或腳本，則要再做一次javascriptEncode編碼，如果是輸出到HTML內(nèi)容或?qū)傩?，則要做一次HTMLEncode。
會(huì)觸發(fā)DOM Based XSS的地方有很多：
document.write()、document.writeln()、xxx.innerHTML=、xxx.outerHTML=、innerHTML.replace、document.attachEvent()、window.attachEvent()、document.location.replace()、document.location.assign()
PHP如何做好最基礎(chǔ)的安全防范
php給了開(kāi)發(fā)者極大的靈活性，但是這也為安全問(wèn)題帶來(lái)了潛在的隱患，PHP如何做好最基礎(chǔ)的安全防范呢？下面我為大家解答一下，希望能幫到您！
當(dāng)開(kāi)發(fā)一個(gè)互聯(lián)網(wǎng)服務(wù)的時(shí)候，必須時(shí)刻牢記安全觀念，并在開(kāi)發(fā)的代碼中體現(xiàn)。PHP腳本語(yǔ)言對(duì)安全問(wèn)題并不關(guān)心，特別是對(duì)大多數(shù)沒(méi)有經(jīng)驗(yàn)的開(kāi)發(fā)者來(lái)說(shuō)。每當(dāng)你講任何涉及到錢財(cái)事務(wù)等交易問(wèn)題時(shí)，需要特別注意安全問(wèn)題的考慮，例如開(kāi)發(fā)一個(gè)論壇或者是一個(gè)購(gòu)物車等。
安全保護(hù)一般性要點(diǎn)
不相信表單
對(duì)于一般的Javascript前臺(tái)驗(yàn)證，由于無(wú)法得知用戶的行為，例如關(guān)閉了瀏覽器的javascript引擎，這樣通過(guò)POST惡意數(shù)據(jù)到服務(wù)器。需要在服務(wù)器端進(jìn)行驗(yàn)證，對(duì)每個(gè)php腳本驗(yàn)證傳遞到的數(shù)據(jù)，防止XSS攻擊和SQL注入。
不相信用戶
要假設(shè)你的網(wǎng)站接收的每一條數(shù)據(jù)都是存在惡意代碼的，存在隱藏的威脅，要對(duì)每一條數(shù)據(jù)都進(jìn)行清理
關(guān)閉全局變量
在php.ini文件中進(jìn)行以下配置：
register_globals = Off
如果這個(gè)配置選項(xiàng)打開(kāi)之后，會(huì)出現(xiàn)很大的安全隱患。例如有一個(gè)process.php的腳本文件，會(huì)將接收到的數(shù)據(jù)插入到數(shù)據(jù)庫(kù)，接收用戶輸入數(shù)據(jù)的表單可能如下：
input name="username" type ="text" size = "15" maxlength = "64"
這樣，當(dāng)提交數(shù)據(jù)到process.php之后，php會(huì)注冊(cè)一個(gè)$username變量，將這個(gè)變量數(shù)據(jù)提交到process.php，同時(shí)對(duì)于任何POST或GET請(qǐng)求參數(shù)，都會(huì)設(shè)置這樣的變量。如果不是顯示進(jìn)行初始化那么就會(huì)出現(xiàn)下面的問(wèn)題：
?php
// Define $authorized = true only if user is authenticated
if
(authenticated_user()) {
$authorized = true;
}
?
此處，假設(shè)authenticated_user函數(shù)就是判斷$authorized變量的值，如果開(kāi)啟了register_globals配置，那么任何用戶都可以發(fā)送一個(gè)請(qǐng)求，來(lái)設(shè)置$authorized變量的值為任意值從而就能繞過(guò)這個(gè)驗(yàn)證。所有的這些提交數(shù)據(jù)都應(yīng)該通過(guò)PHP預(yù)定義內(nèi)置的全局?jǐn)?shù)組來(lái)獲取，包括$_POST、$_GET、$_FILES、$_SERVER、$_REQUEST等，其中$_REQUEST是一個(gè)$_GET/$_POST/$_COOKIE三個(gè)數(shù)組的聯(lián)合變量，默認(rèn)的順序是$_COOKIE、$_POST、$_GET。
推薦的安全配置選項(xiàng)
error_reporting設(shè)置為Off：不要暴露錯(cuò)誤信息給用戶，開(kāi)發(fā)的時(shí)候可以設(shè)置為ON
safe_mode設(shè)置為Off
register_globals設(shè)置為Off
將以下函數(shù)禁用：system、exec、passthru、shell_exec、proc_open、popen
open_basedir設(shè)置為 /tmp ，這樣可以讓session信息有存儲(chǔ)權(quán)限，同時(shí)設(shè)置單獨(dú)的網(wǎng)站根目錄expose_php設(shè)置為Offallow_url_fopen設(shè)置為Offallow_url_include設(shè)置為Off
SQL注入攻擊
對(duì)于操作數(shù)據(jù)庫(kù)的SQL語(yǔ)句，需要特別注意安全性，因?yàn)橛脩艨赡茌斎胩囟ㄕZ(yǔ)句使得原有的SQL語(yǔ)句改變了功能。類似下面的例子：
$sql ="select * from pinfo where product = '$product'";
此時(shí)如果用戶輸入的$product參數(shù)為：'39'; DROP pinfo; SELECT 'FOO
那么最終SQL語(yǔ)句就變成了如下的`樣子：
select product from pinfo where product = '39';
DROP pinfo;
SELECT 'FOO'
這樣就會(huì)變成三條SQL語(yǔ)句，會(huì)造成pinfo表被刪除，這樣會(huì)造成嚴(yán)重的后果。這個(gè)問(wèn)題可以簡(jiǎn)單的使用PHP的內(nèi)置函數(shù)解決：
$sql = 'Select * from pinfo where product = '"' mysql_real_escape_string($product) . '"';
防止SQL注入攻擊需要做好兩件事：對(duì)輸入的參數(shù)總是進(jìn)行類型驗(yàn)證對(duì)單引號(hào)、雙引號(hào)、反引號(hào)等特殊字符總是使用mysql_real_escape_string函數(shù)進(jìn)行轉(zhuǎn)義但是，這里根據(jù)開(kāi)發(fā)經(jīng)驗(yàn)，不要開(kāi)啟php的Magic Quotes，這個(gè)特性在php6中已經(jīng)廢除，總是自己在需要的時(shí)候進(jìn)行轉(zhuǎn)義。
防止基本的XSS攻擊
XSS攻擊不像其他攻擊，這種攻擊在客戶端進(jìn)行，最基本的XSS工具就是防止一段javascript腳本在用戶待提交的表單頁(yè)面，將用戶提交的數(shù)據(jù)和cookie偷取過(guò)來(lái)。XSS工具比SQL注入更加難以防護(hù)，各大公司網(wǎng)站都被XSS攻擊過(guò)，雖然這種攻擊與php語(yǔ)言無(wú)關(guān)，但可以使用php來(lái)篩選用戶數(shù)據(jù)達(dá)到保護(hù)用戶數(shù)據(jù)的目的，這里主要使用的是對(duì)用戶的數(shù)據(jù)進(jìn)行過(guò)濾，一般過(guò)濾掉HTML標(biāo)簽，特別是a標(biāo)簽。下面是一個(gè)普通的過(guò)濾方法：
function transform_HTML( $string , $length null) { // Helps prevent XSS attacks
// Remove dead space.
$string = trim( $string );
// Prevent potential Unicode codec problems.
$string = utf8_decode( $string );
// HTMLize HTML-specific characters.
$string = htmlentities( $string , ENT_NOQUOTES);
$string = str_replace ( "#" , "#" , $string );
$string = str_replace ( "%" , "%" , $string );
$length = intval ( $length );
if ( $length 0) {
$string = substr ( $string , 0, $length );
}return $string ;
}
這個(gè)函數(shù)將HTML的特殊字符轉(zhuǎn)換為了HTML實(shí)體，瀏覽器在渲染這段文本的時(shí)候以純文本形式顯示。如bold會(huì)被顯示為： BoldText 上述函數(shù)的核心就是htmlentities函數(shù)，這個(gè)函數(shù)將html特殊標(biāo)簽轉(zhuǎn)換為html實(shí)體字符，這樣可以過(guò)濾大部分的XSS攻擊。但是對(duì)于有經(jīng)驗(yàn)的XSS攻擊者，有更加巧妙的辦法進(jìn)行攻擊：將他們的惡意代碼使用十六進(jìn)制或者utf-8編碼，而不是普通的ASCII文本，例如可以使用下面的方式進(jìn)行：
這樣瀏覽器渲染的結(jié)果其實(shí)是：
a href = ""
SCRIPT Dosomethingmalicious
這樣就達(dá)到了攻擊的目的。為了防止這種情況，需要在transform_HTML函數(shù)的基礎(chǔ)上再將#和%轉(zhuǎn)換為他們對(duì)應(yīng)的實(shí)體符號(hào)，同時(shí)加上了$length參數(shù)來(lái)限制提交的數(shù)據(jù)的最大長(zhǎng)度。
使用SafeHTML防止XSS攻擊
上述關(guān)于XSS攻擊的防護(hù)非常簡(jiǎn)單，但是不包含用戶的所有標(biāo)記，同時(shí)有上百種繞過(guò)過(guò)濾函數(shù)提交javascript代碼的方法，也沒(méi)有辦法能完全阻止這個(gè)情況。目前，沒(méi)有一個(gè)單一的腳本能保證不被攻擊突破，但是總有相對(duì)來(lái)說(shuō)防護(hù)程度更好的。一共有兩個(gè)安全防護(hù)的方式：白名單和黑名單。其中白名單更加簡(jiǎn)單和有效。一種白名單解決方案就是SafeHTML，它足夠智能能夠識(shí)別有效的HTML，然后就可以去除任何危險(xiǎn)的標(biāo)簽。這個(gè)需要基于HTMLSax包來(lái)進(jìn)行解析。安裝使用SafeHTML的方法：
1、前往 下載最新的SafeHTML
2、將文件放入服務(wù)器的classes 目錄，這個(gè)目錄包含所有的SafeHTML和HTMLSax庫(kù)
3、在自己的腳本中包含SafeHTML類文件
4、建立一個(gè)SafeHTML對(duì)象
5、使用parse方法進(jìn)行過(guò)濾
?php/* If you're storing the HTMLSax3.php in the /classes directory, along
with the safehtml.php script, define XML_HTMLSAX3 as a null string. */define(XML_HTMLSAX3, '' );// Include the class file.require_once ( 'classes/safehtml.php' );
// Define some sample bad code.
$data = This data would raise an alert
" ;// Create a safehtml object.$safehtml = new safehtml();// Parse and sanitize the data.$safe_data = $safehtml -parse( $data );// Display result. echo 'The sanitized data is ' . $safe_data ;
?
SafeHTML并不能完全防止XSS攻擊，只是一個(gè)相對(duì)復(fù)雜的腳本來(lái)檢驗(yàn)的方式。
使用單向HASH加密方式來(lái)保護(hù)數(shù)據(jù)
單向hash加密保證對(duì)每個(gè)用戶的密碼都是唯一的，而且不能被破譯的，只有最終用戶知道密碼，系統(tǒng)也是不知道原始密碼的。這樣的一個(gè)好處是在系統(tǒng)被攻擊后攻擊者也無(wú)法知道原始密碼數(shù)據(jù)。加密和Hash是不同的兩個(gè)過(guò)程。與加密不同，Hash是無(wú)法被解密的，是單向的；同時(shí)兩個(gè)不同的字符串可能會(huì)得到同一個(gè)hash值，并不能保證hash值的唯一性。MD5函數(shù)處理過(guò)的hash值基本不能被破解，但是總是有可能性的，而且網(wǎng)上也有MD5的hash字典。
使用mcrypt加密數(shù)據(jù)MD5 hash函數(shù)可以在可讀的表單中顯示數(shù)據(jù)，但是對(duì)于存儲(chǔ)用戶的信用卡信息的時(shí)候，需要進(jìn)行加密處理后存儲(chǔ)，并且需要之后進(jìn)行解密。最好的方法是使用mcrypt模塊，這個(gè)模塊包含了超過(guò)30中加密方式來(lái)保證只有加密者才能解密數(shù)據(jù)。
?php$data = "Stuff you want encrypted" ;
$key = "Secret passphrase used to encrypt your data" ;
$cipher = "MCRYPT_SERPENT_256" $mode = "MCRYPT_MODE_CBC" ;function encrypt( $data, $key , cipher , $mode ) {// Encrypt datareturn (string) base64_encode ( mcrypt_encrypt ( $cipher , substr (md5( $key ),0,mcrypt_get_key_size( $cipher , $mode )), $data , $mode , substr (md5( $key ),0,mcrypt_get_block_size( $cipher , $mode )) ) );
}function decrypt( $data , $key ,$cipher , $mode ) {// Decrypt data
return (string) mcrypt_decrypt ( $cipher , substr (md5( $key ),0,mcrypt_get_key_size( $cipher , $mode )), base64_decode ( $data ), $mode , substr (md5( $key ),0,mcrypt_get_block_size( $cipher , $mode )) );
}?
mcrypt函數(shù)需要以下信息：
1、待加密數(shù)據(jù)
2、用來(lái)加密和解密數(shù)據(jù)的key
3、用戶選擇的加密數(shù)據(jù)的特定算法（cipher：
如 MCRYPT_TWOFISH192
,MCRYPT_SERPENT_256， MCRYPT_RC2
, MCRYPT_DES
, and MCRYPT_LOKI97
）
4、用來(lái)加密的模式
5、加密的種子，用來(lái)起始加密過(guò)程的數(shù)據(jù)，是一個(gè)額外的二進(jìn)制數(shù)據(jù)用來(lái)初始化加密算法
6、加密key和種子的長(zhǎng)度，使用mcrypt_get_key_size函數(shù)和mcrypt_get_block_size函數(shù)可以獲取如果數(shù)據(jù)和key都被盜取，那么攻擊者可以遍歷ciphers尋找開(kāi)行的方式即可，因此我們需要將加密的key進(jìn)行MD5一次后保證安全性。同時(shí)由于mcrypt函數(shù)返回的加密數(shù)據(jù)是一個(gè)二進(jìn)制數(shù)據(jù)，這樣保存到數(shù)據(jù)庫(kù)字段中會(huì)引起其他錯(cuò)誤，使用了base64encode將這些數(shù)據(jù)轉(zhuǎn)換為了十六進(jìn)制數(shù)方便保存。
;
傳統(tǒng)防御技術(shù)
2.1.1基于特征的防御
傳統(tǒng)XSS防御多采用特征匹配方式，在所有提交的信息中都進(jìn)行匹配檢查。對(duì)于這種類型的XSS攻擊，采用的模式匹配方法一般會(huì)需要對(duì)“javascript”這個(gè)關(guān)鍵字進(jìn)行檢索，一旦發(fā)現(xiàn)提交信息中包含“javascript”，就認(rèn)定為XSS攻擊。
2.1.2 基于代碼修改的防御
和SQL注入防御一樣，XSS攻擊也是利用了Web頁(yè)面的編寫疏忽，所以還有一種方法就是從Web應(yīng)用開(kāi)發(fā)的角度來(lái)避免：
1、對(duì)所有用戶提交內(nèi)容進(jìn)行可靠的輸入驗(yàn)證，包括對(duì)URL、查詢關(guān)鍵字、HTTP頭、POST數(shù)據(jù)等，僅接受指定長(zhǎng)度范圍內(nèi)、采用適當(dāng)格式、采用所預(yù)期的字符的內(nèi)容提交，對(duì)其他的一律過(guò)濾。
2、實(shí)現(xiàn)Session標(biāo)記(session tokens)、CAPTCHA系統(tǒng)或者HTTP引用頭檢查，以防功能被第三方網(wǎng)站所執(zhí)行。
3、確認(rèn)接收的的內(nèi)容被妥善的規(guī)范化，僅包含最小的、安全的Tag(沒(méi)有javascript)，去掉任何對(duì)遠(yuǎn)程內(nèi)容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。
當(dāng)然，如上方法將會(huì)降低Web業(yè)務(wù)系統(tǒng)的可用性，用戶僅能輸入少量的制定字符，人與系統(tǒng)間的交互被降到極致，僅適用于信息發(fā)布型站點(diǎn)。
并且考慮到很少有Web編碼人員受過(guò)正規(guī)的安全培訓(xùn)，很難做到完全避免頁(yè)面中的XSS漏洞。
擴(kuò)展資料：
XSS攻擊的危害包括
1、盜取各類用戶帳號(hào)，如機(jī)器登錄帳號(hào)、用戶網(wǎng)銀帳號(hào)、各類管理員帳號(hào)
2、控制企業(yè)數(shù)據(jù)，包括讀取、篡改、添加、刪除企業(yè)敏感數(shù)據(jù)的能力
3、盜竊企業(yè)重要的具有商業(yè)價(jià)值的資料
4、非法轉(zhuǎn)賬
5、強(qiáng)制發(fā)送電子郵件
6、網(wǎng)站掛馬
7、控制受害者機(jī)器向其它網(wǎng)站發(fā)起攻擊
受攻擊事件
新浪微博XSS受攻擊事件
2011年6月28日晚，新浪微博出現(xiàn)了一次比較大的XSS攻擊事件。
大量用戶自動(dòng)發(fā)送諸如：
“郭美美事件的一些未注意到的細(xì)節(jié)”，“建黨大業(yè)中穿幫地方”，“讓女人心動(dòng)的100句詩(shī)歌”，“這是傳說(shuō)中的神仙眷侶啊”等等微博和私信，并自動(dòng)關(guān)注一位名為hellosamy的用戶。
事件的經(jīng)過(guò)線索如下：
20:14，開(kāi)始有大量帶V的認(rèn)證用戶中招轉(zhuǎn)發(fā)蠕蟲
20:30，某網(wǎng)站中的病毒頁(yè)面無(wú)法訪問(wèn)
20:32，新浪微博中hellosamy用戶無(wú)法訪問(wèn)
21:02，新浪漏洞修補(bǔ)完畢
百度貼吧xss攻擊事件
2014年3月9晚，六安吧等幾十個(gè)貼吧出現(xiàn)點(diǎn)擊推廣貼會(huì)自動(dòng)轉(zhuǎn)發(fā)等。并且吧友所關(guān)注的每個(gè)關(guān)注的貼吧都會(huì)轉(zhuǎn)一遍，病毒循環(huán)發(fā)帖。并且導(dǎo)致吧務(wù)人員，和吧友被封禁。
參考資料：
XSS攻擊-百度百科
重慶分公司
重慶分公司
