程序对用户的请求没有进行权限验证或限制不足，导致用户可跨域访问、越权访问。
1. Flash跨域访问
1.1. 漏洞描述
flash跨域通信，依据的是crossdomain.xml文件。该文件配置在服务端，一般为根目录下，限制了flash是否可以跨域获取数据以及允许从什么地方跨域获取数据。
举个例子：
1. www.a.com域下不存在crossdomain.xml文件，则不允许除了www.a.com域之外的其他任何域下的flash进行跨域请求。
2. www.a.com域下存在crossdomain.xml文件，如若配置 allow-access-from 为www.b.com，则只允许www.b.com域下的flash进行跨域请求，以及来自自身域www.a.com的网络请求。crossdomain.xml需严格遵守XML语法，有且仅有一个根节点cross-domain-policy，且不包含任何属性。在此根节点下只能包含如下的子节点：
site-control
allow-access-from
allow-access-from-identity
allow-http-request-headers-from
如果crossdomain.xml文件配置allow-access-from为*，将允许任何域下的flash进行跨域请求。
1.2. 漏洞成因
没有限制跨域请求来源
1.3. 风险评估
攻击者可获取用户敏感信息
漏洞风险等级：建议中
1.4. 测试方法
下面列举一个具体的利用场景：
http://www.xxx.com/crossdomain.xml，文件内容如下图所示：
利用开源的FlashHTTPRequest，下载地址：
https://github.com/mandatoryprogrammer/FlashHTTPRequest，FlashHTTPRequest，使用方法参考README。
在本地服务器编写一个HTML页面，嵌入FlashHTTPRequest.swf，此页面的目的是获取受害者的账号设置页面：http://www.xxx.com/user-setting，源代码如下：
|
<!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <script undefined></script> <script> var res=""; function setres(data){ //将返回结果打印至页面中 window.res=data; //console.log(data); document.write(data); } function onhook() { FlashHTTPRequest.open('GET', 'http://www.xxx.com/user-setting', '', 'setres' ); } </script> </head> <body> <div id="flashBridge"></div> </body> </html> |
登录该网站后，访问构造好的HTML页面：
http://127.0.0.1/crossdomain/index.html，页面内容是该网站的账号设置页面，如下图所示：
由此也可以构造CSRF攻击……
1.5. 加固方法
限制跨域请求来源，即设置allow-access-from的值，只允许可信域的flash跨域请求。
2. jsonp跨域请求
2.1. 漏洞描述
当某网站通过 JSONP 的方式来传递用户认证后的敏感信息时，攻击者通过构造恶意的 JSONP 调用页面，诱导被攻击者访问来达到截取用户敏感信息的目的。
2.2. 漏洞成因
1．Referer过滤不严谨；
2．空Referer(在通过跨协议调用JS时，发送的http请求里的Referer为空)；
3．CSRF调用json文件方式不安全，token可重复利用；
4．JSON输出的Content-Type及编码不符合标准(gb2312可能存在宽字节注入)；
5．未严格过滤callback函数名及JSON里数据的输出；
6．未严格限制JSONP输出callback函数名的长度。
2.3. 风险评估
攻击者可利用该漏洞结合社会工程学，诱导用户点击某个精心构造的页面，从而达到窃取用户敏感信息的目的。
漏洞风险等级：建议为中
2.4. 测试方法
1. 一个典型的 JSON劫持攻击代码：
<script>
function test(v){
alert(v.username);
}
</script>
<script undefined></script>
当被攻击者在登陆www.xxx.com网站的情况下访问了该网页时，那么用户的隐私数据（如用户名，邮箱等）可能被攻击者劫持。
2. JSONP具体实现
·远程服务器remoteserver.com根目录下有个remote.js文件代码
·本地服务器localserver.com下有个jsonp.html页面代码
·在jsonp.html页面定义一个函数，然后在远程remote.js中传入数据进行调用
·运行之后查看结果，页面成功弹出提示窗口，显示本地函数被跨域的远程js调用成功，并且还接收到了远程js带来的数据。
·只要服务端提供的js脚本是动态生成的，这样调用者可以传一个参数过去告诉服务端 “我想要一段调用XXX函数的js代码，请你返回给我”，于是服务器就可以按照客户端的需求来生成js脚本并响应。
2.5. 加固方法
建议从以下几个方面进行防御：
1．严格安全的实现CSRF方式调用JSON文件：限制Referer、部署一次性Token等。
2．严格安装JSON格式标准输出Content-Type及编码（Content-Type : application/json; charset=utf-8）。
3．严格过滤callback函数名及JSON里数据的输出。
4．严格限制对JSONP输出callback函数名的长度。
5．在callback输出之前加入其他字符(如：/**/、回车换行)这样既不影响JSON文件加载，又能一定程度预防其他文件格式的输出。
3. CORS跨域请求
3.1. 漏洞描述
CORS（Cross-Origin Resource Sharing 跨来源资源共享）,CORS允许浏览器向跨域服务器发出XmlHttpRequest请求，CORS与JSONP的区别：是JSONP的升级版，JSONP只能通过get方式请求，CORS支持get和post请求。
3.2. 漏洞成因
服务端配置的规则不当所导致的，如：
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Allow-Methods: PUT,POST,GET,DELETE,OPTIONS
这个响应头表示访问允许，*表示所有的请求源的所有形式的请求，都被允许访问数据，这样也就造成了一个跨域读取敏感信息的漏洞。
3.3. 风险评估
攻击者可利用该漏洞结合社会工程学，诱导用户点击某个精心构造的页面，从而达到窃取用户敏感信息的目的。
漏洞风险等级：建议为中
3.4. 测试方法
CORS的漏洞主要看当我们发起的请求中带有Origin头部字段时，服务器的返回包带有CORS的相关字段并且允许Origin的域访问。
一般测试WEB漏洞都会用上BurpSuite，而BurpSuite可以实现帮助我们检测这个漏洞。
首先是自动在HTTP请求包中加上Origin的头部字段，打开BurpSuite，选择Proxy模块中的Options选项，找到Match and Replace这一栏，勾选Request header 将空替换为Origin:foo.example.org的Enable框。
然后我们就可以在开启Burpsuite的情况下访问我们认为有漏洞的网站，访问足够多后在BurpSuite的Proxy模块下的HTTP history来筛选带有CORS头部的值
筛选条件可以设置成：
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
3.5. 加固方法
1．关闭CORS
2．定义“源”的白名单。；
3．仅允许安全的协议，验证协议以确保不允许来自不安全通道（HTTP）的交互；
4．尽可能的返回”Vary: Origin”这个头部；
5．避免使用“Credentials”头；
6．限制使用的方法；
7．限制缓存的时间；
8．仅配置所需要的头；
4. 未授权访问(Web)
4.1. 漏洞描述
未授权访问漏洞，是在攻击者没有获取到登录权限或未授权的情况下，或者不需要输入密码，即可通过直接输入网站控制台主页面地址，或者不允许查看的链接便可进行访问，同时进行操作。
4.2. 漏洞成因
未对用户操作进行权限限制及合法性验证
4.3. 风险评估
攻击者猜测管理后台地址或利用已知的访问地址，尝试在未登录的情况下直接访问，常见的后台登录地址有：admin.jsp、index.jsp、main.jsp、left.jsp、right.jsp、top.jsp等。攻击者进入管理后台后可修改Web应用程序设置，利用后台对上传文件过滤不严的缺陷，上传webshell等实施恶意操作。
漏洞风险等级：建议高
4.4. 测试方法
1. 通过对登录后的页面进行抓包，将抓取到的功能链接，在其他浏览器进行打开。
2. 也可以通过web扫描工具进行扫描，爬虫得到相关地址链接，进行直接访问，如果未进行跳转到登录页面，则可判断为存在未授权访问漏洞。
3. 弱口令
4.5. 加固方法
常见的修复方法：在系统中，加入用户身份认证机制或者tonken验证，防止可被直接通过连接就可访问到用户的功能进行操作，简而言之，一定对系统重要功能点增加权限控制，对用户操作进行合法性验证，下列为针对常见的JSP语言编写的网站的安全修复方案：
采用JAVA过滤器技术，对/pages下所有URL进行登录状态检查，通过session.getAttribute()方法从session中获取登录成功时存入session中的身份标识，判断客户端传递过来的身份标识是否与session中保存的一致，不一致则跳转到登录页面。关键代码如下：
|
//从session里取的用户名信息 String username = (String) session.getAttribute("userID"); //getAttribute中变量根据实际变量传入。 //判断如果没有取到用户信息,就跳转到登陆页面 if ((username == null) || "".equals(username)) { //跳转到登陆页面 res.sendRedirect("http://" + req.getHeader("Host") +"/login_oa.jsp");} else { //已经登陆,继续此次请求 chain.doFilter(req, res); }} |
进行限判断，以下代码为过滤器程序，通过会话获取用户身份信息，进权限判断等操作：
|
//在配置文件中设置过滤器 <filter> <filter-name>SessionFilter</filter-name> <filter-class>com.nsfocus.frame.filter.SessionFilter</filter-class> </filter> <filter-mapping> <filter-name>SessionFilter</filter-name> <url-pattern>/pages/*</url-pattern> </filter-mapping> <filter> ---------------------------------------------------------------------------------------------- //后台过滤程序 public void doFilter(ServletRequest request, ServletResponse response,FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse res = (HttpServletResponse) response; HttpSession session = req.getSession(true); //从session里取的用户名信息 String username = (String) session.getAttribute("userID"); //getAttribute中变量根据实际变量传入。 //判断如果没有取到用户信息,就跳转到登陆页面 if ((username == null) || "".equals(username)) { //跳转到登陆页面 res.sendRedirect("http://" + req.getHeader("Host") +"/login_oa.jsp");} else { //已经登陆,继续此次请求 chain.doFilter(req, res); } } public void destroy() { } } |
资源分享--书籍分享
原文始发于微信公众号（LSCteam）：权限缺失
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论