csrf

跨站请求伪造（scrf）、设置scrf值、CBV加装饰器

阅读更多关于跨站请求伪造（scrf）、设置scrf值、CBV加装饰器

跨站请求伪造（scrf）听说过钓鱼网站吗？就类似于你搭建了一个跟银行一模一样的web页面用户在你的网站转账的时候输入用户名密码对方账户银行里面的钱确实少了但是发现收款人变了原理：你写的form表单中用户的用户名密码都会真实的提交给银行后台但是收款人的账户却不是用户填的你暴露给用户的是一个没有name属性的input框你自己提前写好了一个隐藏的带有name和value的input框解决钓鱼网站的策略: 只要是用户想要提交post请求的页面我在返回给用户的时候就提前设置好一个随机字符串当用户提交post请求的时候我会自动先取查找是否有该随机字符串如果有正常提交如果没有直接报403 所以！！那个被我们注释掉的中间件，就是用来校验你有没有这个随机字符串的。这就是django自带的东西，你可以理解为，这个中间件不允许的前端post请求，都不能通过这一层校验，要怎样让post请求成功呢，就要让他通过校验。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title> <script src="https://cdn.bootcss.com/jquery/3.4.1/jquery.min.js"></script> <link href=

第七章、中间件续写

阅读更多关于第七章、中间件续写

目录第七章、中间件续写一、中间件的执行顺序测试思路：自定义中间件代码二、跨站请求伪造三、csrf装饰器四、post请求提交数据通过 csrf 校验五、自我拷问分FBV和CBV 未注释掉 csrf 中间件时单功能取消 csrf 校验：csrf_exempt 注释掉 csrf 中间件时单功能开启 csrf 校验：csrf_protect 第七章、中间件续写一、中间件的执行顺序测试思路：在 settings.py 里注册不同中间件，探究默认的执行顺序在不同中间件的 process_request 和 process_response 等方法中 return HttpResponse 对象会对执行顺序造成什么影响了解五种方法的触发时机自定义中间件新建一个文件夹（放在全局或 app 内）写一个类继承 MiddlewareMiXin 类里面书写需要的（五个方法中的某些）方法一定要在 settings.py 里配置中间件注册代码 mymiddleware/mdd.py 自定义中间件 from django.utils.deprecation import MiddlewareMixin from django.shortcuts import HttpResponse class MyMdd(MiddlewareMixin): def process

阅读更多关于 csrf

CSRF（Cross Site Request Forgery, 跨站域请求伪造）是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一。跨站请求伪造（CSRF）与跨站请求脚本正好相反。跨站请求脚本的问题在于，客户端信任服务器端发送的数据。跨站请求伪造的问题在于，服务器信任来自客户端的数据。无CSRF时存在的隐患跨站请求伪造是指攻击者通过HTTP请求江数据传送到服务器，从而盗取回话的cookie。盗取回话cookie之后，攻击者不仅可以获取用户的信息，还可以修改该cookie关联的账户信息。来源：博客园作者： sasmen 链接：https://www.cnblogs.com/duhy/p/11657989.html

Django框架之中间件

阅读更多关于 Django框架之中间件

目录一、中间件介绍二、自定义中间件 2.1 process_request 2.2 process_response 2.3 process_view 2.4 process_exception 2.5 process_template_response（用的比较少）三、中间件的执行流程四、中间件的应用场景 4.1 中间件版登录验证五 CSRF_TOKEN跨站请求伪造 5.1 什么是csrf 5.2 csrf攻击原理 5.3 解决 5.4 csrf装饰器附：Django请求流程图一、中间件介绍官方的说法：中间件是一个用来处理Django的请求和响应的框架级别的钩子。它是一个轻量、低级别的插件系统，用于在全局范围内改变Django的输入和输出。每个中间件组件都负责做一些特定的功能。但是由于其影响的是全局，所以需要谨慎使用，使用不当会影响性能。中间件位于web服务端与url路由层之间说的直白一点中间件是帮助我们在视图函数执行之前和执行之后都可以做一些额外的操作，它本质上就是一个自定义类，类中定义了几个方法，Django框架会在请求的特定的时间去执行这些方法。我们一直都在使用中间件，只是没有注意到而已，打开Django项目的Settings.py文件，看到下图的MIDDLEWARE配置项，每一个配置项都对应着一个中间件。请求来的时候

中间件

阅读更多关于中间件

中间件如果涉及到全局的功能就应该考虑使用中间件关于中间件 django.middleware.csrf.CsrfViewMiddleware 这个中间件是解决跨站伪类请求而设置的在前端随机生成一个设置好的随机字符串,提交到我们的数据提交接口的时候就校验,有就提交,没有就403 跨扎伪类请求跨扎伪类请求,其实就是一个钓鱼网站原理搭建一个和转账网站一模一样的网站 form表单中action提交的地址提交到正规网站一样的地址设置一个暴露给用户的收款人的提交框提前隐藏一个收款人的提交框,默认是自己的账户,就是有name和value的input框用户一旦输入,只有用户名和密码是有效的,收款人是无效的,默认的收款人是我们自己,但是提交的接口是有效的,所以转账转到我们账户如何通过CsrfViewMiddleWare中间件 form表单提交只需要在写前端form表单的时候加上一个 {% csrf_token %} ajax如何校验第一种: 先写上 {% csrf_token %} ,在通过标签查找,放在data中传过去 $.ajax({ url:'', type:'post', data:{'name':'xc', 'csrfmiddlewaretoken': $('[name=csrfmiddlewaretoken]').val()} }) 第二种: 直接使用 {{

XSS、CSRF攻击与防范

阅读更多关于 XSS、CSRF攻击与防范

一、XSS攻击　　XSS攻击全称跨站脚本攻击，是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或者 JavaScript 进行一种攻击。攻击者编写脚本设下陷阱，用户在自己的浏览器上运行时，一不小心就会受到被动攻击。　　例子：如果A用户评论 [hello world] 提交到服务器，B用户看到这条评论的时候一切正常。但如果C用户评论 [<script>console.log(document.cookie)</script>]，那么当B用户访问这条评论所在的界面是，这串js代码就会在B用户的浏览器执行，输出cookie的值。这样就构成了XSS攻击。　　防范： 1）使用 XSS Filter 　　　　　　针对用户提交的数据，只接受规定的长度或内容的提交，过滤掉其他的输入类型。例如表单提交年龄只接受 int 类型，过滤掉特殊的HTML标签<script>等，过滤 JS 事件例如 onclick, onfocus等。　　　　　2）对HTML标签插入的不可信数据进行 HTML Entity 编码。　　　　　　　　　　　 3）JavaScript 编码将 \ 转成 \\，将/ 专程/\，将半角符号转成全角符号　　　　　　 4）HTTP Only Cookie 许多XSS攻击是为了得到用户的cookie信息，将重要的cookie信息标记为 http

Django之cookie与session、中间件

阅读更多关于 Django之cookie与session、中间件

目录 cookie与session 为什么会有cookie和session cookie 设置cookie 获取cookie 删除cookie 实例：cookie版登录校验 session 设置session 获取session 删除session session也可以设置超时时间实例：session版登录校验 django中间件应用场景自定义方法 django请求生命周期流程图中间件之前端操作跨站请求伪造(csrf) 钓鱼网站实例防钓鱼网站策略 CBV加装饰器 csrf_exempt 两种装饰方式其他装饰器三种装饰方式每日面试题 python2和python3的区别(至少写三个) 什么是可变，什么是不可变 m=10，n=5,互换值(至少两种方式) cookie与session 为什么会有cookie和session 由于HTTP协议是无状态的，无法记住用户是谁，这样我们在每一次登陆的时候，都要重新输入密码，甚至如果不设置cookie，网页可能都请求不了 cookie 保存在客户端浏览器上的键值对是服务端设置在客户端浏览器上的键值对，也就意味着浏览器其实可以拒绝服务端的命令。默认情况下，浏览器都是直接让服务端设置键值对的在操作开始之前我们需要对三板斧进行变形 obj1 = HttpResponse() return obj1 obj2 =

cookie与 session

阅读更多关于 cookie与 session

一、cookie and session HTTP协议是无状态的也就是说你每一次访问浏览器的话浏览器是不认识你的每一次访问都是独立的，浏览器是‘你虐他千百遍’ 转眼之间"他待你如初恋",他是不会受到前面请求响应情况直接影响，也不会直接影响后面的请求响应的情况，每一次请求都是全新的，对于状态这一词可以理解为客户端和服务端在某次回话中产生的数据，那么无状态就是这些数据不会保存。但是有些会话的数据我们又是需要保存的，也就是要 "保持状态"，因此Cookie就是这样诞生的 1. Cookie cookie具体指的就是一段小信息，他是服务器发出来储存在浏览器上的一组组键值对，下次访问服务器时浏览器会自动携带这些键值对，以便于服务器提取有用的信息其工作原理：有服务器产生内容，浏览器收到请求后保存在本地：当浏览器再次访问时，浏览器会自动带上Cookie，这样子服务器可以通过cookie中的内容来判断这是 "谁" 设置cookie obj = HttpResponse() obj.set_cookie() 获取cookie #第一种 request.COOKIES['key'] #不推荐使用 #第二章 request.COOKIE.get() 删除cookie def logout(request): rep = rediect('/login/') rep.delete

Django-7

阅读更多关于 Django-7

目录 Django-7 Cookie 由来简介原理查看cookie Django中操作cookie 获取cookie 设置cookie 删除cookie 使用cookie实现用户登录认证装饰器功能 session 由来设置session 获取session 删除session session设置超时时间 session版登录验证装饰器 Django中间件什么是中间件中间件的存放位置中间件中可以自定义的五个方法中间件的执行过程有了中间件的Django请求流程图跨站请求伪造(csrf) 钓鱼网站解决策略 CsrfViewMiddleware 局部使用csrfmiddleware中间件 Django-7 Cookie 由来由于http协议是无状态的，每次请求都是独立的，当用户访问浏览器网页时，并不会记录登录状态，所以，对服务器来说，你的每次请求都是全新的。简介那么，为了保存用户的登录状态以及信息，就有了cookie，cookie具体指的是一段小信息，他是服务器大宋出来存储在浏览器上的一组组键值对，下次访问服务器时浏览器会自动携带这些键值对，以便服务器提取有用的信息。原理由服务器产生内容，浏览器收到请求后保存在本地，当浏览器再次访问时，浏览器会自动带上cookie，这样服务器就能通过cookie的内容判断当前用户信息了。查看cookie

django

阅读更多关于 django

目录 1. cookie与session 1.1 cookie 1.2 session 2. django中间件 3. 跨站请求伪造(csrf) 3.1 form表单 3.2 ajax 3.3 CBV中加装饰器相关 1. cookie与session # 为什么会有cookie和session? # 由于http协议是无状态的无法记住用户是谁 # django必会三板斧 return HttpResponse() return render() return redirect() # 变形： obj1 = HttpResponse() return obj1 obj2 = render() return obj2 obj3 = redirect() return obj3 1.1 cookie ''' cookie是保存在客户端浏览器上的键值对是服务端设置在客户端浏览器上的键值对也就意味着浏览器其实可以拒绝服务端的"命令" 默认情况下浏览器都是直接让服务端设置键值对设置cookie obj.set_cookie() 获取cookie request.COOKIES.get() 删除cookie obj.delete_cookie() ''' # 登录功能: 用户登录成功之后一定要保存用户状态 def login(request): # print(request

订阅 csrf