php過濾xss函數

⑴ 求教Thinkphp 有自帶的防止XSS的代碼么

你好,據我所知,ThinkPHP並沒有自帶的防止XSS的代碼.不過,在PHP上,要想防止XSS,其實很簡單,只需要調用一個函數即可:htmlspecialchars()
在你的要求輸入字元的位置,調用htmlspecialchars()函數即可.
希望我的回答能夠對你有所幫助.

⑵ ASP、PHP網站如何根治XSS跨站

避免XSS的主要方法是將用戶所提供的內容輸入輸出進行過濾，許多語言都有提供對HTML的過濾：可以利用下面這些函數對出現xss漏洞的參數進行過濾
PHP的htmlentities()或是htmlspecialchars()，Python的cgi.escape()，ASP的Server.HTMLEncode()，ASP.NET的Server.HtmlEncode()或功能更強的Microsoft Anti-Cross Site Scripting Library，java的xssprotect(Open Source Library)，Node.js的node-validator。

⑶ php漏洞與代碼審計過程中需要注意的幾點

1.xss + sql注入
其中佔大頭的自然是XSS與SQL注入，對於框架類型或者有公共文件的，建議在公共文件中統一做一次XSS和SQL注入的過濾。寫個過濾函數，可由如下所示：
$_REQUEST = filter_xss（$_REQUEST）；
$_GET = filter_xss（$_GET）；
$_POST = filter_xss（$_POST）；
$_COOKIE = filter_xss（$_COOKIE）；
$_POST = filter_sql（$_POST）；
$_GET = filter_sql（$_GET）；
$_COOKIE = filter_sql（$_COOKIE）；
$_REQUEST = filter_sql（$_REQUEST）；
這里有一點需要說明，$_REQUEST雖然等於$_GET+$_POST,但他們是獨立的數組，也就是說假設改變了$_GET的值，但$_REQUEST的值還是原來的值，所以過濾時都不能落下，至於其他的如$_FILE之類的就可忽略了。
最簡單的filter_xss函數是htmlspecialchars（）
最簡單的filter_sql函數是mysql_real_escape_string（）
當然，誰都知道這種過濾filter_sql只能過濾字元型和搜索型的注入，對於數字型是沒有辦法的，但也說明做了這層過濾後，只需在後面注意數字型的SQL語句就可以了，遇到了加intval過濾就可以了，這就變得容易多了。
2. 命令執行
對於命令執行，可以從關鍵字入手，總共可分為3類
（1） php代碼執行 :eval等
（2）shell命令執行：exec、passthru、system、shell_exec等
（3） 文件處理：fwrite、fopen、mkdir等
對於這幾類需要注意其參數是否用戶可控。
3.上傳漏洞
對於上傳漏洞，也是重點關注的地方，要仔細分析它的處理流程，針對上傳的繞過方式是很多的，最保險的方式：在保存文件是採用文件名隨機命名和後綴白名單方式。其次要注意的一點是上傳文件的地方可能不止一處，不要有遺漏，可能會碰到這樣的情況，突然在某個目錄裡麵包含了一個第三方的編輯器在裡面。
文件包含漏洞涉及的函數如include（） 、include_once（）、require（）、require_once（）、file_get_contents（）等
最常見的還是出在下載文件功能函數，例如download.php?file=///etc/passwd 這種類型中。
4. 許可權繞過
許可權繞過可分為兩類吧
（1）後台文件的未授權訪問。後台的文件沒有包含對session的驗證，就容易出現這樣的問題
（2）未作用戶隔離，例如mail.php?id=23顯示了你的信件，那麼換個ID, mail.php?id=24就查看到了別人的信件，編寫代碼是方便，把信件都存在一個數據表裡，id統一編號，前端展現時只需按id取出即可，但未作用戶隔離，判定歸屬，容易造成越權訪問。
這樣的例子是很常見的，給某銀行做評估是就經常發現這種漏洞。
5. 信息泄露
信息泄露算是比較低危的漏洞了，比如列目錄這種就屬於部署問題，而與代碼審計無關了，而像暴路徑、暴源碼這種是需要防止的。曾經遇到這樣的代碼
<?php if（empty（$_GET['a']）） {…} ?>
表面上似乎沒問題，可是當請求變為 xx.php?a[]=1時，即參數變為數組的時候，就會發生錯誤以致路徑泄露，而用isset判斷則不會，當然一個個防太麻煩，建議在配置文件中關閉錯誤提示，或者在公共文件中加入如下代碼以關閉錯誤顯示功能：
<?php error_reporting（0）；?>

⑷ php網站怎樣防禦xss攻擊

過濾用戶輸入的<script></script>以及其他的HTML標簽等。。

⑸ 如何在php中修補XSS漏洞

你好，如果要修補xss漏洞，通用的一個做法是使用htmlspecialchars()函數。
使用該函數大概可以預防90%左右的xss左右的攻擊，避免你的PHP程序受到攻擊。

⑹ XSS（跨站腳本漏洞）誰幫忙修復下，我看著就頭大，一竅不通啊。

對於php你可以用htmlentities()函數
例如這樣:
<?php
echo htmlentities($_POST['abc']);
?>
至於asp，默認就能防xss攻擊，無需任何操作

⑺ 如何正確防禦xss攻擊

傳統防禦技術

2.1.1基於特徵的防禦

傳統XSS防禦多採用特徵匹配方式，在所有提交的信息中都進行匹配檢查。對於這種類型的XSS攻擊，採用的模式匹配方法一般會需要對「javascript」這個關鍵字進行檢索，一旦發現提交信息中包含「javascript」，就認定為XSS攻擊。

2.1.2 基於代碼修改的防禦

和SQL注入防禦一樣，XSS攻擊也是利用了Web頁面的編寫疏忽，所以還有一種方法就是從Web應用開發的角度來避免：

1、對所有用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、POST數據等，僅接受指定長度范圍內、採用適當格式、採用所預期的字元的內容提交，對其他的一律過濾。

2、實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查，以防功能被第三方網站所執行。

3、確認接收的的內容被妥善的規范化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠程內容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。

當然，如上方法將會降低Web業務系統的可用性，用戶僅能輸入少量的制定字元，人與系統間的交互被降到極致，僅適用於信息發布型站點。

並且考慮到很少有Web編碼人員受過正規的安全培訓，很難做到完全避免頁面中的XSS漏洞。

(7)php過濾xss函數擴展閱讀：

XSS攻擊的危害包括

1、盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號

2、控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力

3、盜竊企業重要的具有商業價值的資料

4、非法轉賬

5、強制發送電子郵件

6、網站掛馬

7、控制受害者機器向其它網站發起攻擊

受攻擊事件

新浪微博XSS受攻擊事件

2011年6月28日晚，新浪微博出現了一次比較大的XSS攻擊事件。

大量用戶自動發送諸如：

「郭美美事件的一些未注意到的細節」，「建黨大業中穿幫地方」，「讓女人心動的100句詩歌」，「這是傳說中的神仙眷侶啊」等等微博和私信，並自動關注一位名為hellosamy的用戶。

事件的經過線索如下：

20:14，開始有大量帶V的認證用戶中招轉發蠕蟲

20:30，某網站中的病毒頁面無法訪問

20:32，新浪微博中hellosamy用戶無法訪問

21:02，新浪漏洞修補完畢

網路貼吧xss攻擊事件

2014年3月9晚，六安吧等幾十個貼吧出現點擊推廣貼會自動轉發等。並且吧友所關注的每個關注的貼吧都會轉一遍，病毒循環發帖。並且導致吧務人員，和吧友被封禁。

⑻ 如何防止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()