浅谈大型互联网的安全

这里用浅谈，因为这块也只能算是有点研究，也希望看到本文的各位如果能有所收获即可。如果不喜欢，也请不要喷。码这么多字很不容易，做一个分享者更是如此。

一直以来，很多大厂商的安全一直被认为相对薄弱，因为他们业务线长，同时，子站、分站众多，往往安全性子站与分站没有主站做的那么好。

安全是一直都是遵从木桶原理，整体安全着重看的是最低的一块板的高度。从这，也可以侧面反映了一个厂商对安全的理解是否到位。

下面我会用以下几个真实案例去和大家聊聊大厂商的短板究竟出现在哪些地方

0×01:敏感业务系统未认证登录

百度某后台访问未限制，泄漏业务信息!

目前漏洞还没公开，一部分核心白帽子已经可以提前查看了，这里我就简单说下发现这个后台的思路:

首先我先ping了一下百度贴吧:得到了IP:220.181.111.85。

我再ping了一下其他几个子站的IP，最终得到了IP段大概定位在180.149.132.x，当然了，像百度这样的大型站点是不可能只有一个段的，还有很多，我没有一个一个仔细去挖，点到即止。

当然，这其中走了不少弯路，譬如不好识别哪些到底是不是CDN。(这里我暂时的方法就是多ping一些站点，更好确定ip段，当然，如果你有更好的方法也请告诉我，这里推荐一下核攻击的CDN查询工具，还是挺不错的。当然还有不少CDN查询工具，大家都可以多试试，不要以为上了CDN就很难搞。)

但是坚信一点，找大站的IP段，要从他们的小站入手，很多都可以从邮件(常用的二级域名：mail)、甚至是业务系统中ping出来，得到真实的IP地址。

最终挖出了百度的某个后台：

而往往，大厂商对外IP开放的情况下，对权限设置的就不严谨了。

通过这个IP，直接获取到了搜狐某个站点的备份数据库。大小2G

这里再一次证明，不少厂商没绑定域名的IP上，一样是有业务在运营的，只不过你能否找到，你找到的是否真正能对外访问并且你能操作的。

还有一部分则是因为安全意识不到位造成的。

不少人在线上开发，总会想备份文件，有时贪图方便，往往会把系统文件重命名，但是重命名的过程并没有考虑他是否会被web容器重新解析，如果不被解析，那么攻击者就能直接从这里读取出敏感信息，并且实施下一步的攻击。

这样，攻击者丝毫不费劲的就获得了config配置文件了。

案例:

这两个案例都是因为配置不当造成的任意文件读取。

很多时候，其实tomcat是限制了对WEB-INF的访问，但是因为不少大型业务系统是做反向代理服务，因此非常容易造成敏感业务信息被任意读取。

关于web.xml以及Java那块可以参考早些日子:shine写的那篇文章:

上面这些案例，最终都是为了说明一点，无论厂商们的业务是否绑定域名，这点并不重要。重要的是安全人员一定要清楚，自己的那些业务哪些是暴露在公网，哪些是可以被访问到而又没配置好的。分享这篇文章的目的也只是想和大家探讨探讨，或许文章没有太多闪亮的技术要点，但更多的是安全意识。你，真的做到了吗？