cookie

XSS与httponly 正常情况下，客户端脚本（如JS脚本）是可以通过document.cookie函数获得，这样如果有XSS跨站漏洞，cookie很容易被盗取。浏览器有一个安全策略，通过设置cookie的httponly属性，这样客户端脚本就不能通过document.cookie访问该cookie，即使有XSS漏洞，也不能盗取用户cookie。这个时候就可以利用HTTP TRACE方法来获取到用户的cookie信息。 TRACE方法 TRACE作用：客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在 最终将请求发送给服务器时，看看它变成了什么样子。 下面就来看下允许TRACE方法的服务器，TRACE方法是如何工作的。 请求包： TRACE http://10.20.40.95/bWAPP/bWAPP/xss_get.php?firstname=aaaa&lastname=aaa&form=submit HTTP/1.1 Host: 10.20.40.95 Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

常见web安全及防护原理 sql注入原理 就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令 总的来说有以下几点 永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等 永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取 永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接 不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息 XSS原理及防范 Xss(cross-site scripting)攻击指的是攻击者往Web页面里插入恶意html标签或者javascript代码。比如：攻击者在论坛中放一个看似安全的链接，骗取用户点击后，窃取cookie中的用户私密信息；或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户原本以为的信任站点 XSS防范方法 首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”’”等字符做过滤；其次任何内容写到页面之前都必须加以encode，避免不小心把html tag 弄出来。这一个层面做好，至少可以堵住超过一半的XSS 攻击 XSS与CSRF有什么区别吗？ XSS是获取信息

1.Cookie cookie是比较老的前端缓存技术了，它的特点是想要使用它前端必须要有服务（静态网页是不行的），而且存储大小限制在4kb。那么为什么必须要有服务才能使用cookie呢？因为只要有请求涉及cookie，cookie就要在服务器和浏览器之间来回传送，而且由于浏览器的跨域限制，客户端和服务端必须要保证同源的原则（也就是跨域问题，详情见我的其他文章），由于cookie是存放在前端的，所以安全问题一直是个大问题，因此一般重要的信息不建议放在cookie中存放。 2.Session 对于服务端的程序眼来说session大家肯定很熟悉了，session是一种服务端的机制，也就是能把信息存放在服务端，所以安全可以保障，它的原理是通过session id来识别客户端，这个session id是存放在cookie中的（当然session id让用户看见没无妨），服务端会通过session id来识别客户端进行匹配和判断。它和cookie对比起来差距就很明显了，一个是把数据存在客户端；一个存在服务端，从安全性考虑的话一般像用户名密码这种私密信息一般放在session中。 3.localStorage 它的特点就是“持久”，一旦通过保存，不通过手动清除的话，就会一直保存在前端，它的保存格式是键值对的方式也就是“key-value”的方式保存的，它的存储空间大小限制在500万字符左右

response:响应对象 提供的方法： void addCookie(Cookie cookie);服务端向客户端增加cookie对象 void sendRedirect(String location)throws IOException ;页面跳转的一种方式 void setContentType(String type):设置服务端响应的编码（设置服务端的content） 例如： 登录：login.jsp->check.jsp->success.jsp 请求转发 重定向 地址栏是否改变 不变（check.jsp） 改变（success.jsp） 是否保留第一次 保留 不保留 请求的数据 请求的次数 1 2 跳转发生的位置 服务端 客户端发出的第二次跳转 转发，重定向： 转发：张三（客户端）->A —>B（a内部找的） 重定向： 张三（客户端）->A —>去找B 张三（客户端）->B->结束 来源： CSDN 作者： 路远风 链接： https://blog.csdn.net/qq_43399648/article/details/96730769

expires属性 指 定了coolie的生存期，默认情况下coolie是暂时存在的，他们存储的值只在浏览器会话期间存在，当用户推出浏览器后这些值也会丢失，如果想让 cookie存在一段时间，就要为expires属性设置为未来的一个过期日期。现在已经被max-age属性所取代，max-age用秒来设置 cookie的生存期。p path属性 它指定与cookie关联在一起的网页。在默认的情况下cookie会与创建它的网页，该网页处于同一目录下的网页以及与这个网页所在目录下的子目录下的网页关联。 domain属性 domain属性可以使多个web服务器共享cookie。domain属性的默认值是创建cookie的网页所在服务器的主机名。不能将一个cookie的域设置成服务器所在的域之外的域。 例 如让位于order.example.com的服务器能够读取catalog.example.com设置的cookie值。如果 catalog.example.com的页面创建的cookie把自己的path属性设置为“/”，把domain属性设置成 “.example.com”，那么所有位于catalog.example.com的网页和所有位于orlders.example.com的网页，以 及位于example.com域的其他服务器上的网页都可以访问这个coolie。 secure属性

Model 到目前为止，当我们的程序涉及到数据库相关操作时，我们一般都会这么搞： 创建数据库，设计表结构和字段 使用 MySQLdb 来连接数据库，并编写数据访问层代码 业务逻辑层去调用数据访问层执行数据库操作 View Code django为使用一种新的方式，即：关系对象映射（Object Relational Mapping，简称ORM）。 　　PHP：activerecord 　　Java：Hibernate 　　C#：Entity Framework django中遵循 Code Frist 的原则，即：根据代码中定义的类来自动生成数据库表。 一、创建表 1、基本结构 1 2 3 4 5 6 from django.db import models class userinfo(models.Model): name = models.CharField(max_length = 30 ) email = models.EmailField() memo = models.TextField() 字段 参数 元信息 拓展知识 2、连表结构 一对多：models.ForeignKey(其他表) 多对多：models.ManyToManyField(其他表) 一对一：models.OneToOneField(其他表) 应用场景： 一对多：当一张表中创建一行数据时

设计思路 用户发出登录请求，带着用户名和密码到服务器经行验证，服务器验证成功就在后台生成一个token返回给客户端 客户端将token存储到cookie中，服务端将token存储到redis中，可以设置存储token的有效期。 后续客户端的每次请求资源都必须携带token，这里放在请求头中，服务端接收到请求首先校验是否携带token，以及token是否和redis中的匹配，若不存在或不匹配直接拦截返回错误信息（如未认证）。 token管理：生成、校验、解析、删除 token：这里使用userId_UUID的形式 有效期：使用Redis key有效期设置（每次操作完了都会更新延长有效时间） 销毁token：删除Redis中key为userId的内容 token存储：客户端（Cookie）、服务端（Redis） Cookie的存取操作（jquery.cookie插件） Redis存取（StringRedisTemplate） 实现 【Redis操作类】 package com.bpf.tokenAuth.utils; import java.util.concurrent.TimeUnit; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data

@WebServlet("/reply") public class ReplyServlet extends HttpServlet { @Override protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { //设置编码 req.setCharacterEncoding("UTF-8"); resp.setContentType("text/html;charset=UTF-8"); //创建session对象 HttpSession session = req.getSession(); List<Reply> list = (List<Reply>) session.getAttribute("list"); //判断session中有没有数据 有的话直接跳转 没的话查数据库 if (list==null){ //连接业务层 QuaryServiceImp quaryServiceImp = new QuaryServiceImp(); List<Reply> replies = quaryServiceImp.quaryAll(); session.setAttribute("list",

02-01 请求库之requests库 一 介绍 #介绍：使用requests可以模拟浏览器的请求，比起之前用到的urllib，requests模块的api更加便捷（本质就是封装了urllib3） #注意：requests库发送请求将网页内容下载下来以后，并不会执行js代码，这需要我们自己分析目标站点然后发起新的request请求 #安装：pip3 install requests #各种请求方式：常用的就是requests.get()和requests.post() >>> import requests >>> r = requests.get('https://api.github.com/events') >>> r = requests.post('http://httpbin.org/post', data = {'key':'value'}) >>> r = requests.put('http://httpbin.org/put', data = {'key':'value'}) >>> r = requests.delete('http://httpbin.org/delete') >>> r = requests.head('http://httpbin.org/get') >>> r = requests.options('http://httpbin.org

前言 前后端处理数据交互时往往会遇到跨域的问题,那么什么是跨域? 有哪些跨域方式? 出现跨域又该如何解决呢? 一、什么是跨域? 理解跨域首先要理解同源策略，它是浏览器对js施加的一种安全限制,如果缺少了同源策略，浏览器很容易受到XSS、CSFR、SQL注入等攻击。所谓同源是指协议、域名、端口必须相同。浏览器在请求数据时都要遵循同源策略，那么凡是发送请求的URL中协议、域名、端口三者之中的一点不同时，就叫做跨域。 而在同源策略当中,它所限制的内容就有以下几个: Cookie、LocalStorage、IndexedDB 等存储性内容 DOM 节点 AJAX 请求不能发送 但是以下三个标签是允许跨域加载资源的： img中的src属性: <img src=XXX> link标签的href属性: <link href=XXX> script的src属性: <script src=XXX> 常见的跨域场景上面的图表已经说了,在 协议 , 域名 , 端口号 三者中,倘若其中之一不相同都会导致跨域的现象. 在此特别说明的两点: 第一：如果是协议和端口造成的跨域问题“前台”是无能为力的。 第二：在跨域问题上，仅仅是通过“URL的首部”来识别而不会根据域名对应的IP地址是否相同来判断。“URL的首部”可以理解为“协议, 域名和端口必须匹配” 。 这里你或许有个疑问： 请求跨域了