2013-10-21 48 views
0

我需要处理使用Jekyll构建的静态网站的查询表单。防止使用查询表格的静态网站(即Jekyll网站)针对JSONP请求伪造JSONP请求

查询表单向另一个处理请求的域上的PHP应用程序提交JSONP请求(GET)。

是否可以防止CSRF,因为表单将是静态的?

我注意到了PHP Slim Framework的CSRF中间件只能保护POST,PUT & DELETE方法,而不是GET。

如果我在静态站点中创建脚本,那么每个页面上的表单加载的服务器请求的数据(cookie值,csrf标记以及字段值等)可以工作吗?

感谢您的时间对CSRF

+1

你想要保护什么?如果用户没有以任何方式进行身份验证,则提供CSRF保护没有任何好处。是这样吗? – SilverlightFox

+0

这是正确的,用户没有被认证。 – Globalz

+1

没有必要保护CSRF,因为表单在当前用户的上下文中没有获得任何东西 - 如果攻击者想要在您的网站上提交表单,则不需要“跨站点”。他们只会提交它。听起来好像你在使用CAPTCHA来防止机器人提交表单(如果这就是你真正的追求?)。 – SilverlightFox

回答

1

因为表单在当前用户的上下文中没有获得任何东西 - 因此,如果攻击者想在您的网站上提交表单,则不需要“跨站点“......他们只会提交它。

听起来好像你是在CAPTCHA之后,以阻止机器人提交表单(如果这是你真的以后?)。

1

防御取决于从哪个发送请求的页面,并在服务器上,它被送到同意的用户的唯一标识符。

由于表单是静态的,所以不能在表单中放置该唯一标识符。

如果我在静态网站中有一个脚本构建每个页面上的表单加载与服务器请求的数据(cookie值,csrf标记以及字段值等)可以工作吗?

只有当它是服务器端脚本(所以表单不会是静态的),否则任何站点都可以包含它以获取令牌。


我注意到了PHP框架修身的CSRF中间件只能从POST保护,PUT & DELETE方法,而不是GET。

这是因为GET requests shouldn't be doing anything in the first place,所以(除非你滥用它们),不需要对它们应用CSRF保护。

特别是,该惯例已经确定,GET和HEAD方法不应该具有采取除检索以外的行为的意义。这些方法应该被认为是“安全的”。这允许用户代理以一种特殊的方式表示其他方法,例如POST,PUT和DELETE,以便使用户意识到正在请求可能不安全的操作的事实。

+0

谢谢你。我现在认为CORS可能更好,因为它支持的不仅仅是GET请求,而不像JSONP – Globalz

+0

即使使用CORS,CSRF仍然是个问题。攻击只需要提出请求,它不需要将响应暴露给JS。 – Quentin

+0

很酷。我想通过一个简单的get jsonp请求提供服务器提供的csrf令牌的JavaScript编译表单,因为它只是检索。表单提交将向PHP应用发出CORS POST请求,以验证请求并采取必要措施,例如发送带有表单值的电子邮件 – Globalz