开发人员使数据库面临十大方面风险
过于相信输入方法
开发人员将数据库置于风险之中的一种重要方法是，使其应用程序遭受SQL注入攻击。当开发人员过于相信用户输入时，就往往会出现SQL注入漏洞。解决这种问题的最好方法之一就是使用参数化查询。参数化查询可以防止攻击者改变查询中的逻辑或代码，并阻止大多数SQL注入攻击。此外，还要对用户输入进行净化和验证，因为有时参数化并不可行。
数据库错误消息显示给终端用户
在应用程序的SQL查询出现问题时，如果开发人员允许弹出特定的错误消息，这也许有助于诊断，但这也向攻击者提供了一个探查后端数据库的内部工作机制的很好途径。开发者应当在页面显示一般性的错误消息而非特定消息。
轻率地对待口令
许多开发者用多种不安全的方法来轻率地对待用户口令。例如，他们可能将口令硬编码到应用程序中或存放到纯文本中。开发人员应当将口令进行哈希并加盐，同时在应用程序中构建强健的口令认证。
使所有的连接都是“超级”的
许多开发者通过“根”或其它一些超级用户账户来将应用程序连接到数据库中，从而将数据库置于风险之中。所有的应用程序都应当使用最少特权的用户凭证连接到数据库。
相信存储过程是SQL注入的解决之道
许多开发人员相信，存储过程是防止SQL注入的一种可靠方法。事实上，如果存储过程自身的代码中包含漏洞，或者如果存储过程被以一种不安全的方式调用，它并不能防止SQL注入。
将调试代码留放到生产环境中
开发人员必须在将程序投放到生产环境中之前，清理其代码，以免打开数据库的后门。忘记在生产环境中清除这种调试代码是愚蠢的，但也是很常见的错误。
劣质加密
错误地使用加密会给企业带来一种虚假的安全感。开发人员应当谨慎地对待其加密技术方面的技能和技巧，并选择合适的加密方法。
盲目相信第三方代码
开发人员不能在测试代码问题上抄近路，以确保所复制的代码不会给应用程序带来易受攻击的漏洞。开发人员需要为整个应用程序的威胁分析负责，并使用最新的开发框架。
轻率地实施REST架构
开发人员应当为一系列抽象的应用程序的特定资源类型和资源的适当操作设计REST接口，而不是把接口直接设计到物理的数据表和非特殊操作。
随处乱放备份的数据库副本
开发环境必须小心地遵循生产环境中的安全标准，包括对备份数据库副本的安全措施。安全策略应当为数据的所有副本负责，而不仅仅是在线副本。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
