不受信任的网站可以通过创建表单并将其发布到目标站点来构造伪造的 POST 请求。但是,此 POST 的原始内容将由浏览器编码为以下格式:
param1=value1¶m2=value2
不受信任的网站是否有可能构建包含任意原始内容的伪造 POST——例如字符串化的 JSON?
{param1: value1, param2: value2}
换句话说: 网站可以使浏览器向第三方域发布任意内容吗?
不受信任的网站可以通过创建表单并将其发布到目标站点来构造伪造的 POST 请求。但是,此 POST 的原始内容将由浏览器编码为以下格式:
param1=value1¶m2=value2
不受信任的网站是否有可能构建包含任意原始内容的伪造 POST——例如字符串化的 JSON?
{param1: value1, param2: value2}
换句话说: 网站可以使浏览器向第三方域发布任意内容吗?
HTML 表单请求的 POST 正文始终是application/x-www-form-urlencoded、multipart/form-data或text/plainenctype
,因为它们反映了属性的有效值。尤其text/plain
是可以用来形成有效的 JSON 数据。所以这里可以使用基于表单的 CSRF,但是,它需要服务器接受它为text/plain
.
此外,基于 XHR 的 CSRF 可以用作XMLHttpRequest API 允许发送任意 POST 数据。唯一剩下的障碍是同源策略:只有当两者具有相同的来源或您的服务器支持跨域请求共享并允许资源共享时,才能伪造此类有效的 POST 请求。
是的!POST 请求只不过是发送到 Web 服务器的特定格式的文本。您可以使用 IE 或 Chrome 开发人员工具查看每个请求的外观。
所以是的,您可以创建一个伪造的 POST 请求并更改您想要的任何内容,但是如果请求格式不正确,大多数 Web 服务器将拒绝它。
网站的客户端代码很难伪造这样的请求,但服务器端代码可以很容易地做到这一点。
由于您的网站无法判断请求是来自浏览器还是行为类似于浏览器的服务器,所以浏览器的限制是没有保护的。
您可以通过常规表单帖子创建有效的 JSON。这只是创造性地命名表单参数的问题。特别是,参数名称可以包含引号。
http://blog.opensecurityresearch.com/2012/02/json-csrf-with-parameter-padding.html
在纯 HTML 表单的情况下,是的,它将始终根据规范进行编码。但还有其他编码方案,例如 MIME multipart。还有 Javascript 和XMLHttpRequest的问题。仅在一种情况下特别提到了编码。这强烈暗示在其他情况下没有应用编码。