据说现在台pc(Windows系统)上网时候如果没有任何杀毒软件Software防火墙那么十分钟的内就会被沦陷为病毒的城为什么会如此呢？你上网时候可能有网站WebSite会被植入病毒植入木马什么网站WebSite用户只要登陆如果没有任何防护措施那么你机器肯定会马上被攻陷了当然了网站WebSite也不是故意要挂病毒和木马给用户主要是有些站点在开发的初或上线的后都没有考虑过web安全问题以致于存在很多安全隐患导致被恶意Hacker所控制从而发生上述幕那么该如何防范呢？

　　广告的后更精彩:

　　趋势科技 让Hacker病毒们去死！

　　第对于普通用户来说可以下载些著名安全软件Software来使用比如趋势科技WTP 网站WebSite管理员也可以使用趋势防毒墙但是我觉得要解决根本还是从站点开发的初来防范这些漏洞 当然漏洞也是变化上线以后还是部署个趋势防毒墙更保险

　　＝＝

　　身为名Rails开发者就说下web安全十大漏洞和rails开发中该如何防范这些漏洞

　　A1 - Cross Site Scripting (XSS)

　　这是攻击者利用在网站WebSite里嵌入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刚才所说rails20开启了这个思路方法TextHelper#sanitize.

　　3.在使用BlueCloth和RedCloth时候应该联合WhiteList来用避免引发安全问题

　　4在Rails1.2.3版本的前不要使用to_json思路方法小心殆害！

　　A2 - Injection Flaws

　　注入攻击有很多种SQLLDAPXPathXSTLHTMLXMLOS 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 开发的道2nd610页

　　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则通过伪装来自受信任用户请求来利用受信任网站WebSite网网这两种攻击思路方法是买送关系利用XSS伪装受信任用户利用这个受信任用户来进行CSRF攻击来利用网站WebSite

　　例子:个网站WebSite用户Bob可能正在浏览聊天论坛而同时另 个用户Alice也在此论坛中并且后刚刚发布了个具有Bob银行链接图片消息设想下Alice编写了个在Bob银行站点上进行取款form提交链接并将此链接作为图片tag如果Bob银行在cookie中保存他授权信息并且此cookie没有过期那么当Bob浏览器尝试装载图片时将提交这个取款form和他cookie这样在没经Bob同意情况下便授权了这次事务

　　CSRF是种依赖web浏览器、被混淆过代理人攻击(deputy attack)在上面银行举例中代理人是Bobweb浏览器它被混淆后误将Bob授权直接交给了Alice使用

　　下面是CSRF常见特性:

　　依靠用户标识危害网站WebSite

　　利用网站WebSite对用户标识信任

　　欺骗用户浏览器发送HTTP请求给目标站点

　　CSRF攻击依赖下面假定:

　　攻击者了解受害者所在站点

　　攻击者目标站点具有持久化授权cookie或者受害者具有当前会话cookie

　　目标站点没有对用户在网站WebSite行为第 2授权

　　防范措施

　　在form中包含秘密信息、用户指定代号作为cookie的外验证那些导致对安全产生"副作用"请求应该总使用Post方式发送Post方式不会在web服务器和代理服务器日志中留下数据尾巴然而Get方式却会留下数据尾巴

　　Rails策略:

　　1慎用get请求也就是上面所说 那些导致对安全产生"副作用"请求应该总使用Post方式发送

　　2Use the Csrf_killer plugin to a security token in forms.(插件方式过期但是使用rails2.0y下版本项目需要注意)

　　在Rails2.0中通过在form中增加特殊字段来防止CRSF攻击这功能在新应用中默认是开启

　　A6 - Information Leakage and Improper Error Handling

　　些重要信息泄露般是通过里异常信息透露给攻击者如果异常信息太详细那么就很危险了所以和上面条样要进行异常处理全局异常处理

def rescue_action_in_public(exception)
exception..name
when 'ActiveRecord::RecordNotFound','::ActionController::UnknownAction','::ActionController::RoutingError'
RAILS_DEFAULT_LOGGER.error("404 displayed")
render(:file => "#{RAILS_ROOT}/public/404.html", :status => "404 Error")

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: 是通过网络监听来获取有些snfer软件Software等等

　　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 session when someone successfully logs in.

　　用re_session但是你不得不把老session里数据copy过来比如user_id.

　　对策4 : 在用户注销以后让session无效设置session过期时间

　　2.Session fixation(Session定制攻击)

　　how:攻击者通过得到用户合法session id并强迫浏览器使用这个session_id 来进行攻击在php里session管理器接受任何session id即便这个id不存在但是ruby _disibledevent=> " Ruby Notes " }” 博客请务必保留此出处http://blackanger.blog.51cto.com/140924/91764