cookie

web安全问题 csrf <script> document.write(` <form name="commentForm" target="csrf" method="post" action="http://localhost:1521/post/addComment"> <input name="postId" type="hidden" value="13"> <textarea name="content">来自csrf</textarea> </form> ` ); var iframe = document.createElement('iframe'); iframe.name = 'csrf'; iframe.style.display = 'none'; document.body.appendChild(iframe); setTimeout(function(){ document.querySelector('[name=commentForm]').submit(); },1000) </script> <img src="http://localhost:1521/ajax/addComment?postId=13&content=123123"> <a href="http://localhost:1521/ajax/addComment

1. 两种跨站攻击：XSS：跨站脚本（Cross-site scripting） CSRF：跨站请求伪造（Cross-site request forgery） 2.XSS特点：是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本 1.盗取用户cookie,伪造用户身份 2.控制用户浏览器 3.结合浏览器及其插件漏洞，下载病毒木马到浏览者的计算机运行 4.衍生URL跳转漏洞 5.官网挂钓鱼网站 6.蠕虫攻击 3.CSRF：冒充用户之手，伪造请求 -->横向提权（修改个人数据）；纵向提权（添加用户）； 区别：XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实 现的 CSRF 称为 XSRF。 xss：跨站点攻击。xss攻击的主要目的是想办法获取目标攻击网站的cookie，因为有了cookie相当于有了session，有了这些信息就可以在任意能接进互联网的PC登陆该网站，并以其他人的身份登陆做破坏。预防措施防止下发界面显示html标签，把</>等符号转义。 csrf：跨站点伪装请求。csrf攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，类似于钓鱼

大家都知道，比如我们登录一个OA网站，看到的数据和同事的是有不同的，简单一想，是因为我们的登录账户不同，但是技术上是怎么实现的呢？ 尤其是login后，我们访问的都是同一个URL，为什么页面上展示的数据会不同呢？ 技术初探 最近小编亲自编写了一个web应用，终于略懂一二，和大家分享。 后台会根据请求所关联的用户去过滤数据 用户在浏览器中输入URL，后台根据URL匹配处理他的视图，返回属于该用户的数据。 为什么在浏览器中输入URL，后台程序能知道这次请求所关联的用户是谁？请看下一节，技术细探 技术细探（Cookie/Session机制详解） 会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。 详情推荐大家阅读：https://www.cnblogs.com/zhouhbing/p/4204132.html 这边提炼几个关键点： HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。 目前Cookie已经成为标准，所有的主流浏览器都支持Cookie。 Cookie实际上是一小段的文本信息。客户端请求服务器

郑重声明: 本文仅供学习使用,禁止用于非法用途,否则后果自负,如有侵权,烦请告知删除,谢谢合作! 开篇明义 本文针对 自主开发 的 抢票 脚本在抢票过程中常常遇到的 请求无效 等问题,简单分析了 12306 网站的前端加密算法,更准确的说,是探究 RAIL_DEVICEID 的生成过程. 因为该 cookie 值是抢票请求的 核心基础 ,没有它将无法正确发送请求,或者一段时间后就会到期失效需要重新获取,或者明明更改了浏览器用户代理(navigator.userAgent)标识却还是被限制访问… 因为它并不是真正的客户端标识,只是迷惑性战术,浏览器唯一标识其实是 RAIL_OkLJUJ 而它却被 12306 网站设计者 故意没有添加到 cookie ,因此造成了很强的欺骗性,编程真的是一门艺术! 你以为你的爬虫已经可以正常模仿浏览器,殊不知,只要没搞懂谁才是真正的浏览器标识,那么再怎么换马甲也 难逃造假事实 . 上图展示了 RAIL_OkLJUJ 的存在位置,可能是为了 兼容市面上绝大数浏览器 ,也可能是为了 联合各种前端缓存技术作为特征码 ,总是除了 cookie 之外, RAIL_OkLJUJ 存在于 Local Storage , Session Storage , IndexedDB 和 Web SQL 等. 值得注意的是,cookie 中 故意没有设置 RAIL

提出问题： Http 是一种无状态的协议，web 服务器本身不能识别那些请求是同一个浏览器发出的，浏览器每一次请求都是孤立的。 怎么实现购物车呢？某个用户从网站的登录页面登入后，再进入购物页面购物时，负责处理购物请求的服务器程序必须知道处理上-次请求的程序所得到的用户信息。 在 servlet 中，常用以下两种机制完成会话跟踪： Cookie session Cookie cookie机制采用的是在客户端保持HTTP状态信息的方案 Cookie是 在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中附带传送给浏览器的一个小文本文件 一旦WEB浏览器保存了某个Cookie ,那么它在以后每次访问该WEB服务器时都会在HTTP请求头中将这个Cookie回传给WEB服务器 底层的实现原理: WEB服务器通过在HTTP响应消息中增加Set-Cookie响应头字段将Cookie信息发送给浏览器,浏览器则通过在HTTP请求消息中增加Cookie请求头字段将Cookie回传给WEB服务器。 一个Cookie只能标识一种信息，它至少含有-一个标识该信息的名称( NAME )和设置值( VALUE ) 一个WEB站点可以给一个WEB浏览器发送多个Cookie，一个WEB浏览器也可以存储多个WEB站点提供的Cookie。 浏览器一般只允许存放300个Cookie

1.如果我们浏览器设置的安全级别较高，服务器与浏览器之间的cookie不能传输，则sessionID也就不能送到服务器或浏览器。 2.URL重写就是如果上述情况出现，则采用了备用方案，利用参数的形式将sessionID带回服务器： 　　response.encodeURL("...")：调用该方法当sessionID的cookie不存在或不能发送时，路径后面追加参数；如果cookie存在且可以发送服务器，就不需要后面跟参数了 3.request.getSession()这个方法首先会先判断cookie的sessionID，如果没有再去找参数为sessionID的参数； 来源： https://www.cnblogs.com/ibcdwx/p/12316484.html

今天使用Cookie时被摆了一道，忘记指定Cookie的存在时间导致Cookie的时效仅仅停留在了会话级别。 　这是API的原文： 　By default, -1 indicating the cookie will persist until browser shutdown. 但是同时也发现了Chrome查询Cookie的方法： 1.点击这个小锁，在我自己写的的页面则显示的时一个感叹号，位置一样； 2.点击以后就能看到使用的三个Cookie，在点一下就能看到详细的信息； so easy， 更加详细和高端的操作也请看这里： https://jingyan.baidu.com/article/37bce2be5c93961002f3a2fd.html 度娘有时候也挺靠谱的嘛！ 来源： https://www.cnblogs.com/YFEYI/p/12316499.html

1.servlet 1）servlet是什么： servlet是用来在客户端与服务端进行中转交互的地方，狭义的servlet是java编写的接口，通常我们说的都是继承了HttpServlet的类—>它实现接口里的方法；servlet的本质其实也是一个java bean，controller是对servlet的封装，底层依旧是servlet。（个人综合理解，要官方术语解释可百度） 2)servlet2.5 i:配置用web.xml iI:访问执行顺序 客服端请求访问===》通过url-patern找到对应servlet==》在找到<servlet-mappinp标签下的servlet-name==》锁定<servlet的servlet-name==>在根据它对应的类(继承了HttpServlet) >处理业务 》返回数据 3)servlet3.0 i:配置用注解@webServlet(“url-pattern值”) ii:路径分析： iii:生命周期 2.request 1)request常用方法 重要：请求转发 request.getRequestDispatcher(" ").forword(request,response); 3.response 重要：重定向 response.sendRedirect(" ") 1）常用方法： 2)请求转发 4.cookie 5

用户认证 用户认证流程分析 用户认证流程如下： 业务流程说明如下： 1、客户端请求认证服务进行认证。 2、认证服务认证通过向浏览器cookie写入token(身份令牌) 认证服务请求用户中心查询用户信息。 认证服务请求Spring Security申请令牌。 认证服务将token(身份令牌)和jwt令牌存储至redis中。 认证服务向cookie写入 token(身份令牌)。 3、前端携带token请求认证服务获取jwt令牌 前端获取到jwt令牌并存储在sessionStorage。 前端从jwt令牌中解析中用户信息并显示在页面。 4、前端携带cookie中的token身份令牌及jwt令牌访问资源服务 前端请求资源服务需要携带两个token，一个是cookie中的身份令牌，一个是http header中的jwt令牌 前端请求资源服务前在http header上添加jwt请求资源 5、网关校验token的合法性 用户请求必须携带 token身份令牌和jwt令牌 网关校验redis中token是否合法，已过期则要求用户重新登录 6、资源服务校验jwt的合法性并完成授权 资源服务校验jwt令牌，完成授权，拥有权限的方法正常执行，没有权限的方法将拒绝访问。 查询用户接口 Api接口 用户中心对外提供如下接口： 1、响应数据类型 此接口将来被用来查询用户信息及用户权限信息

54 HTTP-session 功能 ：解决HTTP中无状态的缺陷； 无状态 ： 服务器不知道客户端情况，于是认为每一次访问、请求都是一次全新的请求；比如对于需要登录的系统，登录系统之后的每一步操作，系统都认为是全新的操作，每次都要重新登录。而session 保存了客户端的登录状态，这样就不需要重复的多次登录。 工作机制 客户端访问服务器时，服务器分配SESSIONID，服务器记录登录信息，并将保存信息的文件SESSIONID 保存到服务器，之后服务器根据客户端的SESSIONID和本地记录的文件判断浏览器的登录状态。 Set-Cookie : SESSIONID = 32 位的16进制数字，= 16的32次方，重复的概率很低，可以当做唯一性标识； SESSION 是用来记录浏览器状态的，服务器会给访问的浏览器分配一个SESSIONID，之后会根据SESSIONID来识别浏览器； SESSIONID 保存在tmp文件中（以SESSIONID 命名的文件；服务器所在目录的tmp文件，不是浏览器本地的文件）；并且该文件记录了登录用户的信息； userID|s:1:"1" = 表示 userID 是string 格式，长度 = 1，= 1； 如果将“isLogin ” 的值 由 “true” 修改为“false”， 此时点击页面时，系统返回登录界面，要求重新登录； 注意： 输入网址的时候