從客戶端(textarea="<p>wewqe</p>")中檢測到有潛在危險的 Request.QueryString 值。

用過富文本編輯器的人應該會遇到過這類似的問題,就是在我對富文本上的文字進行保存的時候,有2種方式,一

種是純文本信息,如:“今天我寫了一個博客”,而另一種就是純html格式,如:<p>“今天我寫了一個博客”</p>。


有的時候我們爲了方便對文本信息的處理可能會將編輯的內容保存成html格式存放到數據庫,這樣可以方便我們的後續操作,比如原來的一些樣式不會變,但你存string字符串格式獲取到文本後就得重新編排了,所以很顯然html格式很實用。


但是,問題來了。我們存html格式的數據會存在一個驗證問題,如下:



參考網上衆多案例分析,以asp.net爲例,有這樣做的:

validateRequest="false"

也有這樣做的:修改web.config文件:

<configuration>
    <system.web>
        <pages validateRequest="false" />
    </system.web>
</configuration>

web.config裏面加上

<system.web>
    <httpRuntime requestValidationMode="2.0" />
</system.web>


諸此種種...


然而我發現這並沒有什麼卵用




1.首先我用的是MVC模式,可能環境不一樣這樣做的效果貌似行不通


2.項目文件大了有的東西不是說改就能改的,何況4.0或者4.5的程序改成2.0的是要冒一點風險性的


3.不安全。


關於不安全這一點我的理解是,存在這個異常(問題/bug)絕非是偶然的,用哲學的話來講叫存在即合理,說白了這裏之所以提示具有潛在的危險值應該是開發工具的一個智能檢測,像上面提到的,存html格式的文本信息的時候“<p>“今天我寫了一個博客”</p>”是這樣的,裏面包含特殊字符,如“<>”尖括號。這樣的值在某些時候對於數據庫可能是致命的,衆所周知的就是SQL注入式攻擊,一般在處理添加數據的時候都會有驗證來防止這個,但是文本編輯器處理的文本多了問題也就來了。


說到這裏你可能想到解決辦法了,既然注入式攻擊是從添加的時候做正則驗證來避免的,那麼這裏是不是也可以這樣?


由於文本編輯器在輸入值的時候是不帶hml標記的,只有取值的時候你才知道那些標記是怎樣回事,因此這裏用正則之類的驗證不合理,綜合以上種種方法的優劣性,我換了一種方式實現數據的存取,就是對獲取的字符串進行編碼和解碼處理!


編碼:



存放到數據庫中的字符串樣例:



解碼:



編碼解碼簡化樣例:

var html="<p>今天寫了一篇長長的博客</p>";//需要編碼的字符串

var htmlEscape=escape(html);//編碼

//----存放到數據庫----

//----從數據庫取出----用變量htmlSQL接收

var htmlUnEscape=unescape(htmlSQL);//解碼

//---然後alert彈窗測試,和原來的值一樣,但是最開始的那個問題解決了.....雖然寫了很多,但解決問題也就2行代碼,以上側重思路。



Sakura,2015.7.8號編制





發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章