免費AI編程助手
Ajax的安全性問題
在Ajax請求/響應的數(shù)據(jù)可以在XML或JSON，認為這是一種重量輕的數(shù)據(jù)傳輸比傳統(tǒng)形式的基礎(chǔ)數(shù)據(jù)。
數(shù)據(jù)泄漏在Ajax或JSON劫持：
在繼續(xù)之前讓我們明白一個重要的概念:
1.JavaScript表達式
2.JavaScript數(shù)組
JavaScript表達式執(zhí)行的JavaScript解析器，但數(shù)組是：
列如：
<script>
{“t”:1,”p”:1,”r”:1,”rows”:[{"i":0,"c":["n","H, C","A","5","T","n"]}]}
</script>
這將不被執(zhí)行，即對象將不會被創(chuàng)建。上面的例子是一個JavaScript表達式。
但現(xiàn)在，當它被轉(zhuǎn)換成一個數(shù)組，如下面給出：
<script>
[{"t":1,"p":1,"r":1,"rows":[{"i":0,"c":["n","H, C","A","5","T","n"]}]}]
</script>
這才會被執(zhí)行。
情景：
用戶登錄到一個脆弱的應用（victimsite.com）的服務(wù)器JSON形式的陣列和數(shù)據(jù)敏感性質(zhì)。用戶獲取認證令牌（身份驗證）的應用。
攻擊者誘使用戶點擊一個鏈接，使用網(wǎng)絡(luò)釣魚或發(fā)送電子郵件給用戶。
用戶點擊該鏈接時，頁面加載，從攻擊者的網(wǎng)站，下面的腳本嵌入：
<script>
Object.prototype.__defineSetter__(“t”,function(obj){alert(1);for(var i in obj) {alert(i + ‘=’ + obj[i]);} });
</script>
<script>
src=”http://victimsite.com/mainJSON”/> //this points to the JSON
</script>
腳本再次發(fā)出請求，victimsite.com和訪問主JSON頁發(fā)送敏感數(shù)據(jù)到攻擊者的網(wǎng)頁，其中有兩個：現(xiàn)在JSON數(shù)據(jù)和身份驗證令牌。
然而,上述攻擊的先決條件是JSON數(shù)據(jù)必須敏感于自然和瀏覽器應該接受__defineSetter__方法,它覆蓋了現(xiàn)有的DOM或函數(shù)時調(diào)用屬性setter。在以上示例中,只要是被稱為“t”內(nèi)的屬性，函數(shù)警報，并且顯示它。然而，沒有多少瀏覽器支持defineSetter，’方法。
應對措施：
切勿將敏感信息發(fā)送JSON或不給他們使用JSON數(shù)組，這使得它可以通過腳本標記有效的JavaScript。
只服務(wù)身份驗證的請求，意味著使用某種形式的身份驗證來保護數(shù)據(jù)
必須發(fā)送JSON數(shù)據(jù)通過POST，GET，這將使它很難在<script>標簽包括URL
CSRF是什么？
CSRF代表跨站請求偽造，利用Web技術(shù)的一個基本的缺陷，它依賴于基于cookie認證并提交一個請求從用戶到服務(wù)器。在CSRF攻擊者可以欺騙用戶執(zhí)行，這是一個動作,不是有意的。必須進行身份驗證和用戶的攻擊的時候，有一個有效的會話ID。攻擊者也是使用一個有效的應用程序，并知道應用程序的內(nèi)部運作。更多關(guān)于CSRF這里：
CSRF和Ajax：
盡管CSRF是在傳統(tǒng)的Web應用中非常普遍，如果預防是無法實現(xiàn)的，它也可以進行基于AJAX的Web應用程序。唯一困難的是，因為它是一個隱藏的請求，它不是直接創(chuàng)建一個有效的請求。我們需要不僅要求技巧的標準，但我們也需要堅持有效的數(shù)據(jù)格式。
攻擊的步驟：
1.用戶到Web應用程序進行身份驗證，并瀏覽其內(nèi)容。
2.攻擊者，也是一個有效的用戶，創(chuàng)建一個用戶身份驗證點擊一個鏈接,獲取以下html頁面和加載載在其瀏覽器。
3.因此瀏覽器發(fā)出請求代表身份驗證的用戶。
防御措施：
為了防止這種攻擊，類似傳統(tǒng)的做法，要做到這一點有兩種方式：
嵌入非猜測的,隨機的令牌稱為當前請求/響應用戶請求的身份驗證和一個來自攻擊者的區(qū)分。這種方法基本上服務(wù)器嵌入當前請求頁面。當用戶提交頁面的服務(wù)器的可用性檢查的隨機數(shù),如果匹配,完成請求,否則拒絕。
使用Anti-CSRF header：我們的想法是生成一個自定義的heade， x-session-token在這種情況下，這被認為是敏感的，包括任何形式的交易請求。例如：xhr.setRequestHeader（’x-session-token’，csrf_token）
在服務(wù)端，服務(wù)器檢查這個header如果發(fā)現(xiàn)請求匹配，否則拒絕。我們需要利用這種技術(shù)使用XHR調(diào)用，還沒有用常規(guī)POST和GET請求。
XSS和Ajax：
XSS或跨站腳本：當一個應用程序不將用戶輸入或輸出為HTML渲染之前，它成為一個誘人的目標，因為他們可以在應用程序中插入惡意的JavaScript，并隨后進行放一炮而紅的攻擊目標，例如，會話劫持，網(wǎng)絡(luò)釣魚，惡意軟件感染等更多在這里：
在Ajax應用程序中尋找XSS:
可能的XSS指針是在JavaScript文件中的以下功能（JS）的存在。Ajax從后端接收響應，并填充的瀏覽器，使用以下功能之一：
document.write(): 這可能導致基于DOM的XSS。如果值沒有被正確過濾或修改一個特定部分的信息使用eval()是另一個指針。
其他易受傷害的功能被定為的innerHTML（）和write（）。
仔細掃描JavaScript的文件，在客戶端加載目標頁面的加載時間，可以給正在使用危害的函數(shù)一些提示。Firebug工具，它是偉大的，非常方便的在做這樣的分析。我們可以找出所有的Ajax調(diào)用XHR標簽
下（圖）：防御措施：
此外看看以下實例：
if(window.XMLHttpRequest)
http = new XMLHttpRequest();
eval(info);
if(window.XMLHttpRequest)
http = new XMLHttpRequest();
document.write(blogdetail);
我們需要分析這些功能，因為它們可能是未過濾的數(shù)據(jù)，可被利用的入口點。
一個從iSEC Partners的好例子：
XSS有效加載在Jason和它們的效果：
var inboundJSON = {“people”: [
{"name": "Joel", "address": “<script type="text/javascript">// <![CDATA[
badStuff();
// ]]></script>”, “phone”: “911″}]};
someObject.innerHTML(inboundJSON.people[0].address); // Vulnerable
document.write(inboundJSON.people[0].address); // Vulnerable
someObject.innerText(inboundJSON.people[0].address // Not Vulnerable
防御措施：
幾乎是相同的，我們會做傳統(tǒng)的XSS預防：
輸入驗證：嚴格檢查什么是允許的,什么不是在用戶輸入。正確過濾白名單允許的字符
輸出驗證：這意味著，所有的輸出必須正確編碼，然后呈現(xiàn)給用戶如HTMLEncoding。
結(jié)論：
因此，大部分影響Ajax的問題是那些傳統(tǒng)的Web應用程序，他們可能同樣的方式得到減輕。
更多建議：