一、基础学科知识
1.1 计网基础知识
- SSL握手-传送门
* **"client hello"消息**:客户端通过发送"client hello"消息向服务器发起握手请求,该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择,还有一个"client random"随机字符串。
* **"server hello"消息**:服务器发送"server hello"消息对客户端进行回应,该消息包含了数字证书,服务器选择的密码组合和"server random"随机字符串。
* **验证**:客户端对服务器发来的证书进行验证,确保对方的合法身份,验证过程可以细化为以下几个步骤:
* 检查数字签名
* 验证证书链 (这个概念下面会进行说明)
* 检查证书的有效期
* 检查证书的撤回状态 (撤回代表证书已失效)
* **"premaster secret"字符串**:客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)",这个字符串是经过服务器的公钥加密过的,只有对应的私钥才能解密。
* **使用私钥**:服务器使用私钥解密"premaster secret"。
* **生成共享密钥**:客户端和服务器均使用 client random,server random 和 premaster secret,并通过相同的算法生成相同的共享密钥 KEY。
* **客户端就绪**:客户端发送经过共享密钥 KEY加密过的"finished"信号。
* **服务器就绪**:服务器发送经过共享密钥 KEY加密过的"finished"信号。
* **达成安全通信**:握手完成,双方使用对称加密进行安全通信。
1.2 密码学知识
- RSA-非对称
传送门
- 随机选择两个不相等的质数p和q
- 计算p和q的乘积n
- 计算n的欧拉函数φ(n)
- 随机选择一个整数e,条件是1< e < φ(n),且e与φ(n) 互质
- 计算e对于φ(n)的模反元素d
- 将n和e封装成公钥,n和d封装成私钥
- AES、DES-对称
传送门
- DH交换-非对称
传送门
1.3 web基础知识
- 同源策略
同源策略SOP(同协议,同域名,同端口)
- 跨域的方法(允许跨域 script src a herf img)
- JSONP 通过回调函数来进行跨域获取最终的值(因为是使用script src来调用)
- CORS 通过服务端设置 Access-Control-Allow-Origin 来设置允许的域名来进行跨域
- 现代浏览器常用iFrame来进行跨域
- 通信可以用 postMessage服务端代理来进行跨域,跨域的服务器不受控制。
1.4 数据结构知识
二、安全攻防
2.1 OWASP TOP 10漏洞相关原理
- SQL预编译场景下的攻击和防御
预编译确实是防御SQL注入的有效的安全策略,但是其在一些场景下也存在一定的缺陷,且没有合理使用安全策略、方法同样会带来安全问题,并不是使用了预编译就可以完全防住sql注入。
Mybatis中使用#和是直接拼接SQL的形式。Mybatis中SQL语句以XML文件的形式在配置文件中存在,可以手动写或自动生成。
- Mybatis框架下易产生的三种攻击类型:-传送门
- 模糊查询:
select * from news where title like ‘%#{title}%’
在这种情况下使用#程序会报错,新手程序员就把#号改成了$,这样如果java代码层面没有对用户输入的内容做处理势必会产生SQL注入漏洞。
正确写法:
select * from news where tile like concat(‘%’,#{title}, ‘%’)
* in之后的多个参数
Select * from news where id in (#{ids})
正确用法为使用foreach,而不是将#替换为$
id in#{ids}
* order by 之后
SQL语句中的一些部分,例如order by字段、表名等,是无法使用预编译语句的。这种场景极易产生SQL注入。这种场景应当在Java层面做映射,设置一个字段/表名数组,仅允许用户传入索引值。这样保证传入的字段或者表名都在白名单里面。需要注意的是在mybatis-generator自动生成的SQL语句中,order by使用的也是$,而like和in没有问题。
- XSS的原理以及防御
- 原理
攻击者通过“html”注入,使服务器将用户输入的数据当成代码,攻击者篡改了网页,插入了恶意的脚本,从而在用户浏览网页时,恶意脚本被执行。
* 反射型XSS
* 存储型XSS
* DOM Based XSS
- 反射型XSS和DOM型XSS的区别
DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞。
- 防御手段
- httponly:浏览器禁止javascript访问httponly的cookie
- 输入检测
- 白名单,格式限制(服务端和客户端都得做检查)
- XSS Filter
- 富文本:标签白名单、CSS检测
- 输出检查
- htmlEncode
- 内容安全策略-CSP
- Automatic Context-Aware Escaping
所谓 Context-Aware,就是说模板引擎在解析模板字符串的时候,就解析模板语法,分析出每个插入点所处的上下文,据此自动选用不同的转义规则。这样就减轻了业务 RD 的工作负担,也减少了人为带来的疏漏。
* DOM Based XSS的防御
安全开发规范。比如在使用 .innerHTML、.outerHTML、document.write()时要特别小心,不要把不可信的数据作为HTML插到页面上,而应尽量使用.textContent、.setAttribute() 等。
2.2 CSRF
- 原理
即用户登录了A网站,攻击者在B网站恶意构造了一个A网站的请求(比如删除帖子之类的),然后诱导用户在B网站上点击该链接则用户就会在不知情的情况下进行了一些操作(往往是写操作)。
- 防御
- 服务端
- 验证码
- 影响用户体验,不是最优选择
- referer check
- referer也是用户可控,虽有浏览器限制,但任不可信。可用于监控CSRF的发生,并不能有效防御CSRF
- Token---一致做法
- 不可预测性
- 并不是防止重复提交,可以是生命周期形式,不一定要是一次性
- 防止Token泄露(比如被修改了的恶意referer造成泄露),GET改POST
- 验证码
- 客户端(浏览器)
- SameSite-传送门
- json形式的CSRF
- Django的CSRF防御方案
传送门,CSRF的防御方案一般来说都是token的形式,但是在设计一个CSRF防御体系的时候就需要考虑很多,总结为以下几点:
* token生成和存储
* token的验证
* token的更新
Django的CSRF防御方案中,针对所有的POST的请求都会要求加上csrf_token,对GET请求没有CSRF防御,GET请求在如果在链接中添加token,存在token泄露的风险。且GET请求一般不涉及写操作,在开发规范中限制只有POST请求涉及写操作。
2.3 SSRF
传送门
- 原理
服务器请求伪造,即在正常的业务功能中可能会接受用户传入的url,服务器进行访问,攻击者可以利用此漏洞使用服务器为代理,或攻击内网,或作为攻击代理。所有能发起请求的地方都可能存在该漏洞。
比如:业务场景、从URL上传图片、订阅RSS、爬虫、预览、离线下载、数据库内置功能、邮箱服务器、文件处理、编码处理、属性处理。
协议:file、dict(打redis)、ftp、ftps、tftp、telnet、Gopher、smb、imp等。
- 防御
- 限制协议(比如仅http/https)
- 禁止30x跳转
- 设置URL/IP白名单
- 威胁情报IOC黑名单 + 流量检测
- 在一些业务场景下可能不能使用域名白名单的情况,则需要使用利用威胁情报设置域名黑名单,防止被攻击者恶意利用。
- 针对DNS重绑定的防御
1.TTL=0的域名服务商 2.概率论,解析两个ip 3. 自建DNS
* 威胁情报IOC域名黑名单 + 流量检测
* 恶意DNS服务器限制。黑名单/白名单根据业务场景考虑
- 一些绕过手段
- 更改IP地址写法
- 其他进制写法:8进制格式:0300.0250.0.1
- 省略模式:ipv6绕过、127.1、127.0.0.1.、0
- 利用解析URL出现的问题
- 在某些情况下,后端程序可能会对访问的URL进行解析,对解析出来的host地址进行过滤。这时候可能会出现对URL参数解析不当,导致可以绕过过滤。
http://[email protected]/与http://192.168.0.1请求的都是192.168.0.1的内容
- 利用302跳转
- 302跳转
- http://xip.io和xip.name当我们访问这个网站的子域名的时候,例如192.168.0.1.xip.io,就会自动重定向到192.168.0.1。
- 使用非http协议
- DNS重绑定
2.4 JAVA相关漏洞以及技术栈
2.5 工具相关
- 工具观
- 第一种,知道一个工具是用底层或者其它层的哪些协议/功能的特性去进行测试/工作的,就可以根据当前的需求去找工具对应参数去进行测试/使用,存在不支持的就可以自己修改代码去做。
- 第二种,很了解某个工具,熟悉这个工具各类参数,那在场景中就根据需求去选择参数,但是如果存在参数方法无法做到的情况,人也无法做到,人被工具局限。
- nmap的痛点/缺点/使用时的问题
在需要超时时长较长以及扫描主机数量很大时,使用nmap是很耗时的,因此我们会使用python来多主机调用nmap,或者dnmap,openvas中分布式调用nmap来进行扫描。其是就是大规模整体调度的问题。
- sqlmap的痛点/缺点/使用时的问题
2.6 windows技术栈
- SMB协议
- Kerberos协议原理
- 域知识
2.7 SRC情况/渗透场景/业务安全对抗场景
三、研发技术栈
3.1 前后端相关
- 前端与后端
- 前后端交互
- AJAX前后端交互
- 创建XMLHTTPRequest对象
- 使用open方法设置和服务器的交互信息
- 设置发送的数据,开始和服务器端交互
- 注册事件
- 更新界面
- websocket
- 客户端通过HTTP请求服务器网页;
- 客户端接收请求的网页并在页面上执行JavaScript,该页面从服务器请求文件。
- 当任意端新数据可用时,服务器和客户端可以相互发送消息(所以这个是双向的客户端和服务器连接,及可以互相推送消息)。
- 从服务器到客户端以及从客户端到服务器的实时流量,服务器端支持event loop,使用WebSockets,可以跨域连接服务器。
- eventSource
- 客户端通过HTTP请求服务器网页;
- 客户端接收请求的网页并在页面上执行JavaScript,该页面从服务器请求文件;
- 从服务器到客户端的实时流量,服务器端支持event loop,推送消息(所以这个是单向的服务器推送)。注意只有正确的CORS设置才能与来自其他域的服务器建立连接。
- AJAX前后端交互
3.2 MVC框架
- MVC介绍
* Model(模型)表示应用程序核心,用于处理应用程序数据逻辑的部分,通常模型对象负责在数据库中存取数据。
* View(视图)显示数据,是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
* Controller(控制器)是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。
- Spring MVC
传送门
Spring web mvc和Struts2都属于表现层的框架,它是Spring框架的一部分,我们可以从Spring的整体结构中看得出来:
- Spring web mvc架构
- 处理流程图
* 流程
* 用户发送请求至前端控制器DispatcherServlet.
* DispatcherServlet收到请求调用HandlerMapping处理器映射器.
* 处理器映射器找到具体的处理器,生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet.
* DispatcherServlet调用HandlerAdapter处理器适配器.
* HandlerAdapter经过适配调用具体的处理器(Controller,也叫后端控制器).
* Controller执行完成返回ModelAndView.
* HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet.
* DispatcherServlet将ModelAndView传给ViewReslover视图解析器.
* ViewReslover解析后返回具体View.
* DispatcherServlet根据View进行渲染视图(即将模型数据填充至视图中)。
* DispatcherServlet响应用户
-
四、企业安全建设
4.1 权限设计
- 自主访问控制(DAC)
根据权限表来判断用户是否有某对象的哪些权限。
- 强制访问控制(MAC)
用户与对象都有权限标致。
- 基于角色的访问控制(RBAC)
每个用户关联一个或多个角色,每个角色关联一个或多个权限,从而可以实现了非常灵活的权限管理。
- 基于属性的权限验证(ABAC)
https://www.jianshu.com/p/ce0944b4a903
4.2 安全评估
- 威胁分析
- STRIDE模型
威胁 | 定义 | 对应的安全属性 |
---|---|---|
Spoofing(伪装) | 冒充他人身份 | 认证 |
Tampering(篡改) | 修改数据或代码 | 完整性 |
Repudiation(抵赖) | 否认做过的事 | 不可抵赖性 |
Information Disclosure(信息泄露) | 机密信息泄露 | 机密性 |
Denial of Service(拒绝服务) | 拒绝服务 | 可用性 |
Elevation of Privilege(提升权限) | 未经授权获得许可 | 授权 |
- 风险评估
- DREAD模型
risk = D + R + E + A + D
等级 | 高(3) | 中(2) | 低(1) |
---|---|---|---|
Damage Potential | 获取完全验证权限,执行管理员操作,非法上传文件 | 泄露敏感信息 | 泄露其他信息 |
Reproducibility | 攻击者可以随意再次攻击 | 攻击者可以重复攻击,但有时间限制 | 攻击者很难重复攻击过程 |
Exploitability | 初学者短期能掌握攻击方法 | 熟练的攻击者才能完成这次攻击 | 漏洞利用条件非常苛刻 |
Affected users | 所有用户,默认配置,关键用户 | 部分用户,非默认配置 | 极少数用户,匿名用户 |
Discoverability | 漏洞很显眼,攻击条件很容易获得 | 在私有区域,部分人能看到,需要深入挖掘漏洞 | 发现漏洞极其困难 |
4.3 安全运营
4.4 SDLC
SDLC是一个模型,不断进化,decsecops是一种具体的方法论。SDLC发展会有传统的瀑布模式,还有适应快速开发的敏捷模式。
- 白盒审计
实际上,对于甲方公司来说,完全可以根据开发规范来定制代码审计工具。其核心思想是,并非直接检查代码是否安全,而是检查开发者是否遵守了开发规范。
4.5 Devops/Devsecops
传送门-百度
传送门-腾讯
- Devops
瀑布模式就是 设计-开发-测试-部署
敏捷模式就是 设计-开发-测试-部署---开发-测试-部署---开发-测试-部署
DEVOPS就是 设计-(开发、测试、部署)---(开发、测试、部署)
- Devsecops
SDLC是软件生命开发周期模型,Devsecops是模式、框架、方法。其是SDL各阶段的全流程覆盖的、高自动化集成、强调安全与业务协同的业务安全保障框架。
* 安全左移
* 默认安全
* 运行时安全
* 安全服务自动化/自助化
* 利用基础设施即代码
* 利用持续集成和交付
* 需要组织和文化建设
4.6 入侵检测
传送门
入侵行为和正常行为的区别:微博案例 黑白名单?业务历史行为(基线模型),异常对比,非黑即白
告警:聚和 联动
海量告警:漏报、误报 漏报解决:多个模型,性价比高
检测策略
4.7 数据安全与隐私保护
- 数据安全能力成熟度模型
4.8 办公网安全
4.9 活动反作弊
- 网易活动反作弊-传送门
- 行为式验证码
- 注册/登录保护
- 营销反作弊
- 设备/手机号/邮箱/ip黑名单
- 模拟器/多开工具/群控识别
- 设备篡改识别(root、Xposed、越狱等)
- 具体业务风险模型
- 实人信息认证
- 支付宝小程序营销反作弊-传送门
- 身份特质
- 基础身份特质
- 垃圾注册
- 交易历史
- 作弊交易
- 交易链路异常/交易特征
- 交易方风险
- 交易方可信
- 团伙模型
- 资金链路
- 资金闭环
- 资金网络
- 时空介质
- 设备模拟器/介质关系
- LBS异常
- 身份特质
- 反欺诈技术体系
传送门
4.10 企业安全建设思路
- 梳理拓扑、技术栈
- 了解业务
- 安全建设
- 网络-hids、告警elk、waf
- 主机-nids、补丁、升级
- 应用-sdl、rasp(还有容器、源)
- 办公网-蜜罐、安全培训
- 物理安全-灾备,两地三中心等
- 安全能力输出
- 以人载体输出安全能力
- 以安全产品为载体输出安全能力