Django之CSRF XSS原理解析【交互篇四】

上一篇:Django之模板HTML相关【交互篇三】点击跳转
目录篇:Django之前后端交互篇目录 点击跳转
下一篇:Django之Ajax【交互篇五】点击跳转

目录

  • CSRF
  • XSS

CSRF

Django之CSRF XSS原理解析【交互篇四】_第1张图片

CSRF原理:安全验证机制(跨域请求保护)
列子:假如A某在自己的电脑登录了一个招商银行的网站

1.我们再去点招商银行该网站的其他页面,是不需要继续登录的


2.服务端和客户端是一个短连接,也就是客户端发送请求以后,服务端回复了以后链接就断开了。可以这样理解,客户端发送了请求,服务端返回了数据,然后我们看到数据的时候,其实内部已经和服务器断开了,相当于客户端在服务端下载了数据,然后在自己的浏览器进行模板渲染。


3.然后我们再次点击渲染数据内的链接,那么等于重新发起一个请求,那么问题来了请问服务器是如何确定还是A某点击的?
解决这个问题,就是A某登录的时候,服务端生成一个session id,然后把session id返回给了客户端,客户端在把session id存到浏览器cookie里面去,每次A某的浏览器访问的时候其实已经发送了这个session id给服务端了,所以服务端能确认是A某,就无需A某在登录


4.此刻A某登录另外一个AV网站,该AV网站也有自身的session id 放到了A某浏览器的cookie里面 和招商网站的session id放在A某的cookie里的没任何关系。可以这样比喻:AV网站在客户端的浏览器创建了文件然后把session id放入这个文件,招商银行的同理,所以是两个网站的cookie是没关系的,


5.由于安全机制,两个cookie之间是隔离的,拿不到对方的cookie,浏览器是不允许的,如果av网站的cookie可以拿到招商的cookie拿就完蛋了,所以浏览器出了同源策略,


6.浏览器的同源策略:如果两个页面的协议,端口(如果有指定)和域名都相同,则两个页面具有相同的源。
简单来说:(域名和A某的cookie判断是否同源)也就是你访问AV 该网站,只能从AV该网站之前存放A某客户端的cookie拿到session id发送请求,而不能去拿招商cookie里面的session id(因为不同源)  

 
7都已经有同源策略了,为什么还需要CSRF?
    1)假如 A某进行转账请求:href=”icbc.com/transfer/account=A某,to=burgess,amount=1000” ---》招商网站
招商银行拿到了请求也验证了A某的session id,如果没问题就完成了转账

    2)假如一个高级X某黑客,想要进行高破坏.但是又拿不到A某的招商cookie怎么办,就开始想办法,
           -----1:截取请求url然后更改转账到自己名下?不可能银行使用的是HTTPS,用抓包软件是抓不到的,涉及到安全交易之类的网站都是加密的. 就算截获了也是乱码,现在不关是安全交易之类的网站连百度都使用了https
          -----2:X某知道了A某喜欢看AV网站,X某就建立了一个AV网站,X某知道A某会经常看他的AV网站,就在该AV网站的某个AV视频埋下木马(事件函数),就在A某打开该视频链接在线观看的时候,触发了木马事件函数(如是个a标签超级链接
该标签href=”icbc.com/transfer/account=A某,to=X某,amount=1000” )X某本身也是招行的客户,知道招行发送请求的格式。这个时候招商银行收到了请求,然后就进行了验证用户的session id(认为是合法的)验证就通过..然后钱就到了X某(注意这里是A某的浏览器点击发送的,所以是A某进行发送的)
其实X某的AV网站无非就是做了一个ajax链接而已,但是只要你点击就等同于你从你的浏览器发送了这个请求

所以怎么办?我们自己写网站的都知道,你是看不出的,一个按钮里面触发函数你是不知道了,
所以招行的服务器需要判定是不是从招行本身网站的页面发送这条请求的,而不是通过别人网站页面发送(这样就OK了)
这就出现了CSRF机制了

1.所以我们第一次登陆访问了招商银行的页面(get请求),那么招商银行生成一串值然后随着页面返回(相当于招商银行的页面多出了一个标签存放这一串值),那么如果你下一次发送post请求的时候,你必须带着该页面的这串值,一起提交否则无效

2.这次我们登录了黑客的AV网站,我们点击请求转账,黑客的网站页面是没有该串值的,所以请求是无效的
这串值就是csrf_token 我们可以理解成令牌或者口令(GET 获取数据  幂等请求(没涉及数据的修改))
form标签内添加 csrf_token
Django之CSRF XSS原理解析【交互篇四】_第2张图片

submit提交自动把csrf_token进行提交(无需任何操作,但是ajax就需要进行获取csrf_token进行提交)

ajax提交内添加csrf_token
方式1(获取csrf进行请求头发送)

    
    
    

方式2(前端添加一个自动函数,所有ajax提交之前都会执行该函数先进行提交csrf)

    
    
    

 

XSS

XSS:就是用户使用回复进行写标签造成攻击,但是这些默认都是不允许的,所以是小事(如,不停的弹框,或者严重的写标签偷偷的拿走了你的银行登录的cookie之类)

所以默认用户提交会字符串显示(失去标签作用)

但是虽然上面可以避免Xss攻击,但是有一些网站是需要用户自己写标签的(如:博客网站就可以让用户写标签)

Xss攻击(过滤的函数或类):
    博客网站,写标签格式提交的,服务器默认阻止,如:

老子的博客

最终显示也是以字符串形式显示,但是我们需要显示标签的效果出来,实现2种方法,1 前端:字符串|safe 表示允许该字符串为标签 2后台:mark_safe(字符串)、但是这也会出现问题,就是用户提供了javasacrip的talert,用户照样能看到,所以必须要求用户提交是安全的。解决:我们在页面输出没法做安全机制,只能在用户提交的时候做安全机制,把用户提交过来的数据进行过滤(如:设置一个白名单,只有什么标签的什么属性才可以通过验证),

Django定义字符串标签允许作为标签显示:

前端

 

后台

Django之CSRF XSS原理解析【交互篇四】_第3张图片

防止XSS攻击(如论坛回复使用标签字符串回复,这肯定不允许)
可过beautifulSoup4过滤标签(白名单机制)

上一篇:Django之模板HTML相关【交互篇三】点击跳转
目录篇:Django之前后端交互篇目录 点击跳转
下一篇:Django之Ajax【交互篇五】点击跳转

你可能感兴趣的:(Django)