【网络安全】---web网络安全总结

我们页面常见的web安全问题有：

一、保证我们的前端页面没有漏洞可循

1. xss跨站点脚本攻击： 不要新人任何用户的输入， 能跟用户产生交互的地方都需要对参数进行转译或者过滤
2. 文件上传漏洞攻击： 校验文件格式， 后端限制存放文件路径的权限，限制运行脚本
3. SQL注入攻击： 对用户输入进行转译， 后端采用预编译的sql，不要直接使用前端参数
4. CSRF 跨站请求伪造

• anti CSRF token： 原理是从后端拿过来的html文件会在session存储一个随机的验证信息， 每次请求都发送这个验证信息进行校验
• 验证码登录： 这种的验证原理是确认操作的是人，而不是脚本，绝大部分验证码都不会被现有的脚本破解
• reffer 请求头验证，reffer会带原网站的访问信息

二、保证前后端传输不被盗取

采用https的验证方式， 那么为什么https的验证方式会那么安全？

1. 对称加密： 公钥跟私钥是一样的， 都可以用来进行数据加密和解密， 攻击者只需要得到公钥，那么数据就像是未曾加密过一样，对称加密的问题是不会对每个用户生成一个秘钥。
2. 非对称加密， 由服务器生成公钥私钥， 前端拿到公钥，对数据进行加密，私钥可以对数据进行解密。 非对称加密的问题是攻击者也可以得到公钥，所以可以拿到服务器返回的信息
3. 对称加密 + 非对称加密： 这种方式的操作原理是，由客户端使用非对称加密的方式跟服务端商量出一个独一无二的key， 然后利用对称加密生成一个客户端独一无二的公钥。那么攻击者无法得到这个独一无二的公钥，便无法完成攻击。 但是这种方式仍然是有漏洞的，比如在客户端与服务端商量key的时候被中间人拦截， 问题是我们无法知道过来的请求是好的还是坏的
4. 对称加密 + 非对称加密 + CA认证： 原理： 由CA部门颁发认证， 只有经过CA部门认证过的请求我们才认为是有效的请求。 具体的实现过程是

• 由CA部门提供算法来加密我们的公钥得到一个证书， 客户端请求到一个liscense，客户端得到liscense之后需要对其进行解密。
• 此时就需要CA部门提供的私钥来进行解密
• 为了防止从CA部门获取数字证书的过程中又被截获， 我们的操作系统中预先安装了数字证书， 即是我们用来解密的CA的私钥。

一、XSRF 攻击

想象一下，你登录了 bank.com 网站。此时：你有了来自该网站的身份验证 cookie。你的浏览器会在每次请求时将其发送到 bank.com，以便识别你，并执行所有敏感的财务上的操作。

现在，在另外一个窗口中浏览网页时，你不小心访问了另一个网站 evil.com。该网站具有向 bank.com 网站提交一个具有启动与黑客账户交易的字段的表单 

 的 JavaScript 代码。

你每次访问 bank.com 时，浏览器都会发送 cookie，即使该表单是从 evil.com 提交过来的。因此，银行会识别你的身份，并执行真实的付款。

 

这就是“跨网站请求伪造（Cross-Site Request Forgery，简称 XSRF）”攻击。

当然，实际的银行会防止出现这种情况。所有由 bank.com 生成的表单都具有一个特殊的字段，即所谓的 “XSRF 保护 token”，恶意页面既不能生成，也不能从远程页面提取它（它可以在那里提交表单，但是无法获取数据）。并且，网站 bank.com 会对收到的每个表单都进行这种 token 的检查。

但是，实现这种防护需要花费时间：我们需要确保每个表单都具有 token 字段，并且还必须检查所有请求。

1、输入 cookie samesite 选项

Cookie 的 samesite 选项提供了另一种防止此类攻击的方式，（理论上）不需要要求 “XSRF 保护 token”。

它有两个可能的值：

• samesite=strict（和没有值的 samesite 一样)

如果用户来自同一网站之外，那么设置了 samesite=strict 的 cookie 永远不会被发送。

换句话说，无论用户是通过邮件链接还是从 evil.com 提交表单，或者进行了任何来自其他域下的操作，cookie 都不会被发送。

如果身份验证 cookie 具有 samesite 选项，那么 XSRF 攻击是没有机会成功的，因为来自 evil.com 的提交没有 cookie。因此，bank.com 将无法识别用户，也就不会继续进行付款。

这种保护是相当可靠的。只有来自 bank.com 的操作才会发送 samesite cookie，例如来自 bank.com 的另一页面的表单提交。

虽然，这样有一些不方便。

当用户通过合法的链接访问 bank.com 时，例如从他们自己的笔记，他们会感到惊讶，bank.com 无法识别他们的身份。实际上，在这种情况下不会发送 samesite=strict cookie。

我们可以通过使用两个 cookie 来解决这个问题：一个 cookie 用于“一般识别”，仅用于说 “Hello, John”，另一个带有 samesite=strict 的 cookie 用于进行数据更改的操作。这样，从网站外部来的用户会看到欢迎信息，但是支付操作必须是从银行网站启动的，这样第二个 cookie 才能被发送。

• samesite=lax

一种更轻松的方法，该方法还可以防止 XSRF 攻击，并且不会破坏用户体验。

宽松（lax）模式，和 strict 模式类似，当从外部来到网站，则禁止浏览器发送 cookie，但是增加了一个例外。

如果以下两个条件均成立，则会发送含 samesite=lax 的 cookie：

1. HTTP 方法是“安全的”（例如 GET 方法，而不是 POST）。

   所有安全的 HTTP 方法详见 RFC7231 规范。基本上，这些都是用于读取而不是写入数据的方法。它们不得执行任何更改数据的操作。跟随链接始终是 GET，是安全的方法。

2. 该操作执行顶级导航（更改浏览器地址栏中的 URL）。

   这通常是成立的，但是如果导航是在一个