zoukankan      html  css  js  c++  java
  • web安全防范策略

    一、XSS跨站脚本攻击

      1、XSS攻击有两大步骤:

        (1)、攻击者提交恶意代码

        (2)、浏览器执行恶意代码

      2、XSS攻击的分类

        根据攻击的来源,XSS攻击可以分为存储型、反射型、DOM型三种:

    类型存储区*插入点*防范措施
    存储型 XSS 后端数据库 HTML

    1、纯前端渲染,把代码和数据分割开

    2、对html充分转义

    反射型 XSS URL HTML
    DOM 型 XSS 后端数据库/前端存储/URL 前端 JavaScript

    1、避免使用.innerHTML.outerHTMLdocument.write()等方法

    2、DOM 中的内联事件监听器(locationonclickonerroronloadonmouseove等)、

    <a> 标签的 href 属性,JavaScript 的 eval()setTimeout()setInterval() 等,

    都可以把字符串作为代码运行,使用的时候需要注意

     

     

     

      存储型 XSS

      存储型 XSS 的攻击步骤:

    1. 攻击者将恶意代码提交到目标网站的数据库中。
    2. 用户打开目标网站时,网站服务端将恶意代码从数据库取出,拼接在 HTML 中返回给浏览器。
    3. 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

      这种攻击常见于带有用户保存数据的网站功能,如论坛发帖、商品评论、用户私信等。

      反射型 XSS

      反射型 XSS 的攻击步骤:

    1. 攻击者构造出特殊的 URL,其中包含恶意代码。
    2. 用户打开带有恶意代码的 URL 时,网站服务端将恶意代码从 URL 中取出,拼接在 HTML 中返回给浏览器。
    3. 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

      反射型 XSS 跟存储型 XSS 的区别是:存储型 XSS 的恶意代码存在数据库里,反射型 XSS 的恶意代码存在 URL 里。

      反射型 XSS 漏洞常见于通过 URL 传递参数的功能,如网站搜索、跳转等。

      由于需要用户主动打开恶意的 URL 才能生效,攻击者往往会结合多种手段诱导用户点击。

      POST 的内容也可以触发反射型 XSS,只不过其触发条件比较苛刻(需要构造表单提交页面,并引导用户点击),所以非常少见。

      DOM 型 XSS

      DOM 型 XSS 的攻击步骤:

    1. 攻击者构造出特殊的 URL,其中包含恶意代码。
    2. 用户打开带有恶意代码的 URL。
    3. 用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

      DOM 型 XSS 跟前两种 XSS 的区别:DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞。

      其它的防范策略:

        避免加载外域代码、禁止外域提交、HTTP-only Cookie、验证码、输入长度控制、表单数据指定具体类型等

    二、CSRF(Cross-site request forgery)跨站请求伪造

      一个典型的CSRF攻击有着如下的流程:

    • 受害者登录a.com,并保留了登录凭证(Cookie)。
    • 攻击者引诱受害者访问了b.com。
    • b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会默认携带a.com的Cookie。
    • a.com接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求。
    • a.com以受害者的名义执行了act=xx。
    • 攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让a.com执行了自己定义的操作。

      1、常见的攻击类型:

        (1)、get请求:例如利用图片发起一次http请求,会携带cookie

        

    <img style="0;" src="https://www.test.com/xxx" />

        (2)、post请求:例如利用隐藏表单自动提交

        

    <form action="https://www.test.com/xxx" method=POST>
        <input type="hidden" name="account" value="xiaoming" />
        <input type="hidden" name="amount" value="10000" />
    </form>
    <script> document.forms[0].submit(); </script> 

        (3)、url攻击:需要诱导用户手动点击

        

    <a href="https://www.test.com/xxx" taget="_blank">
      一刀9999级,神级装备,顶级神宠,开服就有!!
    <a/>

      2、特点

    • 攻击一般发起在第三方网站,而不是被攻击的网站。被攻击的网站无法防止攻击发生。
    • 攻击利用受害者在被攻击网站的登录凭证,冒充受害者提交操作;而不是直接窃取数据。
    • 整个过程攻击者并不能获取到受害者的登录凭证,仅仅是“冒用”。
    • 跨站请求可以用各种方式:图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中,难以进行追踪。

      3、防护策略

        根据csrf的特点: 

    • CSRF(通常)发生在第三方域名。
    • CSRF攻击者不能获取到Cookie等信息,只是使用。

      制订防护策略:

    • 阻止不明外域的访问
      • 同源检测
      • Samesite Cookie
    • 提交时要求附加本域才能获取的信息
      • CSRF Token
      • 双重Cookie验证
      • 验证码

        

      同源检测:根据请求的Origin和Referer,阻止外域请求或白名单以外的请求,html请求除外

      Samesite Cookie:设置cookie属性:Strict 除了本域外任何外域都无法携带,页面跳转也不会携带;Lax:这个请求是(改变了当前页面或者打开了新页面)且同时是个GET请求,则携带;Samesite Cookie不支持子域。

      Token:请求携带随机token, 这个token一定得是随机的,让攻击者猜不到。可以是服务器生成的随机数、也可以是随机字符串、时间戳、userid加密生成的签名

      双重Cookie验证:请求自己携带cookie的同时,在请求参数上也拼接cookie,服务器进行对比。(csrf攻击可以携带cookie,但是无法获取cookie),但是子域可以修改cookie,所以攻击者可以通过子域修改cookie,使得双Cookie验证失效

      验证码:在关键位置使用验证码或类似支付密码的方式

      其它一些防范措施:

    • 严格管理所有的上传接口,防止任何预期之外的上传内容(例如HTML)。
    • 添加Header X-Content-Type-Options: nosniff 防止黑客上传HTML内容的资源(例如图片)被解析为网页。
    • 对于用户上传的图片,进行转存或者校验。不要直接使用用户填写的图片链接。
    • 当前用户打开其他用户填写的链接时,需告知风险(这也是很多论坛不允许直接在内容中发布外域链接的原因之一,不仅仅是为了用户留存,也有安全考虑)

      

     

  • 相关阅读:
    my read map subway / metro / map / ditie / gaotie / traffic / jiaotong
    hd printer lexmark / dazifuyin / dayin / fuyin
    软件应用程序的打包和部署
    99款高质量免费(X)HTML/CSS模板
    PetShop4.0的安装、设置、调试与体验(草稿)
    山塞一个PetShop(Task000)——架构
    如何用C#开发的计算器小软件
    DIV+CSS布局参考站点
    影响计算机性能的设置
    ASP.NET知识点:母版页的路径问题
  • 原文地址:https://www.cnblogs.com/fqlGlog/p/11408486.html
Copyright © 2011-2022 走看看