精华内容
下载资源
问答
  • web前端页面访问两种方式
    千次阅读
    2019-04-08 09:06:37

    有人会问了 同样是web前端的项目,为什么用模块化(ng、react、vue)开发的项目必须得tomcat、http-server等服务器才能正常访问呢?而普通的项目文件能直接访问。

    其实很简单,就是因为index文件引入的其他文件是绝对路径,注意是路径问题。

    因为vue-cli的默认配置中, publishPath是用绝对目录, 所以dist文件夹里的文件必须放在服务器的根目录。

    如果你想打包后的文件在本地运行,那么以下提供一种解决办法可尝试(解决办法很多)

    解决办法其中之一:只要把产出后的index.html文件资源路径前面的'/'去掉,就O了。

    更多相关内容
  • 页面跳转的两种方式区别及应用场景分析 转发重定向区别详解转发重定向的图解两种跳转获得对象的方式转发跳转的小结转发重定向的选择转发重定向的应用场景 转发重定向区别详解 1、request....

    转发和重定向区别详解

    1、request.getRequestDispatcher().forward()方法,只能将请求转发给同一个WEB应用中的组件;而response.sendRedirect() 方法不仅可以重定向到当前应用程序中的其他资源,还可以重定向到同一个站点上的其他应用程序中的资源,甚至是使用绝对URL重定向到其他站点的资源。

    如果传递给response.sendRedirect()方法的相对URL以“/”开头,它是相对于整个WEB站点的根目录;如果创建request.getRequestDispatcher()对象时指定的相对URL以“/”开头,它是相对于当前WEB应用程序的根目录。

    2、重定向访问过程结束后,浏览器地址栏中显示的URL会发生改变,由初始的URL地址变成重定向的目标URL;请求转发过程结束后,浏览器地址栏保持初始的URL地址不变。

    3、HttpServletResponse.sendRedirect方法对浏览器的请求直接作出响应,响应的结果就是告诉浏览器去重新发出对另外一个URL的访问请求,这个过程好比有个绰号叫“浏览器”的人写信找张三借钱,张三回信说没有钱,让“浏览器”去找李四借,并将李四现在的通信地址告诉给了“浏览器”。于是,“浏览器”又按张三提供通信地址给李四写信借钱,李四收到信后就把钱汇给了“浏览器”。

    由此可见,重定向的时候,“浏览器”一共发出了两封信和收到了两次回复,“浏览器”也知道他借到的钱出自李四之手。

    request.getRequestDispatcher().forward()方法在服务器端内部将请求转发给另外一个资源,浏览器只知道发出了请求并得到了响应结果,并不知道在服务器程序内部发生了转发行为。这个过程好比绰号叫“浏览器”的人写信找张三借钱,张三没有钱,于是张三找李四借了一些钱,甚至还可以加上自己的一些钱,然后再将这些钱汇给了“浏览器”。

    由此可见,转发的时候,“浏览器”只发 出了一封信和收到了一次回复,他只知道从张三那里借到了钱,并不知道有一部分钱出自李四之手。

    4、request.getRequestDispatcher().forward()方法的调用者与被调用者之间共享相同的request对象和response对象,它们属于同一个访问请求和响应过程;

    而response.sendRedirect()方法调用者与被调用者使用各自的request对象和response对象,它们属于两个独立的访问请求和响应过程。对于同一个WEB应用程序的内部资源之间的跳转,特别是跳转之前要对请求进行一些前期预处理,并要使用HttpServletRequest.setAttribute方法传递预处理结果,那就应该使用request.getRequestDispatcher().forward()方法。不同WEB应用程序之间的重定向,特别是要重定向到另外一个WEB站点上的资源的情况,都应该使用response.sendRedirect()方法。

    5、无论是request.getRequestDispatcher().forward()方法,还是response.sendRedirect()方法,在调用它们之前,都不能有内容已经被实际输出到了客户端。如果缓冲区中已经有了一些内容,这些内容将被从缓冲区中。

    以上五点的论述来源于:https://blog.csdn.net/xybelieve1990/article/details/49486751

    转发和重定向的图解

    在这里插入图片描述

    两种跳转获得对象的方式

    //获得转发对象getRequestDispatcher()
    HttpServletRequest(httpServletRequest).getRequestDispatcher
    ServletContext.getRequestDispatcher();
     
    //获得重定向对象sendRedirect()
    HttpServletResponse(httpServletResponse).sendRedirect();
    

    转发和跳转的小结

    1、转发使用的是getRequestDispatcher()方法;重定向使用的是sendRedirect();
    2、转发:浏览器URL的地址栏不变。重定向:浏览器URL的地址栏改变;
    3、转发是服务器行为,重定向是客户端行为;
    4、转发是浏览器只做了一次访问请求。重定向是浏览器做了至少两次的访问请求;
    5、转发2次跳转之间传输的信息不会丢失,重定向2次跳转之间传输的信息会丢失(request范围)。

    转发和重定向的选择

    1、重定向的速度比转发慢,因为浏览器还得发出一个新的请求,如果在使用转发和重定向都无所谓的时候建议使用转发。
    2、因为转发只能访问当前WEB的应用程序,所以不同WEB应用程序之间的访问,特别是要访问到另外一个WEB站点上的资源的情况,这个时候就只能使用重定向了。

    转发和重定向的应用场景

    在上面我已经提到了,转发是要比重定向快,因为重定向需要经过客户端,而转发没有。有时候,采用重定向会更好,若需要重定向到另外一个外部网站,则无法使用转发。另外,重定向还有一个应用场景:避免在用户重新加载页面时两次调用相同的动作。

    例如,当提交产品表单的时候,执行保存的方法将会被调用,并执行相应的动作;这在一个真实的应用程序中,很有可能将表单中的所有产品信息加入到数据库中。但是如果在提交表单后,重新加载页面,执行保存的方法就很有可能再次被调用。同样的产品信息就将可能再次被添加,为了避免这种情况,提交表单后,你可以将用户重定向到一个不同的页面,这样的话,这个网页任意重新加载都没有副作用;

    但是,使用重定向不太方便的地方是,使用它无法将值轻松地传递给目标页面。而采用转发,则可以简单地将属性添加到Model,使得目标视图可以轻松访问。由于重定向经过客户端,所以Model中的一切都会在重定向时丢失。但幸运的是,在Spring3.1版本以后,我们可以通过Flash属性,解决重定向时传值丢失的问题。

    要使用Flash属性,必须在Spring MVC的配置文件中添加一个。然后,还必须再方法上添加一个新的参数类型:org.springframework.web.servlet.mvc.support.RedirectAttributes。

    
    @RequestMapping(value="saveProduct",method=RequestMethod.POST)
    public String saveProduct(ProductForm productForm,RedirectAttributes redirectAttributes){
     
         //执行产品保存的业务逻辑等
      
         //传递参数
           redirectAttributes.addFlashAttribute("message","The product is saved successfully");
       
         //执行重定向
          return "redirect:/……";
    
    
    
    ## 如何插入一段漂亮的代码片
    
    去[博客设置](https://mp.csdn.net/console/configBlog)页面,选择一款你喜欢的代码片高亮样式,下面展示同样高亮的 `代码片`.
    ```javascript
    // An highlighted block
    var foo = 'bar';
    

    原创链接:https://blog.csdn.net/liubin5620/article/details/79922692

    展开全文
  • 浏览器安全分为 Web 页面安全、浏览器网络安全和浏览器系统安全。 1、为什么需要安全策略 假设这样一个场景:你先打开了个银行网站,并登录了,然后不小心打开了个恶意网站,由于没有安全策略,此时恶意网站完全可以...

    浏览器安全分为 Web 页面安全、浏览器网络安全和浏览器系统安全。

    1、为什么需要安全策略

    假设这样一个场景:你先打开了个银行网站,并登录了,然后不小心打开了个恶意网站,由于没有安全策略,此时恶意网站完全可以对银行网站进行任意操作,比如更改银行网站的 DOM 元素,甚至获取 cookie 等信息,伪造接口请求等,可想而知是很恐怖的。所以在没有安全保障的 Web 世界中,我们是没有隐私的,因此需要安全策略来保障我们的隐私和数据的安全。

    2、同源策略

    说到安全策略,就不得不提同源策略,那何为同源策略呢?
    要理解同源策略,先理解下同源的概念:

    如果两个 URL 的协议、域名和端口都相同,我们就称这两个 URL 同源。

    比如下面这两个 URL 就属于同源,具有相同的协议 https,相同的域名 juejin.cn,相同的端口

    https://juejin.cn/books
    https://juejin.cn/events/all
    

    两个不同的源之间若想要相互访问资源或者操作 DOM,那么会有一套基础的安全策略的制约,我们把这称为同源策略。
    具体来讲,同源策略主要表现在 DOM、Web 数据和网络这三个层面。

    2.1、DOM 层面

    同源策略限制了来自不同源的 JavaScript 脚本对当前 DOM 对象读和写的操作。
    比如你 window.open 个网站,那么如果该网站与当前网站属于同源,就可以在新打开的网站上操作原网站的 DOM 元素,否则就不可以修改

    2.2、Web 数据

    同源策略限制了不同源的站点读取当前站点的 Cookie、IndexDB、LocalStorage 等数据

    2.3、网络

    无法访问跨域的资源

    3、安全策略

    如果完全采用同源策略,当然是最安全的,但这样会使得 Web 项目难以开发和使用。所以要出让些安全性来满足灵活性,这就是目前的页面安全策略原型。

    3.1、页面中可以嵌入第三方资源

    同源策略要让一个页面的所有资源都来自于同一个源,也就是要将该页面的所有 HTML 文件、JavaScript 文件、CSS 文件、图片等资源都部署在同一台服务器上,这明显很不合理,比如我要将一些静态资源从 CDN 上获取,就办不到。所以就需要同源策略放[松]下,允许任意引用外部文件。
    但因为这个方案,导致页面里会注入恶意的脚本文件,导致 XSS 攻击,后面细讲。

    3.2、跨域资源共享

    同源策略限制了访问跨域的资源,这会大大制约生产力。所以引进了跨域资源共享(CORS),使用该机制可以进行跨域访问控制,从而使跨域数据传输得以安全进行。
    比如响应头部设置如下

    access-control-allow-origin: *
    

    3.3、跨文档消息机制

    同源策略限制了两个不同源之间的 DOM 操作,但有时需要两个不同源的 DOM 之间进行通信,于是浏览器中又引入了跨文档消息机制。

    比如一个页面通过 iframe 嵌入了另一个不同源的页面,此时双方想要进行通信,就得采用 window.postMessage。

    4、XSS

    由于支持页面中的第三方资源引用和 CORS 带来了很多安全问题,其中最典型的就是 XSS 攻击。

    4.1、什么是 XSS

    XSS 全称为 Cross Site Scripting ,为了与 CSS 区分开来,所以简称 XSS,翻译过来是跨站脚本
    XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本,从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。

    4.2、XSS 攻击的危害

    • 窃取 Cookie 信息:恶意脚本通过 document.cookie 的方式获取 cookie 信息,并利用 CORS 将 cookie 信息上传到恶意服务器。
    • 监听用户行为:使用 addEventListener 接口来监听键盘事件,比如监听用户输入的信用卡等信息,并上传到恶意服务器。
    • 修改 DOM:伪造登录窗口,骗取用户输入账号与密码等信息
    • 在页面内生成浮窗广告

    4.3、XSS 攻击方式

    4.3.1、存储型 XSS 攻击

    产生存储型 XSS 步骤如下:

    1. 黑客将带有恶意脚本的表单提交保存到数据库
    2. 用户请求包含了该脚本的页面
    3. 用户浏览该页面时,恶意脚本就会将 Cookie 等数据上传到恶意服务器

    4.3.2、反射型 XSS 攻击

    用户将一段含有恶意代码的请求提交给 Web 服务器,Web 服务器接收到请求时,又将恶意代码反射给了浏览器端。

    比如:http://localhost:3000/?xss=<script>alert('你被xss攻击了')</script>

    黑客经常会通过 QQ 群或者邮件等渠道诱导用户去点击这些恶意链接,所以对于不知来源的链接,要谨慎。

    4.3.3、基于 DOM 的 XSS 攻击

    基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。

    在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。

    4.4、如何阻止 XSS 攻击

    无论是何种类型的 XSS 攻击,它们都有一个共同点,那就是首先往浏览器中注入恶意脚本,然后再通过恶意脚本将用户信息发送至黑客部署的恶意服务器上。

    所以要阻止 XSS 攻击,可以通过阻止恶意 JavaScript 脚本的注入和恶意消息的发送来实现。

    4.4.1、纯前端渲染

    不要采用服务端渲染,而是通过接口请求,然后采用 innerText,setAttribute 等方式设置内容或属性

    4.4.2、服务器对输入脚本进行过滤或转码

    在服务端将一些关键的字符进行转码,比如 <script 转为 &lt;script&gt;

    4.4.3、利用 CSP

    CSP 全称为 Content-Security-Policy,翻译过来为内容安全策略

    • 限制加载其他域下的资源文件,这样即使黑客插入了一个 JavaScript 文件,这个 JavaScript 文件也是无法被加载的;
    • 禁止向第三方域提交数据,这样用户数据也不会外泄;
    • 禁止执行内联脚本和未授权的脚本;
      比如
    • 只允许加载本站资源:
    Content-Security-Policy: default-src ‘self’
    
    • 只允许加载 HTTPS 协议图片:
    Content-Security-Policy: img-src https://*
    
    • 允许加载任何来源框架:
    Content-Security-Policy: child-src 'none'
    

    4.4.4、使用 HttpOnly 属性

    使用 HttpOnly 标记的 Cookie 只能使用在 HTTP 请求过程中,所以无法通过 JavaScript 来读取这段 Cookie。

    5、CSRF

    5.1、什么是 CSRF

    CSRF 英文全称是 Cross-site request forgery,所以又称为“跨站请求伪造”,是指黑客引诱用户打开黑客的网站,在黑客的网站中,利用用户的登录状态发起的跨站请求。简单来讲,CSRF 攻击就是黑客利用了用户的登录状态,并通过第三方的站点来做一些坏事。

    5.2、CSRF 攻击的方式

    发起 CSRF 攻击的三个必要条件:

    • 目标站点要有 CSRF 漏洞;
    • 用户要登录过目标站点,并且在浏览器上保持有该站点的登录状态;
    • 需要用户打开一个第三方站点,可以是黑客的站点,也可以是一些论坛。
      通常当用户打开了黑客的页面后,黑客有三种方式去实施 CSRF 攻击。
    • 自动发起 Get 请求
      比如黑客页面有张图片,页面一加载该图片就发起了请求
     <img src="xxx">
    
    • 自动发起 POST 请求

      构建个隐藏表单,页面加载时触发表单提交

    • 引诱用户点击链接

    5.3、如何阻止 CSRF 攻击

    CSRF 主要是由于服务端的漏洞引起的,所以主要的防护手段是提升服务器的安全性

    5.3.1、利用 Cookie 的 SameSite 属性

    • Strict 最为严格。如果 SameSite 的值是 Strict,那么浏览器会完全禁止第三方 Cookie。
    • Lax 相对宽松一点。在跨站点的情况下,从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法,或者通过 img、iframe 等标签加载的 URL,这些场景都不会携带 Cookie。
    • None:在任何情况下都会发送 Cookie 数据。

    将一些关键的 Cookie 设置为 Strict 或者 Lax 模式,这样第三方站点发起请求时,这些关键 cookie 就不会带上,从而使得登录验证失败,自然 CSRF 攻击也就无效了。

    5.3.2、验证请求的来源站点

    攻击都是来自于第三节站点,所以可以通过来源来阻止 CSRF 攻击,那么要如何获取来源呢?
    就得采用 HTTP 请求头中的 Referer 和 Origin 属性。
    Origin
    优先判断 Origin,如果请求头中没有包含 Origin 属性,再根据实际情况判断是否使用 Referer 值。

    5.3.3、CSRF Token

    服务器返回页面时带个标识,调用接口时带上该标识。由于第三方站点无法获取到该标识,所以就算发出了请求,服务端也会因为标识不正确而拒绝请求。

    6、相关面试题

    1. 简明说明下你对同源策略的理解
    2. 同源与同一站点的区别
    3. xss 攻击里存储型与反射型攻击的区别
    4. 如何阻止 xss 攻击
    5. CSRF 是什么
    6. 如何阻止 CSRF 攻击
    7. 谈谈你对 XSS 与 CSRF 两种攻击的理解
    8. 为什么会有 XSS 与 CSRF 攻击
      建议自己先根据上面的内容解答下。

    解答:

    1. 简明说明下你对同源策略的理解:
      答:同一协议,同一域名,同一端口的称为同源,同源之间可以进行任意操作,而不同源之间就会有些限制,分为 DOM 、Web 数据和网络三个层面,DOM 上不同源无法修改,无法获取到不同源上的 cookie 等数据,使用 xml 或 fetch 方式无法调用不同源的接口。

    2. 同源与同一站点的区别
      答:同源要求协议、域名以及端口均一样才行;同一站点只要求协议,根域名相同即可,
      比如如下两个 URL 就属于同一站点,而不属于同源。

    https://shop.example.com
    https://www.example.com
    
    1. xss 攻击里存储型与反射型攻击的区别
      答:Web 服务器不会存储反射型 XSS 攻击的恶意脚本,这是和存储型 XSS 攻击不同的地方

    2. 如何阻止 xss 攻击
      答:见 4.3 内容

    3. CSRF 是什么
      答:跨域请求伪造,通过第三方站点模拟用户请求行为

    4. 如何阻止 CSRF 攻击
      答:见 5.3 内容

    5. 谈谈你对 XSS 与 CSRF 两种攻击的理解
      答:XSS 是通过往用户的页面中注入恶意脚本,然后再通过恶意脚本将用户页面的数据上传到黑客的服务器上,最后黑客再利用这些数据进行一些恶意操作。CSRF 攻击不需要将恶意代码注入用户的页面,仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。XSS 是利用用户对网站的信任采取攻击的,而 CSRF 是利用网站对用户的信任采取攻击的。

    6. 为什么会有 XSS 与 CSRF 攻击
      答:浏览器为同源策略开的两个“后门”:一个是在页面中可以任意引用第三方资源,另外一个是通过 CORS 策略让 XMLHttpRequest 和 Fetch 去跨域请求资源。

    参考链接

    浏览器工作原理与实践

    展开全文
  • 浏览器默认个相同的源之间是可以相互访问资源操作 DOM 的。 什么是同源?如果个页面拥有相同的协议、域名端口,那么这个页面具有相同的源。 同源政策:是浏览器提供的一个安全功能。是为了保证用户信息的...

    一、Web页面安全

    同源和跨域:

    什么是同源?如果两个页面拥有相同的协议(scheme)、域名(host)和端口(port)(http默认port80,https默认端口号443),那么这两个页面具有相同的源。
    同源策略:是浏览器提供的一个安全策略。
    同源策略主要表现在 DOM、Web 数据和网络这三个层面。
    第一个,DOM 层面。同源策略限制了来自不同源的 JavaScript 脚本对当前 DOM 对象读和写的操作。(解决:跨文档消息机制:通过window.postMessage 的 JavaScript 接口来和不同源的 DOM 进行通信。)
    第二个,数据层面。同源策略限制了不同源的站点读取当前站点的 Cookie、IndexDB、LocalStorage 等数据。
    第三个,网络层面。同源策略限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点。

    什么是跨域?同源指的是两个url的协议(scheme)、域名(host name)、端口(port)一致,反之则是跨域。出现的根本原因:由浏览器的同源策略导致。
    在这里插入图片描述
    拦截是如何发生的
    当xhr.send被调用时,即Ajax准备发送请求时,还只是在渲染进程中,浏览器给每个渲染进程装进了沙箱,在沙箱中的渲染进程是无法发送网络请求的,需通过IPC将数据传给浏览器主进程,由主进程发起网络请求。服务端处理完数据后将数据返回,主进程检查到跨域,且没有cors响应头,将响应体全部丢掉,并不会发送给渲染进程。达到了拦截数据的目的。
    如何解决跨域
    实现跨域数据请求有几种解决方案:JSONP、CORS、nginx反向代理(通过自家服务器访问别的服务器再响应回自家客户端)、websocket、iframe(诸多不便)。ranges’ 跨域解决方案
    在这里插入图片描述
    脚手架配置代理
    在这里插入图片描述
    JSONP:
    注意JSONP和Ajax之间没有任何关系,不能把JSONP请求数据的方式叫做ajax,因为JSONP没有用到XMLHttpRequest这个对象。
    JSONP的实现原理:JSONP是JSON的一种“使用模式”。
    在这里插入图片描述
    注意这里强调函数调用,从服务器返回一个函数的调用,在客户端执行回调,客户端决定调用哪个函数,通过查询字符串的形式(传入?callback=函数名)。
    手写JSONP(封装JSONP)

    function jsonp(url,params,callback){
        var script=document.createElement('script');
        var fnName='myJsonp'+Math.random().toString().replace('.','');//保证每次请求的方法都不会重复
        //window[fnName]=obj.callback.name;//.后面不能跟变量,只能跟属性,所以用中括号
        var params='';
        for(let key in params){
            params+='&'+key+'='+params[key];//&name='lisi'&age=19
        }
        script.src=url+'?callback='+fnName+params;
        document.body.appendChild(script);
        script.onload=function(){
            document.body.removeChild(script);
        }
    }
    jsonp({
        url:'http://localhost:3001/better',
        params:{
            name:'lisi',
            age:19
        },
        callback:function(data){
            console.log(data);
        }
    })
    

    使用JSONP的风险
    JSONP安全风险
    JSONP劫持(属于CSRF漏洞)(jsonp劫持就是攻击者获取了本应该传给网站其他接口的数据)(通过JSONP技术可以实现数据的跨域访问,必然会产生安全问题,如果网站B对网站A的JSONP请求没有进行安全检查直接返回数据,则网站B 便存在JSONP 漏洞,网站A 利用JSONP漏洞能够获取用户在网站B上的数据。)

    CORS(cross origin resource sharing跨域资源共享)
    是W3C的一个标准,需要浏览器和服务器的共同支持,主要是服务器端响应头中做一些改动,设置哪些客户端可以访问服务器以及设置客户端可以以哪种方式(get/post)访问服务器。
    简单了解一下简单请求与非简单请求:浏览器根据请求方法和请求头的特定字段,将请求做了分类,满足以下三个条件的属于简单请求:1,请求方法为GET、POST、HEAD。2,请求头的取值范围:Accept Accept-Language Content-Language Content-Type(只限于三个值:application/x-www-form-urlencoded,multipart/form-data,text/plain)。以外的属于非简单请求。
    简单请求:请求发出去之前,浏览器做了什么?
    它会自动在请求头当中,添加一个Origin字段,用来说明请求来自哪个源。服务器拿到请求之后,在回应时对应地添加Access-Control-Allow-Origin字段,如果Origin不在这个字段的范围中,那么浏览器就会将响应拦截。
    因此,Access-Control-Allow-Origin字段是服务器用来决定浏览器是否拦截这个响应,这是必需的字段。与此同时,其它一些可选的功能性的字段,用来描述如果不会拦截,这些字段将会发挥各自的作用。
    Access-Control-Allow-Credentials。这个字段是一个布尔值,表示是否允许发送 Cookie,对于跨域请求,浏览器对这个字段默认值设为 false,而如果需要拿到浏览器的 Cookie,需要添加这个响应头并设为true, 并且在前端也需要设置withCredentials属性:

    let xhr = new XMLHttpRequest();
    xhr.withCredentials = true;
    

    Access-Control-Expose-Headers。这个字段是给 XMLHttpRequest 对象赋能,让它不仅可以拿到基本的 6 个响应头字段(包括Cache-Control、Content-Language、Content-Type、Expires、Last-Modified和Pragma), 还能拿到这个字段声明的响应头字段。比如这样设置:

    Access-Control-Expose-Headers: aaa//在前端可以通过 XMLHttpRequest.getResponseHeader('aaa') 拿到 aaa 这个字段的值
    

    非简单请求:非简单请求相对而言会有些不同,体现在两个方面: 预检请求和响应字段。为什么会有预检请求?因为复杂请求对服务器有一定的要求,如果服务器不同意预检请求的话,那么在返回的头部字段里面就会校验失败,预检请求校验失败了之后后面的请求也就不会发送了。
    CORS请求和简单请求一样,浏览器自动加上Origin字段,服务端响应头返回Access-Control-Allow-Origin:
    在这里插入图片描述
    代理服务器
    正向代理、反向代理。
    正向代理帮助客户端访问客户端自己访问不到的服务器,然后将结果返回给客户端。
    反向代理拿到客户端的请求,将请求转发给其他的服务器,主要的场景是维持服务器集群的负载均衡,换句话说,反向代理帮其它的服务器拿到请求,然后选择一个合适的服务器,将请求转交给它。
    因此,两者的区别就很明显了,正向代理服务器是帮客户端做事情,而反向代理服务器是帮其它的服务器做事情。
    在这里插入图片描述

    总结

    1. 读取数据和操作 DOM 要用跨文档机制
    2. 跨域请求(Ajax、fetch)要用 CORS 机制
    3. 引用第三方资源要用内容安全策略:CSP(解决XSS攻击)

    跨站脚本攻击(XSS)

    支持页面中的第三方资源引用和 CORS 也带来了很多安全问题,其中最典型的就是 XSS 攻击。
    什么是XSS攻击?XSS 全称是 Cross Site Scripting,‘跨站脚本攻击’。XSS攻击是指黑客往HTML文件或者DOM中注入恶意脚本。
    恶意脚本能做的事情:

    • 可以通过document.cookie窃取Cookie信息,然后通过XMLHttpRequest 或者 Fetch 加上CORS 功能将数据发送给恶意服务器。恶意服务器拿到用户的 Cookie 信息之后,就可以模拟用户的登录,然后进行转账等操作;
    • 可以监听用户行为。恶意 JavaScript 可以使用“addEventListener”接口来监听键盘事件,比如可以获取用户输入的信用卡等信息,将其发送到恶意服务器。
    • 可以通过修改 DOM 伪造假的登录窗口,用来欺骗用户输入用户名和密码等信息。
    • 可以在页面内生成浮窗广告。

    常见的注入恶意脚本的方式:存储型XSS攻击、反射性XSS攻击、基于DOM的XSS攻击。
    1,存储型XSS攻击
    在这里插入图片描述
    攻击步骤:
    首先黑客利用站点漏洞将一段恶意 JavaScript 代码提交到网站的数据库中;
    然后用户向网站请求包含了恶意 JavaScript 脚本的页面;
    当用户浏览该页面的时候,恶意脚本就会将用户的 Cookie 信息等数据上传到恶意服务器
    2,反射型XSS攻击
    在一个反射型 XSS 攻击过程中,恶意 JavaScript 脚本属于用户发送给网站请求中的一部分,黑客通过各种方式诱导用户去点击恶意链接,随后网站把恶意 JavaScript 脚本返回给用户。
    Web 服务器不会存储反射型 XSS 攻击的恶意脚本,这是和存储型 XSS 攻击不同的地方。
    3,基于DOM的XSS攻击
    基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。具体来讲,黑客通过各种手段将恶意脚本注入用户的页面中,比如通过网络劫持在页面传输过程中修改 HTML 页面的内容,这种劫持类型很多,有通过 WiFi 路由器劫持的,有通过本地恶意软件来劫持的,它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。
    4,mutation-based xss
    在这里插入图片描述
    在这里插入图片描述
    如何阻止XSS攻击
    我们知道存储型 XSS 攻击和反射型 XSS 攻击都是需要经过 Web 服务器来处理的,因此可以认为这两种类型的漏洞是服务端的安全漏洞。而基于 DOM 的 XSS 攻击全部都是在浏览器端完成的,因此基于 DOM 的 XSS 攻击是属于前端的安全漏洞。
    但无论是何种类型的 XSS 攻击,它们都有一个共同点,那就是首先往浏览器中注入恶意脚本,然后再通过恶意脚本将用户信息发送至黑客部署的恶意服务器上。
    所以要阻止 XSS 攻击,我们可以通过阻止恶意 JavaScript 脚本的注入阻止恶意消息的发送来实现。
    常见策略

    • 服务器对输入脚本进行过滤或转码
    • 充分利用CSP(内容安全策略)
      CSP 的核心思想是让服务器决定浏览器能够加载哪些资源,让服务器决定浏览器是否能够执行内联 JavaScript 代码。
      CSP 有如下几个功能:
      限制加载其他域下的资源文件,这样即使黑客插入了一个 JavaScript 文件,这个 JavaScript文件也是无法被加载的;
      禁止向第三方域提交数据,这样用户数据也不会外泄;
      禁止执行内联脚本和未授权的脚本;
      还提供了上报机制,这样可以帮助我们尽快发现有哪些XSS 攻击,以便尽快修复问题。
    • 使用HttpOnly属性
      由于很多 XSS 攻击都是来盗用 Cookie 的,服务器可以在HTTP响应头中,将某些 Cookie 设置为 HttpOnly 标志,,即set-cookie 属性值使用 HttpOnly 来标记该 Cookie。顾名思义,使用 HttpOnly 标记的 Cookie 只能使用在 HTTP 请求过程中,所以无法通过 JavaScript 来读取这段 Cookie(document.cookie)。

    当然除了以上策略之外,我们还可以通过添加验证码防止脚本冒充用户提交危险操作。而对于一些不受信任的输入,还可以限制其输入长度,这样可以增大 XSS 攻击的难度。

    CSRF攻击

    什么是CSRF攻击?CSRF 英文全称是 Cross-site request forgery,所以又称为“跨站请求伪造”,是指黑客引诱用户打开黑客的网站,在黑客的网站中,利用用户的登录状态发起的跨站请求。简单来讲,CSRF 攻击就是黑客利用了用户的登录状态,并通过第三方的站点发起请求
    通常当用户打开了黑客的页面后,黑客有三种方式去实施 CSRF 攻击:
    1,自动发起Get请求
    举例,在黑客的页面中,有一张图片的src对应的链接是一个转账的api,当用户被引诱进入了黑客的页面,页面被加载的时候,浏览器会自动发起img的资源请求,同时,借用用户的登录状态,就完成了这个转账的操作。
    2,自动发起POST请求
    举例,在黑客的页面中,有一个隐藏的表单,表单的内容为转账的api,当用户进入这个页面,表单被自动提交,服务器就会执行转账操作。
    3,引诱用户点击链接
    举例,通过引诱用户点击某个黑客的链接,该链接为转账的api,一旦点击链接,服务器就会执行转账操作。

    和 XSS 不同的是,CSRF 攻击不需要将恶意代码注入用户的页面,因此黑客是无法通过 CSRF 攻击来获取用户页面数据的;仅仅是利用服务器的漏洞和用户的登录状态来实施攻击,所以要提高服务器安全性。

    如何防止CSRF攻击
    发起 CSRF 攻击的三个必要条件:
    第一个,目标站点一定要有 CSRF 漏洞;
    第二个,用户要登录过目标站点,并且在浏览器上保持有该站点的登录状态;
    第三个,需要用户打开一个第三方站点,可以是黑客的站点,也可以是一些论坛。
    要让服务器避免遭受到 CSRF 攻击,通常有以下几种途径:

    • 充分利用好 Cookie 的 SameSite 属性:
      原理:Cookie 是浏览器和服务器之间维护登录状态的一个关键数据,实现从第三方站点发送请求时禁止 Cookie 的发送,因此在浏览器通过不同来源发送 HTTP 请求时,有如下区别:如果是从第三方站点发起的请求,那么需要浏览器禁止发送某些关键 Cookie 数据到服务器;如果是同一个站点发起的请求,那么就需要保证 Cookie 数据正常发送。在 HTTP 响应头中,通过 set-cookie 字段设置 Cookie 时,可以带上 SameSite 选项。SameSite 选项通常有三个值:Strict:最为严格。浏览器会完全禁止第三方 Cookie。比如,如果你从 RANGE 的页面中访问 SIRIUS 的资源,而 SIRIUS 的某些 Cookie 设置了 SameSite = Strict 的话,那么这些 Cookie 是不会被发送到 SIRIUS 的服务器上的。只有你从 SIRIUS 的站点去请求 SIRIUS 的资源时,才会带上这些 Cookie。Lax:相对宽松一点。在跨站点的情况下,从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法,或者通过 img、iframe 等标签加载的 URL,这些场景都不会携带 Cookie。None:在任何情况下都会发送 Cookie 数据。
      在这里插入图片描述
    • 在服务器端验证请求来源的站点
      由于 CSRF 攻击大多来自于第三方站点,因此服务器可以禁止来自第三方站点的请求。那么该怎么判断请求是否来自第三方站点呢?根据HTTP 请求头中的 Referer 和 Origin 属性,服务器的策略是优先判断 Origin,如果请求头中没有包含 Origin 属性,再根据实际情况判断是否使用 Referer 值。
    • CSRF Token
      第一步,在浏览器向服务器发起请求时,服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的字符串,然后将该字符串植入到返回的页面中;第二步,在浏览器端如果要发起转账的请求,那么需要带上页面中的 CSRF Token,然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求,那么将无法获取到 CSRF Token 的值,所以即使发出了请求,服务器也会因为 CSRF Token 不正确而拒绝请求。
      总结
      页面安全问题的主要原因就是浏览器为同源策略开的两个“后门”:一个是在页面中可以任意引用第三方资源,另外一个是通过 CORS 策略让 XMLHttpRequest 和 Fetch 去跨域请求资源。

    注入攻击

    SQL injection
    在这里插入图片描述
    在这里插入图片描述
    DOS攻击:
    在这里插入图片描述
    DDOS:消耗带宽

    二、浏览器网络安全

    网络安全协议HTTPS(超文本传输安全协议)
    HTTP是明文传输,使用 HTTP 传输的内容很容易被中间人窃取、伪造和篡改,通常我们把这种攻击方式称为中间人攻击
    所以在 HTTP 协议栈中引入安全层(HTTP+加密+认证+完整性保护=HTTPS):
    在这里插入图片描述
    从图中我们可以看出 HTTPS 并非是一个新的协议,通常 HTTP 直接和 TCP 通信,HTTPS 则先和安全层通信,然后安全层再和 TCP 层通信。也就是说 HTTPS 所有的安全核心都在安全层,它不会影响到上面的 HTTP 协议,也不会影响到下面的 TCP/IP,因此要搞清楚 HTTPS 是如何工作的,就要弄清楚安全层是怎么工作的。总的来说,安全层有两个主要的职责:对发起 HTTP 请求的数据进行加密操作和对接收到 HTTP 的内容进行解密操作
    第一版:使用对称加密(加密解密速度快)
    所谓对称加密是指加密和解密都使用的是相同的密钥。密钥在传输时也会被黑客截获。

    • 浏览器发送它所支持的加密套件列表和一个随机数client-random
    • 服务器会从加密套件列表中选取一个加密套件,然后还会生成一个随机数service-random,并将 service-random和加密套件列表返回给浏览器。
    • 最后浏览器和服务器分别返回确认消息。

    这样浏览器端和服务器端都有相同的 client-random 和service-random 了,然后它们再使用相同的方法将 client-random 和 service-random混合起来生成一个密钥 master secret,有了密钥 master secret 和加密套件之后,双方就可以进行数据的加密传输了。

    第二版:使用非对称加密(速度慢、中间人攻击)
    有公钥和私钥。先传公钥过去(相当于保险箱),小蓝手里的保险箱钥匙就是私钥,公钥(保险箱)谁都可以获取到,但是经过公钥加密的内容(保险箱里的信件)只有私钥可以解开。
    小蓝相当于发送公钥的服务器。
    中间人攻击见下图:
    在这里插入图片描述

    第三版:对称加密和非对称加密搭配使用
    第一版中对称加密的密钥不是会被截获嘛,我们先用非对称加密来进行密钥交换,然后传输数据阶段依然使用对称加密通讯。

    • 首先浏览器向服务器发送对称加密套件列表、非对称加密套件列表和随机数 client-random;
    • 服务器保存随机数client-random,选择对称加密和非对称加密的套件,然后生成随机数service-random,向浏览器发送选择的对称和非对称加密套件、service-random 和公钥
    • 浏览器保存公钥,并生成随机数pre-master,然后利用公钥对 pre-master 加密,并向服务器发送加密后的数据;
    • 最后服务器拿出自己的私钥,解密出 pre-master 数据,并返回确认消息。

    到此为止,服务器和浏览器就有了共同的 client-random、service-random 和 pre-master,然后服务器和浏览器会使用这三组随机数生成对称密钥,因为服务器和浏览器使用同一套方法来生成密钥,所以最终生成的密钥也是相同的。
    有了对称加密的密钥之后,双方就可以使用对称加密的方式来传输数据了。
    第四版:添加数字证书(验证服务器身份)
    混合加密还会存在的问题:
    服务器发送给浏览器的公钥,路上可能会被黑客劫持,替换成黑客自己的公钥,所以服务器需要向浏览器证明自己的身份,这样浏览器才能放心使用服务器发来的公钥给数据加密。

    相较于第三版的 HTTPS 协议,这里主要有两点改变:

    • 服务器没有直接返回公钥给浏览器,而是返回了数字证书,而公钥正是包含在数字证书中的;
    • 在浏览器端多了一个证书验证的操作,验证了证书之后,才继续后续流程。

    数字证书的申请过程:服务器生成一对公钥和私钥,私钥自己保存,通过公钥+企业+网站信息去CA机构申请证书。CA机构通过全方位的验证给这个网站颁发证书,证书内容包括企业信息、证书有效期、证书编号等,首先 CA 使用 Hash 函数来计算网站提交的明文信息,并得出信息摘要;然后 CA 再使用CA的私钥对信息摘要进行加密,加密后的密文就是 CA 颁给网站的数字签名。
    浏览器校验证书的流程:浏览器接收到数字证书之后,会对数字证书进行验证。首先浏览器读取证书中相关的明文信息,采用 CA 签名时相同的 Hash 函数来计算并得到信息摘要 A;然后再利用对应 CA 的公钥(内置于操作系统或浏览器中)解密签名数据,得到信息摘要 B;对比信息摘要 A 和信息摘要 B,如果一致,则可以确认证书是合法的,即证明了这个服务器是网站的;同时浏览器还会验证证书相关的域名信息、有效时间等信息。
    什么是数字证书?相当于网站的“身份证”,CA机构相当于颁发身份证的“国家”。数字证书中包含了网站域名、证书持有者、有效期、颁发机构、服务器公钥、hash算法。
    什么是数字签名?相当于盖的章。对公钥+颁发机构+服务方提供的信息生成一个信息,再对该信息使用hash函数生成一个信息摘要,然后CA机构用私钥对信息摘要进行加密,加密后的密文就是数字签名。
    数字证书作用:一、通过数字证书向浏览器证明服务器的身份;二、数字证书里面包含了服务器的公钥。

    HTTPS握手过程
    HTTPS(TLS握手过程)&TCP协议(三次握手四次挥手)

    HTTPS连接中接收/发送HTTP数据包会怎么样
    会怎么样:
    HTTPS会不高兴,浏览器也会不高兴。
    阻止掉HTTP的AJAX请求,然后报一个Mixed Content的错误(黄色的警告)。
    引入一个HTTP请求的 js 文件,会被浏览器直接 block 掉。
    解决方案:
    相对协议:将URL的协议(http、https)去掉,只保留//及后面的内容。
    iframe:使用 iframe 的方式引入 http 资源

    三、浏览器系统安全

    浏览器的单进程架构的不足:
    浏览器本身的漏洞是单进程浏览器的一个主要问题,如果浏览器被曝出存在漏洞,那么在这些漏洞没有被及时修复的情况下,黑客就有可能通过恶意的页面向浏览器中注入恶意程序,其中最常见的攻击方式是利用缓冲区溢出,不过需要注意这种类型的攻击和 XSS 注入的脚本是不一样的。XSS 攻击只是将恶意的 JavaScript 脚本注入到页面中,虽然能窃取一些 Cookie 相关的数据,但是 XSS 无法对操作系统进行攻击。而通过浏览器漏洞进行的攻击是可以入侵到浏览器进程内部的,可以读取和修改浏览器进程内部的任意内容,还可以穿透浏览器,在用户的操作系统上悄悄地安装恶意软件、监听用户键盘输入信息以及读取用户硬盘上的文件内容。
    浏览器的多进程架构
    在这里插入图片描述
    渲染进程操作系统隔离的这道墙就是安全沙箱。
    浏览器中的安全沙箱是利用操作系统提供的安全技术,让渲染进程在执行过程中无法访问或者修改操作系统中的数据,在渲染进程需要访问系统资源的时候,需要通过浏览器内核来实现,然后将访问的结果通过 IPC 转发给渲染进程。安全沙箱最小的保护单位是进程。因为单进程浏览器需要频繁访问或者修改操作系统的数据,所以单进程浏览器是无法被安全沙箱保护的,而现代浏览器采用的多进程架构使得安全沙箱可以发挥作用。
    我们知道安全沙箱能限制进程对操作系统资源的访问和修改,这就意味着如果要让安全沙箱应用在某个进程上,那么这个进程必须没有读写操作系统的功能,比如读写本地文件、发起网络请求、调用 GPU 接口等。
    浏览器内核和渲染进程各自职责:
    在这里插入图片描述
    通过该图,我们可以看到由于渲染进程需要安全沙箱的保护,因此需要把在渲染进程内部涉及到和系统交互的功能都转移到浏览器内核中去实现。

    展开全文
  • 浅析Web开发中前端路由实现的几种方式主题 Web开发故事从名叫Oliver的绿箭虾`说起,这位大虾酷爱社交网站,一天他打开了 Twitter ,从发过的tweets的选项卡一路切到followers选项卡,Oliver发现页面的内容变化了...
  • 首先感谢原作者的辛辛苦苦编写的文章,可以帮助一个正在学习的小白。 目前没有自己心得,只是个知识的搬运工。防止原作者删除,我就复制下,存档以便后观看。...转发重定向区别详解 作为一名程序员...
  • PC端web页面调试比较容易,这里主要说几移动端调试的方法,从简单到复杂、从模拟调试到远程调试,大概分为几部分: 1、Chrome DevTools(谷歌浏览器)的模拟手机调试 2、weinre(web inspector remote)远程调试工具...
  • 当输入一个网址时,浏览器会按照一定的规则去分析这个网址的含义,然后生成请求消息;例如在浏览器输入下面的网址: **[http://www.lab.glasscom.com/sample1.html](http://www.lab.glasscom.com/sample1.html)**;...
  • 前言 本章接着之前的根据组件学习javaFX的系列教程,本章为javaFX视频播放器的...web组件(web component)<------本章 css样式 UI控件(UI controls) 布局(layout) 视觉特效(visual effects) 参考 本章有且
  • 但是在Vue中如果想要进行调试时,如果是在js中调试的话,可以直接添加一个debugger,然后在浏览器打开检查进行断点调试。 但是如果在vue界面的话则没法逐步查看变量的值。 比如: 在Vue页面中,点击搜索按钮时 ...
  • 浏览器跨域访问限制

    千次阅读 2020-07-29 11:12:34
    一.什么是跨域 广义的跨域: (1) 资源跳转:A链接、重定向...其实我们通常所说的跨域是狭义的,是由浏览器同源策略限制的一类请求场景。 二.什么浏览器跨域限制?本质是什么? 所谓浏览器跨域限制,其实是为了数据安
  • 浏览器跨域访问

    2020-11-06 23:18:00
    什么是跨域资源共享 跨源资源共享 (CORS)是http-基于标头的...浏览器的同源策略会导致跨域,这里同源策略又分为以下两种 DOM同源策略:禁止对不同源页面DOM进行操作。这里主要场景是iframe跨域的情况,不同域名的if
  • 安全测试 web安全测试 常规安全漏洞 可能存在SQLJS注入漏洞场景分析。为什么自己没有找到漏洞,哪么可能存在漏洞场景是?SQL注入漏洞修复 JS注入漏洞修复 漏洞存在场景分析修复示例
  • 说到cookie,其实cookie有个主要功能, 用于解决http无状态的缺点,在客户端存储会话信息,记录用户的状态 也就是我们现在也经常使用cookie在客户端存储一些数据 1.2、cookie的构成 一般来说,cookie是由浏览器...
  • Web客户端的几存储方式

    千次阅读 2017-09-26 21:25:46
    常见的浏览器端存储技术有:cookie sessionStorage localStorage userData indexDB服务器端存储技术:session一、HTML5 web存储(WebStorage)HTML5 可以在本地存储用户的浏览数据,不存储在服务器上,可以存储...
  • 常用的Web安全认证方式

    万次阅读 2019-05-26 20:13:12
    这是一最古老的安全认证方式,这种方式就是简单的访问API的时候,带上访问的usernamepassword,由于信息会暴露出去,所以现在也越来越少了,现在都更加安全保密的认证方式,可能某些老的平台还在。...
  • 文章目录说明准备条件搭建一个默认web服务器最简单的方法搭建一个自定义index.html路径的web服务器添加web服务器路径修改默认监听端口创建一个动态web服务器 说明 常规情况下,只要安装了http服务,启动这个服务就会...
  • Web浏览器中的JavaScript

    千次阅读 2019-01-10 22:46:40
    它表示Web浏览器的一个窗口或窗体,并且可以标识符window来引用它。Window对象定义了一些属性,比如,指代Location对象的location属性,Location对象指定当前显示在窗口中的URL,并允许脚本往窗口里载入新的URL: ...
  • web浏览器数据本地存储

    万次阅读 2018-07-17 20:52:51
    浏览器中存储主要分为以下三种方式 localstorage 2、sessionStorage 3、cookie   localStorage 生命周期永久,除非用户清除浏览器中的localStorage信息,否则永远存在; 存放数据大小一般为5MB; 仅在浏览器...
  • 两种存储方式是 session storage local storage,它们将用于处理不同的情况。 几乎所有最新版的浏览器都支持 HTML5 存储,包括 IE 浏览器。 会话存储_会话存储_被设计用于用户执行单一事务的场景
  • 一、网页启动APP由于安全...web网页上启动app的方式两种:1. schemaandroid与ios均支持自定义schema,通过访问自定义schema的url即可启动对应的app,如weixin://dl/scan这个url,这里的weixin就是自定义的schema。j...
  • Http请求方式的正确使用场景

    千次阅读 2021-11-28 16:55:38
    文章目录 前言 一、pandas是什么? 二、使用步骤 1.... 2....我们从大一刚开始学习Java到现在...时日至今,我很荣幸能够成为一名web后端学习者,在我们前后端合作写项目的同时,我们后端的任务就是维护数据写接口...
  • cookiecookiecookie的应用场景cookie与session的区别cookie与web storage的区别 cookie 在程序中,会话跟踪是很重要的事情。理论上,一个用户的所有请求操作都应该属于同一个会话,而另一个用户的所有请求操作则...
  • 聊聊webWorker

    2020-12-29 11:33:25
    先看几个例子结论:是? // 带着思考看下去背景JavaScript引擎是单线程运行的,JavaScript中耗时的I/O操作都被处理为...当这些异步任务发生的时候,它们将会被放入浏览器的事件任务队列中去,等到JavaScript运行时执...
  • EDI的两种解决方案:直连EDI和Web-EDI

    千次阅读 2019-01-17 14:45:11
    常见的EDI(电子数据交换)平台有三,直连EDI、Web-EDI增值网络VAN。 VAN是一比较落后的EDI对接方式,这种方式由于自身的很多局限性,会逐渐被取代,我们就不详细说明了。今天我们主要了解下直连EDI和Web-EDI...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 116,348
精华内容 46,539
关键字:

用浏览器和访问web两种打开方式分别适用于什么场景