再谈Web安全

2019年5月14日 180次阅读 来源: youkale

0x01

现今WEB安全主要面临的几个问题：

  • sql 注入
  • xss 跨站脚本
  • csrf 跨站域请求伪造

0x02

那么如何设计一个安全的站点呢？
我们先看看原理:
输入类：sql 注入 和 xss 跨站脚本，一个可能造成非法的数据库请求，一个可能造成非法的js引用，防范方法，我们只需要在用户输入时对其输入的内容在前后台进行校验或转意或使用参数化sql等手段

输入检测说明

那么什么是(CSRF)跨站伪造请求.呢？
举个例子：假如上面这个表单的页面地址是http://0x1024.com，黑阔想通过http://hack.com页面获取到你http://0x1024.com的用户信息或者使用你0x1024的cookie访问你的个人账户并转钱1000块.
伪造其实很简单，我举个栗子

![](http://0x1024.com/money?desc_user_id=hack&money=1000)

假如你恰好登录了0x1024，那么很有可能你的钱就莫名其妙少了1000块了。

想想是不是很可怕，有的朋友可能说使用post就安全一点了，我只能说呵呵了，假如黑阔使用iframe元素把你的表单内嵌到了hack.com呢？？
然后用某种方式诱导你填入用户名和密码，那么你的帐号同样还是被骗走了。

CSRF可以说是浏览器的一个特(que)性(xian), 那么Session这玩意那么容易被csrf，那么怎么防嘛，目前防御的方法有几种

  • 验证来源 Http请求中的Referer
  • Token
  • 隐藏表单 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>
  • 隐藏头部 <meta name=”csrf-token” content=”pa5chCM1n1″ />
在理想的情况下，客户端和服务端时间永远一致，那么可以考虑使用Google两部验证的思路来替代token

上面几招都是通过，这篇文章来的。CSRF 攻击的应对之道

但是这篇文章中少了个同源请求的问题,假如被人使用iframe把整个页面嵌入了呢？这种就是所谓的clickjacking,其实浏览器早就有这类的声明了。只需要在响应头里加入X-Frame-Options:SAMEORIGIN即可防范，下面是x-frame-options的说明

X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 <frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，也从而避免了点击劫持 (clickjacking) 的攻击。

想必大黑阔们对我这些招都已经是过眼云烟了。。。。

    原文作者：youkale
    原文地址: https://www.jianshu.com/p/6fcfd3fc2bb5
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞