Rails安全導讀【四】

5. 企業內聯專用網和管理安全

企業內聯網和管理界面是最流行的***目標, 因爲它們有特殊的訪問權限. 雖然它會有一些額外的安全措施,可是現實裏並非如此。

2007年,在線招聘站點Monster.com遭受了一起定製***(Tailor-made Trojans)***,這是第一隻專門從企業內聯網偷竊信息的定製***。定製***是非常罕見的,迄今爲止,發生率比較低, 但是它也確實是可能發生的,這也是一個客戶端主機安全何等重要的例子. 然而,企業內聯網和管理應用程序面對的最大威脅還是XSS和CSRF.

XSS  如果你的應用重現了惡意用戶從外網的輸入,那麼你的應用會受到XSS的危害。用戶名,評論,垃圾郵件等是容易被XSS***的常見的例子。
在管理界面或是內網只要一個地方沒有被消毒(sanitized)就會導致整個應用遭受危害。可能的漏洞包括竊取有特權管理員的cookie,iframe注入(Monster.com就是被這樣***的)竊取管理員密碼或者是通過瀏覽器的安全漏洞安裝一款惡意軟件來接管管理員的計算機。
參看Injection章節,有XSS的對策,以及推薦了一款在內網和管理員界面使用的SafeErb的插件。
 
CSRF 跨站點 Reference 僞造 (CSRF) 是一個強大的***方法,它允許***者能做內網用戶和管理員能做的一切事情。正如你已經看到上面幾部分裏CSRF如何工作的,這裏也有一些例子,說明***者能在內網和管理界面做些什麼。
一個現實世界的例子是一個通過CSRF重新配置路由的例子。這個***者發送了一封包含CSRF的惡意的電子郵件給墨西哥的用戶。電子郵件聲稱有一個電子賀卡等着他們,但是它也包含了一個可以造成一個HTTP- GET請求去重新設置用戶路由的圖像標記(image tag)(這在墨西哥比較流行)。這個請求改變了DNS設置以便到墨西哥銀行的請求可以映射到***者的站點。每個訪問銀行網站的人通過這個路由都能看到***者的僞造站點,並且他的證書被盜。
 
另一個例子是通過GSRF改變Google Adsense的email地址和密碼。如果受害者是登陸到Google Adsense,一個Google競投廣告的管理界面,***者可能會改變他的安全證書。
另一種流行的***是你的web應用上的垃圾, 在你的blog或者論壇傳播惡意XSS. 當然,***者必須知道URL結構,但是大多數的Rails URLS是相對簡單,或者,如果它是一個開源應用的管理界面,是很容易被他們找出的。***者甚至可以做1000個僅包括惡意img tags的幸運的猜測去嘗試每一個可能的組合。
 
對於在管理界面和內網應用的CSRF對策,請參考CSRF章節裏的對策。
 

5.1. 額外的預防措施

一般的管理界面是這樣工作的: 它的位置是[url]www.example.com/admin[/url], 可只有在用戶模式被設置了admin tag的才能訪問。重現用戶的輸入,然後刪除,增加,修改想要的任何數據。這裏有一些想法:
  • 考慮最壞的情況是非常重要的: 如果某人真的掌握了我的cookie或是用戶證書。你能控制角色爲管理界面去限制***者的可能性。或者除了哪些用於公共部分的應用,爲管理界面提供一個專門的登陸證書如何,或者對於每次重要的action提供一個密碼 ?
  • 是否這個管理員真的必須能從世界各地訪問這個接口? 考慮一下根據ip地址段來限制登陸。檢測request.remote_ip 瞭解用戶的IP地址. 這並不是防彈的,而只是製造一個障礙。但請記住,有可能有人在使用代理。
  • 把管理界面放到一個專門的子域,例如admin.application.com,使其用戶管理成爲一個單獨的應用程序。這使得***者不可能從通常的[url]www.application.com[/url]竊取cookie。這是因爲在你的瀏覽器裏存在同一個原生標準: 在[url]www.application.com[/url]的注入腳本(XSS)不能讀取admin.application.com的cookie,反之亦然。

6. Mass assignment

是指對Model.new(params[:model]) 允許***者設置任意數據庫列的值沒有任何防範措施。

這個mass-assignment可能變成一個問題, 因爲它允許***者通過操作hash傳到一個model的new()方法裏來設置model的任意屬性 :
def signup
params[:user] #=> {:name => “ow3ned”, :admin => true}
@user = User.new(params[:user])
end
Mass-assignment爲你省去了大量的工作, 因爲你不必要去設置每個單獨的值。只需要給new()方法傳一個hash,或者是指定attributes=(attributes)hash值,就可以在hash裏設置一個model的屬性。問題是,在controller裏經常使用可用的hash參數會被***者操縱。 他可能會這樣改變URL:
這樣會在controller裏設置如下的參數 :
params[:user] #=> {:name => “ow3ned”, :admin => true}

如果你通過
mass-assignment這種方式創建一個新用戶,那麼這個用戶很有可能會變成一個管理員。

6.1. 對策

爲了避免這個問題, Rails在ActiveRecord類裏提供了兩個類方法去控制訪問你的那些model的屬性。attr_protected方法可以設置一個不被mass-assignment方式訪問的屬性清單(黑名單):
attr_protected :admin
attr_accessible是一個更好的方式,因爲它遵循了白名單原則。 這和attr_protected是完全相反的,因爲它列出的是可被訪問的屬性清單。 所有其他的屬性會被保護。這樣你就不會忘記去保護在開發過程中增加的新的屬性。這裏有個例子:
attr_accessible :name
如果你想要保護一個屬性,你就必須獨立的去指定它 :
params[:user] #=> {:name => "ow3ned", :admin => true}
@user = User.new(params[:user])
@user.admin #=> false # not mass-assigned
@user.admin = true
@user.admin #=> true
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章