如何让网络请求更安全？
这个讲解的范畴很大了，我看我们公司的技术分享上关于这个讲了很多，我可能没有理解那么多概念，之前一直对XSS、CSRF、sql注入、OS命令注入、点击劫持的概念都不明白，其实最开始XSS就不懂，面试的时候也有被问到过，只知道XSS是个跨站脚本攻击，相当于只知道个名字，其他一概不了解，所以看到这个公司之前的知识点分享，想着读一读了解一下真正的什么东西顺便总结一下，如果自己理解的不好就相当于搬砖了，把写好的帖子直接复制粘贴过来了，自己还是尽可能看的明白点让自己知道怎么回事
XSS（Cross-Site Scripting）,跨站脚本攻击，因为缩写和CSS重叠，所以只能叫XSS。
CSS (Cascading Style Sheets) 是不是冷不丁懵住了
跨站脚本攻击是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或是JavaScript进行的一种攻击。
看到这 我还是想说什么样的网站算是存在安全漏洞的，然后XSS真正是怎么进行攻击的，因为我们平时写代码也没想过网站的安全漏洞的问题啊，是我们写代码造成的吗？
也就是说我们的代码会造成网站有安全漏洞吗？怎样可以避免？这是平时我们写代码的时候几乎不会考虑的问题，反正我是没考虑过，因为大部分开发人员几乎写的都是业务代码（搬砖）
跨站脚本攻击有可能造成以下影响
1）利用虚假输入表单骗取用户个人信息
2）利用脚本窃取用户的Cookie值，被害者在不知情的情况下，帮助攻击者发送恶意请求。
3）显示伪造的文章或图片。
XSS的原理是恶意攻击者在web页面里面插入恶意可执行网页脚本代码，当用户浏览该页时，嵌入里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或者其他侵犯用户安全隐私的目的。
非持久型XSS（反射型XSS）
非持久型XSS漏洞一般是通过给别人发送带有恶意脚本代码参数的URL，当URL被打开时，特有的恶意代码参数会被解析执行。
eg:https://xxx.xx.xx?default=<script>alert(document.cookie)</script>
怎样防止出现非持久型XSS攻击
web页面渲染的所有内容或者渲染的数据都必须来自于服务器。
尽量不要从URL、document.referrer、document.forms等这种DOM API中获取数据直接渲染。
尽量不要使用eval、new Function()、document.write()、document.writeln()、window.setInterval()、window.setTimeout()、innerHTML、document.createElement() 等可执行字符串的方法。
如果做不到以上几点，也必须对涉及DOM渲染的方法传入的字符串参数做转义。
前端渲染的时候对任何的字段都需要做转义编码。
持久型XSS (存储型XSS)
持久型XSS漏洞，一般存在于Form表单提交等交互功能，黑客利用的XSS漏洞将内容经正常功能提交进入数据库中持久保存，当前端页面获得后端从数据库中读取的注入代码时，恰好将其渲染执行。
如何防御？
CSP
设置HTTP header 中的Content-Security-Policy
设置meta标签的方式
了解更多 https://www.jianshu.com/p/a8b769e7d4bd
转义字符
转义就是对输入输出的内容对于引号、尖括号、斜杠进行转义
HttpOnly Cookie
这是预防XSS攻击窃取用户cookie最有效的防御手段。web应用程序在设置cookie时，将其属性设为HttpOnly，就可以避免该网页的cookie被客户端恶意JavaScript窃取，保护用户cookie信息。
CSRF(Cross Site Request Forgery),即跨站请求伪造，是一种常见的web攻击，它利用用户已登录的身份，在用户毫不知情的情况下，以用户的名义完成非法操作。
完成CSRF攻击必须要有的三个条件
1）用户已经登陆了站点A，并且在本地记录了cookie
2）站点A没有做任何CSRF防御
3）在用户没有登出站点A的情况下(也就是cookie生效的情况下)，访问了恶意攻击者提供的引诱危险站点B。
举例描述:受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2，可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。
如何防御？
1）SameSite：可以对cookie设置SameSite属性。该属性表示cookie不随着跨域请求发送，可以很大程度减少CSRF攻击，但是该属性目前不是所有浏览器都兼容。
2) Referer Check
HTTP Referer是header的一部分，当浏览器向web服务器发送请求时，一般会带上Referer信息告诉服务器是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。正常请求的referer具有一定规律，如在提交表单的referer必定是在该页面发起的请求。所以通过检查http包头referer的值是不是这个页面，来判断是不是CSRF攻击。但在某些情况下如从https跳转到http，浏览器处于安全考虑，不会发送referer，服务器就无法进行check了。若与该网站同域的其他网站有XSS漏洞，那么攻击者可以在其他网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。出于以上原因，无法完全依赖Referer Check作为防御CSRF的主要手段。但是可以通过Referer Check来监控CSRF攻击的发生。
3) Anti CSRF
Token目前比较完善的解决方案是加入Anti-CSRF-Token。即发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token，并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值，会进行校验该请求当中的token和cookie当中的token值是否都存在且相等，才认为这是合法的请求。否则认为这次请求是违法的，拒绝该次服务。这种方法相比Referer检查要安全很多，token可以在用户登陆后产生并放于session或cookie中，然后在每次请求时服务器把token从session或cookie中拿出，与本次请求中的token 进行比对。由于token的存在，攻击者无法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时，当某个页面消耗掉token后，其他页面的表单保存的还是被消耗掉的那个token，其他页面的表单提交时会出现token错误。
4) 验证码
应用程序和用户进行交互过程中，特别是账户交易这种核心步骤，强制用户输入验证码，才能完成最终请求。在通常情况下，验证码够很好地遏制CSRF攻击。但增加验证码降低了用户的体验，网站不能给所有的操作都加上验证码。所以只能将验证码作为一种辅助手段，在关键业务点设置验证码。
点击劫持是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过iframe嵌套的方式嵌入自己的网页中，并将iframe设置为透明，在页面中透出一个按钮诱导用户点击。
如何防御？
X-FRAME-OPTIONS是一个 HTTP 响应头，在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe 嵌套的点击劫持攻击。
该响应头有三个值可选，分别是：
DENY，表示页面不允许通过 iframe 的方式展示
SAMEORIGIN，表示页面可以在相同域名下通过 iframe 的方式展示
ALLOW-FROM，表示页面可以在指定来源的 iframe 中展示
SQL注入与OS命令注入：不明白SQL注入与OS命令注入的，可以上网搜一下对于这两种注入举的非常经典的例子看一下
SQL注入是针对数据库的，而OS命令注入是针对操作系统的本质其实都是数据与代码未分离，即数据当做了代码来执行。
防御手段:加强权限设置，对特殊字符进行转义处理或编码转换等