我正在研究Rails，即将学习创建用户和身份验证。作为初学者，我想知道你是如何知道的，如果正在遵循的教程或你使用的技术是否足以安全公共使用？
是否有一套通常被认为安全的标准？是否比我想象的更容易使数据库安全？
如果您想构建付款功能，如果不是安全专家，您怎么知道这是否安全？
答案 0 :(得分：1)
您可以阅读这些文章，并建立自己的自信心。
答案 1 :(得分：1)
正如Sergio Tulentsev在评论中提到的那样，使（生产）Rails应用程序能够抵御真实世界的威胁需要强大的专业知识。
现在，如果您正处于学习过程中并希望了解哪些内容可能会使您的应用容易受到攻击以及如何解决每一个问题，我建议您阅读以下安全检查清单之一：
答案 2 :(得分：1)
几乎所有的Web服务应用程序都使用相同的安全协议，换句话说，用户必须输入密码才能访问他们的东西，有些人已经实现了两步验证 - 这确实有很大帮助。
根据您的构建，所有内容都遵循一些核心基础结构以确保安全性。
甚至像Facebook和谷歌这样的网站都被黑了。有些软件是逆向工程的。
我曾经想过： 你能对黑客做些什么吗？答案是否定的。除了修复软件中的错误和安全漏洞，并希望最好。
即使是最顶尖的计算机安全专家也无能为力。
Google快速搜索给了我这个：
Techniques to Secure Your Website with Ruby On Rails (Part 1)
<强> @darkace： 这里有一些额外的建议，如果你想建立你的梦想网络服务，那就去吧。 Facebook的安全性较差，在早期，他们将未经过清洗的密码存储到* .txt文件中。任何以某种方式访问ROOT目录的人都可以突然访问密码和用户的电子邮件，而不是Facebook员工。
然而今天，Facebook是一家价值十亿美元的公司，已经聘请了很多安全专家，并且已经提升并保护了其服务器基础设施。
一旦您的应用程序服务产生现金，您就可以投资以保护它。现在不要太担心。世界上没有黑客关心你的应用程序。你现在太小了，但是如果你从中成长并从中赚到数百万，那么黑客就会追随你的软件。
答案 3 :(得分：1)
以下是在投入使用之前要检查的应用程序列表：
您可能正在使用Devise进行身份验证。这是一个非常好的开始。与身份验证没有直接关系，但请确保您不会在会话中存储任何秘密（会话[...]在Rails中）。还要注意有重放攻击（参见Rails安全指南，重播攻击部分），所以请考虑一下你在会话中存储的内容。
根据应用程序的大小，但如果增长，请使用CanCanCan或Pundit之类的授权gem。这通常很有效，并且有许多示例应用程序。但是，如果您拥有多个所有权层（例如projects / 2 / documents / 5），请确保不仅父对象属于此用户（项目2属于此示例中的当前用户），此子对象也属于父对象（文档5属于示例中的项目2）。这种检查是一个常见问题。
SSL：如果你使用HTTPS，并且可能应该使用严肃的应用程序，那么请确保它在任何地方都使用，它只是HTTPS，并通过SSLlabs检查服务器配置
HTTP标头：确保您了解使用Rails发送的默认HTTP标头的功能，请参阅Rails安全指南的第9节“默认标头”。
路线：不要使用默认路线：匹配＆＃39;：控制器（/：action（/：id（。：format）））＆＃39;并确保所有路由仅通过一个HTTP动词可用。这也可以作为CSRF保护。更像问题的URL应该是HTTP GET，更改应用状态的操作应该是非GET。请参阅路由Rails指南。
数据库配置：最重要的两个步骤：使数据库服务器只能在localhost上访问（仅搜索google mysql localhost）。并使用GRANT SQL语法限制Rails DB用户在数据库级别的权限（搜索＆＃34; mysql grant＆＃34;）。
记录：不要在日志文件中记录机密，将Rails.application.config.filter_parameters添加到您的配置中，并包含以下属性：密码。
这是一个非常广泛的主题，但您可能已经知道Rails会自动逃脱＆＃34;不安全＆＃34;视图中的字符串，以及来自用户或数据库的所有内容。使用raw（）方法时，或者如果您在方法中自己构建HTML，请务必小心。来自用户的所有内容都可能存在安全风险。事实上，这是帐户获取＆＃34;黑客攻击的第一个原因。
不要直接或间接使用params与render（）方法。
您是否在控制器中使用respond_to？如果是这样，请检查每个操作是否响应.xml或.json版本，因为它可能是您在此处渲染的信息太多。每当你调用model.to_xml或model.to_json（也间接通过respond_with）时，你可能会泄露秘密或者太多。
使用redirect_to时，请确保您不直接使用用户参数，也不要使用它的一部分。如果您需要动态重定向，请为所有允许的目标制作白名单，或使用正则表达式进行检查，例如： params [：back_url] =〜％r（\ A＃{home_url}）
您的应用程序应该对CSRF安全，阅读它（请参阅Rails安全指南，CSRF部分）并尝试通过篡改您在每个Rails表单中找到的真实性令牌来自行利用它。
上传的文件可能包含除指示的文件扩展名之外的其他内容（PNG图像中的HTML注释是一个着名的示例）。确保验证允许的内容类型（例如，仅允许PNG）并尽可能将文件作为附件发送（请参阅send_file方法，：disposition选项）。最好的选择是将上传的文件存储在不同的服务器上，以防文件中存在XSS。
正则表达式：不要使用^和$来匹配字符串的开头和结尾，而是使用\ A，\ z。
秘密：您有三个存储值的选项：明文，加密哈希（单向，原始文本无法再检索），加密值。密码应以散列形式存储（Devise为您执行此操作），任何其他秘密字段都应加密（例如使用attr_encrypted）以用于最坏情况。
Rails在防止SQLi方面做得很好，但是你要记住以下几点： *永远不要在字符串变形中使用用户提供的值，如User.delete_all（＆＃34; id =＃{params [：id]}＆＃34;） *在http://rails-sqli.org/
上查看代码以了解所有其他示例如果您是初学者，请确保您尽可能少地使用它。使用宝石和支付提供商，他们确保付款细节永远不会通过您的服务器。
我建议保持最新状态，不断测试安全性，制定自己的安全策略，为最坏的情况做好准备并运行一些自动安全检查。一些提示如何在您没有时间的情况下处理所有这些问题I've summarized here。 然后，您越来越接近生产就绪的应用程序。