cookie

客户端第一次请求服务器 服务端会产生一个session对象（用户保存该客户的信息）; 每个session对象都会有一个唯一的sessionID(用户区分其他session); 服务端会又会产生一个cookie，并且该cookie的name=JSESSIONID,value=服务端sessionID的值； 然后服务端会在响应客户端的同时将该cookie发送给客户端； 至此，客户端就有了一个cookie(JSESSIONID)； 客户端的cookie和服务端的session一一对应 ： （JSESSIONID - sessionID) ** 客户端第二次/n此访问服务器 服务端会先用客户端cookie中的JSESSIONID 去服务端的session中匹配sessionid, 如果匹配成功（cookie jsessionid和sessionid ）,说明此用户不是第一次访问，无需登录 总结: 第一次 客户请求时 产生一个sessionid 并复制给cookie 的jsessionid 然后 发跟踪客户端。 最终 通过session的sessionid-cookie的jsessionid 扩展 session常用方法： getId ( ) : //获取sessionId bolean isNew ( ) ; //判断是否是 新用户（第一次访问） void invalitate ( ) :

WEB端缓存机制 什么是WEB缓存 Web缓存是指一个Web资源（如html页面，图片，js，数据等）存在于Web服务器和客户端（浏览器）之间的副本。缓存会根据进来的请求保存输出内容的副本；当下一个请求来到的时候，如果是相同的URL，缓存会根据缓存机制决定是直接使用副本响应访问请求，还是向源服务器再次发送请求。比较常见的就是浏览器会缓存访问过网站的网页，当再次访问这个URL地址的时候，如果网页没有更新，就不会再次下载网页，而是直接使用本地缓存的网页。只有当网站明确标识资源已经更新，浏览器才会再次下载网页 数据库数据缓存 数据库数据缓存的实质就是将频繁使用的数据从数据库（硬盘）存到内存中，而内存的读取速度远远快于直接在磁盘读取的速度。至于为什么会有明显的速度差异，浅显的理解是因为内存是电存储，硬盘存储是磁存储。电的速度远远大于磁盘（相当于磁带转动的速度）的速度。即使现在出现了固态硬盘但还仅仅只是在磁盘的基础上有所提高。 服务器端缓存 代理服务器缓存 代理服务器是浏览器和源服务器之间的中间服务器，浏览器先向这个中间服务器发起Web请求，经过处理后（比如权限验证，缓存匹配等），再将请求转发到源服务器。代理服务器缓存的运作原理跟浏览器的运作原理差不多，只是规模更大。可以把它理解为一个共享缓存，不只为一个用户服务，一般为大量用户提供服务，因此在减少相应时间和带宽使用方面很有效

点击下载 软件介绍 Chrome谷歌浏览器是目前使用人数、好评都比较高的一款浏览器了、深受用户的喜爱，追求的是全方位的快速体验，它不仅能飞快地从桌面上启动，而且能瞬间完成网页加载，还能以闪电般的速度运行网络应用。Chrome 浏览器整洁且直观，您可在同一位置进行搜索和导航，可随意排列标签页，既快捷又轻松。您不必成为安全专家即可放心地浏览网络。Chrome 默认会为用户提供安全保护，并可供所有人轻松且安全地使用。 版本更新 拦截Cookie文件 在此之前，谷歌浏览器一直允许所有Cookie文件不受限制地加载，无论创建Cookie的网站域和加载Cookie的网站如何。现在，在Chrome 80中，谷歌引入了全新的Cookie分类模型SameSite，该分类模型更加安全、更加严格。因此，只有HTTPS、且SameSite设置为None时才允许第三方调用Cookie。也就是说，该模型可大幅限制Cookie被第三方网站追踪个人数据，能更进一步保护用户隐私。如果你是非技术用户，那么这种变化很难引起你的注意，你只需要知道自己的隐私从此更加有保障即可。 关闭网站弹出窗口通知 在这次更新中，谷歌已经彻底解决了Chrome浏览器中的通知显示问题。现在，当网站发送通知权限提示时，横幅或者弹窗通知会更加安静的方式展现。在新版本中，网站一旦向用户发送通知，再也不会出现烦人的弹出窗口

一、flask session简介 flask中session组件可分为内置的session组件还有第三方flask-session组件，内置的session组件缺点： 功能单一 session是保存在浏览器中的cookie中，不安全， 大小有限制 而第三方插件flask-session可支持redis、memcached、文本等session的存储。 二、内置session处理机制 Cookie与Session 我们回顾一下cookie和session知识 Cookie Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。 Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie

这里主要讲的是CTF中linux下的ELF二进制文件的保护机制。在linux中有一个脚本checksec命令可以查看当前二进制文件的保护机制。任意安装一款gdb插件都会把checksec脚本包含进来。 在gdb中执行： gdb> checksec test Canary : No NX : Yes PIE : No Fortify : No RelRO : Partial 直接在shell中执行： $ checksec test Arch: i386-32-little RELRO: Partial RELRO Stack: No canary found NX: NX enabled PIE: No PIE (0x8048000) 可以看到checksec可以查看当前二进制文件的指令架构以及采取了哪些保护机制。 1.Canary（栈保护） 这个选项表示栈保护功能有没有开启。 栈溢出保护是一种缓冲区溢出攻击缓解手段，当函数存在缓冲区溢出攻击漏洞时，攻击者可以覆盖栈上的返回地址来让shellcode能够得到执行。当启用栈保护后，函数开始执行的时候会先往栈里插入cookie信息，当函数真正返回的时候会验证cookie信息是否合法，如果不合法就停止程序运行。攻击者在覆盖返回地址的时候往往也会将cookie信息给覆盖掉，导致栈保护检查失败而阻止shellcode的执行

之前已经介绍了SP2010中支持CSOM的API进行远程访问SharePoint，但是CSOM的API仍然有一定的局限性，首先使用CSOM类库是基于.Net的，因此也将使用CSOM限制在了.Net平台上(包括托管的.Net代码，Silver Light 以及Javascript)。如何能在非.Net平台上操作SharePoint数据呢？ 本文简单介绍一下SharePoint REST api的使用方式，笔者本人也没有用到过相关技术进行开发，难免有理解不到位的地方。欢迎大家拍砖。 读懂此文章，建议你至少大概的知道，什么是REST api，为什么使用REST api，它的优势在哪。本文不会展开讲述讲述REST相关的知识。 REST API架构 从SharePoint2013开始，REST被集成到了SharePoint中，你可以创建一个RESTful 的HttpWebRequest来访问SharePoint数据。REST的大体架构如下： 首先，通过用OData标准，创建一个符合你想要调用的Client Object Model的API所匹配的Http请求。SharePoint服务器端在通过client.svc处理HttpRequest后，会返回相应的Atom或者JSON。 如何生成一个RESTful的HttpRequest 在SharePoint的Client Object Model

requeses库 安装 pip install requests 中文文档：http://docs.python-requests.org/zh_CN/latest/index.html github地址：https://github.com/requests/requests import requests 发送get请求 最简单的发送get请求就是通过requests.get来调用 response = requests . get ( 'http://www.baidu.com/' ) response <Response [200]> 添加headers和查询参数 如果想添加 headers，可以传入headers参数来增加请求头中的headers信息。如果要将参数放在url中传递，可以利用 params 参数。相关示例代码如下 kw = { 'wd' : '中国' } headers = { "User-Agent" : "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36" } # params 接收一个字典或者字符串的查询参数，字典类型自动转换为url编码，不需要urlencode()

flask_session是flask框架实现session功能的一个插件，用来替代flask自带的session实现机制。 配置参数详解 SESSION_COOKIE_NAME 设置返回给客户端的cookie的名称，默认是“session”;放置在response的头部； SESSION_COOKIE_DOMAIN 设置会话的域，默认是当前的服务器，因为Session是一个全局的变量，可能应用在多个app中； SESSION_COOKIE_PATH 设置会话的路径，即哪些路由下应该设置cookie，如果不设置，那么默认为‘/’，所有的路由都会设置cookie； SESSION_COOKIE_HTTPONLY cookie应该和httponly标志一起设置，默认为True，这个一般采用默认。 SESSION_COOKIE_SECURE cookie是否和安全标志一起设置，默认为false，这个一般采用默认。 PERMANENT_SESSION_LIFETIME 设置session的有效期，即cookie的失效时间，单位是s。这个参数很重要，因为默认会话是永久性的。 SESSION_TYPE 设置session保存的位置，可以有多种配置， SESSION_TYPE = ‘null’ : 采用flask默认的保存在cookie中； SESSION_TYPE = ‘redis’ :

在前后端分离开发时为什么需要用户认证呢？原因是由于HTTP协定是不储存状态的(stateless)，这意味着当我们透过帐号密码验证一个使用者时，当下一个request请求时它就把刚刚的资料忘了。于是我们的程序就不知道谁是谁，就要再验证一次。所以为了保证系统安全，我们就需要验证用户否处于登录状态。 传统方式 前后端分离通过Restful API进行数据交互时，如何验证用户的登录信息及权限。在原来的项目中，使用的是最传统也是最简单的方式，前端登录，后端根据用户信息生成一个 token ，并保存这个 token 和对应的用户id到数据库或Session中，接着把 token 传给用户，存入浏览器 cookie，之后浏览器请求带上这个cookie，后端根据这个cookie值来查询用户，验证是否过期。 但这样做问题就很多，如果我们的页面出现了 XSS 漏洞，由于 cookie 可以被 JavaScript 读取，XSS 漏洞会导致用户 token 泄露，而作为后端识别用户的标识，cookie 的泄露意味着用户信息不再安全。尽管我们通过转义输出内容，使用 CDN 等可以尽量避免 XSS 注入，但谁也不能保证在大型的项目中不会出现这个问题。 在设置 cookie 的时候，其实你还可以设置 httpOnly 以及 secure 项。设置 httpOnly 后 cookie 将不能被 JS 读取

在前后端分离开发时为什么需要用户认证呢？原因是由于HTTP协定是不储存状态的(stateless)，这意味着当我们透过帐号密码验证一个使用者时，当下一个request请求时它就把刚刚的资料忘了。于是我们的程序就不知道谁是谁，就要再验证一次。所以为了保证系统安全，我们就需要验证用户否处于登录状态。 传统方式 前后端分离通过Restful API进行数据交互时，如何验证用户的登录信息及权限。在原来的项目中，使用的是最传统也是最简单的方式，前端登录，后端根据用户信息生成一个 token ，并保存这个 token 和对应的用户id到数据库或Session中，接着把 token 传给用户，存入浏览器 cookie，之后浏览器请求带上这个cookie，后端根据这个cookie值来查询用户，验证是否过期。 但这样做问题就很多，如果我们的页面出现了 XSS 漏洞，由于 cookie 可以被 JavaScript 读取，XSS 漏洞会导致用户 token 泄露，而作为后端识别用户的标识，cookie 的泄露意味着用户信息不再安全。尽管我们通过转义输出内容，使用 CDN 等可以尽量避免 XSS 注入，但谁也不能保证在大型的项目中不会出现这个问题。 在设置 cookie 的时候，其实你还可以设置 httpOnly 以及 secure 项。设置 httpOnly 后 cookie 将不能被 JS 读取