安全审计

首先说一下审计日志的处理。审计日志处理的位置，应该是在认证之后，授权之前。因为只有你在认证之后，你才能知道这个请求到底是谁发出来的，谁在做这个事情。在这个授权之前，这样的话那些被拒绝掉的请求。在响应的时候你才可以把他记下来。 日志一定要持久化，可以把它存到数据库里，也可以把它写到文件里。 怎么保证过滤器按照顺序执行的，我们在做流控和认证的过滤器的时候，实际上，并没有指定的顺序。那么现在到底是流控先执行 还是认证先执行？ 在流控的Filter先打印一个1 在认证的Filter里面 我们再打一个2 发送请求 发现先输出了2 后输出了1。说明先走的认证 再走的流控 调整Filter的执行顺序 认证在第二个 就写个@Order(2) 重启服务进行测试 审计日志-简单实现 审计日志不能用filter来做了。因为审计日志我们要做两个动作。第一个是在请求进来后，我们要做一个动作。然后在请求出去之后，要把这个日志更新一下，所以进和出都要做事。如果只在请求进来记录 实际上不知道最终这个请求最终是成功了还是失败了。这样这个日志记录不完整。 如果用Filter来做，它只有一个doFilterInternal这么个方法，它是标准的Filter方法的实现，并没有明确的区分在请求进来执行还是请求出去的时候执行。 我们使用SpringBoot提供的Interceptor。

最近发现公司测试在内网部署了YAPI，同事在对yapi进行测试过程中很快就发现了一个xss漏洞，于是自己也就动手审计起来，这是nodejs的代码，之前看过一篇相关的审计漏洞详情，发现nodejs对漏洞的审计主要还是着重于几个要点 文件操作类漏洞，诸如任意文件上传、文件读写漏洞等 命令、代码执行漏洞 SQL注入漏洞 文件操作 首先，对于文件操作类漏洞，nodejs我就搜索require('fs')来追踪关键代码，整个yapi项目对于文件写入仅仅有两处地方，都位于控制器下的test.js文件 /** * 测试 单文件上传 * @interface /test/single/upload * @method POST * @returns {Object} * @example */ async testSingleUpload(ctx) { try { // let params = ctx.request.body; let req = ctx.req; let chunks = [], size = 0; req.on('data', function(chunk) { chunks.push(chunk); size += chunk.length; }); req.on('finish', function() { console.log(34343); }); req.on(

一、等级保护内容框架 技术要求：物理安全、网络安全、主机安全、应用安全、数据安全及备份恢复 管理要求：安全管理制度、安全管理机构、人员安全管理、系统建设管理、系统运维管理 二、等级保护二、三、四级内容 四级等保要求 三级等保要求 二级等保要求 8.1技术要求 8.1.1物理安全 8.1.1.1物理位置的选择 机房和办公场地应选择在具有防震、防风和防雨等能力的建筑内。 b) 机房场地应避免设在建筑物的高层或地下室，以及用水设备的下层或隔壁 8.1.1.2物理访问控制 并配置电子门禁系统 ，控制、鉴别和记录进入的人员 b) 需进入机房的来访人员应经过申请和审批流程，并限制和监控其活动范围； d) 重要区域应配置第二道电子门禁系统，控制、鉴别和记录进入的人员 8.1.1.3 防盗窃和防破坏 b) 应将设备或主要部件进行固定，并设置明显的不易除去的标记； c) 应将通信线缆铺设在隐蔽处，可铺设在地下或管道中； d) 应对介质分类标识，存储在介质库或档案室中； e) 应利用光、电等技术设置机房防盗报警系统 f) 应对机房设置监控报警系统。 8.1.1.4 防雷击 b) 应设置防雷保安器，防止感应雷； c) 机房应设置交流电源地线。 8.1.1.5 防火（G4） 机房应设置灭火设备和火灾自动报警系统。 b) 机房及相关的工作房间和辅助房应采用具有耐火等级的建筑材料； c)

前言 本小节我们就来总结一下在PHP代码审计中常用到的代码审计思路 敏感函数回溯参数过程 根据敏感函数的来逆向追踪参数的传递过程，是目前使用的最多的一种方式，因为大多数漏洞是由于函数的使用不当造成的。另外非函数使用不当的漏洞，如sql注入，也有一些特征，比如select、insert等，再结合from和where等关键字，我们就可以判读是否是一条SQL语句，通过对字符串的识别分析，就能判读这个sql语句里面的参数有没有使用单引号过滤，或者根据我们的经验来判断。 就像是HTTP头里面的HTTP_CLIENT_IP和HTTP_X_FORWARDFOR等获取到的IP地址经常没有安全过滤就直接拼接到了SQL语句中，并且由于它们是在$_SERVERE变量中不受GPC的影响，那我们就可以去查找HTTP_CLIENT_IP和HTTP_X_FORWARDFOR关键字来快速寻找漏洞。 这种方式的 优点 是只需要搜索相关敏感关键字，即可以快速第挖掘想要的漏洞，具有可定向挖掘和高效、高质量的优点。 缺点 是由于没有通读代码对程序的整体框架了解不够深入，在挖掘漏洞时定位利用点会花费一点时间，另外对逻辑漏洞挖掘覆盖不到。 通读全文代码 前面提到的根据敏感关键字来回溯传入的参数，是一种逆向追踪的思路，我们也提到了这种方式的优点与缺点，实际上在需要快速寻找漏洞的情况下用回溯参数的方式是非常有效的

系统设计的三员管理 一、“三员”职责 系统管理员：主要负责系统的日常运行维护工作。包括网络设备、安全保密产品、服务器和用户终端、操作系统数据库、涉密业务系统的安装、配置、升级、维护、运行管理；网络和系统的用户增加或删除；网络和系统的数据备份、运行日志审查和运行情况监控；应急条件下的安全恢复。 安全保密管理员：主要负责系统的日常安全保密管理工作。包括网络和系统用户权限的授予与撤销；用户操作行为的安全设计；安全保密设备管理；系统安全事件的审计、分析和处理；应急条件下的安全恢复。 安全审计员：主要负责对系统管理员和安全保密员的操作行为进行审计跟踪、分析和监督检查，及时发现违规行为，并定期向系统安全保密管理机构汇报情况。 二、“三员”配置要求 1、系统管理员、安全保密管理员和安全审计员不能以其他用户身份登录系统;不能查看和修改任何业务数据库中的信息；不能增删改日志内容。 2、涉密信息系统三员应由本单位内部人员担任，要求政治上可靠，熟悉涉密信息系统管理操作流程，具有较强的责任意识和风险防控意识；并签署保密承诺书。 3、系统管理人员和安全保密管理人员可由信息化部门专业技术人员担任，对于业务性较强的涉密信息系统可由相关业务部门担任；安全审计员根据工作需要由保密部门或其他能胜任安全审计员工作的人员担任。 4、同一设备或系统的系统管理员和安全审计员不能由同一人兼任

企业上云的现状与趋势 云计算，如今已经成为了像水和电一般关系到国计民生的国家基础设施。云计算为企业带了前所未有的资源交付效率和运维效率的提升，同时也用全新的技术帮助企业在新的价值网络中创造新的商业赛道、挖掘新的商业模式。越来越多的企业开始主动或被动地尝试使用云，而那些已经尝到云“甜头”的企业在加速上云节奏，不断将创新业务、非核心的企业业务、乃至企业核心业务逐步迁移上云。 企业的上云步骤，一般可分为“尝鲜”和“云化”两个阶段。 在“尝鲜”阶段，企业初始做云化，一般会从开发测试环境开始，或者选择企业的创新业务、非核心业务去尝试构建云原生应用，尝试云产品，对比不同云服务以及基础设施架构。 在“云化”阶段，企业对基础设施进行改造，在企业信息安全和成本控制允许的情况下，将更多业务迁移到云上来，既要兼顾企业云上业务发展的便捷、高效与速度，同时需要帮助企业在云上的安全管控、成本优化等做好保驾护航。 在“云化”阶段，随着企业云上业务量的增加、云上业务对企业的重要性或者核心程度的增加，对于有着多年内部 IT 管理业务和经验的企业来说，原来“深藏不露”的企业 IT 管理部门势必被推到云上管理的前台，配合业务部门，为企业在云上的资源购买和使用、云上业务应用或服务等提供云上 IT 运维管理和支持。随之而来的，还有企业的财务与安全合规部门

企业上云的现状与趋势 云计算，如今已经成为了像水和电一般关系到国计民生的国家基础设施。云计算为企业带了前所未有的资源交付效率和运维效率的提升，同时也用全新的技术帮助企业在新的价值网络中创造新的商业赛道、挖掘新的商业模式。越来越多的企业开始主动或被动地尝试使用云，而那些已经尝到云“甜头”的企业在加速上云节奏，不断将创新业务、非核心的企业业务、乃至企业核心业务逐步迁移上云。 企业的上云步骤，一般可分为“尝鲜”和“云化”两个阶段。 在“尝鲜”阶段，企业初始做云化，一般会从开发测试环境开始，或者选择企业的创新业务、非核心业务去尝试构建云原生应用，尝试云产品，对比不同云服务以及基础设施架构。 在“云化”阶段，企业对基础设施进行改造，在企业信息安全和成本控制允许的情况下，将更多业务迁移到云上来，既要兼顾企业云上业务发展的便捷、高效与速度，同时需要帮助企业在云上的安全管控、成本优化等做好保驾护航。 在“云化”阶段，随着企业云上业务量的增加、云上业务对企业的重要性或者核心程度的增加，对于有着多年内部 IT 管理业务和经验的企业来说，原来“深藏不露”的企业 IT 管理部门势必被推到云上管理的前台，配合业务部门，为企业在云上的资源购买和使用、云上业务应用或服务等提供云上 IT 运维管理和支持。随之而来的，还有企业的财务与安全合规部门

随着互联网的快速发展，企业通过各种应用产生在数据库中的所有关于商业以及公共安全性的数据，已经成为各企事业单位最具有价值的资产。通常企业为了防止这些敏感数据被竞争对手或者黑客非法获取，用以谋求不正当的利益，都会通过各种方式将这些信息严密保护起来。 但是，根据星瑞格软件统计显示：企业绝大多数重要的敏感的数据存储于数据库，90%以上敏感信息泄露源于数据库。而外泄的敏感信息主要是个人信息泄露，包括：用户名、用户密码、电子邮件、电话号码、银行账号、个人财产信息等。对于数据泄露的方式，主要包括：外包商滥用、离职员工窃取、管理者滥用、使用者误操作、内部人员窃取以及黑客窃取等。这也表明，企业对数据库防护并没有想象中的那么完美，而是面临各种安全风险的挑战。 数据库面临管理风险的挑战，主要表现在：人员职责的定位不明确、工作流程的不完善、内部员工的日常操作不规范、第三方维护人员的操作监控失效以及离职员工恶意泄漏等，这些原因都会导致数据库安全事件的发生，并且无法追溯并定位真实的操作者。随着目前企事业单位都进行扁平化管理体系的建立，需要将权力下放，并且电子文档传递工具发展迅速（QQ，微信……），会导致机密数据在企事业单位内部随处可见。但是，员工的泄密并不都是恶意的，有的是不清楚公司的规范而导致数据的误用和传递。 传统的数据库安全审计，基本都依赖于数据库自身的审计功能

centos/Fedora/RHEL • 整改方法： • 验证检查： 1、查看/etc/login.defs，访谈询问当前所设置的密码长度及更换周期； 2、查看/etc/pam.d/system-auth，确认密码复杂度要求。 密码最长有效期PASS_MAX_DAYS； 密码最短存留期PASS_MIN_DAYS； 密码长度最小值PASS_MIN_LENS； 密码有效期警告PASS_WARN_AEG； 密码须包含大写字母个数ucredit； 密码须包含小写字母个数lcredit； 密码须包含的数字字符个数dcredit； 密码须包含的特殊符号个数ocredit。 建议整改： （一）策略修改 1、/etc/login.defs文件中进行如下变量配置： PASS_MAX_DAYS：90； PASS_MIN_DAYS：2； PASS_MIN_LENS：8； PASS_WARN_AEG：7； 2、/etc/pam.d/system-auth文件中添加下面信息： password requisite pam_cracklib.so minlen=8 ucredit=-1 lcredit=-1 dcredit=-1ocredit=-1； 3、当前所设置的密码长度应不少于8位，具有一定的复杂度并能定期更换。 • Ubuntu/Debian • 整改方法： • 验证检查： 1、查看/etc