• 计算机网络(6): http cookie


    Cookie作用:

    1)帮助管理用户会话信息(用户需要记录的信息:登陆状态等)

    2)跟踪浏览器的行为

    3)用户自定义设置

    实现方式:

    当用户浏览带有Cookie的网站时,网站自动为其生成一个唯一的标志符号,并且在后端数据库里以其为索引添加一项(这样就能记录用户信息了),用户收到这个信息后,在之后请求阶段都带上这个头部!官方描述如下:

    当服务器收到HTTP请求时,服务器可以在响应头里面添加一个Set-Cookie选项。浏览器收到响应后通常会保存下Cookie,之后对该服务器每一次请求中都通过Cookie请求头部将Cookie信息发送给服务器。另外,Cookie的过期时间、域、路径、有效期、适用站点都可以根据需要来指定

    过期时间: 

    会话期Cookie

    是最简单的Cookie:浏览器关闭之后它会被自动删除,也就是说它仅在会话期内有效。会话期Cookie不需要指定过期时间(Expires)或者有效期(Max-Age)。需要注意的是,有些浏览器提供了会话恢复功能,这种情况下即使关闭了浏览器,会话期Cookie也会被保留下来,就好像浏览器从来没有关闭一样。

    持久性Cookie

    和关闭浏览器便失效的会话期Cookie不同,持久性Cookie可以指定一个特定的过期时间(Expires)或有效期(Max-Age)。

    域:

    Domain 和 Path 标识定义了Cookie的作用域:即Cookie应该发送给哪些URL。

    Domain 标识指定了哪些主机可以接受Cookie。如果不指定,默认为当前文档的主机不包含子域名)。如果指定了Domain,则一般包含子域名。

    例如,如果设置 Domain=mozilla.org,则Cookie也包含在子域名中(如developer.mozilla.org)。

    Path 标识指定了主机下的哪些路径可以接受Cookie(该URL路径必须存在于请求URL中)。以字符 %x2F ("/") 作为路径分隔符,子路径也会被匹配。

    例如,设置 Path=/docs,则以下地址都会匹配:

    • /docs
    • /docs/Web/
    • /docs/Web/HTTP

    是否可以link其他站点:

    SameSite Cookie允许服务器要求某个cookie在跨站请求时不会被发送,从而可以阻止跨站请求伪造攻击(CSRF)。

    SameSite cookies是相对较新的一个字段,所有主流浏览器都已经得到支持

    下面是例子:

    Set-Cookie: key=value; SameSite=Strict

    SameSite可以有下面三种值:

    None

    浏览器会在同站请求、跨站请求下继续发送cookies,不区分大小写。

    Strict

    浏览器将只发送相同站点请求的cookie(即当前网页URL与请求目标URL完全一致)。如果请求来自与当前location的URL不同的URL,则不包括标记为Strict属性的cookie。

    Lax

    在新版本浏览器中,为默认选项,Same-site cookies 将会为一些跨站子请求保留,如图片加载或者frames的调用,但只有当用户从外部站点导航到URL时才会发送。如link链接

     

    其他:

    1. 安全问题

    会话劫持和XSS

    在Web应用中,Cookie常用来标记用户或授权会话。因此,如果Web应用的Cookie被窃取,可能导致授权用户的会话受到攻击。常用的窃取Cookie的方法有利用社会工程学攻击和利用应用程序漏洞进行XSS攻击。(跨站脚本攻击(Cross Site Script为了区别于CSS简称为XSS)指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意用户的特殊目的。)

    如:

    攻击者想拥有留言系统中后台管理员的权限,只要截取添加管理员账号时的HTTP请求信息,然后使用XML HTTP对象在后台发送一个HTTP请求即可。

    怎么截取添加后台管理员账号的请求消息呢?这个不是抓包获取,是在正常添加用户时XSS代码中用 xmlhttp对象发送一个POST请求,由于该请求带上了被攻击者的Cookie并一同发送到服务端,所以能在后台悄悄地添加一个管理员账户

    添加管理员请求的POST数据:UserName=12345&password=1234

    XSS Shellcode:

    var params ="UserName=xss&password=1234";

    xmlhttp.send(params);

    跨站请求伪造(CSRF)

    在不安全聊天室或论坛上的一张图片,它实际上是一个给你银行服务器发送提现的请求:

    <img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

    当你打开含有了这张图片的HTML页面时,如果你之前已经登录了你的银行帐号并且Cookie仍然有效(还没有其它验证步骤),你银行里的钱很可能会被自动转走。有一些方法可以阻止此类事件的发生:

    • 对用户输入进行过滤来阻止XSS
    • 任何敏感操作都需要确认;
    • 用于敏感信息的Cookie只能拥有较短的生命周期;

    2. 隐私问题

    第三方Cookie
    每个Cookie都会有与之关联的域(Domain),如果Cookie的域和页面的域相同,那么我们称这个Cookie为第一方Cookiefirst-party cookie),如果Cookie的域和页面的域不同,则称之为第三方Cookiethird-party cookie.)。一个页面包含图片或存放在其他域上的资源(如图片广告)时,第一方的Cookie也只会发送给设置它们的服务器。通过第三方组件发送的第三方Cookie主要用于广告和网络追踪。这方面可以看谷歌使用的Cookie类型(types of cookies used by Google)。大多数浏览器默认都允许第三方Cookie,但是可以通过附加组件来阻止第三方Cookie(如EFFPrivacy Badger)。

    PS:

    唯一的标志符号:uuid怎么生成?

    UUID是128位的全局唯一标识符,通常由32字节的字符串表示。它可以保证时间和空间的唯一性,也称为GUID,全称为:UUID —— Universally Unique IDentifier,Python 中叫 UUID。
    它通过MAC地址、时间戳、命名空间、随机数、伪随机数来保证生成ID的唯一性。
    UUID主要有五个算法,也就是五种方法来实现。

        • uuid1()——基于时间戳。由MAC地址、当前时间戳、随机数生成。可以保证全球范围内的唯一性,但MAC的使用同时带来安全性问题,局域网中可以使用IP来代替MAC。
        • uuid3()——基于名字的MD5散列值。通过计算名字和命名空间的MD5散列值得到,保证了同一命名空间中不同名字的唯一性,和不同命名空间的唯一性,但同一命名空间的同一名字生成相同的uuid。 
        • uuid4()——基于随机数。由伪随机数得到,有一定的重复概率,该概率可以计算出来。
        • uuid5()——基于名字的SHA-1散列值。算法与uuid3相同,不同的是使用 Secure Hash Algorithm 1 算法。

    最近对cookie有了更深的理解,特此批注:

    Cookie和Session

    不要混淆 session 和 session 实现。

    本来 session 是一个抽象概念,开发者为了实现中断和继续等操作,将 user agent 和 server 之间一对一的交互,抽象为“会话”,进而衍生出“会话状态”,也就是 session 的概念。

    而 cookie 是一个实际存在的东西,http 协议中定义在 header 中的字段。可以认为是 session 的一种后端无状态实现。

    而我们今天常说的 “session”,是为了绕开 cookie 的各种限制,通常借助 cookie 本身和后端存储实现的,一种更高级的会话状态实现。

    所以 cookie 和 session,你可以认为是同一层次的概念,也可以认为是不同层次的概念。具体到实现,session 因为 session id 的存在,通常要借助 cookie 实现,但这并非必要,只能说是通用性较好的一种实现方案。


    链接:https://www.zhihu.com/question/19786827/answer/84540780

    CSRF攻击是什么

    CSRF是跨站请求伪造的缩写,也被称为XSRF, 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。
    跟跨网站脚本(XSS)相比,XSS利用的是用户对指定网站的信任,CSRF利用的是网站对用户网页浏览器的信任。
    因为CSRF攻击利用的是冲着浏览器分不清发起请求是不是真正的用户本人。,也就是说,简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。

     

    CSRF攻击基本原理

    CSRF是跨站请求伪造的缩写,也被称为XSRF, 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。
    跟跨网站脚本(XSS)相比,XSS利用的是用户对指定网站的信任,CSRF利用的是网站对用户网页浏览器的信任。
    因为CSRF攻击利用的是冲着浏览器分不清发起请求是不是真正的用户本人。,也就是说,简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。

    最简单的CSRF攻击

    1. 用户Alice登录和访问某银行网站A,保留cookie
    2. Alice被某些信息诱导访问危险网站B。
    3. 危险网站B上有一个<img>标签:<img src="http://www.examplebank.com/account=Alice&amount=1000&payfor=Badman" >
    4. 这个标签的src不指向一张图片,而是一个http请求,这个请求向银行要求将Alice的1000元转给Badman,由于Alice的浏览器上有cookie,这样浏览器发出的这个请求就能得到响应执行。
    5. 这样Alice的钱就被偷了。
    链接:https://zhuanlan.zhihu.com/p/37293032

    作者:PPPPPython
    链接:https://zhuanlan.zhihu.com/p/37295186
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    XSS攻击

     

    XSS攻击是什么

    • XSS是跨站脚本攻击的缩写,是一种网站应用程序的安全漏洞攻击,是代码注入的一种。
    • 通常是通过利用网页开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。
    • 这些恶意网页程序通常是JavaScript,但实际上也可以包括Java,VBScript,ActiveX,Flash或者甚至是普通的HTML。
    • 攻击成功后,攻击者可能得到更高的权限(如执行一些操作)、私密网页内容、会话和cookie等各种内容。

     

    XSS攻击基本原理——代码注入

    在web的世界里有各种各样的语言,于是乎对于语句的解析大家各不相同,有一些语句在一种语言里是合法的,但是在另外一种语言里是非法的。这种二义性使得黑客可以用代码注入的方式进行攻击——将恶意代码注入合法代码里隐藏起来,再诱发恶意代码,从而进行各种各样的非法活动。只要破坏跨层协议的数据/指令的构造,我们就能攻击。
    历史悠久的SQL注入XSS注入都是这种攻击方式的典范。现如今,随着参数化查询的普及,我们已经离SQL注入很远了。但是,历史同样悠久的XSS却没有远离我们。
    XSS的基本实现思路很简单——比如持久型XSS通过一些正常的站内交互途径,例如发布评论,提交含有JavaScript的内容文本。这时服务器端如果没有过滤或转义掉这些脚本,作为内容发布到了页面上,其他用户访问这个页面的时候就会运行这些脚本,从而被攻击。

     
     

    参考:
    rfc文档:https://github.com/renaesop/blog/issues/4

    官方文档:https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Cookies

    XSS和会话劫持:https://www.cnblogs.com/dolphinX/p/3391351.html

    python uuid:https://www.cnblogs.com/loveapple/p/9445507.html

  • 相关阅读:
    Codeforces Round #590 D. Distinct Characters Queries
    线段树模板加模板题POJ3468
    hihoCoder挑战赛5 C 与链
    HDU 5044 Tree 树链剖分
    HYSBZ 1901 Dynamic Rankings 树状数组套主席树
    POJ 2761 Feed the dogs 主席树
    POJ 2104 K-th Number 主席树 区间第K大
    HDU 4547 CD操作 LCA
    POJ 1470 Closest Common Ancestors 离线LCA
    HYSBZ 1036 树的统计Count 树链剖分 线段树
  • 原文地址:https://www.cnblogs.com/Plorde/p/12308228.html
走看看 - 开发者的网上家园