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