安全检测网站.docx

上传人:b****6 文档编号:7577446 上传时间:2023-01-25 格式:DOCX 页数:14 大小:392.07KB
下载 相关 举报
安全检测网站.docx_第1页
第1页 / 共14页
安全检测网站.docx_第2页
第2页 / 共14页
安全检测网站.docx_第3页
第3页 / 共14页
安全检测网站.docx_第4页
第4页 / 共14页
安全检测网站.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

安全检测网站.docx

《安全检测网站.docx》由会员分享,可在线阅读,更多相关《安全检测网站.docx(14页珍藏版)》请在冰豆网上搜索。

安全检测网站.docx

安全检测网站

 

注意:

本人也是刚刚来到这个圈子的菜鸟.希望和大家一起学习一起交流一起进步.看到一些好文章.虽然没有什么技术含量.但是适合我们菜鸟学习.高手飘过~~

最近闲着无聊,想对国内的黑客网站进行安全检测,第一个拿来开刀的是教主的黑色技术网站。

按照国际惯例我们先扫注入点,结果如图1所示。

图1

根据工具显示,没有发现注入点。

我们先去找找后台吧,再次用工具扫,我扫我扫我扫扫扫,如图所示2

图2

果然不出所料,是黑客站点就不可能把后台放在显眼的地方,不然教主干什么吃呀。

根据以往的经验,在敌方的网站里一般可以找到很多有用的线索。

在主页我随便到处点一点、看一看。

李白说的真好:

“抬头望明月。

”不看不知道,一看吓一跳。

如图3所示。

图3

天那!

后缀名居然是DLL动态链接库文件!

Ohmydog!

不是,是Ohmygod!

看来教主也不是吹出来的“教主”嘛。

看来刚才扫的后台要把后缀ASP换成DLL的才能正确扫出,我一个一个试了之后,发现login.dll是后台的登陆地址如图4所所示。

图4

我先用了最简单的帐号:

'or'='or'和密码:

'or'='or'试了试,无疑肯定是无效的。

我们只好从其它方面入手了,先扫描下他的服务器开了什么端口,我用的是SuperScan3.0来扫描的,设置的是从1号端口扫描到65535端口,可是刚开始扫描我就发现不对头了,如图5。

图5

我扫描到了3191个端口就暂停了,工具显示1-3191这3191个端口全部都打开了,这是不可能的,看来教主对端口扫描做了相应的防范。

我们再去他的黑色技术论坛参观一下,一进去就豁然开朗,如图6。

图6

看来他的黑色技术论坛遭到了别人DDOS的黑手了,得罪了这么多的人,哎——

既然没别的入口,只好从他主站的后台入手了,这个站的后台的验证码是5位的,所以应该是讯时,我们先从网上下到源码看看login.dll。

从代码中可以看出有admindj、adminuser和adminpass3个表。

发现可以进行Cookie注入,我来给大家说下什么是Cookie注入。

Cookie注入,我来给大家说下什么是Cookie注入。

\n这是目前流行的一种攻击方式,普通的注入攻击比较好防范,但是如果把注入语句添加到Cookies中提交就往往被人忽略。

当一套程序的Cookies过滤不严时,就为攻击者打开了方便之门,而且还能无视防注入系统。

那么什么Cookie呢,我这里给大家一个解释,Cookie是一个储存于浏览器目录中的文个字符组成,仅4K硬盘空间。

当用户正在浏览某站点时,它储存于用户机的随机存取存储本文件,记录你访问一个特定站点的信息,且只能被创建这Cookie的站点读回,约由255器RAM中,退出浏览器后,它储存于用户的硬盘中。

储存在Cookies中的大部分信息是普通的,如当你浏览一个站点时,此文件记录了每一次的击键信息和被访站点的地址等。

但是许多Web站点使用Cookies来储存针对私人的数据,如:

注册口令、用户名、信用卡编号等。

理论是需要实践来证明的,我们开始实施Cookie注入吧。

我们就用这个Cookies进行注入

admindj=1;adminuser=%27or%27%3d%27or%27;adminpass=21232f297a5dfd

我们用老兵的Cookies浏览器进入

图7

现在显示的Cookie是

AJSTAT_ok_times=1;virtualwall=vsid=1cc39e686c7ab7353b2946bcc02fa982;AJSTAT_ok_times=2;ASPSESSIONIDCSSBQSSB=HKJKNMJCKMMJPGEGEHJHFAEM

我们先点下左边的小金锁,然后把这段Cookie改成

admindj=1;adminuser=%27or%27%3d%27or%27;adminpass=21232f297a5dfd

接着我们访问admin_index.dll,就进了后台,如图8

图8

哈哈,想不到教主做的站安全也不怎么样,看以来像是几套程序套在一起组装出来的。

在新闻添加的里面有一个附件上传,我们把我们的ASP马改成GIF图片格式,上传试试。

没想到居然上传成功了。

在下面我们还看到一个备份,如图9。

图9

通过备份我们拿到了一个SHELL,如图10。

图10

我们到他的站点根目录下去,去分析下他网站的漏洞。

出现漏洞的是这admin_chk.dll中的这三处代码

admin_chk.dll文件中没作任何过滤

session("admin__user")=Request.Cookies("adminuser")

session("admin__pass")=Request.Cookies("adminpass")

session("dJ")=Request.Cookies("admindj")

从cookies读取adminuser,adminpass,admindj这些信息,然后到数据库查询,为空则数据不存在,转向登录解密那

 

adminuser=Request.Cookies("adminuser")

adminpass=Request.Cookies("adminpass")

admindj=Request.Cookies("admindj")

adminuser,adminpass只是简单检查了一下是否为空就直接参加了sql查询,形成了sql注入漏洞

sql="select*fromadminwhere[user]='"&adminuser&"'and[pass]='"&adminpass&"'"

没有过滤"&adminuser&"'and[pass]='"&adminpass&"'"

如果我们在登录页面将adminuser和adminpass的值输入''or'='or'

相当于

sql="select*fromadminwhere[user]='''or'='or'"and[pass]="'or''='or'"

意思:

从user表中查找user为空的用户(user=''就是这句)或者空=('or'='or'空这句)很明显了。

admin表中不会有用户名为空的人。

前面着句结果是假,而后面空=空,很明显就是真了。

那么我们结合上面说的or的性质,就可以判定这个最后的结果是真值

那么后面这句andpass=''or''='or"将不会被执行了!

也就是说我们通过了验证!

修补漏洞的方法

username=replace(trim(request("username")),"'","")

password=replace(trim(Request("password")),"'","")

把“'”给过滤了

如果你想用“'”当做密码就用下面的方法

1、select*fromuserwhereuser=’"&User&"'"

2、如果返回不为假,则取密码

pass=rs("passwd")

3、判断:

ifpass=password

4、得出结论。

;例子

sql="select*from****_adminwhereadmin_pass='"&admin_pass&"'andadmin='"&admin&"'"

rs.opensql,conn,1,3

ifnot(rs.bofandrs.eof)then

ifadmin_pass=rs("admin_pass")then

session("admin")=rs("admin")

总之,我的入侵方法就是这样的,没有什么技术含量,只是想说明即使是黑客网站也是有低级的漏洞,所以像和我一样的菜鸟朋友不要畏惧去检测黑客网站。

之后又对部分有名的黑客网站的安全检测也证明了这一点,都是存在着不同的漏洞可以利用,看来教主的黑色技术不会很安全了。

好了,文章就到这里就结束了。

希望大家有什么好的入侵方法能和我交流、互相学习.欢迎大家来我的Blog:

拖把哥,我把帖子发上来咯O(∩_∩)O哈哈~

网站安全性检测及防范措施

安全性测试(securitytesting)是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。

  注意:

网站安全检测并不最终证明应用程序是安全的,而是用于验证所设立策略的有效性,这些对策是基于威胁分析阶段所做的假设而选择的。

  WEB安全性测试

  一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。

参数操作、异常管理、审核和日志记录等几个方面入手。

1.安全体系测试

1)部署与基础结构

  网络是否提供了安全的通信

  部署拓扑结构是否包括内部的防火墙

  部署拓扑结构中是否包括远程应用程序服务器

  基础结构安全性需求的限制是什么

  目标环境支持怎样的信任级别

2)输入验证

l如何验证输入

A.是否清楚入口点

B.是否清楚信任边界

C.是否验证Web页输入

D.是否对传递到组件或Web服务的参数进行验证

E.是否验证从数据库中检索的数据

F.是否将方法集中起来

G.是否依赖客户端的验证

H.应用程序是否易受SQL注入攻击

I.应用程序是否易受XSS攻击

l如何处理输入

3)身份验证

  是否区分公共访问和受限访问

  是否明确服务帐户要求

  如何验证调用者身份

  如何验证数据库的身份

  是否强制试用帐户管理措施

4)授权

  如何向最终用户授权

  如何在数据库中授权应用程序

  如何将访问限定于系统级资源

5)配置管理

  是否支持远程管理

  是否保证配置存储的安全

  是否隔离管理员特权

6)敏感数据

  是否存储机密信息

  如何存储敏感数据

  是否在网络中传递敏感数据

  是否记录敏感数据

7)会话管理

  如何交换会话标识符

  是否限制会话生存期

  如何确保会话存储状态的安全

8)加密

  为何使用特定的算法

  如何确保加密密钥的安全性

9)参数操作

  是否验证所有的输入参数

  是否在参数过程中传递敏感数据

  是否为了安全问题而使用HTTP头数据

10)异常管理

  是否使用结构化的异常处理

  是否向客户端公开了太多的信息

11)审核和日志记录

  是否明确了要审核的活动

  是否考虑如何流动原始调用这身份

2.应用及传输安全

  WEB应用系统的安全性从使用角度可以分为应用级的安全与传输级的安全,安全性测试也可以从这两方面入手。

  应用级的安全测试的主要目的是查找Web系统自身程序设计中存在的安全隐患,主要测试区域如下。

  注册与登陆:

现在的Web应用系统基本采用先注册,后登录的方式。

A.必须测试有效和无效的用户名和密码

B.要注意是否存在大小写敏感,

C.可以尝试多少次的限制

D.是否可以不登录而直接浏览某个页面安全等。

在线超时:

Web应用系统是否有超时的限制,也就是说,用户登陆一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

  操作留痕:

为了保证Web应用系统的安全性,日志文件是至关重要的。

需要测试相关信息是否写进入了日志文件,是否可追踪。

  备份与恢复:

为了防范系统的意外崩溃造成的数据丢失,备份与恢复手段是一个Web系统的必备功能。

备份与恢复根据Web系统对安全性的要求可以采用多种手段,如数据库增量备份、数据库完全备份、系统完全备份等。

出于更高的安全性要求,某些实时系统经常会采用双机热备或多级热备。

除了对于这些备份与恢复方式进行验证测试以外,还要评估这种备份与恢复方式是否满足Web系统的安全性需求。

  传输级的安全测试是考虑到Web系统的传输的特殊性,重点测试数据经客户端传送到服务器端可能存在的安全漏洞,以及服务器防范非法访问的能力。

一般测试项目包括以下几个方面。

  HTTPS和SSL测试:

默认的情况下,安全HTTP(SoureHTTP)通过安全套接字SSL(SourceSocketLayer)协议在端口443上使用普通的HTTP。

HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别,但从某种意义上来说,安全性的保证是以损失性能为代价的。

除了还要测试加密是否正确,检查信息的完整性和确认HTTPS的安全级别外,还要注意在此安全级别下,其性能是否达到要求。

  服务器端的脚本漏洞检查:

存在于服务器端的脚本常常构成安全漏洞,这些漏洞又往往被黑客利用。

所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

  防火墙测试:

防火墙是一种主要用于防护非法访问的路由器,在Web系统中是很常用的一种安全系统。

防火墙测试是一个很大很专业的课题。

这里所涉及的只是对防火墙功能、设置进行测试,以判断本Web网站系统安全需求。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 经管营销 > 经济市场

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1