cookie

1、 HTTP协议 Internet的基本协议是TCP/IP协议（传输控制协议和网际协议），目前广泛使用的FTP、HTTP（超文本传输协议）、Archie Gopher都是建立在TCP/IP上面的应用层协议，不同的协议对应不同的应用。而HTTP协议是Web应用所使用的主要协议。 HTTP协议是基于请求响应模式的。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户端信息和内容的类似MIME的消息结果。服务器则以一个状态行作为响应，相应的内容包括消息协议的版本、成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。 HTTP是无状态协议，依赖于瞬间或者近乎瞬间的请求处理。请求信息被立即发送，理想的情况是没有延时的进行敕处理，不过，延时还是客观存在的。HTTP有一种内置的机制，在消息的传递时间上由一定的灵活性：超时机制。一个超时就是客户机等待请求消息的返回信息的最长时间。 HTTP的请求和响应消息如果没有发送并传递成功的话，不保存任何已传递的信息。比如，单击“提交”按钮，如果表单没有发送出去，则浏览器将显示错误信息页，并且返回空白表单。虽然没有发送成功，但是HTTP不保存表单信息。 由于HTTP协议的上述特点，通常，客户端每次需要更新信息都必须重新向服务器发起请求，客户端收到服务器返回的信息后再更新屏幕内容。 基于HTTP协议的客户端

1.概念 session时服务器会话技术， 在一次会话 的多次请求间共享数据，将数据保存在服务端的对象HttpSession中，是一个域对象 2.使用 HttpSession接口中有几个方法： void setAttribute(String var1, Object var2); Object getAttribute(String var1); void removeAttribute(String var1); 以下是使用的具体过程： 输出结果为 hello session 在这里提一下req.getSession() HttpSession为一个接口，且没有任何实现类，获取session是通过request获取 来看一下request内的方法 HttpSession getSession ( ) ; 是一个空实现，我们再来打印一下session： org . apache . catalina . session . StandardSessionFacade @17e49b93 结果发现session对象的创建与request和response一样，是由tomcat内部创建 在这里列出getSession（）的用法： 有参：true或false true:HttpServletRequest.getSession(ture) :参数为true时，若存在会话，则返回该会话

date_default_timezone_set('PRC'); //时区 echo date('Y-m-d H:i:s',time()); // date('时间格式',时间戳()); //time时间戳 echo date('Y-m-d',strtotime(date('Y-m-d',time()-60*60*24))); //strtotime字符串转换时间戳 echo str_replace('-','月',date('m-d',time()-date('w',time()*86400))).'日'; // str_replace('查找的值','替换的值','被搜索的字符串'); 第一步：setcookie('ida','a') 因为cookie是设置在客户端的，setcookie函数自己并不能设置cookie，它只能通过头信息的方式告诉浏览器说：兄弟，我要设置一个cookie，键为ida，值为a，你在你那里帮我设置一下。 第二步：$_COOKIE['ida']$_COOKIE['ida'] 很简单，执行的操作就是在浏览器带过来的cookie字符串中搜索键为ida的cookie，并返回它的值。 很明显，这个”键为ida“的cookie不可能找到，因为客户端访问服务器的时候，这个cookie压根就不存在，而前面第一步设置cookie的头信息，也还没有返回给客户端

本篇继续对于安全性测试话题，结合DVWA进行研习。 Session Hijacking用户会话劫持 1. Session和Cookies 这篇严格来说是用户会话劫持诸多情况中的一种，通过会话标识规则来破解用户session。 而且与前几篇不同，我们有必要先来理解一下Session和Cookie的工作机制。 实际上要谈论这两个小伙伴，又要先理解http协议的运作机制，这样讨论下去可就篇幅太长了。 我们只需要了解以下事实： http协议是无状态的 就好像两个人用老式的手摇电话机通电话。每一次http请求和数据交换就像这样的一次电话通话过程，当请求完毕以后，再进行下一次请求时，http协议是无法追踪上一则通话记录的。这样每一次用户与服务器的交互都是独立的一次通话，对于一个web应用而言显然是存在问题的，因为用户的请求十有八九具有连续性。就比如一个用户在商城添加了某商品到购物车，当他去结账时，又是一次新的请求，他的购物车http协议仅仅通过连接状态是无法追踪的！ Session：来来来 给你分配个号码牌 为了解决用户的接续访问问题，一个简单的想法就是，将每一次用户与服务器之间的持续通话做为一个“会话”存放在服务器端。 当用户第一次打call进来的时候，你先别说话，先给你个小牌牌，这个小牌牌就用来做为这次用户会话的跟踪。 在我们的应用内通常使用sessionID或者类似的形式进行记录。

一、CSRF介绍 伪造一个站点，在站点中伪造一个向其他站点的请求，在用户访问该站点时让用户执行 假设有如下URL能删除一篇文章： 攻击者在自己的域中构造一个页面： 内容为： 使用一个img标签，其地址指向了删除博客文章的链接 在用户访问该站点的时候，用户看到了一张无法显示的图片，并且用户删除了该文章 这个删除博客文章的请求，是攻击者伪造的，所以这种攻击就被叫做“跨站点请求伪造” 二、CSRF进阶 2.1 Cookie策略 Cookie分类： 1、Session Cookie：又称为临时Cookie，在浏览器关闭之后，就消失。保存在浏览器的内存空间 2、Thrid-party Cookie：又称为本地Cookie，在服务器设置该类Cookie时，会指定一个Expire时间，代表失效时间。保存在本地 IE默认禁止在<img><iframe><script><link>等标签中发送第三方Cookie，但Firefox会，所以上一节的攻击多半发生在Firefox之上。如果IE等需要攻击成功，还需要引诱用户访问目标网页得到Session Cookie 2.2 P3P头的副作用 如果网站返回给浏览器的HTTP头中包含有P3P头，即使是IE，也将允许浏览器发送第三方Cookie， 2.3 GET？POST？ 不一定只能通过<img><iframe><script>等发起get请求

CSRF即Cross Site Request Forgery（跨站点请求伪造）。 用户在客户端（浏览器）上任何一个操作如提交表单、点击超链接、或者是页面资源的显示都是向服务器发起请求 而得以实现的，所以攻击者往往都是可以通过模拟真实用户的请求来“代替”用户完成操作的。 例如A用户删除id为18的文章的请求地址为：www.eco.com/delete?id=18 那么攻击者可以构造一个html页面，页面中有这样一段代码： *** <img src="http://www.eco.com/delete?id=18" /> *** （当然，用户会看到一张无法显示的图片） 然后引导A用户去访问攻击者的这个html页面，A用户看到了这样一张无法显示的图片，然后回到自己的博客，一看， 自己的id为18的文章不翼而飞了，这，就是跨站点请求伪造。当然了，CSRF肯定不会这么轻易就能成功的，因为大多 数web项目都会对http请求设置一个过滤器，用来验证发出请求的用户身份，使得CSRF的实施变得麻烦起来。 1.浏览器的cookie策略 我应该不止一次地说过，用户注册之后，会设置一个cookie（token）返回给客户端（浏览器），用于之后请求的身份 验证。 浏览器所持有的cookie分为两种，一种是“Session Cookie”、一种是“Third-party Cookie

CSRF（Cross Site Request Forgery）跨站点请求伪造：攻击者诱使用户在访问 A 站点的时候点击一个掩盖了目的的链接，该链接能够在 B 站点执行某个操作，从而在用户不知情的情况下完成了一次对 B 站点的修改。 CSRF 实现 Cookie 策略 Cookie 分为 Session Cookie（临时 Cookie） 和 Third-party Cookie（本地 Cookie）。本地 Cookie 有失效时间，在失效时间内都可以使用。临时 Cookie 则在浏览器关闭后立即失效。CSRF 攻击过程中，用户浏览器将上传 Cookie 作为认证信息（无需认证的除外）。如果用户同时正在访问 B 站点，那么就有活跃的临时 Cookie 将被上传。然而，如果用户并未打开 B 站点，但存有未失效的本地 Cookie，根据流量器安全策略的不同（IE 默认禁止在<img>、<iframe>、<script>、<link>等标签中发送本地 Cookie，Firefox 默认允许发送本地 Cookie；默认会拦截本地 Cookie 的浏览器：IE 6/7/8，Safari；默认不拦截本地 Cookie 的浏览器：Firefox 2/3，Opera，Google Chrome，Android），本地 Cookie 可能被上传认证，导致攻击成功。【安全建议：及时清除浏览器数据

一、导读 本文大纲 读取 HTTP Cookie 设置 HTTP Cookie 读取所有 Cookie[] 为 Cookie 设置过期时间 Https 与 Cookie HttpOnly Cookie 删除 Cookie HTTP Cookie（也称为Web cookie，浏览器cookie）是服务器在用户浏览器中存储的小部分数据。服务器端应用程序在返回浏览器请求响应的时候设置cookie，浏览器存储cookie，并将它们在下一个请求一起发送的时候自动带回服务器端应用程序。 Cookies提供了一种在服务器和浏览器之间交换信息的方法，以管理会话（登录，购物车，游戏得分），记住用户首选项（主题，隐私策略接受）以及跟踪整个站点的用户行为。Cookies在一定程度上解放了服务器端的压力，因为将一部分数据放在浏览器端存储，所以这部分数据不能是涉及应用安全的数据。在本文中，我们将学习如何在Spring Boot应用程序中读取、设置和删除HTTP cookie。 二、读取HTTP Cookie Spring框架提供@CookieValue注释来获取HTTP cookie的值，此注解可直接用在控制器方法参数中。 @GetMapping("/") public String readCookie(@CookieValue(value = "username", defaultValue =

背景知识：Authentication和Authorization的区别： Authentication：用户认证，指的是验证用户的身份，例如你希望以小A的身份登录，那么应用程序需要通过用户名和密码确认你真的是小A。 Authorization：授权，指的是确认你的身份之后提供给你权限，例如用户小A可以修改数据，而用户小B只能阅读数据。 由于http协议是无状态的，每一次请求都无状态。当一个用户通过用户名和密码登录了之后，他的下一个请求不会携带任何状态，应用程序无法知道他的身份，那就必须重新认证。因此我们希望用户登录成功之后的每一次http请求，都能够保存他的登录状态。 目前主流的用户认证方法有基于token和基于session两种方式。 基于session的用户认证 基于session的认证流程如下： 用户输入其登录信息 服务器验证信息是否正确，并创建一个session，然后将其存储在数据库中 服务器为用户生成一个sessionId，将具有sesssionId的Cookie将放置在用户浏览器中 在后续请求中，会根据数据库验证sessionID，如果有效，则接受请求 一旦用户注销应用程序，会话将在客户端和服务器端都被销毁 基于token（令牌）的用户认证 最常用的是JSON Web Token（jwt）： 用户输入其登录信息 服务器验证信息是否正确，并返回已签名的token

CSRF（Cross-site request forgery） 跨站请求伪造，也被称为 One Click Attack 或者 Session Riding ，通常缩写为 CSRF 或 XSRF ，是一种对网站的恶意利用。尽管听起来像跨站脚本（ XSS ），但它与 XSS 非常不同， XSS 利用站点内的信任用户，而 CSRF 则通过伪装成受信任用户的请求来利用受信任的网站。与 XSS 攻击相比， CSRF 攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比 XSS 更具危险性。 CSRF 是一种依赖web浏览器的、被混淆过的代理人攻击（ deputy attack ）。 如何防御 使用POST请求时，确实避免了如img、script、iframe等标签自动发起GET请求的问题，但这并不能杜绝CSRF攻击的发生。一些恶意网站会通过表单的形式构造攻击请求 public final class CsrfFilter extends OncePerRequestFilter { public static final RequestMatcher DEFAULT_CSRF_MATCHER = new CsrfFilter.DefaultRequiresCsrfMatcher(); private final Log logger = LogFactory