开发的系统一定要求安全,稳定,可靠,这一章节就写一些关于安全防护的面试题,希望对大家有用
1.说说安全要素与 STRIDE 威胁
STRIDE 威胁
STRIDE 威胁，代表六种安全威胁：
-
身份假冒（Spoofing）
身份假冒，即伪装成某对象或某人。例如，我们通过伪造别人的 ID 进行操作 -
篡改（Tampering）
篡改，即未经授权修改数据或者代码。例如，我通过网络抓包或者某种途径修改某个请求包，而服务端没有进行进一步的防范措施，使得我篡改的请求包提交成功 -
抵赖（Repudiation）
抵赖，即拒绝执行他人无法证实也无法反对的行为而产生抵赖。例如，我攻击了某个产品，他们并不知道是我做的，没有证据证明是我做的，我就可以进行抵赖，换句话说，我可以死不承认 -
信息泄露（Information Disclosure）
信息泄露，即将信息暴露给未授权用户。例如，我通过某种途径获取未经加密的敏感信息，例如用户密码 -
拒绝服务（Denial of Service）
拒绝服务，即拒绝或降低有效用户的服务级别。例如，我通过拒绝服务攻击，使得其他正常用户无法使用产品的相关服务功能 -
特权提升（Elevation of Privilege）
特权提升，即通过非授权方式获得更高权限。例如，我试图用管理员的权限进行业务操作
安全要素
为了防范上面的 STRIDE 威胁，我们需要采用一些防范措施：
2.怎么防范常见的 Web 攻击
2.1SQL 注入攻击
SQL 注入攻击，这个是最常聊到的话题，使用过 Java 的开发人员，第一个反应就是一定要使用预编译的 PrepareStatement
什么是 SQL 注入攻击
攻击者在 HTTP 请求中注入恶意的 SQL 代码，服务器使用参数构建数据库 SQL 命令时，恶意 SQL 被一起构造，并在数据库中执行。
用户登录，输入用户名 Lusifer，密码 'or ‘1’ = ‘1’ ，如果此时使用参数构造的方式，就会出现
select * from user where name = 'Lusifer' and password = '' or '1'='1'
不管用户名和密码是什么内容，使查询出来的用户列表不为空
现在还会存在 SQL 注入攻击么
这个问题在使用了预编译的 PrepareStatement 后，安全性得到了很大的提高，但是真实情况下，很多同学并不重视，还是会留下漏洞的。举个例子，看看，大家的代码中对 sql 中 in 操作，使用了预编译，还是仍然还是通过字符串拼接呢？
如何防范 SQL 注入攻击
使用预编译的 PrepareStatement 是必须的，但是一般我们会从两个方面同时入手：
- Web 端
1.有效性检验。
2.限制字符串输入的长度。 - 服务端
1.不用拼接 SQL 字符串
2.使用预编译的 PrepareStatement
3.有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过 Web 端请求)
4.过滤 SQL 需要的参数中的特殊字符。比如单引号、双引号
2.2XSS 攻击
什么是 XSS 攻击
跨站点脚本攻击，指攻击者通过篡改网页，嵌入恶意脚本程序，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式
如何防范 XSS 攻击
1.前端，服务端，同时需要字符串输入的长度限制。
2.前端，服务端，同时需要对HTML转义处理。将其中的 < ,> 等特殊字符进行转义编码
2.3CSRF 攻击
什么是 CSRF 攻击
跨站点请求伪造，指攻击者通过跨站请求，以合法的用户的身份进行非法操作。可以这么理解 CSRF 攻击：攻击者盗用你的身份，以你的名义向第三方网站发送恶意请求。CRSF 能做的事情包括利用你的身份发邮件，发短信，进行交易转账，甚至盗取账号信息
如何防范 CSRF 攻击
1.安全框架，例如 Spring Security。
2.token 机制。在 HTTP 请求中进行 token 验证，如果请求中没有 token 或者 token 内容不正确，则认为 CSRF 攻击而拒绝该请求
3.证码。通常情况下，验证码能够很好的遏制 CSRF 攻击，但是很多情况下，出于用户体验考虑，验证码只能作为一种辅助手段，而不是最主要的解决方案
4.referer 识别。在 HTTP Header 中有一个字段 Referer，它记录了 HTTP 请求的来源地址。如果 Referer 是其他网站，就有可能是 CSRF 攻击，则拒绝该请求。但是，服务器并非都能取到 Referer。很多用户出于隐私保护的考虑，限制了 Referer 的发送。在某些情况下，浏览器也不会发送 Referer，例如 HTTPS 跳转到 HTTP
2.4文件上传漏洞
什么是文件上传漏洞
文件上传漏洞，指的是用户上传一个可执行的脚本文件，并通过此脚本文件获得了执行服务端命令的能力。
许多第三方框架、服务，都曾经被爆出文件上传漏洞，比如很早之前的 Struts2，以及富文本编辑器等等，可能被一旦被攻击者上传恶意代码，有可能服务端就被人黑了。
如何防范文件上传漏洞
1.文件上传的目录设置为不可执行。
2.判断文件类型。在判断文件类型的时候，可以结合使用 MIME Type，后缀检查等方式。因为对于上传文件，不能简单地通过后缀名称来判断文件的类型，因为攻击者可以将可执行文件的后缀名称改为图片或其他后缀类型，诱导用户执行。
3.对上传的文件类型进行白名单校验，只允许上传可靠类型。
4.上传的文件需要进行重新命名，使攻击者无法猜想上传文件的访问路径，将极大地增加攻击成本，同时向 shell, php, rar, ara 这种文件，因为重命名而无法成功实施攻击。
5.限制上传文件的大小。
6.单独设置文件服务器的域名
3.服务端通信安全攻防
服务端接口通信过程中，一般是明文传输的，没有经过任何安全处理。那么这个时候就很容易在传输过程中被中间者窃听、篡改、冒充等风险。因此，对于敏感信息，以及重要文件就需要进行加密策略，保证通信的安全性
Base64 加密传输
Base64 是网络上最常见的用于传输 8Bit 字节代码的编码方式之一，但是它其实并不是一种用于安全领域的加密解密算法。
但是，Base64 编码的数据并不会被人用肉眼所直观的理解，所以也有人使用 Base64 来进行加密解密，这里所说的加密与解密实际是指编码和解码的过程。
这种，加密传输的安全性是非常低的，Base64 加密非常容易被人识别并解码
DES 对称加密
DES 也是一种非常常用的加密方案，我们会将敏感的信息在通信过程中通过DES进行加密传输，然后在客户端和服务端直接进行解码。
此时，作为读者的你，可能会有个疑问，那如何保管密钥呢？其实，想想，答案就复出水面了，因为客户端和服务端都需要进行解码，所以两者都要存一份密钥。其实，还有一种方案是通过服务端下发，但是下发的时候通信的安全性也是没有很好的保障。
所以，DES 对称加密也是存在一定的安全隐患：密钥可能会泄漏。这边，举个真实的案例，某个 APP 的资源不错，同事想抓包分析下其服务端通信的信息结构，但是发现它既然全部采用了 DES 加密方案，本来想放弃了，但是我们又回头想想客户端肯定需要密钥对接口的加密的内容做解码才能正常展现，那么密钥肯定在 APP 包中，因此我们又对 APP 进行了反编译，结果成功的获取到了密钥，对服务端通信的加密信息进行了解码
AES 对称加密
AES 和 DES 类似，相较于 DES 算法而言，AES 算法有着更高的速度和资源使用效率，安全级别也较之更高。一般情况下，用于文件的加密。我们之前做个不准确测试，AES 和 DES 分别对一个大文件加密，AES 的速度大概是 DES 的 5 倍。（因为基于工具和环境问题，这个数据不是很准确哟）。
仍然存在一个相同的问题：密钥可能会泄漏。因此，保管好密钥很关键
升级到 HTTPS
HTTPS 的价值在于：
- 内容加密，第三方无法窃听
- 身份认证，一旦被篡改，通信双方会立刻发现
- 数据完整性。防止内容冒充或者篡改
这个方案，没法保护敏感数据，如果需要对敏感数据进行加密，还是需要考虑加密方案
双向 RSA 加密
RSA 双向认证，就是用对方的公钥加密是为了保密，这个只有对方用私钥能解密。用自己的私钥加密是为了防抵赖，能用我的公钥解开，说明这是我发来的。
例如，支付宝的支付接口就是非常典型的 RSA 双向认证的安全方案。此外，教育资源、敏感验证码出于安全性考虑都借鉴了这个方案
这一章节内容以及问题相对较少一些,各位有什么好的问题都可以提出来
前几期系列有心态篇,基础篇,集合篇,线程篇,锁机制篇,Spring框架篇,分布式篇,微服务篇,数据存储篇,缓存使用篇,消息队列篇
本系列总共所涉及Java基础,集合,线程,锁机制,spring框架,分布式,微服务,数据存储,缓存使用,消息队列,安全,性能调优,设计模式以及需求分析
