对于session欺骗 大家都蒙了。
百度上有一篇文章 骗了整个网络界 虽然有不少人已经发现是错误的理论 误导的文章 。使不少人觉得 session欺骗很牛x 其实不然
那篇文章叫eWebEditor session欺骗漏洞
没错 ew的确存在那漏洞 但是那个作者说错了 原文：
eWebEditor session欺骗漏洞
文章作者：nowthk
eWebEditor在线编辑器
漏洞文件:Admin_Private.asp
漏洞语句:<%
If Session("eWebEditor_User") = "" Then
Response.Redirect "admin_login.asp"
Response.End
End If
只判断了session，没有判断cookies和路径的验证问题。
漏洞利用:
新建一个test.asp内容如下:
<%Session("eWebEditor_User") = "11111111"%>
访问test.asp，再访问后台任何文件，for example:Admin_Default.asp
漏洞影响:虚拟主机的克星. by nowthk
noethk大牛想法不错 但是很可惜 背离了session的运行机制。要知道 session是存放在服务端的 而放在客户端的只是一个服务端分发的sessionID 。原文作者是在本地架设的环境 所以根本不存在客户端服务端之说.如果文章没有加上 虚拟主机的克星这几个字 估计就不会有什么争议。 的确 session是可以被欺骗。这个话题我丢到后面再说。先说机制。
虽然sessionID的唯一性大大地提高了session认证的总体安全 但是这世界上还有一样东西叫盗窃.
我们来说说session的运行机制 . 例如你访问www.link0day.cn 这个站 那么服务端就会分给你一个sessionID值（前提是他们开启session） 什么时候你不爽 你关了浏览器 那么sessionID就失效了吗？
个人通过收集资料觉得 session在服务端是有存活期的。 你关了浏览器的话 那么就只是注销了该站的sessionID值 但服务端还残留着 iis默认是保存20分钟 这样就给了我们可乘之机。
继续说到session运行机制 有一个很重要的知识点就是 服务端与客户端交接 是通过cookies存放在某一文件夹里面的 也就是说 xss也可以盗取session。
先别慌，看这一捉包来的数据：ASPSESSIONIDGQGGQAFC=FPGBGNOCAGPLAPOFOPJGODCJ
看到没 asp sessionid*********** 等号后面就是他的sessionID值。 为了方便大家理解和验证方法的可行。我与老大 樱木花盗 做了一实验(部分修改)。
老大登陆一后台（当然是session有验证）。然后捉包 发他的sessionID给我 然后他关了浏览器。也就是结束了客户端与服务端的连接 但那sessionID没过期。 我这边用啊D修改session 然后直接点击登陆 。 结果可想而知 成功登陆。
这是说明 客户端与客户端之间对服务端的欺骗 文绉绉地说 也就是中间人攻击，
这里 可能你会问 入侵的时候 别人会那么傻给你sessionID么。嘿嘿 问得好 。这里就出现了xss。
要知道 我们可爱的xss可以盗取cookies。。 我们直接把他的cookies相关直接盗过来。
Xss恰恰可以做到这一点。 至于怎么触发跨站就不用说了把。。 盗取cookies的文件 网上一堆 自己找一下 改一下就可以。跨站的时候拿cookie可以，但是拿session就麻烦。Session很快就要失效，除非没事一直等着目标中招后立即行动，不然就算拿到了session早就过期N久了
上面说的是中间人攻击 ， 下面就说一下另一种情况。直接”欺骗”服务端。
这里就要纠正不少人的观点了。回到文章一开始说的那个ew编辑器session欺骗的文章 作者当然是想错了 看了我前部分所说的运行机制 应该就能弄个半懂把。也就说 客户端不能提交修改后的sessionID值到服务端 让服务端信任你。那样是不成立的。并且实验证明 不是行的。
另外一个实验如下：
WIN2003 SP1 +IIS6.0 不是虚拟主机，iis建的两个网站A、B。
A -->s.asp : <%session("test")="ok"%>
A -->e.asp :<%if session("test")<>"" then response.write("good!")%>
B -->e.asp :<%if session("test")<>"" then response.write("good!")%>
1.访问http://A/e.asp 显示为空
2.访问http://B/e.asp 显示为空
3.访问http://A/s.asp
4.访问http://A/e.asp 显示"good!"
5.访问http://B/e.asp 显示为空
6.访问http://B/s.asp
7.访问http://B/e.asp 显示"good!"
实验三：
在http://www.xxx.net/1.asp写下了如下代码：
<%
session("username")="abddwww"
%>
又在同一主机另一个站点下写下了如下代码：(test.asp)
<%
if session("username")<>"" then
response.write "ok"
else
response.write "no session"
end if
%>
先访问test.asp返回no session，然后访问1.asp，再次访问test.asp还是返回no session（同一ie进程下）
说明想跨站欺骗是不成功的
假如要成功运用那个漏洞，除非www.x1.cn和www.x2.cn是绑定在同一主机头下，同目录。
为什么？ 这又与iis用户有关.. 假如权限设置得适当 是没办法read目录 +write目录的话 那样session欺骗是不成立的
所以 要使成功 就必须以下几个条件
1：成功获取了该域名下的一个webshell
2：有读权限
3：需要入侵的系统采用了session认证
4：管理员使用的密码无法破解
5：可以获得session验证的语句
6. 同iis用户
7. 同域名（一级or二级）.：
例如 www.sb.cn ，那么二级域名就可以是这样： fuck.sb.cn
8. 同目录
这样的洞洞是不是很难利用？ 其实一般小站都用不上 大站才用得上
我曾经检测国内某某大学的时候 就是靠这洞弄下不少shell 然后提权之。
所以 事实证明 session欺骗是存在 但是 利用范围比较狭窄 一般小站用不上 大站用这方法的话 倒是百试百灵~
【小议session欺骗的利用以及价值】相关文章：
★ FSO的开启方法