网站换空间商什么意思,seo在线诊断工具,微商城平台开发,西安做网站那家公司好在编写应用程序时#xff0c;都会访问一些存储系统获取相关的信息。最简单的例子就是用户登录#xff0c;需要访问存储的用户和密码#xff0c;进而可以验证用户是否可以正常登录。为了访问数据库各种框架结构也都提供了相应的方法和接口支持。但是#xff0c;程序员在实现… 在编写应用程序时都会访问一些存储系统获取相关的信息。最简单的例子就是用户登录需要访问存储的用户和密码进而可以验证用户是否可以正常登录。为了访问数据库各种框架结构也都提供了相应的方法和接口支持。但是程序员在实现时为了方便经常会使用一些不太安全的方法容易导致系统的存储系统的访问账号和密码的泄露。而存储系统经常存储一些重要的敏感的信息这就可能导致重要信息的泄露。一旦像数据库中的信息泄露将会给系统带来严重的负面影响。
下面列举一下常见的错误
将密码写死在代码里
这是最容易也是最简单地实现访问存储系统的方法直接写在代码里访问数据库非常简单。同时也就意味着会用同一套代码部署的系统只能用同一个账号和密码访问数据库。一旦密码泄露也很难及时修复系统。必须要研发团队重新修改代码升级系统同时也需要数据库管理团队的密切配合。给系统的维护带来很大的不便。
将密码写死在配置文件
写入配置文件相对于写在代码里稍微好一些但是也有同一个问题就是开发环境和实际运行环境是否使用了不同的配置文件是否能够保证使用了不同的配置文件之后使用的账号和密码是不同的 如果使用不同的配置文件但是使用相同的账号和密码这个和使用同一个配置文件也没什么区别主要的区别就是修改产品线上的账号和密码时比较容易一些。
在代码仓库上的默认的配置是否能够保证在实际部署时能够保证在产品线上使用不同的密码
使用系统默认的用户名和密码
所有的数据库系统基本上都会提供一个默认的管理员级别的用户名和密码有些开发为省事就直接使用这个账号和密码。当一个攻击者扫描到一个数据库系统时就会首先尝试使用默认的用户名和密码。所以一旦使用默认的用户名和密码攻击者就可以控制整个数据库系统。
关于解决这些硬编码的密码的方案也有很多种下面就罗列一下我自己的一些想法
在代码的仓库里一定不能含有硬编码的密码尤其是在产品线上仍然使用的密码不管是在代码里还是在配置文件里。如果是测试代码建议使用一些明显测试特征的密码例如Test1234。曾经在Review代码时发现测试代码里测试加解密的代码里居然有访问数据的账号和密码这就导致了密码多一个泄露的地方而且隐藏的很深。这些密码需要保存在一个受保护的区域由专门的人负责维护。同时对维护和访问的所有操作都要记录日志实时监控。可以放在专门的系统里例如Vault也可以放在HSM里不过HSM的价格一般比较昂贵。这些密码需要有一个安全的机制让应用程序在启动之前能够获取。应用程序和这些存储服务之间有严格认证关系保证只有信任的服务器才能够访问。例如可以使用公钥和私钥系统认证系统。密码可以定期更新同时所有应用程序可以根据更新的机制同步更新不影响访问数据库系统。 例如将账号和密码都列入更新的范围这样新老账号可以同时工作一段时间以防出现问题可以及时回滚等新的账号和密码验证可以工作了再删除老的。像MySQL8.0可以支持Dual-password的功能就可以使用一个账号然后同时使用两个密码等新的密码确认可以正常工作时再废弃老的密码。更新时需要有通知的机制保证各个团队都能够及时关注更新观察产品是否能够正常运行。一旦发现有问题要有机制尅及时回滚。要有机制废弃老的密码或者账号。如果更换了新的账号或者密码但是老的账号或者密码没有机制保证能够及时废除也是很危险的。可以设置一个自动超时机制一旦超过一定的时间老的账号或者密码就强制自动废弃。一定不能使用系统默认的账号和密码。需要根据系统的需要专门创建一个符合应用需求的足够权限的账号即可没有必要给太多权限给的权限越多出问题时导致的伤害就会越大。例如有SQL注入的问题时如果提供的root账号攻击者就可以做一些对系统由致命打击的删除操作导致系统彻底不能使用。 总之无论如何尽量避免hardcoded的关键敏感信息包括密码、token、加密的密钥等需要在实现之初就应该规划好如何管理这些内容如何能够基于当前的系统架构实现动态更新这样才能保证一旦出现泄漏问题可以及时更换泄露的内容保护系统的安全。
