后端开发都应该了解的信息泄露风险

文章首发于公众号 「会玩code」

在黑客攻击中，信息收集是进行攻击的第一步，也是至关重要的一步。信息泄露发生的途径有很多，攻击者可以根据接口返回信息，分析前端代码，分析页面文件信息、甚至是开发人员或用户在第三方网站上的资料托管，都能进行有效的信息收集。作为开发人员，我们应该了解常见信息泄露风险点并谨慎规避。

接口返回详细报错信息

• 一些框架，如django，允许设置debug=true，在调用接口失败时，会将代码堆栈信息和一些环境信息都打印在页面上，方便调试；
• 业务开发时，有些同学可能习惯将err（包含代码调用堆栈信息）直接返回给用户。攻击者通过这些信息可以窥探代码逻辑，造成安全隐患。

以登录为例子，用户输入账号密码后，后台会去数据库中根据账号查询对应密码，用数据库中的密码与请求携带的密码对比。sql大致逻辑是select passwd from t_user where user_name = \'xxx\'xxx即为我们传入的账号名。

如果后台是手动拼接构造的sql，就会存在sql注入漏洞。我们在用户名位置输入一个单引号(最后构造的sql: select passwd from t_user where user_name = \'\'\'),
sql执行报错...MySQL server version for the right syntax to use near \'\'\'\')\'..., 这时接口把sql报错信息一路透传返回前端，攻击者可根据返回的报错信息推导得知系统存在sql注入漏洞，从而发起攻击。

密码明文存储

这是个低级、但后果十分严重且普遍的安全问题，Google、FaceBook等大公司都曾被爆过明文存储用户密码。由于明文存储密码导致用户密码泄露的事故也是屡见不鲜。

密码应该使用哈希加密保存，这样即使攻击者获取了密码，也只是一串毫无意义的字符。当然，对于哈希密码，攻击者也能通过密码字典的方式对哈希密码进行“撞库”破解，或构造彩虹表对密码进行破解。
比如123456的哈希值是E10ADC3949BA59ABBE56E057F20F883E,可以在cmd5上很容易反查到哈希值的明文信息。

所以为了加大密码破译难度，可以在哈希时加盐处理，先密码的特定位置插入特定的字符串(salt)，再进行哈希。

加盐后的密码经过哈希加密得到的哈希串与加盐前的哈希串完全不同。为了进一步增加随机性，可以每个用户哈希保存密码时使用的"盐值"都不相同，比如使用用户名或用户id等用户不可变属性当作哈希时的"盐"。

网站文件泄露

nginx可用于静态资源服务器，为了下载资源方便，可能会开启目录浏览(autoindex = true)的功能。

一旦不小心在目录下存放了敏感文件信息，就容易被用户下载获取。

为了避免随意访问资源，可以添加身份认证，在访问前先进行账号密码认证。
更安全的做法是同时关掉目录浏览功能，用户只能通过完整资源路径获取指定资源。比如资源根目录下有"xx.txt", 用户只能通过"http://huiwan_code.com/xx.txt"获取，而不能访问"http://huiwan_code.com"打开目录页面。再在页面上点击下载"xx.txt"。

过于详细的robots.txt

许多网站都提供文件 /robots.txt 和 /sitemap.xml 帮助搜索引擎爬取其网站。搜索引擎可以通过robots文件可以获知哪些页面可以爬取，哪些页面不可以爬取。

上面是百度的robots.txt内容，可以直接通过网站域名(wwww.baidu.com)后加robots.txt查看。robots可以针对不同的搜索引擎进行不同的页面规则爬取限制。allow表示允许爬取；disallow表示不允许爬取。

如果robots.txt文件编辑的太过详细，会泄露网站的敏感目录或者文件。比如disallow: /admin/login、disallow/admin/register等，直接将详细的后台路径写出来，容易被攻击者收集利用。

可以通过正则通配符的方式，模糊的进行路径匹配:

• User-agent: * 这里的代表的所有的搜索引擎种类
• Disallow: /admin/ 表示禁止爬寻admin目录下面的目录
• Disallow: /? 禁止访问网站中所有包含问号?的网址
• Disallow: /.jpg禁止抓取网页所有的jpg格式的图片
  ...

前端保存密钥信息

有时候，系统可能需要依赖第三方系统进行一些辅助功能，比如发短信、审批系统等。如果业务架构设计不合理，将这些第三方服务的密钥key放在前端存储，前端直接调用服务。攻击者可以分析前端js代码获取到密钥，导致信息泄露。

接口返回用户敏感信息未进行脱敏处理

当接口需要返回用户敏感信息(如：身份证、手机号、姓名、详细地址等)时，需要对这些信息进行脱敏处理。避免被攻击者获取利用。

过多返回用户敏感信息

有些时候，可能一个接口会被不同前端模块调用，但各个模块需要用到的信息不同，比如A模块需要展示用户的名称，B模块需要获取用户的地址。接口把全部信息返回，然后前端获取接口全部字段后按需使用。有些同学可能会说敏感信息都已经脱敏处理了，即使全部返回也不会有风险了。

只能说too young too simple, 假设攻击者拿到一个手机号后，根据微博、qq等社交软件获取到几个可能是手机号号主姓名的名单，如何进一步确认呢？
相信大家都用支付宝转过账，通过手机号转账时，会显示收款人的脱敏姓名，支付宝是实名验证的，所以这是用户的真实姓名脱敏信息。

「点此验证」还能输入收款人的姓，进一步确认用户姓名。

这里并不是说支付宝有漏洞，毕竟这个泄露风险与用户未经确认导致转错账相比不值一提，只是想提醒大家，敏感信息也有可能成为攻击者的一个有用信息。所以，接口应尽可能少的返回敏感信息。

如果确实想要一个接口满足多个数据要求，GraphQL是个不错的选择。后端先定义好数据格式和字段。前端可按需请求需要的字段信息。

第三方平台泄露

信息泄露也会发生在工作时使用的第三方平台网站上。

公司代码上传到github

有意或无意。我们可能会将公司代码上传到github上，如果代码中包含配置文件、数据库账号密码等，会造成严重泄露后果。

除了加强培训员工安全意识，强化公司管理制度，避免员工私自上传代码。公司还可以利用Hawkeye等github泄露监控工具对github代码库进行监控，及时发现员工托管公司代码到GitHub行为并预警，降低代码泄露风险。

工作笔记上传到云存储工具

为了方便，有时候会将工作笔记、工作资料存放到网盘、云笔记上，多端直接同步。但由此导致的安全问题也不可忽视。
拿印象笔记举例，印象笔记提供了邮箱找回密码的功能，一旦邮箱账号和密码被泄露，攻击者可通过邮箱重置印象笔记账号密码，登录用户印象笔记。

写在最后

喜欢本文的朋友，欢迎关注公众号「会玩code」，专注大白话分享实用技术