中卫网站建设哪家好,建设厂招工信息网站,html是前端还是后端,温州seo建站跨域资源共享(CORS)安全性背景 提起浏览器的同源策略#xff0c;大家都很熟悉。不同域的客户端脚本不能读写对方的资源。但是实践中有一些场景需要跨域的读写#xff0c;所以出现了一些hack的方式来跨域。比如在同域内做一个代理#xff0c;JSON-P等。但这些方式都存在缺陷大家都很熟悉。不同域的客户端脚本不能读写对方的资源。但是实践中有一些场景需要跨域的读写所以出现了一些hack的方式来跨域。比如在同域内做一个代理JSON-P等。但这些方式都存在缺陷无法完美的实现跨域读写。所以在XMLHttpRequest v2标准下提出了CORS(Cross Origin Resourse-Sharing)的模型试图提供安全方便的跨域读写资源。目前主流浏览器均支持CORS。技术原理 CORS定义了两种跨域请求简单跨域请求和非简单跨域请求。当一个跨域请求发送简单跨域请求包括请求方法为HEADGETPOST;请求头只有4个字段AcceptAccept-LanguageContent-LanguageLast-Event-ID;如果设置了Content-Type则其值只能是application/x-www-form-urlencoded,multipart/form-data,text/plain。说起来比较别扭简单的意思就是设置了一个白名单符合这个条件的才是简单请求。其他不符合的都是非简单请求。之所以有这个分类是因为浏览器对简单请求和非简单请求的处理机制是不一样的。当我们需要发送一个跨域请求的时候浏览器会首先检查这个请求如果它符合上面所述的简单跨域请求浏览器就会立刻发送这个请求。如果浏览器检查之后发现这是一个非简单请求比如请求头含有X-Forwarded-For字段。这时候浏览器不会马上发送这个请求而是有一个preflight跟服务器验证的过程。浏览器先发送一个options方法的预检请求。如果预检通过则发送这个请求否则就不拒绝发送这个跨域请求。下面详细分析一下实现安全跨域请求的控制方式。先看一下非简单请求的预检过程。非简单请求 浏览器先发送一个options方法的请求。带有如下字段- Origin: 普通的HTTP请求也会带有在CORS中专门作为Origin信息供后端比对,表明来源域。- Access-Control-Request-Method: 接下来请求的方法例如PUT, DELETE等等- Access-Control-Request-Headers: 自定义的头部所有用setRequestHeader方法设置的头部都将会以逗号隔开的形式包含在这个头中服务器收到预检请求以后检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后确认允许跨源请求就可以做出回应。会返回对应对的字段Access-Control-Allow-Origin:Access-Control-Allow-Methods:该字段必需它的值是逗号分隔的一个字符串表明服务器支持的所有跨域请求的方法。注意返回的是所有支持的方法而不单是浏览器请求的那个方法。这是为了避免多次“预检”请求。Access-Control-Allow-Headers:如果服务器否定了预检请求会返回一个正常的HTTP回应但是没有任何CORS相关的头信息字段。这时浏览器就会认定服务器不同意预检请求因此触发一个错误被XMLHttpRequest对象的onerror回调函数捕获一旦服务器通过了预检请求以后每次浏览器正常的CORS请求就都跟简单请求一样会有一个Origin头信息字段。服务器的回应也都会有一个Access-Control-Allow-Origin头信息字段。为什么要预检这是为了防止这些新增的请求对传统的没有 CORS 支持的服务器形成压力给服务器一个提前拒绝的机会这样可以防止服务器大量收到DELETE和PUT请求这些传统的表单不可能跨域发出的请求。简单请求 简单请求前面讲过是直接发送只是多加一个origin字段表明跨域请求的来源。如果Origin指定的源不在许可范围内服务器会返回一个正常的HTTP回应。浏览器发现这个回应的头信息没有包含Access-Control-Allow-Origin字段(详见下文)就知道出错了从而抛出一个错误被XMLHttpRequest的onerror回调函数捕获。注意这种错误无法通过状态码识别因为HTTP回应的状态码有可能是200。如果Origin指定的域名在许可范围内服务器返回的响应会多出几个头信息字段。Access-Control-Allow-Origin: 允许跨域访问的域可以是一个域的列表也可以是通配符*。这里要注意Origin规则只对域名有效并不会对子目录有效。即http://foo.example/subdir/ 是无效的。但是不同子域名需要分开设置这里的规则可以参照同源策略Access-Control-Allow-Credentials: 是否允许请求带有验证信息这部分将会在下面详细解释Access-Control-Expose-Headers: 允许脚本访问的返回头请求成功后脚本可以在XMLHttpRequest中访问这些头的信息(貌似webkit没有实现这个)Access-Control-Max-Age: 缓存此次请求的秒数。在这个时间范围内所有同类型的请求都将不再发送预检请求而是直接使用此次返回的头作为判断依据非常有用大幅优化请求次数Access-Control-Allow-Methods: 允许使用的请求方法以逗号隔开Access-Control-Allow-Headers: 允许自定义的头部以逗号隔开大小写不敏感然后浏览器通过返回结果的这些控制字段来决定是将结果开放给客户端脚本读取还是屏蔽掉。如果服务器没有配置cors返回结果没有控制字段浏览器会屏蔽脚本对返回信息的读取。withCredentials withCredentials是什么withCredentials是XMLHttpRequest的一个属性表示跨域请求是否提供凭据信息(cookie、HTTP认证及客户端SSL证明等)实际中用途就是跨域请求是要不要携带cookie在需要跨域携带cookie时要把withCredentials设置为true比如var xhr new XMLHttpRequest()xhr.withCredentials truexhr.open(GET, http://localhost:8888/, true)xhr.send(null)服务端的设置只有客户端设置当然不够了服务端还需要设置两点比如你页面所在的域名为http://www.abc.com服务端的Access-Control-Allow-Origin必须是http://www.abc.comAccess-Control-Allow-Credentials在响应头中Access-Control-Allow-Credentials这个值也要设置为true根据mdn上的说法只有设置为true的时候浏览器才会把响应结果暴露给你的js代码Access-Control-Allow-Origin既然是跨域请求服务端要设置Access-Control-Allow-Origin告诉浏览器允许跨域而且这个值必须指定域名不能设置为*尽管浏览器可以支持通配符但是不能同时将凭证标志设置成true。就像下面这种头部配置Access-Control-Allow-Origin: *Access-Control-Allow-Credentials: true这样配置浏览器将会报错因为在响应具有凭据的请求时服务器必须指定单个域所不能使用通配符。简单的使用通配符将有效的禁用“Access-Control-Allow-Credentials”这个字段。这些限制和行为的结果就是许多CORS的实现方式是根据“Origin”这个头部字段的值来生成“AccessControl-Allow-Origin”的值为什么不能两者共存?默认情况下如果没有设置“Access-Control-Allow-Credentials”这个头的话浏览器发送的请求就不会带有用户的身份数据(cookie或者HTTP身份数据)所以就不会泄露用户隐私信息。下面这个图展示一个简单的CORS请求流其实图片所展示的就是经典的CSRF攻击。而Origin的限制是为了明确是哪个站点发送的请求根据Origin就可以发现是钓鱼网站发起的请求。从而避免cookie的泄露。参考文献CORS通信跨域资源共享(CORS)安全性浅析【web前端】withCredentials有什么作用cors安全完全指南
