Eric Pascarello解析Ajax安全性
來源:互聯網
上載者:User
ajax|安全|安全性 導讀】本文中,Ajax in Action 作家之一Eric Pascarello 談論了關於 Ajax 安全方面的相關議題。
Eric Pascarello 是 Ajax in Action " 的作家之一。Pascarello Penn 州立大學的 2002 畢業生,獲得了機械工程學位。他也是 JavaRanch.com 上的知名人物。在這一次面談中,他談論 Ajax 安全方面的相關議題。
Ajax 作為一種技術傳達著使用者更為豐富的使用經驗從而受到廣泛的讚美。但是 XMLHttpRequest 的使用真的能確保安全?
Eric Pascare: 人們在面對 Ajax 的時候往往就是看到一個在網頁上表演魔術的被稱為 XMLHttpRequest 的東西,而且他們認為這東西能完美的彌補安全上的一些差漏。當我們在頁上做簡單的視野來源的時候, 我們見到的是我們調用,用來傳送參數的頁。任何使用 JavaScript 的人只要擁有最基本知識就能很容易地在每個頁面上進行編寫,改變資料。因此,攻擊是很有可能的, 但是這並不需要害怕.
人們可能會說,如果某人能如此容易的接管一個請求,這是多麼可怕啊。但是這些人需要瞭解 XMLHttpRequest 並不比普遍的技術容易被破壞。你能想象出它在另外的架構被調用的一種形式。表現出來就像是在頁上形成的標籤和隱藏的本文領域。通過一個正常的 HTML 格式, 我們能抓取元素名字而且見到傳送給伺服器的參數。我們能看行動屬性而且見到我們正在調用資料的地方。正如同我們如何去認識 XMLHttpRequest 一樣, 我們能在任何的網頁上見到這一切。
為什麼說在伺服器上做確認是非常重要的?
Pascarello: 我們能利用區域屬性改變瀏覽器上相對頁面上的內容。不完整的,唯讀, 隱藏的。但可能在用戶端看來這也許根本不過是一個笑話。輸入 javascript:document.FormName.ElementName.disabled="false";void(0) 後可以見到那些很可能被改變的領域是否是受到保護了的。這就是為什麼任何經驗豐富的開發人員告訴你需要在伺服器上做確認的原因。你無法確定那些你收到的資料從何而來。我能在我的案頭上寫一種形式且使它遵從你所看到的頁。這可能是一個電腦駭客嘗試注射 SQL 指令劃除你的資料。或是在JavaScript 中加入有害的代碼。資料是不安全的,這一點得隨時保持警惕。
對於 Ajax 是否遇到一些不同於以往的威脅?
Pascarello:Ajax所遇到的一些安全上的威脅一個開發人員可能不瞭解。如果他們只是單純的設計和實現以 Ajax 為基礎的控制,他們可能很容易地導致他們的伺服器崩潰。想像一個網頁同時有1,000個使用者。他們的伺服器能夠在這樣的負荷下處理以正常形式進入的資料。他們一起在用戶端或者伺服器身上沒有做儲存而直接進入資料庫得到資料的控制。現在我們1,000個人將這樣的請求重複十次。那這個伺服器將達到10倍於以往的運算。如果伺服器不能夠處理它, 他們可能會漏掉或者根本就完全停止了。
你注意到利用 JavaScript 在跨領域請求時所受到的攻擊。你能對此做相應解釋嗎?
Pascarello: 對於安全方面的問題真正讓我吃驚的是開發人員想要能夠用 JavaScript 運行跨領域的請求。現在有一些好的理由去做這, 像是Web服務這些, 但是大部份還只能在本地上作為伺服器端的代碼。一般的使用者設定的 JavaScript 不能夠操縱或者訪問來自另外的一個領域的資料。開發人員想要能夠做這,他們必須明確能夠不需要在領域外工作的目的。這樣的安全設定給我們帶來很大的保護,免於我們打通另外的架構遭到攻擊,或者是利用 XMLHttpRequest抓我們的電子郵件,存入銀行的資料,卡片資料, eBay 帳戶以及其他。我確定這些人也是真的不想這樣。在一個不熟悉的地方調用資料,並交換代碼,可是,你會真的信賴正在調用資料的安全麼? 對一個罐頭火腿肉新品種的廣告說hello?
看 Samy 在 MySpace.com 上寫的 Ajax 蠕蟲 [2005 年十月,一個青少年 "Samy" 在MySpace 發布了一條自我繁殖的 Ajax 蠕蟲 ]。這對於主要使用 Ajax 技術的網站是一種大的安全威脅。你得瞭解蠕蟲的作者藉由伺服器端的安全檢查將病毒注入到一個網頁。現在他可能已經可以很容易地改變密碼,在頁面上抓取使用者資料。XMLHttpRequest相對於其他的並不是更容易受到攻擊,相對而言,你所需要擔心的依舊是一些常規的問題。
Pascarello為 Ajax 安全性所提出的經驗法則:
如果你使用身分識別驗證, 確定你在請求頁上檢查!
為 SQL 注入檢查。
為 JavaScript 注入檢查。
保留商務邏輯在伺服器上!
不要假設每個請求是真正的!
確認檢查資料!
審查請求的資料而且確定它是正確的。
<