web攻击面
network
OS
web server
APP server
web application
database
browser
web攻击面
network
OS
web server
APP server
web application
database
browser
vea更关注web代码层面上的漏洞
Web扫描器:APPSCAN
Watchfire APPScan,2007被IBM收购
扫描过程:
1、探索阶段(爬网阶段)ps:将ie浏览器集成到自己的程序端口里
2、测试阶段(对所有URL进行注入探测),可能额外发现些URL
第一个过程发现新的URL地址,下个过程自动开始
1、向导方式
2、完全配置
NIKTO使用方法:
空格 |
报告当前扫描状态 |
v |
显示详细信息(verbose) |
d |
调试信息(及其详细信息) |
e |
显示错误信息 |
p |
显示扫描进度 |
r |
显示重定向信息 |
c |
显示cookie |
a |
身份认证过程显示出来 |
q |
退出 |
N |
扫描下一个目标 |
P |
暂停扫描 |
配置文件:
路径:/etc/nikto.conf
User Agent中文名为用户代理,简称 UA,它是一个特殊字符串头,使得服务器能够识别客户使用的操作系统及版本;在nikto中最好修改成别的浏览器user agent;
设置cookie:
在配置文件中找到cookie进行设置(#STATIC-COOKIE= "cookie1"="cookie value";"cookie2"="cookie val")
IDS逃避技术:主要为了躲避IDS、IPS检测告警
-evasion #此参数使用方式(Nikto -host http://1.1.1.1 -evasion 1234)逃避方式共8种:1、随机url编码,2、自选路径,3、过早结束的URL,4、优先考虑长随机字符串,5、参数欺骗,6、使用TAB作为命令的分隔符,7、使用变化的URL,8、使用Windows路径分隔符
profile : import export new dispacher 可以做分布式扫描 grid 网格式的烧苗 该网站的cookie不断的变化
.arachni_rpcd --address =url --port=... --nickname=name dispatchmode
在URL地址之后加上-s 可以检查源代码
.arachni_rpcd --address =url --port=... --nickname=name2 --nerghbour=url:port girdmod
Vega做代理访问https网站的注意事项
证书用到的算法最主要的是非对称加密,非对称加密主要有公钥和私钥
公钥加密的内容只能用私钥去解密
对称加密不一样,你用这个密码加密,你也用这个密码解密
例如压缩文件的加密与解密都是要用同一个密码
公私钥是由一次数学计算产生的一对密钥对,一个称为公钥,一个称为私钥
公钥是扔出来给所有人看,所有人看到都没关系,但是经过公钥加密的内容,回传给服务器,只有服务器用自己的私钥才能解密
在公私钥加密体系里,私钥的安全性是保障安全的根本,私钥一旦泄露,整个安全体系就没有安全性可言
客户端访问https服务器,客户端发出请求,服务器第一次返回的不是页面,而是一张公钥证书,客户端拿到公钥以后,会在本地随机生成一个对称密钥,这个对称密钥是用来加密后来通信过程中的数据部分
所有的数据都必须要通过这个对称密钥来加密
对称加密加密解密都是同一个密钥,服务器也要有相同的对称密钥才能解密客户端发来的内容
如果直接以明文的方式将密钥发给服务器,则很容易被人嗅探的,整个传输过程就没有加密可言
因此整个传输过程的关键是如何将对称密钥传到服务器那里,一般客户端会用服务器发过来的公钥对对称密钥进行加密
发给服务器,服务器收到后会用自己的私钥来解密,这样双方都拿到这个对称密钥,后续通信过程中数据的加密解密都是用这个对称密钥,非对称密钥只是在首次通信时实现对称密钥的交换时用到
在具体数据的传输过程中,我们还要通过哈希值来对数据的完整性做校验,假如有人窃取了数据,即使你拿到加密的对称密钥
对内容进行修改,还是可以通过哈希校验来发现数据已被篡改,篡改的数据在服务器端是被拒绝接受的
虽然在访问速度上,https要比http慢,但随着https的传输过程的不断优化,在用户体验上已经和http没有什么差别了
我们会遇到这样一种情况,在访问一些网站时,浏览器会提示不安全,并且提示你不要访问,而一些大的网站且不会出现此类问题】
这是因为证书的问题,在于证书是由谁生成的,从哪来的。
像一些大的网站,证书都不是自己随便生成一个,服务器可以创建自己的所谓的自签名的证书,就是自己给自己发一个证书
但是这种自签名的证书都没有第三方对其的认可
这些大网站的证书都是由证书颁发机构CA颁发的,客户端浏览器默认已经信任了这些证书颁发机构了,它是通过安装这些证书颁发机构颁发的根证书来实现对这些证书的默认的信任
这些证书颁发机构的根证书里面都含有这些证书颁发机构的公钥,安装了这些根证书就相当于我们这台机器有了他们的公钥了
当这些网站它们向这些证书颁发机构申请证书时,申请下来的证书都是由CA所签发的,进行签名的
什么是签名?
签名就是给你这个证书,然后对你整张证书的内容进行哈希计算,生成一个哈希值,然后再把这个哈希值用根颁发机构的证书的私钥进行加密,生成一堆数据
然后再发给证书的申请者(也就是这些网站)
当这个网站拿到这个证书后,当有人向它发出访问请求时,它就会将证书的公钥信息和签名信息一起发给客户端使用者,客户端在收到这个信息后,它会查看证书
里面的签名信息,如果签名声称是由某个服务器颁发的,客户端就会使用对应的证书颁发机构的根证书的公钥来解密这里面的哈希值,如果成功解密,拿到这个哈希值
这时候通过拿到证书,客户端会对证书里面的内容进行哈希运算,在本地生成一个H2,如果计算得到的结果和服务器的哈希值一样,就会确认这个证书一定是对应的证书颁发机构颁发的
目的:实现对目标网站身份的确认,
如果一个WEB服务器生成的是自签名的证书,则这个证书不被浏览器所信任,因为客户端没有根证书
自签名的证书虽然浏览器不信任,但如果强行访问,之后的通信步骤都是一样的
只是缺少了一个对其身份真实性认证的过程,不确定对方的服务器是不是你想要访问的服务器
现在存在DNS欺骗等手段,会将你引向黑客的服务器
浏览器告警是因为这个证书无法证明你所访问的网站是真实的所有者
通过Vega做中间代理访问,如果是访问https的网站,访问请求到了Vega代理之后,Vega在本地也会生成自己自签名的证书
请求发到Vega那里时,Vega就会将自己的公钥发给浏览器,然后浏览器生成会话密钥,再把会话密钥通过公钥加密发给Vega
完成密钥交换,浏览器与Vega之间会话用的密钥都是Vega生成的
另一方面Vega会和你要访问的目标Web服务器进行通信,他们两个通信的过程是使用真正的由证书颁发机构颁发的证书来进行加密的
这个时候由于Vega是一个自签名的证书,它返回的是一个自签名的证书
如果你在另外一台机器使用Vega代理,再用本机浏览器借用Vega去访问,浏览器报错,这就不一定确定你用的Vega代理是你自己的代理
有可能是别人通过地址欺骗,让你去访问另外一个人的代理,当你访问他时,他就在本地用自己的私钥去解密你的请求,他也会把你的请求发出去给目标服务器
当然这里面的数据已经被他篡改了,而传回来的数据也有可能被篡改了,所以没有能力去防护这种基于地址欺骗的攻击
想要防护,只能将vega这张证书安装到本地的浏览器中去,让浏览器信任这张证书,这样访问一般不会出错,如果出错,则是地址被欺骗了,把你的流量转去另外
一台服务器上了,而这台服务器上的证书你是不信任的,因此才引起报错
如何安装Vega证书
证书颁发时是颁发给域名,不是IP地址
默认操作系统已经已经将世界上权威的证书颁发机构已经做了信任了
查看浏览器信任的证书:
edit->preference->Advance->Certificates->view Certificates->Authorities(这一栏全是证书颁发机构的根证书)
将Vega证书添加给浏览器受信任,打开Vega代理的情况下,访问网址http://vega/ca.crt 在浏览器上勾选Trust this CA to identify websites
点击OK即可
扫描工具:Nikto
基于WEB的扫描工具大部分都支持两种扫描模式
代理截断模式,主动扫描模式
扫描就是主动发起探测,每个参数都尝试各种命令和注入,看是否能成功
Nikto(春主动型扫描
Vega(两种都支持)
攻击前一定要先扫描,只有了解整个网站输入点才能更好地渗透
扫描分为自动扫描和手动扫描
手动扫描:
自动扫描可以辅助手动扫描
手动扫描不会发现一些隐藏的网页链接,自动工具会凭借字典发现所有的链接
nikto:使用Perl语言开发的开源的web安全扫描器
大部分扫描器会把扫描的范围集中在webapplication代码的扫描
1.nikto会扫描WEB服务器使用的软件的版本,若版本老旧,则会返回当前版本与新版本的差别
2.可以去搜索存在安全隐患的文件,比如备份的源代码(往往是维护人员习惯不好留在WEB目录里)
或者可能泄露安全隐私的文件存在
3.会扫描服务器配置的漏洞
现在很多服务器都是大杂烩,很多组件组合起来都是默认配置,但默认配置并不是最安全的配置,所以在这些配置中有可能存在漏洞
默认配置问题已经被列入十大安全之列
4.检查常见的安全漏洞问题(sql注入,跨站脚本等等)
避免404误判,有些服务器不遵守RFC标准,对于不存在的对象返回200相应代码,造成误判
去除时间信息后的内容取MD5值
参数-no404不会对404进行判断(不建议使用)
常用命令:
nikto -update(
nikto -host http://1.1.1
列出所有插件:nikto -list -plugins
扫描:
nikto -host ip地址(+目录)
也可以用http方式输入
nikto -host http://192.168.1.112/dvwa/
也可以通过ip地址加端口来输入
如: nikto -host 192.168.1.112 -port 80(后面可添加多个端口,用逗号隔开)
nikto还支持ssl,即https来扫描
https默认是443端口
例:nikto -host www.baidu.com -port 443 -ssl
The anti-clickjacking X-Frame-Options header is not present.
防止点击劫持
The X-XSS-Protection header is not defined.
没设XSS保护头
当扫描多个主机或域名时,可以用一个文件来存放要扫描的连接
命令:nikto -host host.txt
host文件里面的连接书写方式:
192.168.60.90:80
https://192.168.60.90:8443
192.168.60.90
nikto与nmap一起使用
nmap -p80 192.168.1.0/24 -oG - | nikto -host -
显示需要手动测试的结果:/users/: This might be interesting...
现在很多WEB程序需要登录后才能进一步扫描
nikto里面有个参数叫-id-,这个参数只支持http身份验证,不是基于表单的身份认证,他是基于webServer本身的http协议的身份认证,不是基于WEBApplication的代码
级的,它是将id:password转化成base位编码,将这个值作为身份认证的信息发给服务器
http认证的服务器很少,基本上是一些嵌入式的设备用这个方式来进行认证,大部分主流的都是基于表单的身份认证,使用程序代码
nikto不支持表单认证,但支持cookie认证
cookie就是你进行验证后服务器发给你的凭证,下次你的客户端发出的请求再带有cookie,服务器就认为你是合法的用户
然后就将该给你看的页面给你看
一旦拿到cookie,就证明你已经拿到身份认证信息
nikto支持我们拿到cookie后将cookie传给nikto做进一步探测
但必须将cookie整到配置环境里面才能被调用
nikto配置文件路径 /etc/nikto.conf
常用参数:USERAGENT:客户端代理,每个浏览器都有自己的代理
可以基于插件伪装成各种浏览器
RFI URL:远程文件包含
Cookies的添加:STATIC-COOKIE="cookie1"="cookie value";"cookie2"="cookie value";
多个cookie可用分号隔开
编辑过程:vi /etc/nikto.conf
找到cookie那一栏,将原本的例子注释掉,写上STATIC-COOKIE="PHPSESSID"="02c4b8cd372d8a1aac773f8d30facdee";"security"="high"
:wq退出,然后再对目标服务器进行扫描
nikto -host http://192.168.1.107/dvwa/
按 d可查看cookies是否被调用
nikto还有躲避,欺骗ids入侵检测的技术
使用躲避技术应使用参数 -evasion :
使用LibWhisker中对IDS的躲避技术,可使用一下几种类型
1.随机URL编码(非utf-8方式)
2.自选择路径(/./)
3.过早结束的URL
4.优先考虑长随机字符串
5.参数欺骗
6.使用TAB作为命令的分隔符,代替空格
7.使用变化的url
8.使用windows路径分隔符"\"
命令:nikto -host http://192.168.1.107/dvwa/ -evasion 12345678