我的譯言連結：
[url]http://www.yeeyan.com/articles/view/blackanger/17939[/url]
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請求去重新設定使用者路由的影像標記（p_w_picpath tag）（這在墨西哥比較流行）。這個請求改變了DNS設定以便到墨西哥銀行的請求可以對映到***者的站點。每個訪問銀行網站的人通過這個路由都能看到***者的偽造站點，並且他的證書被盜。
另一種流行的***是你的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:
[url]http://www.example.com/user/signup?user[/url][name]=ow3ned&user[admin]=1
這樣會在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