面试准备（实时更新）

2021-03-16 本文已影响0人折戟尘风

一、基础学科知识

1.1 计网基础知识

SSL握手-传送门

image.png

* **"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语句组成，其中#拼接是进入预编译形式，而$ 是直接拼接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<foreach collection="ids" item="item" open="("separatosr="," close=")">#{ids} </foreach>

* 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://www.baidu.com@192.168.0.1/与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设置才能与来自其他域的服务器建立连接。

3.2 MVC框架

MVC介绍

image.png

* Model（模型）表示应用程序核心，用于处理应用程序数据逻辑的部分，通常模型对象负责在数据库中存取数据。
* View（视图）显示数据，是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
* Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

Spring MVC

传送门

Spring web mvc和Struts2都属于表现层的框架,它是Spring框架的一部分,我们可以从Spring的整体结构中看得出来:

image.png

Spring web mvc架构
- 处理流程图

image.png

* 流程
    * 用户发送请求至前端控制器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

SDLC是一个模型，不断进化，decsecops是一种具体的方法论。SDLC发展会有传统的瀑布模式，还有适应快速开发的敏捷模式。

白盒审计

实际上，对于甲方公司来说，完全可以根据开发规范来定制代码审计工具。其核心思想是，并非直接检查代码是否安全，而是检查开发者是否遵守了开发规范。

4.5 Devops/Devsecops

传送门-百度

传送门-腾讯

Devops

image.png

瀑布模式就是设计-开发-测试-部署

敏捷模式就是设计-开发-测试-部署---开发-测试-部署---开发-测试-部署

DEVOPS就是设计-（开发、测试、部署）---（开发、测试、部署）

image.png

Devsecops

SDLC是软件生命开发周期模型，Devsecops是模式、框架、方法。其是SDL各阶段的全流程覆盖的、高自动化集成、强调安全与业务协同的业务安全保障框架。

* 安全左移
* 默认安全
* 运行时安全
* 安全服务自动化/自助化
* 利用基础设施即代码
* 利用持续集成和交付
* 需要组织和文化建设

4.6 入侵检测

传送门

入侵行为和正常行为的区别：微博案例黑白名单？业务历史行为（基线模型），异常对比，非黑即白

告警：聚和联动

海量告警：漏报、误报漏报解决：多个模型，性价比高

检测策略

4.7 数据安全与隐私保护

数据安全能力成熟度模型

image.png

4.8 办公网安全

4.9 活动反作弊

网易活动反作弊-传送门
- 行为式验证码
- 注册/登录保护
- 营销反作弊
  - 设备/手机号/邮箱/ip黑名单
  - 模拟器/多开工具/群控识别
  - 设备篡改识别（root、Xposed、越狱等）
  - 具体业务风险模型
- 实人信息认证
支付宝小程序营销反作弊-传送门
- 身份特质
  - 基础身份特质
  - 垃圾注册
- 交易历史
  - 作弊交易
  - 交易链路异常/交易特征
- 交易方风险
  - 交易方可信
  - 团伙模型
- 资金链路
  - 资金闭环
  - 资金网络
- 时空介质
  - 设备模拟器/介质关系
  - LBS异常
反欺诈技术体系

传送门

image.png

4.10 企业安全建设思路

梳理拓扑、技术栈
了解业务
安全建设
- 网络-hids、告警elk、waf
- 主机-nids、补丁、升级
- 应用-sdl、rasp（还有容器、源）
- 办公网-蜜罐、安全培训
- 物理安全-灾备，两地三中心等
安全能力输出
- 以人载体输出安全能力
- 以安全产品为载体输出安全能力

面试准备（实时更新）

一、基础学科知识

1.1 计网基础知识

1.2 密码学知识

1.3 web基础知识

1.4 数据结构知识

二、安全攻防

2.1 OWASP TOP 10漏洞相关原理

2.2 CSRF

2.3 SSRF

2.4 JAVA相关漏洞以及技术栈

2.5 工具相关

2.6 windows技术栈

2.7 SRC情况/渗透场景/业务安全对抗场景

三、研发技术栈

3.1 前后端相关

3.2 MVC框架

四、企业安全建设

4.1 权限设计

4.2 安全评估

4.3 安全运营

4.4 SDLC

4.5 Devops/Devsecops

4.6 入侵检测

4.7 数据安全与隐私保护

4.8 办公网安全

4.9 活动反作弊

4.10 企业安全建设思路

猜你喜欢

热点阅读