开发语言:ASP
开发框架:.NET 4.0.30319
由于使用的是ASP.NET开发框架,因此服务器中间件大概率是IIS了。
同理数据库可能采用的是MSSQL
中间件:Tengine
支持的请求方法:GET、POST、OPTIONS
.do
结尾的,网上搜到的相关介绍都是说该后缀的文件是Java的,但是根据前面收集到的信息显然是不合理的,结合后面一些遇到的URI,推测这是一种以.
来分割的路由书写格式。微课上传
资源上传
文章发布
相册上传
视频上传
话题发布、回复、点赞、删除
私信功能
关注、取消关注功能
个人资料修改、头像修改、隐私设置功能
安全设置中的邮箱、手机绑定功能
UserName
这个变量,因为后端会对UserNumb
这个字段进行校验,因此需要知道受害者的UserNumb
这个字段是多少,但是其他功能点并不一定有该限制。BurpSuite
的CSRF
构造功能生成相应的CSRF
页面:CSRF
的方式除了对请求的主动性进行验证之外,还有就是附加数据(cookie
)是否设置了httponly
属性来禁止跨域。cookie
EDUSSO
就设置了httponly
属性来禁止跨域,不过这里还是有csrf漏洞。get
、post
、options
三种http
的请求头,此处我们利用BurpSuite
的功能修改请求方式由post
至get
,再生成csrf
的poc
。微课上传
资源发布
话题删除
私信
关注、取消关注
个人资料修改、隐私设置功能
安全设置中的邮箱、手机绑定功能
视频上传功能
不过这个视频上传功能处的CSRF利用局限性较大,需要知道视频专辑处随机生成的唯一识别ID才能够上传至指定的专辑。
post
方式修改为了get
方式之后就绕过了httponly
限制的原理,这里标记一下,后面需要了解一下httponly
的实现原理。httponly
的限制之外还手动添加了token
字段来验证请求的主动
性。GET
方式的请求无法成功,其中TypeID
为文章分类的ID识别发送人的是SESSION
因此CSRF以及越权都没有此类漏洞。MyArticle.Post.data
尝试修改其中的Post
为Get
再发送请求,但请求失败证明了后台没有相关功能,不能通过Get
请求来发布文章。AddTime
参数能控制前台显示的时间,但是时间格式有严格限制,无法实现存储型XSS。id
的方式来确定修改的文章编号:POST
传递参数,通过SESSION
来确定用户,因此并且通过服务器自动参数的ID来标识文章分类,因此这里不会有越权以及XSS。GET
方式来发送请求,继续测试是否存在CSRF漏洞。Post
及Get
方式参数数据,经过测试此处存在CSRF,但实现CSRF还需要知道分类ID,限制较大。Get
方式发送请求,同样不支持通过修改ID来删除其他人的分类、删除系统分类。fileName[]
这个属性的值会被展示在前台的DOM树当中且无过滤,故此处存在XSS漏洞:console.log("b1ak2")
来进行JS脚本运行判断,修改请求包相关字段如下:Get
方式,经过测试此处同样存在CSRF漏洞。采用相同的方式,通过GET请求来完成CSRF,不过这次的功能点会弹出文件下载请求:HTTP
代码如下:Get
方式传递http
请求故同样存在csrf
漏洞,但伪造难度过大。http
请求包如下:imgList
属性值来达到修改显示名称的作用,且该段数据可以插入到DOM树当中,但是对双引号有一定限制措施,尝试了一下之后没有找到有效的利用方式,不在这个功能点上死磕了。categoryId
来确定要上传的相册位置,替换为他人的相册ID之后服务端会报错,故此处并不存在越权漏洞,此处也支持Get
方式传递数据故CSRF漏洞同样存在。Get
方式发送请求,故此处不像之前一样有CSRF漏洞Name
属性的值会出现在DOM树当中,同样可以通过修改来达到存储型XSS的目的,但是对这里有长度限制,不过这里出里共会在DOM当中出现3次,可以依靠这个来实现绕过也说不一定。Get
方式发送请求,CSRF漏洞无望,数据包情况如下:Get
形式传递请求则同样存在CSRF漏洞。而修改至他人ID后服务器端处理出错,也不存在逻辑漏洞。CategoryName
与PicURL
两参数均存在存储型XSS,修改相应参数即可。不过PicURL
会判断双引号是否成对出现,不过采用1"><script>alert(1)</script><"
类似的格式来绕过即可Get
方式传递http请求故存在CSRF漏洞。Session
即无法测试相关的越权漏洞。CategoryID
来确定相册的,本身功能页面是和创建相册相同的,相同漏洞此处不重复测试。CategoryID
来定位到其他用户的相册,故相册编辑功能处存在逻辑越权漏洞。CategoryID
来定位相册的,可以通过Get
方式发送http请求,推测此处同样存在CSRF漏洞,经测试确实存在。Get
方式传递http请求,经测试存在CSRF漏洞。CategoryID
来识别的,同样存在越权逻辑漏洞。CategoryID
来识别的,将该ID修改为他人相册后可以成功访问,此处存在水平越权逻辑漏洞。http
请求如下:<>
之前的全部内容,暂未想到有什么好的利用方法。SESSION
故无CSRF及越权漏洞。SESSION
且存在token对请求的唯一性进行验证:token
对请求唯一性进行验证,同时删除他人回复会进行权限检测:Get
方式传输http请求,同样存在CSRF漏洞。Get
方式传递http请求,故此处存在CSRF漏洞。Get
方式发送请求,故此处同样存在CSRF漏洞。而发送者由SESSIOIN
来确定,无法伪造发送人。SESSION
,故也不存在越权漏洞keyword
,对该参数使用fuzz
排查之后并未发现有特殊的回显,故判断此处没有SQL注入漏洞。UserName
这个字段删去之后数据库会返回如下错误信息:Get
方式发送http请求,也就造成了逻辑漏洞。两者配合即可在验证码有效期内修改受害人绑定的手机、邮箱账号。文章来源:http://www.b1ak2.xyz/
作者:b1ak2
如有侵权,请联系删除
推荐阅读