一次面试经历有感而写的经验总结

本文作者：小峰（信安之路新晋作者 & 个人公众号i小峰）

此篇是在前一篇的基础上进一步完善的结果，笔者工作时间不长，加上实习的一年勉强算是有 3 年的工作经验，以下内容不排除有技术上的细节错误，但都是根据自己工作经验的总结，从大学开始在真实环境下进行（说好听点）渗透测试，亲身经历了法律法规上对网络安全的严谨态度以及对公民个人信息的重视，不管是大的监管机构还是行业性质的监管机构，各种标准文件一个接一个的相续出台，企业内部也比较重视信息安全，这里庆幸毕业那会没选择做开发，不然就是加班一时爽，一直加班一直爽了。
这两年的工作经历至少经验上还是有一些积累的，感觉能达到平均水平，至少方向上还是没错的。
在甲方可能没有乙方那种每天可以接触不同的企业安全，对不同类型的应用系统进行渗透测试，应急响应也是千奇百怪，什么都可以遇到，这种经验乙方完全胜过甲方，笔者实习加上毕业后一共在乙方待过两年，深有体会，作为一名技术人员，大部分时间不是在做渗透测试、就是在前往客户公司的路上，我的真实感受，技术人员天天工作在最前线，做着最累的活，领导指哪打哪，标准一条龙服务，售前沟通、写方案，签授权，确定好应用系统、主机服务器，就一把梭搞定，写写报告，拉着甲方相关人员开会，一个小项目即便完成。
这些大部分都是一个人完成，相对来说考验也比较多，个人能力提升也比较快，因为甲方是‘爸爸’啊。后来找了一个甲方，主要是想感受一下做‘爸爸’是不是很爽，可能是因为自己的原因，没感觉爽，反而更糟糕，什么都得自己来，无比孤独，对个人的能力要求更高。
简单写一下这一年多的感受，在一个互联网公司，40+ 的应用系统，安全建设之前为零，一位安全工程师需要哪些能力，才能慢慢把安全做下去，只是作为一位安全工程师的角度分享经验，不是负责人也不是管理。
[h3]技术能力方面[/h3]可能这方面是需要依赖公司的实际情况来要求一个人能力大小，对漏洞的理解，这里的理解是指一个常见的漏洞，应用层面、代码层面、网络层面是怎么表现的。
就拿 OWASP TOP 10 来说把，SQL 注入需要从应用层面能快速找到系统中存在注入的地方，知道怎么攻击利用，利用这个漏洞可以达到什么级别破坏性，代码层面需要看懂 php、java、go 是怎么写的，看懂并指导怎么修复，用哪些修复方式，PDO 怎么写可以防范，特殊情况下怎么做过滤，网络层面要知道攻击者数据包是怎么样的，有哪些特征，看日志读懂攻击者做了哪些事情。因为你面对的是开发、架构师、运维、甚至产品，面对面的沟通，必须要给出明确的解决方案。
下面是一些在面试中经常会被问到的一些技术点，大概说一下相关技术介绍，由于每一个技术点深入下去都可以写很多篇文章，所以这里就不深入了。
XSS 漏洞介绍现在 XSS 主要分为反射型 XSS，DOM 型 XSS、存储型 XSS 三种，其实像 XSS 这种漏洞基本都是攻击者通过盗用用户身份悄悄发送一个请求、或执行某些恶意操作。就是攻击者直接参入进来了。
存储型可能就是攻击者将恶意代码写好，可能保存在服务器端，用户在浏览时加载到了这一块的代码就被攻击了，用户自己都不知道，这种攻击可以复用。
反射型就是攻击者构造好一个链接，欺骗点击、加载，当然欺骗的方法很多种，和服务器没有交互，用户就被攻击了。
DOM 型的，在某种意义上也属于反射型的一种，因为和反射型一样具有一次性，不同的是，DOM 型 XSS 是 js 动态执行 DOM 树的时候，由于没有做好防护，被利用了。当然利用方式可能有多种，现在大多是盗用 Cookie，可能之前还会有一些转账、蠕虫、钓鱼等等，现在算是比较少了。
修复的话可以在代码层进行修复，比如做好输入输出的检查、过滤，html 实体编码、js 编码，合理的运用函数，像 Spring 中的 ·

htmlEscape

复制代码

、

escapeHtml

复制代码

，php 中的

htmlspecialchars

复制代码

等等一些函数，也可以在安全设备上进行防御，但是存在一定绕过危险。
CSRF & SSRFCSRF 和 XSS 易混淆，一个是服务端过度相信客户端、一个是客户端过度相信服务端，想一下，客户端来一个请求就是给它返回数据，也不考虑是不是用户主观发送出来的，反正符合就行，管你是不是主观，那谁让你没点安全意识。可能是 GET 或者 POST 类型的，修复主要靠进行同源检测、使用 CSRF Token，CSRF Token 比较官方，现在基本都是前后端分离、服务异地存储，这样就会比较消耗资源，就可以根据实际情况进行分布式的效验，服务端效验时重新计算这个 Token，就解决一部分复杂度和性能问题。
SSRF 主要是利用漏洞对服务器端的内网进行攻击，扫描啊、打 Payload，或其他的一些协议。修复方法主要是限制我们的协议、比喻 HTTP/HTTPS，禁止 302，设置白名单、IP 一些。
JSONP 劫持jsonp 算是一种协议，那这个协议干吗呢，就是用来实现跨域，实现网页可以得到从其它来源动态产生的 json 数据，跨域对吧，那攻击者也可以在自己的虚假页面中发起恶意的 jsonp 请求的，像是一种不担心的跨域问题的 CSRF，可以做 Referer、CSRF Token 一些防护。
fastjson 漏洞最近没有，好久之前的了，记得应该是

1.2.24

复制代码

之前的 RCE，官方 GitHub 修复写的非常详细，是一个加载函数出现的问题，利用构造好的 POST 请求，好像是带个 type，达到命令执行执行的目的。
app 加固、测试app 测试服务端还是 web 那一套，app 客户端安全问题，比喻说是代码混淆、加壳、劫持、四大组件的利用、本地数据的存储，这些都需要一定的开发经验，用谁的加壳、加固，主要是看供应商的技术水平，是不是开源工具就可以轻松的脱壳、反编译，然后还代码为进行混淆，那就是源码直接暴露出来了，可能攻击者进行代码审计，找到一些漏洞，拿到一些有用的 key，然后进行攻击。然后就是一些合规上的要求，一些隐私说明、权限的乱用、个人信息的展示，拿着官方标准研读一下，再不行找找同行是怎么做的，效仿一下。
网络请求上就看是不是做了一些证书双向效验、SSL Pinning，或者 API 统一加密网关、比喻 okhttp 的拦截器，可能 app 用到的 API 会很多，一些接口传输的不是敏感信息，那就直接做一个数据签名，可以用对称算法，key 就放在 so 中，倒是有碰到比较投机取巧方法，将请求参数进行 SHA256 去掉后面 20 位、前面 20 位，保留中间部分，其实目的都是为了保证数据的完整性，即使暴露了，修改数据，签名不过，服务端就直接返回 error。
服务器安全服务器攻击基本就是主机操作系统以及运行在上面的服务，windows、Linux，基线、补丁做好，各个主机间的隔离做好，上面起的服务应用层出现的漏洞就另说了，一般攻击思路主要是做一些端口扫描、网段扫描、服务扫描，利用一些弱点、协议构造一些请求进行攻击，比较好的工具 metasploit、nmap，就看你利用的熟练程度，我之前用过的关于服务器漏洞扫描的工具还是挺多的，基本大多数都是基于 banner 信息反馈存在的漏洞，有好些扫描工具都是扫出来一片红，可能能利用没有几个，这个时候就需要人工判断，对业务的影响是否需要修复，或者在一些前置设备上进行防护。
漏洞挖掘漏洞挖掘很少，可能会在生活中用到的一些，比喻碰到用快递柜寄快递，不去研究，就不知道原来可以拿到所有用过的用户个人信息，像骑共享单车，可能会想着这个地方会出现问题，从上家离职的时候，进入现在这个行业，会对这个行业的企业简单看看，也会找到很多问题，业务逻辑问题相对多点，都交到 CNVD 了，毕竟还是官方，我觉得靠谱、保险。
相对来说，我在线下模拟的比较多，出现的新漏洞，比较有代表性的漏洞，本地搭建环境，可以在虚拟机或者 docker中进行部署，一个是为了知道怎么攻击利用，还有就是为了看攻击的数据包，做一些记录，这样方便以后快速发现漏洞，在应急的时候也会比较快的找出原因，攻击者怎么利用的。
[h3]安全建设方面[/h3]API 接口安全现在大多数服务端都是各个 API 调来调去，权限验证，有 SSO 的、有用分布式 Session 的，我们主要业务就是几个 App，里面很多 API 调用，刚来的时候发现很多的业务逻辑问题，现在都修复了，要求涉及个人权限认证的统一使用 Session 中的字段，后台进行效验，不完全依赖前端传过来的数据，主要这个 session 是后端在登陆成功时下发的，攻击者没办法伪造。现在架构都趋向微服务，将接口拆得更细，存放的位置可能不同，session 的存放有变成了一个问题。
解决方案可以使用 JWT，比较通用，也是现在比较流行的解决方案，第一段给出了加密方式，第二段放一下用户唯一标识符，过期时间，第三段就是签名，key 在服务端，签名也是在后端完成的，后端到用户、前端到后端的中间过程攻击者就没办法修改这个数据包了，修改完了，签名不过，就不行，不过 jwt 不注意也会有一些小问题，比如禁止 none 的加密方式，如果配置错误就会被攻击者利用，因为 jwt 是每个人都可以解密的，修改加密方式为 none，这样在后台验证是就会通过，从而绕过了验证环节，jwt 对所有人是透明的，可以明文看到里面的数据，所以也不可以保存敏感信息在 jwt 字符串中，还有就是加密用到的 key 值，我之前试过 4 位数的加密 key，2 分钟就可以跑出来，16G、7 代 i5、4 核 Mac，所以设计时这个 key 需要长点、复杂点，再者可能就是销毁问题了，因为 jwt 是无状态的，可能用户退出后，这个 Token 还能用，这里有些思路，比如根据 jwt 里的过期时间来销毁。
再者就是防刷，防刷其实大部分攻击场景是反爬，之前我们有用过某云的产品，做业务风控，主要就是接口的防刷，它是怎么做的呢，第一是根据频率，有几种配置，可以在发现频率高了，web 直接推送验证码，比如图形验证码、滑块验证码，这种可能对用户体验度不好，产品那边不同意，还有就是推 js，后台用发送一些 js 逻辑，这个逻辑需要浏览器去解析运算，得到的结果跟着下一次请求发送到后端，一般的脚本刷接口就可以屏蔽掉了，可是现在 selenium、chrome driver 一些自动化软件的使用，这种也是可以绕过的，只不过成本比较高了，测试中发现，某云的接口防刷功能也是不严谨，触发规则后，浏览器算出来的这个字符串在半个小时内是有效的，那么这半个小时对于攻击者来说，就没什么门槛了，有点像 csrf token 也是这样一种逻辑，就看攻击者的技术能力了。具体还是看业务场景吧，这种我感觉和业务场景依赖比较高。
如果是客户端做的比较好的就是防范中间人劫持，进行证书验证，如果截取不到流量数据，可以说是能防范一半的攻击，安全性提高一个层次，但也会带来性能上的问题，根据实际情况进行取舍。
SDL 实施上家公司安全建设可能也不会有很长时间，人员也比较少，SDL 能做可能就是周期性的面向后台人员、测试、开发进行安全意识、安全测试、安全开发培训，可以拿一些实例进行讲解，这样他们比较有兴趣。然后就是做一些安全评审、需求、开发，上线时的安全测试、主机的安全加固等等。
再就是黑白盒测试，白盒没有商用产品，就是简单的使用 sonar 中的 findbugs 做一些，质量部有 sonar 平台，代码打包就会触发扫描，findbugs 的规则自己把一些认为没用的、效果不好的就关闭掉，一些比较有用的，确实可以检测出问题的就留下来，结果的话就人工去核实，当然也可以自定义规则主要是 java 不熟悉，xpath 语法也不熟悉，就没弄。黑盒主要利用 Mitmproxy 进行数据包的获取，功能测试安装证书，配上代理，统一收集数据， Mitmproxy 自带的类很丰富，自己简单写些 python 脚本处理、格式化一些，主要是 url 的去重，保留 session 一些认证信息，这样基本可以很全的拿到带登陆太的接口数据，因为 appscan、wvs 这种对 ajax 请求没法爬取链接，就没法扫描，拿到这些构造请求发送到 arachni 扫描引擎中，通过对比 arachni 的扫描效果还是不错的，而且 API 比较详细。
剩下可做的就是应急响应了，之前会做很多的告警措施，通过告警到钉钉，人工确认，进行事件的应急，比如一些攻击者的 web 攻击，一些公开的最新漏洞，之前的挖矿病毒等等，可能在甲方不太关注应急响应标准流程步骤，但是之前会有一系列的规范，确定各个业务线的接口人，这样找起来也比较快，加上之前漏洞修复也会知道各个业务线的对应的开发、运维，碰到一些事件首先判断出事件类型，影响范围，进行网络隔离，确保不会让事件再继续恶化下去，后续会有针对恶意文件的研究，包括攻击溯源，分析脚本执行的一系列动作，最后进行加固。
当然应急响应对技术人员的要求也非常高，平时多会关注网上别人应急的一些文章，一些新漏洞的攻击手法，需要本地模拟，分析攻击的数据包，这样在应急的时候至少心里有那样一个事，看一些日志文件，以及服务、主机的弱点会想到攻击者怎么利用，这样在应急时也会很快，不至于束手无策。
安全评审流程其实我们也不是每个功能都会做，如果每个点都做的话，一个人做不过来的，现阶段主要是前期做数据安全的时候定义好了哪些属于敏感数据，涉及到用户传入参数对我们数据库进行操作的一些功能，产品、开发会拉上安全进行评审，比如一些接口需要不需要加密、签名、防重，权限怎么效验，敏感数据需不需要脱敏、主要是安全、法规上的一些要求，这样的话可能比较精确，也不会浪费时间。
漏洞管理实施漏洞管理还比较好，毕竟这个是看得见的，如果不修复就会对公司业务产生影响，比较直接，有的甲方可能会有专门的运营来做这件事情，安全工程师只需要指出哪里出问题、修复后的复测，不关心漏洞跟踪，团队比较少的时候就是一个人干，发现问题在钉钉群里面发出来，每个大的业务线都有一个漏洞跟踪群，发现说一次，修复说一次，系统比较多，线上系统可能就是每个季度进行一次全面的安全测试，上线、临时项目就是另外针对性测试，有漏洞、有问题就直接落实到个人，具体哪个开发，直接过去，咱们翻代码，流程对一遍，看是哪个地方出现的问题，怎么修复，我比较喜欢这种方式，这样的效率比较高。当然、首先你的懂 java、php、go 这些语言，可能比较大的漏洞问题，涉及的人员比较多、业务复杂，就会拉上开发、产品、架构师开会，商量好方案，排期修复，修复好了，也是在群里面说一下，然后去复测。
后来搭建了一套宜信开源的漏洞管理，里面有些功能不适合我们现在架构，我就简单改一些代码，python 写的，读一遍源码，改起来也比较容易，毕竟符合公司现阶段的才是最好的。目前是还没有进行处罚制度，只需要和技术部门负责人定好漏洞的等级，各个等级漏洞多长时间修复，这个是各个负责人都同意的方案，就会在后面修复的时候比较好排期，开发都很配合，也还好。
应急事件处理应急响应可能是一个比较大的系统概念，从前期准备阶段，建立一些应急响应的文档，包括事件的定级、是 web 攻击、恶意软件还是勒索病毒，确定对应的接口责任人，包括一些工具使用等等。
到事件的监测，这里可能很多企业不一样，有的买有很多设备，一部分取决去这些设备的好坏，平民化攻击是可以监测出来，稍微来点绕过、高级的攻击手法就没法检测了，或者是依据 web 日志、主机日志的分析平台，不管是基于规则的还是基于行为分析的，甚至是一些大数据识别的，看你从哪个维度分析，是不是可以检测出来，误报率、漏报率，这些都是关键参数。
检测出来后可能就到了真正事件的处理过程，在处理中就是体现技术人员的水平了，是不是能快速的识别属于哪种攻击事件，可能的攻击途径有哪些，根据一系列的日子、流量能不能快速找到攻击手法，确定好原因，再就是根据个人经验判断攻击者接下来的思路是什么，要干什么，基本上攻击事件背后都是利益驱使，那攻击就会产生的一定利益，如何快速的制定临时解决方案，使得损失降到最小，接下来就是制止，防止事件进一步的发展，比如对应用造成持续影响，服务器持续感染等等。
基本上应急处理完成了，就要进行分析，攻击溯源，还原整个攻击过程，制定长久的解决方案，有漏洞就修复上线，缺少补丁的就打补丁，持续一段时间的监控，业务是否稳定，毕竟安全所做的还是服务于业务。
安全分析平台关于这方面，一个人的精力是有限的，没有人员的支撑，我可能就只能做一部分，搭建 ELK 平台，开源嘛，搭建调通，起码首先做的能运行起来吧，再就是收集日志，像一些蜜罐日志、防病毒日志、waf 日志、nginx 日志。
蜜罐平台是我自己搭建的，开源蜜罐很多，通过对比总有一款适合的，节点可以放在公司的办公网，离线测试机房，服务器用的云服务，相对来说网络隔离做的比较好，我就没有放，蜜罐节点和蜜罐服务端怎么网络打通，需要哪些日志推到 ES 里面，蜜罐维护，这些花一定的时间就可以搞定了，效果还不错，发现了一些问题，nginx 日志数据了会比较大，就直接利用公司现有 kafka，直接读里面的数据。后来有折腾了一下，将蜜罐打包 docker，这样以后安装节点就方便了，就学了一段时间 docker，简单的写 dockerfile、docker-compose 还是没问题的，怎么映射端口、挂在路径，这些本地多模拟模拟，学习技术就是要不停的实验，这样学的比较快，ES 的查询也是的，语法熟悉了，在后面应急的时候很有帮助。
推送数据这部分用的 logstash、filebeat，看你怎么选择吧，一个基于 jvm，比较耗内存、一个基于 c，编写一些格式化语法，推送到 ES，最后在 kibana 中配置源基本展示没什么大问题。
告警用的是 watcher 插件，比较好用，相对规则、统计的维度也比较灵活，其实发现攻击事件，主要就是你制定的规则，从哪些角度去聚合数据，考虑攻击者可能绕过的一些思路，比喻攻击者用非常多的高匿 IP，自定义 agent、post 请求 nginx 一般不记录一些情况，从中找到一个比较好的维度、多维度聚合数据，比喻说一个场景攻击者需要登录才可以进行攻击，获取我们的数据，那么可以从 session 这个维度，一分钟请求多少次，设置一个阈值，多了就告警，这样攻击者用了 IP，随机 agent 也没用了。这样发现率就会提升很多，告警出来，再人工的去核对，就相对单一维度告警，误报会降低很多。
[h3]未来规划[/h3]重复问题 ------
=====================
明确目标，提高效率，这样能力不自觉就会有所提升。
[h3]推荐阅读[/h3]原创大型公司安全技术岗位面试杂谈
原创从面试题中学安全