你的网站可能并不安全

二叶草 2020年3月11日10:14:15安全防范评论阅读模式

 

几年前,在我向一个朋友炫耀如何攻破了公司的一个系统时,他突然说道那你能攻破我公司的网站吗?他微笑的看着我,眼中却尽是挑衅。自己刚吹出去的牛,现在哪能打脸,我就跟他保证说绝对没问题,但是心里却是没有一点底。我是攻破过几个系统,但那也是经过长期研究分析,发现了一些漏洞,是花了不少时间的。而我也不敢保证对于他公司的网站我能顺利发现漏洞,而且如果时间过长势必也会引来他的嘲笑。

 

 

 

既然牛都吹出去了,那也只能硬着头皮上,这时候时间就是面子!打开电脑,浏览了下网站,按照常用的几个url地址试了试能不能找到些有价值的东西,包括robots.txt、/admin、/houtai等,没发现什么有价值的东西。好吧,那就请工具来帮忙,打开了熟悉的Acunetix Web Vulnerability Scanner扫描工具,先对网站进行了全站扫描,确实收获不小,网站的开发语言是PHP、web服务器为apache、发现了管理平台登录地址,这就好说了,主攻管理平台的登录吧!

在管理平台登录页面我先试了基本的sql注入、跨站式注入等基本的web漏洞,发现他们的防范还是挺严格的,对于所有的敏感关键字包括select、insert、from、script等都进行了过滤,看来还是比较注重安全的。我继续去研究网站扫描出来的地址,发现有一些陌生的url,不像是网站普通的访问页面,那我就去百度一下这些地址看能不能搜出来一些有价值的东西。你别说还真有,我发现这些地址来自于国内的某个小的开源框架。我马上去github下载了该开源框架,研究了下view到controller的代码,发现他们有一个很致命的漏洞!该框架为了开发人员request取值方便,默认取值采用了三级取值模式:先从get中取,没有的话再从post中取,再没有就从cookie中取。而在去做敏感关键词过滤的时候竟然只对get请求和post请求进行了拦截过滤,没有对cookie中的值进行拦截过滤!

既然发现了新大陆,那就得马上尝试,我把请求中本该在post中传值的参数去掉,放在了cookie中,对于键值则改成了注入sql。奇迹发生了,还真可以注入!通过注入产生了错误,连错误页面都没有替换,暴露除了他们用户表的表名和用户名、密码等关键字段!那就好说了,通过研究和尝试终于拿到了用户名和密码,不过密码是MD5的。我拿着MD5密码到CMD5网站进行“破解”,免费的无法破解,必须交会员才可以破解,最终花了我20大洋破解了该密码。成功登入到后台管理系统,理论上我已经算是胜利了,但我还想继续去拿服务器控制权,就继续研究了下后台管理系统的功能。我发现他们就连在登录页面做的那么周全的安全机制全都没有了,甚至都没有任何的前端验证。我通过分析那个开源框架以及管理功能,编写了一个可以进行拿shell权的注入脚本,但是最终失败了,因为我在运行该注入脚本的时候少写了最后的一个“>”,整个网站竟然都瘫痪了,因为该功能是直接把填写的内容写入到了PHP的一个配置文件,而该网站所有的页面都引用了该配置文件。我马上打电话告诉我的朋友,最终帮他们恢复了网站的运行,他们也开始注重网络安全问题!

 

 

上面的这个个人小案例不值一提,因为我破解的只是一个没有什么规模的企业小网站,而对于大型网站和政府网站我也是万万不敢去尝试破解的。但是我可以告诉你,大型平台也不是那么安全,甚至由于开发人员参差不齐、采用开源框架、运维人员疏忽等原因可能漏洞更多!看看下面数据案例:2013年6月struts2被曝出严重安全漏洞,苹果、中国移动、中国联通、百度、腾讯、淘宝、京东、Sohu、民生银行等大型企业网站均遭毒手,淘宝网出现大量钓鱼网站;2011年12月21日有黑客在网上公开提供CSDN网站用户数据库下载后,包括人人网、猫扑、多玩等在内的网站部分用户数据库也被传到网上供用户下载;2015年10月网易游戏被暴力破解;2014年12月12306网站曝出重大漏洞,大量用户隐私数据被泄露;2015年5月28日携程网由于遭到不明攻击瘫痪一整天,后解释为由于员工误操作造成…这些案例都触目惊心,损失和影响都是巨大的,这些还都是被报出来的,没有被报出来的更多。所以,你还认为你的网站足够安全吗?

你可能会说那我们的网站一直都运行的很好,也经常会有人扫描我,但是一直没有被攻破,所以足够安全!那是因为你的网站没有足够的理由让他们花大精力去攻击,如果真想去攻击你的网站,可能是易如反掌的事,以下事件足以说明:2001年,由于中美黑客大战,“中国红客联盟”冲破白宫网站,迫使白宫网页一度瘫痪;2011年由于钓鱼岛事件,日本政府多个网站被“插上”了中国国旗;2018年7月23日,由于假疫苗事件长生科技官网被黑客攻击,并配图“不搞你,对不起祖国的花朵”…

我不是一个黑客,也不是一个网络安全技术员,只是一个程序开发人员,我写本文的目的是想从程序开发方面来探讨下你为你系统的漏洞做了多大的“贡献”!我看过很多开发人员的代码,也跟很多开发人员探讨过安全知识,但是发现他们对于自己的代码安全没有足够的重视,也留下了足够多的安全隐患。咱们下面探讨主要下一般开发人员容易留下隐患的安全漏洞。

一、sql注入漏洞

这个漏洞最早被发现于2006年,也是最常见的危害较严重一个漏洞。通过该漏洞可以进行数据库表字段的猜解、数据信息的获取、更改添加数据,甚至可以进行拖库以及拿取服务器的shell权限,从而控制服务器!该漏洞的产生主要原因是由于程序员在写程序的时候对原生sql进行了拼装,而没有对特殊符号进行处理,例如:select * from user where username=’abc’and password=’123456’,在代码中我们可能会这样拼写sql:”select * from user where user=’”+username+”’and password=’”+password+”’”,那么我只需对变量username做些改造即可,比如username值为abc’-- ,大家知道sql的注释符号为--,所有可以认为原sql在程序中真正被执行的就是select * from user where username=’abc’了,当然这只是最简单的sql注入,现在各语言都有自己成熟的ORM框架,只要你按照框架的要求去操作数据库基本可以避免sql注入漏洞,但有些框架还是可能会产生漏洞的,比如java的mybatis框架。

二、XSS漏洞

XSS攻击中文名称为跨站式脚本攻击,英文名称为Cross Site Scripting,被简写为XSS主要是因为CSS已经是别的技术的简写了。这是一种最常见的漏洞,几乎所有的网站都会有,一般严重程度相比于sql注入漏洞略小。产生的原因主要是在请求中获取用户的参数之后没有进行任何处理,后续直接将该结果通过网页展示给客户,而用户的参数有可能是html代码,甚至有可能包含JavaScript代码,造成的结果可能就是网页紊乱、js的执行、网站挂马、钓鱼网站等;由于常被黑客用来编写危害性更大的钓鱼网站,所以被称为跨站式脚本攻击。对于该漏洞的防范主要是将特殊符号进行转义,比如将’<‘转换为’&lt;’,将’>’转换为’&gt;’等。但是如果需要富文本的情况下就比较难以处理,比如论坛发帖可以采用html源码来控制样式,那么展示的时候也应该使用客户编辑好的html来展示,这时就不用用普通的特殊字符替换了,只能针对特殊的脚本、关键字进行替换,这种方法往往很难完全杜绝XSS攻击,因为总有一些你想不到的方式进行注入。

三、session劫持

现在各系统对于登录普遍采用的方式是session来存储用户的登录信息,对于登录拦截验证则是从session中取出进行判断,所以session至关重要。众所周知session是服务器端对用户信息的存储方式,通过从用户访问的cookie信息中取出sessionid来进行session关联。产生的原因是你的sessionid遭到泄露,黑客可以采用更换自己浏览器下该域名sessionid的方式来访问本来只有你权限能访问的系统,而他根本就不需要登录,泄露的方式一般都是通过XSS漏洞的js执行(将document.cookie通过请求方式发向自己预备好的网站或者邮箱中)。造成的危害就是黑客不需要知道你所登录系统的用户名密码即可直接使用你的信息访问该系统,而所有的操作记录全部都是你的。防范方式一般都采用在记录用户登录信息的同时记录用户客户端信息,比如IP地址、useragent信息等,每次访问的时候都验证这些信息是否完全符合,如有不符合则判断该session会话已被劫持,要及时注销该session。

四、CSRF漏洞

CSRF(Cross-site request forgery)跨站请求伪造,称之为漏洞不是很贴切,因为该漏洞相对于一般的开发人员来说或许不是真正的漏洞,因为对于单个功能确实没问题,这只是一种攻击方式。但是该漏洞危害较大,而且难以防范,各种防范方式均有利弊。产生原因,以A系统为例,当用户登录进入A系统操作之后,没有进行退出或者关闭网页,此时他被诱导进入了钓鱼网站B,B网站有诱导他点击的A网站的链接(该链接本来只有该用户登录进去才能操作,比如转账、删除自己的帖子等),他点击了该链接,那么他就合法的、神不知鬼不觉的操作了B诱导他操作的信息,而服务器还认为这个操作是合法的。防范方式包括验证http referrer字段、token验证、自定义属性验证等,但每种方法总有缺陷,开发人员在去开发系统的过程中在敏感信息操作的API上尽量不使用GET方法,比如用GET方式请求/delete/article?id=123,这样伪造起来基本就不费力气,尽量多去采用REST API利用好POST、PUT、DELETE等方法,虽然也可以伪造,但是总是要费一番力气的。

五、文件上传漏洞

一般的网站都会提供文件上传功能,但是如果不注意处理,文件上传功能可能会成为你系统致命的漏洞。产生原因主要是在做文件上传的时候将文件名称未经过任何处理直接放入web中某目录下,用户可能会上传某些可执行文件,比如php网站中上传php文件、java网站中上传jsp文件、上传脚本文件等,用户可通过分析组装相应的文件路径去执行该文件即可去执行黑客想要执行的指令,比如创建后门、拖库等严重后果。防范方式主要是采用白名单形式控制用户可上传文件、上传目录不要在web目录中、对于文件名称进行处理(比如通过UUID生成临时文件名等。

六、数据权限

不可否认每个系统中都会有,因为要做好数据权限是比较复杂的事情。比如你的订单只有你和你的上级可以进行查看,我们一般通用的做法是在订单列表查询中做筛选,看得到就可以点击进入查看详情。但是你有没有想过,查看详情是通过订单ID去检索的,比如/shop/order?orderId=123,但是假如别人知道你的orderId或者通过扫码软件扫描出你的orderId,那么他就只需拼接出该url即可访问,试问你想过去避免这个问题吗?因为要想避免这个问题所有原本简单的查询就变得很复杂,而数据权限很难有统一的解决方案,因为每种数据所需要的权限都是不一样的。唯一的避免方式就是针对不同的业务去做不同的数据权限处理(也或许只是笔者没有想到更简单有效的方法)。

试问开发人员你在日常开发中有注意过这些问题吗?你可以数数你在开发中犯了多少个严重的错误!笔者举的还只是部分最常见的例子,在web漏洞中还有很多:弱口令漏洞、HTTP报头追踪漏洞、struts2远程命令执行漏洞、未加密登录请求漏洞、敏感信息泄露漏洞等。如果你对本文感兴趣或者对于web安全感兴趣,想在后续的开发中尽量去避免这些问题,请扫描下边二维码关注本公众号,我会在后续篇章中独立去讲解每种安全漏洞并提供多种防范方法!

 

 

本文来源于:你的网站可能并不安全-变化吧门户
特别声明:以上文章内容仅代表作者本人观点,不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。

  • 赞助本站
  • 微信扫一扫
  • weinxin
  • 加入Q群
  • QQ扫一扫
  • weinxin
二叶草

发表评论