数据安全方面

1.Cookie

source : cookie和session的详解与区别 - 测试开发喵 - 博客园

source : ​​​​​​Session的生命周期和工作原理 - Rooker - 博客园

2. CSRF

source : Java解决CSRF问题 - morethink - 博客园

source(有案例分析, 希尔顿) : https://segmentfault.com/a/1190000021114673

1. CSRF是什么？

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

2.CSRF可以做什么？

你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

3. CSRF的原理

从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

1. 登录受信任网站A，并在本地生成Cookie。
2. 在不登出A的情况下，访问危险网站B。

看到这你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。确实如此，但你不能保证以下情况不会发生：

1. 你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2. 你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）
3. 上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

4. 预防CSRF攻击: 

简单来说，CSRF 就是网站 A 对用户建立信任关系后，在网站 B 上利用这种信任关系，跨站点向网站 A 发起一些伪造的用户操作请求，以达到攻击的目的。而之所以可以完成攻击是因为B向A发起攻击的时候会把A网站的cookie带给A网站，也就是说cookie已经不安全了。

通过Synchronizer Tokens

Synchronizer Tokens： 在表单里隐藏一个随机变化的 csrf_token csrf_token 提交到后台进行验证，如果验证通过则可以继续执行操作。这种情况有效的主要原因是网站 B 拿不到网站 A 表单里的 csrf_token

这种方式的使用条件是PHP和JSP等。因为cookie已经不安全了，因此把csrf_token值存储在session中，然后每次表单提交时都从session取出来放到form表单的隐藏域中，这样B网站不可以得到这个存储到session中的值。

下面是JSP的：但是我现在的情况是html，不是JSP，并不能动态的从session中取出csrf_token值。只能采用加密的方式了。

<input type="hidden" name="random_form" value=<%=random%>></input>

Hash加密cookie中csrf_token值

这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了。

我采用的hash加密方法是JS实现Java的HashCode方法，得到hash值，这个比较简单。也可以采用其他的hash算法。

前端向后台传递hash之后的csrf_token值和cookie中的csrf_token值，后台拿到cookie中的csrf_token值后得到hashCode值然后与前端传过来的值进行比较，一样则通过。

注意：

1. cookie必须要设置PATH才可以生效，否则在下一次请求的时候无法带给服务器。

2. Spring Boot 出现启动找不到主类的问题时可以mvn clean一下。

3. Filter设置response.sendError(403)在Spring Boot没有效果。

SSH(Secure Shell)

1. SSH

        专为远程登陆的会话。原因在于它采用了非对称加密技术(RSA)加密了所有传输的数据。通过SSH，可以把所有传输的数据进行加密，也能够防止DNS欺骗和IP欺骗。还有一个额外的好处就是传输的数据是经过压缩的，所以可以加快传输的速度。目前已经成为Linux系统的标准配置。

        传统的网络服务程序，如FTP、Pop和Telnet其本质上都是不安全的；因为它们在网络上用明文传送数据、用户帐号和用户口令，很容易受到中间人（man-in-the-middle）攻击方式的攻击。就是存在另一个人或者一台机器冒充真正的服务器接收用户传给服务器的数据，然后再冒充用户把数据传给真正的服务器。

        但并不是说SSH就是绝对安全的，因为它本身提供两种级别的验证方法：

第一种级别（基于口令的安全验证）：只要你知道自己帐号和口令，就可以登录到远程主机。所有传输的数据都会被加密，但是不能保证你正在连接的服务器就是你想连接的服务器。可能会有别的服务器在冒充真正的服务器，也就是受到“中间人攻击”这种方式的攻击。

第二种级别（基于密钥的安全验证）：你必须为自己创建一对密钥，并把公钥放在需要访问的服务器上。如果你要连接到SSH服务器上，客户端软件就会向服务器发出请求，请求用你的密钥进行安全验证。服务器收到请求之后，先在该服务器上你的主目录下寻找你的公钥，然后把它和你发送过来的公钥进行比较。如果两个密钥一致，服务器就用公钥加密“质询”(challenge)并把它发送给客户端软件。客户端软件收到“质询”之后就可以用你的私钥在本地解密再把它发送给服务器完成登录。与第一种级别相比，第二种级别不仅加密所有传输的数据，也不需要在网络上传送口令，因此安全性更高，可以有效防止中间人攻击。

2. DNS 欺骗 ：

source ： DNS欺骗 - MBA智库百科 (mbalib.com)

1. DNS 工作原理

        假设，主机A要访问百度，那么主机A先向本地DNS服务器发送请求，然后，本地DNS服务器查看自己的DNS缓存表中有没有百度的ip地址，如果有，那么根据这个ip地址就直接去访问百度的网站服务器；如果没有，就向根DNS服务器发送访问请求，然后，根服务器根据域名地址的类型，返回对应的域DNS服务器IP地址给主机A，主机A再去访问域DNS服务器，域服务器通过查询注册信息，告诉主机A百度的服务器地址在哪。这样，主机A就可以访问百度了。

 

2. DNS欺骗

source  ： DNS欺骗 - 云+社区 - 腾讯云 (tencent.com)

        域名服务器（DNS）欺骗（又称DNS缓存中毒）是一种攻击，其中使用更改后的DNS记录将在线流量重定向到类似其预期目的地的欺诈网站。一旦出现，用户将被提示登录（他们认为是）他们的账户，从而使犯罪者有机会窃取他们的访问凭证和其他类型的敏感信息。此外，恶意网站通常用于在用户的计算机上安装蠕虫或病毒，使攻击者可以长期访问它以及它所存储的数据。

执行DNS欺骗攻击的方法包括：

中间人（MITM） - 拦截用户和DNS服务器之间的通信，以便将用户路由到不同的/恶意的IP地址。

DNS服务器危害 - 直接劫持DNS服务器，该服务器配置为返回恶意IP地址。