據說現在一台pc（Windows系統）上網的時候，如果沒有任何殺毒軟件防火牆，那麼十分鐘之內就會被 淪陷為病毒之城。為什麼會如此呢？因為你上網的時候，可能有的網站會被植入病毒，植入木馬什麼的， 網站的用戶只要一登陸，如果沒有任何防護措施，那麼你的機器肯定會馬上被攻陷了。當然了，網站也不 是故意要掛病毒和木馬給用戶的，主要是有些站點在開發之初或上線之後都沒有考慮過web安全的問題， 以致於存在很多安全隱患，導致被惡意的Hacker所控制，從而發生上述一幕。那麼該如何防范呢？
廣告之後更精彩：
趨勢科技， 讓Hacker病毒們，去死！
第一，對於普通用戶來說，可以下載一些著名的安全軟件來使用，比如趨勢科技的WTP， 網站管理員 也可以使用趨勢的防毒牆。但是我覺得，要解決根本，還是從站點開發之初來防范這些漏洞。 當然，漏 洞也是變化的，上線以後還是部署個趨勢的防毒牆更保險。
＝。＝
身為一名Rails開發者，就說一下web安全十大漏洞和rails開發中該如何防范這些漏洞。
A1 - Cross Site Scripting (XSS)
這是攻擊者利用在網站裡嵌入javascript來進行獲取受害人的cookie信息。
Rails2.0對XSS攻擊的防范也得到增強，TextHelper#sanitize由黑名單改為了白名單實現。具體攻擊 方法在這裡：http://www.rorsecurity.info/2007/05/01/cross- site-scripting-user-agent- injection-attack-methods/
有助於我們檢測自己的項目。
rails策略：
1.在view裡加入h方法，safeERB插件的作用ms不是為了幫助我們免除這一步。
2.用whitelist，剛才所說的rails2。0開啟了這個方法TextHelper#sanitize.
3.在使用BlueCloth和RedCloth的時候，應該聯合WhiteList來用，避免引發安全問題。
4。在Rails1.2.3版本之前，不要使用to_json方法，小心殆害！
A2 - Injection Flaws
注入攻擊有很多種，SQL，LDAP，XPath，XSTL，HTML，XML，OS COMMAND等等，但主要是SQL注入比較 突出，我們這裡只關注SQL注入的解決方法。
Don't use Project.find(:all, :conditions => "name = '#{params[:name]}'")
Do use Project.find(:all, :conditions => ["name = ?", params[:name]])
sql注入是指攻擊者從客戶端手動輸入參數，使參數傳到數據庫服務器，混入到sql查詢語句裡把一些 信息返回到客戶端，即浏覽器顯示。
Project.find(:all, :conditions => "name = '" + params[:name] + "'")
Project.find(:all, :conditions => "name = '#{params[:name]}'")
比如這兩個例子，將會受到sql注入的攻擊：
攻擊者只要輸入:' or 1 -, 這個時候rails生成的sql語句就變成了：
select * from projects where name = '' or 1 --'
因為在mysql裡的boolean值是1，這個 – 符號（# 和 /*也是注釋）是sql的注釋，後面所有的一切都 會被忽略，所以我們這個sql句相當於
select * from projects
利用sql 注入如何繞過權限驗證：
User.find(:first, "login = '#{params[:name]}' AND password = '#{params
[:password]}'")
params[:name] = ' OR '1'='1
params[:password] = ' OR '2'>'1
params[:name] = ' OR login LIKE '%a%
params[:password] = ' OR ISNULL(1/0) #
Unauthorized Reading
參見：http://www.rorsecurity.info/2007/05/19/sql-injection/
rails的解決辦法就是：
1。用占位符號
User.find(:first, :conditions => ["login = ? AND password = ?", params[:name],
params[:password]])
2。用hash（rails版本是在1.2以上）
User.find(:first, :conditions => {:login => params[:name],
:password => params[:password]})
3。在保證上述兩點的基礎上，把查詢方法放在model裡。這樣會更加安全。
4. 所有rails根據model屬性自己生成的find_by_xxx方法是很安全的，比如：
find_by_name, 等。
5. find_by_sql 也是很安全的。
A3 - Malicious File Execution
這個安全隱患在Rails1.1.6就已經解決了，1.1.6以下的項目需要打個補丁，但是rails2.0出來了，還 是升級吧
相關：
Working with files
這是關於文件上傳的安全策略：
http://www.rorsecurity.info/2007/03/27/working-with-files-in-rails/
參見：Agile 開發之道2nd，610頁。
A4 - Insecure Direct Object Reference
在rails裡，只要注意不要把內部的controller方法暴露出來，即，不要把private方法誤寫到publice 方法裡就行，對一些action和controller做一個全局的異常處理，就不會被攻擊者把你應用程序攻擊的腸 子都流出來了。
A5 - Cross Site Request Forgery (CSRF)
傳說中的跨站偽裝請求攻擊（通常也叫one click attack"或者session riding，通常縮寫為CSRF或者 XSRF）
聽起來有點像css/xss跨站腳本攻擊有點類似，但實質不同，CSRF比起css/xss來更加危險，因為這種 攻擊難以防范（主要是因為不大流行，所以防范資源比較缺乏）。XSS利用站點內的信任用戶，而CSRF則 通過偽裝來自受信任用戶的請求來利用受信任的網站。網網這兩種攻擊方法是買一送一的關系。利用XSS 偽裝受信任用戶，利用這個受信任用戶來進行CSRF攻擊來利用網站。
例子：一個網站用戶Bob可能正在浏覽聊天論壇，而同時另一 個用戶Alice也在此論壇中，並且後剛剛 發布了一個具有Bob銀行鏈接的圖片消息。設想一下，Alice編寫了一個在Bob的銀行站點上進行取款的 form提交的鏈接，並將此鏈接作為圖片tag。如果Bob的銀行在cookie中保存他的授權信息，並且此cookie 沒有過期，那麼當Bob的浏覽器嘗試裝載圖片時將提交這個取款form和他的cookie，這樣在沒經Bob同意的 情況下便授權了這次事務。
CSRF是一種依賴web浏覽器的、被混淆過的代理人攻擊（deputy attack）。在上面銀行示例中的代理 人是Bob的web浏覽器，它被混淆後誤將Bob的授權直接交給了Alice使用。
下面是CSRF的常見特性：
依靠用戶標識危害網站
利用網站對用戶標識的信任
欺騙用戶的浏覽器發送HTTP請求給目標站點
CSRF攻擊依賴下面的假定：
攻擊者了解受害者所在的站點
攻擊者的目標站點具有持久化授權cookie或者受害者具有當前會話cookie
目標站點沒有對用戶在網站行為的第二授權
防范措施
在form中包含秘密信息、用戶指定的代號作為cookie之外的驗證。那些導致對安全產生"副作用"的請 求應該總使用Post方式發送。Post方式不會在web服務器和代理服務器日志中留下數據尾巴，然而Get方式 卻會留下數據尾巴
Rails的策略：
1。慎用get請求，也就是上面所說的， 那些導致對安全產生"副作用"的請求應該總使用Post方式發送 。
2。Use the Csrf_killer plugin to include a security token in forms.（插件方式過期，但是使 用rails2.0y一下版本的項目需要注意）
在Rails2.0中，通過在form中增加特殊字段來防止CRSF攻擊，這一功能在新應用中默認是開啟的。
A6 - Information Leakage and Improper Error Handling
一些重要的信息洩露一般是通過程序裡的異常信息透露給攻擊者的，如果異常信息太詳細，那麼就很 危險了，所以和上面一條一樣，要進行異常處理。全局的異常處理。
def rescue_action_in_public(exception)
case exception.class.name
when
'ActiveRecord::RecordNotFound','::ActionController::UnknownAction','::ActionController::Rout
ingError'
RAILS_DEFAULT_LOGGER.error("404 displayed")
render(:file => "#{RAILS_ROOT}/public/404.html", :status => "404 Error")
else
RAILS_DEFAULT_LOGGER.error("500 displayed")
render(:file => "#{RAILS_ROOT}/public/500.html", :status => "500 Error")
end
end
A7 - Broken Authentication and Session Management
1.session hijacking（session劫持）.
session劫持，是被非法用戶拿到整個session信息（cookie）.然後讓你的所有信息暴露。
how： 是通過網絡監聽來獲取。有些sniffer軟件，等等。。。
Countermeasures:
對策1： Encrypt the traffic using SSL
雖然ssl比較慢，但是還是很安全的，需要在environment.rb中加入：
ActionController::Base.session_options[:session_secure] = true
對策2 ： Include additional information (user agent, IP address, …) in the cookie
我們在session裡加上一些額外的信息，在每一次請求都去驗證它。
對策3 ： Create a new session when someone successfully logs in.
用reset_session，但是你不得不把老的session裡的數據copy過來。比如user_id.
對策4 ： 在用戶注銷以後讓session無效。設置session過期時間。
2.Session fixation（Session定制攻擊）
how：攻擊者通過得到用戶合法的session id，並強迫浏覽器使用這個session_id 來進行攻擊。在php 裡，session管理器接受任何的session id，即便這個id不存在，但是ruby on rails裡是不可能的，ruby on rails只接受已經生成的session id，所以攻擊者會訪問這個rails站點來獲取合法的session id，然 後傳遞給第三方用戶，如果使用這個session id可以登錄成功，那麼其他的session id也一樣不安全。
在得到session id之後，就會用html 標簽<META>來對浏覽器注入session id強迫浏覽器使用這 個session id來登錄站點。
<meta http-equiv=Set-Cookie content="_session_id=4cf69dc5fee46251bdc1f99ef55f52b6">
這是危險的！
對策：
目前最好的對策是： 用reset_session,也就是上面所說的.
3.設置cookie過期時間（ Expiration of cookies ）
1).Client side 客戶端可以指定一個固定的時間。e.g :
ActionController::Base.session_options[:session_expires] = Time.local(2007,"jan")
但是記住用戶可以改變這個過期時間
2). Server side
Remove old sessions from your hard disk or database Rails默認不會清除 session，我們來自己指定。 class SessionCleaner def self.remove_stale_sessions CGI::Session::ActiveRecordStore::Session. destroy_all( ['updated_on <?', 20.minutes.ago] ) end end And then invoke the remove_stale_sessions method every 10 minutes via; */10 * * * * ruby /full/path/to/script/runner -e production "SessionCleaner.remove_stale_sessions"
這是防止攻擊者是通過寫一個腳本來使用被劫持的session持續攻擊。但是我們需要另一個session 存 儲器，像插件SQLSessionStore ，或者an update of the ActiveRecordStore migration so it has a created_at field.
3） 動態設置session過期時間。這裡有個插件：
http://blog.codahale.com/2006/04/08/dynamic-session-expiration-times-with-rails/
rails2。0裡可能不適用了，我們可以參照這個插件來應用到rails2。0裡。
A8 - Insecure Cryptographic Storage
1.用一個good password .參見:http://www.rorsecurity.info/2007/06/05/use-good- passwords/
2.Filter passwords from the log file:
filter_parameter_logging "password"
可以參考railscasts第9集.
3. 清除mysql或bash history可能包含password的地方：
cat /dev/null > ~/.mysql_history and ~/.bash_history
4. 永遠不要以明文存儲密碼。
Signup
self.salt = Digest::SHA1.hexdigest("–#{Time.now.to_s}–#{login}–")
self.crypted_password = Digest::SHA1.hexdigest("–#{salt}–#{password}–")
Login
self.crypted_password == Digest::SHA1.hexdigest("–#{self.salt}– #
{user_entered_password}–")
A9 - Insecure Communications
不 安全通信，解決這個問題需要用SSL來保護一些敏感的數據。IE 7.0 provides a green bar for high trust SSL certificates,but this is not a suitable control to prove safe use of cryptography alone. 所以企業裡用IE一般是不安全的。在安全這方面，我們可以說服企業用戶去用 firefox
1。采用SSL保護敏感數據。
2。確保這些基礎設施之間的通信,比如數據庫和web servers之間的通信，是建立在一個安全的傳輸層 或是一個有高度加密的信用協議的基礎上。
3。必須遵循PCI 安全標准。比如你需要保護信用卡持有者的信息。
具體，這些敏感的數據是不能保存到數據庫的。要保存也需要經過加密以後保存。
Ruby打開ssl
http = Net::HTTP.new(PANEL,PORT)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
請參考PCI安全標准。
A10 - Failure to Restrict URL Access
一般來說加上異常處理，權限設置就很安全了.
權限插件使用的安全考證
目前有好多權限插件，比如LoginGenerator和 Restful_authentication
但是我們使用前最好考證一下這些插件的安全性，可以去參考這個站點：
http://www.rorsecurity.info/
具體待補充。
A11- 其他安全隱患及解決辦法：
Validation
一般放到model裡，有時候需要放到controller的話，可能你需要一個插件：ActiveForm plugin
Regular Expressions
參見
http://www.rorsecurity.info/2007/04/16/ruby-regular-expression-fun/
Securing your MySQL setup Web application security depends on the security of all layers. Start securing your MySQL setup here, then go on here. here: http://www.rorsecurity.info/2007/02/25/securing-mysql/ go on here:http://www.rorsecurity.info/2007/02/27/rails%e2%80%99-friends-securing-mysql- continued/ The mass-assignment problem When @user = User.new(params[:user]) may become a problem. Read it here: http://manuals.rubyonrails.com/read/chapter/47
黑客可以在網絡中通過多種方式攻擊、入侵用戶的終端，其中最常見，也是用戶最容易重招的也正是 通過Web站點的間接入侵，作為網絡管理員，能夠保護企業內網中用戶的上網安全是職責所在，我們可以 通過安全網關、防病毒牆等產品對網絡中數據的通信進行統一管理，也可以結合在終端安裝像上網無憂電 子眼這種工具來進行防護的方式來實現終端的安全。上網無憂電子眼是趨勢科技推出的免費Web威脅防御 工具，通過特有的Web信譽服務與僵屍防御功能，能夠有效的抵御來自網絡的侵襲，使企業用戶能夠對自 身的終端做到合理的防護，從而杜絕僵屍程序、廣播病毒等威脅的擴散傳播，有效的營造了安全的企業網 絡環境。
