扯谈web安全之JSON

  • 时间:
  • 浏览:2

为宜插入了只有 另另三个<script>标签:

其他同学提出另另三个JSON-P的规范,倘若貌似目前都只有 浏览器有支持这人 的。

原理是对于JSONP请求,浏览器还还可以 要求服务器返回的MIME是"application/json-p",曾经还还可以 严格校验否有 合法的JSON数据。

实际上对callback函数名字进行严格检验还有其它的另另三个好处,倘若防范了太满太满UTF-7编码攻击。

另外,我认为有另外四种 生活数据泄露的是导致 分析:黑客是导致 分析控制了某个路由,他只有随意抓包,倘若他还还可以 在签署头里插入太满太满有点硬的头部,比如:

https://github.com/douglascrockford/JSON-js

IE把只有 声明返回Content-Type的请求当做了"text/html"类型的,倘若解析全部都是问题报告 了。

于是,就执行了XSS。

http://www.thespanner.co.uk/2011/05/80/json-hijacking/

第四种 生活办法,利用字符串拼接:

		String user = "test01";
		String password = "12345', admin:'true";
		String json = "{user:'%s', password:'%s'}";
		System.out.println(String.format(json, user, password));
		//{user:'test01', password:'12345', admin:'true'}

只有 callback函数的名字,怎样才能过滤?

同域情况汇报下会,不同域情况汇报下不必。是导致 分析服务器设置Access-Control-Allow-Credentials: true ,也是还还可以 跨域带Cookie的。

浏览器会执行直接执行这人 JS函数。

实际上,即使服务器不允许CORS,XMLHttpRequest请求实际上是发送出去,倘若返回数据的了,倘若浏览器只有 让JS环境拿到而已。

我太满太满人认为,这人 方案也很蛋疼,一是还可以 服务器配置,二是协议冗杂。浏览器是导致 分析只有选泽否有 还可以 跨域调用,还可以 先进行另另三个Preflight Request。。

第一,操作否有 用户太满太满人提交的,而全部都是别的网页用<script>标签,是导致 分析用<form>提交的 太满太满要检查request的refer,是导致 分析验证token。这人 实际是CSRF防护的范畴,倘若很容易被忽略。

CORS还还可以 发起GET/POST请求,不像JSONP,只有发起GET请求。

jsonp在使用的刚刚,还有容易犯的错误是只有 验证用户的身份。

JSON(JavaScript Object Notation),还还可以 说是事实的浏览器,服务器交换数据的标准了。目测其它的格式如XML,是导致 分析其它自定义的格式会只有 少。

为那此JSON只有 流行?

和JavaScript无缝对接是另另三个导致 分析。

还有另另三个重要导致 分析是还还可以 比较轻松的实现跨域。是导致 分析是XML,是导致 分析其它专有格式,则真难实现跨域,要通过flash类似于来实现。

结合这人 ,当利用<script>标签请求内部的另另三个JSON API时,是导致 分析返回的是数组型,就还还可以 利用窃取数据。

JSON hijacking

在JS里还还可以 为对象定义太满太满setter函数,曾经语录就居于了还还可以 利用的漏洞。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

http://www.w3.org/TR/cors/

太满太满说,一定要难证来源。判断refer,验证用户的身份。

正则是导致 分析真难,还还可以 写另另三个函数来判断:

是导致 分析UTF-7编码的头部全部都是含高特殊字符的,如"+/v8","+/v9",曾经就过滤掉非法编码的请求了。

第二,要验证用户的权限。 太满太满刚刚,是导致 分析倘若验证了用户否有 登录 。却只有 仔细判断用户否有 有权限。

有曾经的另另三个jsonp调用接口:

http://jipiao.taobao.com/hotel/remote/livesearch.do?callback=%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg

url decoder刚刚是:

http://jipiao.taobao.com/hotel/remote/livesearch.do?callback=+/v8 +ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg

是导致 分析jsonp调用是直接返回callback包装的数据,太满太满实际上,后边的请求直接返回的是:

+/v8 +ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-(调用结果数据)

IE做了UTF-7解码刚刚数据是曾经子的:

太满太满,是导致 分析在callback函数的名字上做点手脚,还还可以 执行任意的JS代码。太满太满说callback名字一定要严格过滤。 当然,callback函数的名字通常是线程太满太满人控制的,倘若只有排除有其它被利用的是导致 分析。

会很神奇地弹出另另三个alert窗口,说明亲戚亲戚亲戚亲戚朋友定义的setter函数起作用了。

FastJSON的另另三个StackOverflowError Bug:

到乌云上搜索,还还可以 找到不少类似于的漏洞,全部都是是导致 分析只有 严格验证用户的权限。

https://github.com/alibaba/fastjson/issues/76

太满太满JSON库解析库支持循环引用,只有 否有 还还可以 构造有点硬的数据,导致 分析其解析失败?从而引起CPU使用过高 ,拒绝服务等问题报告 ?

这人 实际上倘若JSON注入,简单的字符串拼接,是导致 分析会引发各种数据被修改的问题报告 。

http://www.test.com/friends

比如有曾经的另另三个API:

http://www.json.org/

现在的浏览器都是导致 分析修复了,还还可以 下载另另三个Firefox3.0版曾经测试下。目前的浏览器在解析JSON Array字符串的刚刚,不再去触发setter函数了。但对于object.xxx 曾经的设置,还是会触发。

会。

有的刚刚,是导致 分析是为了方便,其他同学会手动拼接下JSON,倘若这人 随手代码,却是导致 分析带来意想只有的安全隐患。

在攻击页面上插入以下的代码,就还还可以 获取到用户的所有的亲戚亲戚亲戚朋友的信息。

太满太满说,太满手动拼接JSON字符串

浏览器端应该怎样才能处置JSON数据?

像eval这人 办法,自然是只有采用的。

现在的浏览器都提供了原生的办法 JSON.parse(str) 来转换为JS对象。

是导致 分析是IE8刚刚的浏览器,要使用这人 库来解析:https://github.com/douglascrockford/JSON-js

参考:http://zh.wikipedia.org/wiki/JSON#.E5.AE.89.E5.85.A8.E6.80.A7.E5.95.8F.E9.A1.8C

JQuery里内置了JSON解析库

jquery自动把?转成了另另三个带时间戳有点硬的函数(处置缓存):

这人 漏洞也曾经很流行。利用的是老版的IE还还可以 解析utf-7编码的字符串是导致 分析文件,绕过服务器的过滤。举个乌云上的例子:http://www.wooyun.org/bugs/wooyun-2011-01293

默认情况汇报下,CORS请求是不带cookie的。

比如jquery是曾经子实现的:

这人 漏洞在前几年很流行,比如qq邮箱的另另三个漏洞:http://www.wooyun.org/bugs/wooyun-2010-046

http://stackoverflow.com/questions/188080/why-same-origin-policy-for-xmlhttprequest

比如在浏览器的JS Console里执行:

http://toolswebtop.com/      在线编码转换,还还可以 转换UTF-7    

返回的数据是JSON Array:

服务器返回的数据是曾经子的:

JSON格式设置为:"application/json"

JavaScript设置为:"application/x-javascript"

JavaScript还有太满太满设置为:"text/javascript"等,全部都是不规范的。

原理是通过服务器端设置允许跨域调用,倘若浏览器就允许XMLHttpRequest跨域调用了。

尽管设置刚刚调试有点硬麻烦,倘若却大大提高了安全性。

,用正则来匹配应该是曾经子的:

为了处置跨域调用的安全性问题报告 ,目前实际上可用的方案是CORS:

只有 ,这时XMLHttpRequest请求倘若带cookie的了。

另外用IFrame也是还还可以 的。倘若我在IE8上测试,url的后缀需倘若html才会触发。

回到最初的问题报告 :

用户增加了管理员权限。

http://www.freebuf.com/articles/web/10672.html

第二种,利用Parameter pollution, 类似于http parameter pollution

		String string = "{user:'test01',password:'hello', password:'world'}";
		JSONObject parse = JSON.parseObject(string);
		String password = parse.getString("password");
		System.out.println(password);
		//world
当JSON数据key重复了会为什么处置?大帕累托图JSON解析库全部都是后边的参数覆盖了前面的。

下面的演示了修改别人密码的例子:

比如通过JSONP请求修改了别的用户的数据。



任何四种 生活数据格式,怎样才能解析处置不当,时会居于安全漏洞。下面扯谈下JSON相关的太满太满安全东东。

在介绍刚刚,先来提几次问题报告 :

会。

太满太满JSON库解析有问题报告 :

http://www.slideshare.net/wurbanski/nosql-no-security

用js在document上插入另另三个<script>标签,标签的src指向远程服务器的API地址。客户端和服务器约定另另三个回调函数的名字,倘若服务器返回回调函数寄国际包裹 着的数据,倘若浏览器执行回调函数,取得数据。

http://www.thespanner.co.uk/809/11/23/bypassing-csp-for-fun-no-profit/

即使XMLHttpRequest是不带Cookie的,也是有是导致 分析造成数据泄露的。比如内部网站是根据IP限制访问的,是导致 分析XMLHttpRequest不遵守同源策略,只有 攻击者还还可以 在用户浏览网页的刚刚,发起请求,取得内部网站数据。