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

会员服务 ·

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

2019 年 10 月 8 日 黑客技术与网络安全

来自公众号：i小峰

以下内容根据真实情况编写。

一面——安全工程师

1、XSS的分类、利用和修复

常规的技术问题，XSS大面上主要分为反射型XSS，DOM型XSS、存储型XSS，其实想XSS这种漏洞基本都是攻击者通过盗用用户身份悄悄发送一个请求、或执行某些恶意操作。就是攻击者直接参入进来了。

存储型可能就是攻击者将恶意代码写好，可能保存在服务器端，用户在浏览时加载到了这一块的代码就被攻击了，用户自己都不知道，这种攻击可以复用。

反射型就是攻击者构造好一个链接，欺骗点击、加载，当然欺骗的方法很多种，和服务器没有交互，用户就被攻击了。

DOM型的，在某种意义上也属于反射型的一种，因为和反射型一样具有一次性，不一样的是，DOM型是js动态执行DOM树的时候，由于没有做好防护，被利用了。当然利用方式可能有多种，现在大多是盗用Cookie比较有用，可能之前还会有一些转账、蠕虫、钓鱼等等，现在算是比较少了。

修复的话可能在源代码层进行修复，比喻做好输出输入的检查、过滤，比喻html实体编码、js编码，比喻Spring中的htmlEscape，或者escapeHtml一些函数，也可以在安全设备上进行防御，但是存在一定绕过危险。

2、JSONP劫持

jsonp算是一种协议，那这个协议干吗呢，就是用来实现跨域，实现网页可以得到从其他来源动态产生的json数据，跨域对吧，那攻击者也可以在自己的虚假页面中发起恶意的jsonp请求的，属于CSRF吧，不担心的跨域问题的CSRF，可以做refer、CSRF Token一些防护，当然这些也可以被攻破。

3、CSRF&SSRF区别

CSRF和XSS一个是服务端过度相信客户端、一个是客户端过度相信服务端，想一下，客户端来一个请求就是给它返回数据，也不考虑是不是用户主观发送出来的，反正符合就行，管你是不是主管，那谁让你没点安全意识。

SSRF主要是利用漏洞对服务器端的内网进行攻击，扫描啊、打Payload，或其他的一些协议。修复方法主要是限制我们的协议、比喻HTTP/HTTPS，禁止302，设置白名单、IP一些。

4、说说fastjson漏洞

最近没有，好久之前的了，记得应该是1.2.24之前的RCE，官方GitHub修复写的非常详细，是一个加载函数出现的问题，利用构造好的POST请求，好像是带个type，达到命令执行执行的目的。

5、app的加固和测试

其实大部分app的测试还是web那一套，除了app本身的一些加固，比喻说是代码混淆、加壳、劫持、四大组件的利用、本地数据的存储，其实这些还好，用谁的加壳、加固，主要是看供应商的技术水平，是不是开源工具就可以轻松的脱壳、反编译，还不做代码混淆，那就是源码直接暴露出来了，可能攻击者进行代码审计，找到一些漏洞，拿到一些有用的key。

网络请求上就看是不是做了一些证书双向效验、SSL Pinning，或者API统一加密网关，可能app用到的API会很多，一些重要的接口有不是敏感信息，那就直接做一些数据签名，可以用对称算法，key就放在so中，倒是有碰到比较投机取巧方法，将请求参数进行SHA256去掉后面20位、前面20位，保留中间部分，其实都是为了保证数据的完整性，即使暴露了，修改数据，签名不过，服务端就直接返回error。

6、比较有意思的漏洞挖掘

漏洞挖掘很少，可能会在生活中用到的一些，比喻碰到用快递柜寄快递，不去研究，就不知道原来可以拿到所用用过的用户的很多个人信息，后来交到CNVD了，像骑共享单车是，可能会想着这个地方会出现问题，也是一样交到CNVD了，从上家离职的时候，进入在线教育这个行业，会对这个行业的一个企业简单看看，也会找到很多问题，业务逻辑问题相对多点，也都交到CNVD了，毕竟还是官方，比较靠谱、保险。

在线下模拟的比较多，出现的新漏洞，比较有代表性的漏洞，本地搭建环境，可以在虚拟机或者docker中进行部署，一个是为了知道怎么攻击利用，还有就是为了看攻击的数据包，做一些记录，这样方便以后快速发现漏洞，在应急的时候也会比较快的找出原因，攻击者怎么利用的。

7、服务器安全测试

服务器的攻击基本就是主机了，windows、Linux，基线、补丁做好，各个主机间的隔离做法，上面起的服务出现的漏洞就另说了，一般攻击思路主要是做一些端口扫描、网段扫描、服务扫描，利用一些弱点、协议构造一些请求进行攻击，比较好的工具metasploit，就看你利用的熟练程度，我之前用过的关于服务器漏洞扫描的工具还是挺多的，基本大多数都是基于banner信息反馈存在的漏洞，有好些扫描工具都是扫出来一片红，可能能利用没有几个，这个时候就需要人工判断，对业务的影响时候需要修复，或者在一些前置设备上进行防护。

二面—— 安全部总监

1、SDL实施的成果

上家公司安全建设可能也不会有很长时间，人员也比较少，SDL能做可能就是周期性的面向后台人员、测试、开发进行安全意识、安全测试、安全开发培训，可以拿一些实例进行讲解，这样他们比较有兴趣。然后就是做一些安全评审、需求、开发，上线时的安全测试、主机的安全加固等等。

再就是黑白盒测试，白盒没有商用产品，就是简单的使用sonar中的findbugs做一些，质量部有sonar平台，代码打包就会触发扫描，findbugs的规则自己把一些认为没用的、效果不好的就关闭掉，一些比较有用的，确实可以检测出问题的就留下来，结果的话就人工去核实，当然也可以自定义规则主要是java不熟悉，xpath语法也不熟悉，就没弄。黑盒主要利用Mitmproxy进行数据包的获取，功能测试安装证书，配上代理，统一收集数据，Mitmproxy自带的类很丰富，自己简单写些python脚本处理、格式化一些，主要是url的去重，保留session一些认证信息，这样基本可以很全的拿到带登陆太的接口数据，因为appscan、wvs这种对ajax请求没法爬取链接，就没法扫描，拿到这些构造请求发送到arachni扫描引擎中，通过对比arachni的扫描效果还是不错的，而且API比较详细。

剩下可做的就是应急响应了，之前会做很多的告警措施，通过告警到钉钉，人工确认，进行事件的应急，比喻一些攻击者的web攻击，一些公开的最新漏洞，之前的挖矿病毒等等，可能在甲方不太关注应急响应标准流程步骤，但是之前会有一系列的规范，确定各个业务线的接口人，这样找起来也比较快，加上之前漏洞修复也会知道各个业务线的对应的开发、运维，碰到一些事件首先判断出事件类型，影响范围，进行网络隔离，确保不会让事件再继续恶化下去，后续会有针对恶意文件的研究，包括攻击溯源，分析脚本执行的一系列动作，最后进行加固。

忘记写到哪了，主要是换乘，走路的时候最好别玩手机，倒是摔一跤都不知道牙掉了几个，没找到座位，站着、MMP，这么多人，大周末的

当然应急响应对技术人员的要求也非常高，平时多会关注网上别人应急的一些文章，一些新漏洞的攻击手法，需要本地模拟，分析攻击的数据包，这样在应急的时候至少心里有那样一个事，看一些日志文件，以及服务、主机的弱点会想到攻击者怎么利用，这样在应急时也会很快，不至于束手无策。

2、安全评审流程

其实我们也不是每个功能都会做，如果每个点都做的话，做不过来的，现阶段主要是前期做数据安全的时候定义好了哪些属于敏感数据，涉及到用户传入参数对我们数据库进行操作的一些功能，产品、开发会拉上安全进行评审，比喻一些接口需要不需要加密、签名、防重，权限怎么效验，敏感数据需不需要脱敏、主要是安全、法规上的一些要求，这样的话可能比较精确，也不会浪费时间。

3、漏洞管理实施

漏洞管理还比较好，毕竟这个是看得见的，如果不修复就会对公司业务产生影响，比较直接，有的可能会有专门的运营来做这件事情，安全测试只需要指出哪里出问题、修复后的复测，不关心漏洞跟踪，团队比较少的时候就是一个人干，发现问题在钉钉群里面发出来，每个大的业务线都有一个漏洞跟踪群，发现说一次，修复说一次，线上系统可能就是每个季度进行一次全面的安全测试，上线、临时项目就是另外针对性测试，有漏洞、有问题就直接落实个人，具体哪个开发，直接过去，咱们翻代码，流程对一遍，看是哪个地方出现的问题，怎么修复，对吧，这样的效率比较高，当然、首先你的懂java、php、go这些语言，可能比较大的问题，涉及的人员比较多、业务复杂，就会拉上开发、产品、架构师开会，商量好方案，排期修复，修复好了，也是在群里面说一下，然后去复测，后来搭建了一套宜信开源的漏洞管理，有些不适合我们现在架构，就简单改一些代码，符合公司自身的才是好的，python写的，读一遍源码，改起来也比较容易。目前是还没有进行赏罚制度，只是会和技术部门负责人定好漏洞的等级，各个等级漏洞多长时间修复，这个是各个负责人都同意的方案，就会在后面修复的时候比较好排期，开发都很配合，也还好。

4、未来规划

重复问题 ------

中间hr过来聊了一会，可以忽略。。。

四面 —— 技术vp

1、应急事件处理

应急响应可能是一个比较大的系统概念，从前期准备阶段，建立一些应急响应的文档，包括事件的定级、是web攻击、恶意软件还是勒索病毒，确定对应的接口责任人，包括一些工具使用等等。

到事件的监测，这里可能很多企业不一样，有的买有很多设备，一部分取决去这些设备的好坏，平民化攻击是可以监测出来，稍微来点绕过、高级的攻击手法就没法检测了，或者是依据web日志、主机日志的分析平台，不管是基于规则的还是基于行为分析的，甚至是一些大数据识别的，看你从哪个维度分析，是不是可以检测出来，误报率、漏报率，这些都是关键参数。

检测出来后可能就到了真正事件的处理过程，在处理中就是体现技术人员的水平了，是不是能快速的识别属于哪种攻击事件，可能的攻击途径有哪些，根据一系列的日子、流量能不能快速找到攻击手法，确定好原因，再就是根据个人经验判断攻击者接下来的思路是什么，要干什么，基本上攻击事件背后都是利益驱使，那攻击就会产生的一定利益，如何快速的制定临时解决方案，使得损失降到最小，接下来就是制止，防止事件进一步的发展，比喻对应用造成持续影响，服务器持续感染等等。

基本上应急处理完成了，就要进行分析，攻击溯源，还原整个攻击过程，制定长久的解决方案，有漏洞就修复上线，缺少补丁的就打补丁，持续一段时间的监控，业务是否稳定，毕竟安全所做的还是服务于业务。

2、API权限验证防刷

现在大多数服务端都是各个API调来调去，有SSO的、有用分布式Session的，我们主要业务就是几个App，里面可能很多API调用，之前刚来的时候发现很多的业务逻辑问题，基本什么样的业务逻辑都遇到过，现在都修复了，涉及个人权限认证的统一使用Session中的字段，后台进行效验，主要这个session是后端在登陆成功是下发的，攻击者被办法伪造。现在架构都趋向微服务，将接口拆得更细，存放的位置可能不同，session的存放就是一个问题。

解决方案就是使用JWT，比较通用，也是现在比较流行的解决方案，第一段给出了加密方式，第二段可以放一下用户唯一标识符，过期时间，第三段就是签名，key在服务端，签名也是在后端完成的，后端到用户、前端到后端的中间过程攻击者就没办法修改这个数据包了，修改完了，签名不过，就不行，不过jwt也有一个小问题，比喻禁止none的加密方式，如果配置错误就会攻击者利用，应为JWT是每个人都可以解密的，可以明文看到里面的数据，所以也不可以保存敏感数据在jwt字符串中，修改加密方式为none，这样在后台验证是就会通过，从而绕过了验证环节，还有就是key的值，我之前试过4位数的加密key，2分钟就可以跑出来，16G、7代i5、4核Mac，所以设计时这个key得长点、复杂点，在者可能就是销毁问题了，应为jwt是无状态的，可能用户推出后，这个Token还能用，这里有些设计，比喻根据jwt的过期时间来销毁。

防刷其实大部分攻击场景是反爬，之前我们有用过某云的产品，做业务风控，主要就是接口的防刷，它是怎么做的呢，第一是根据频率，有几种配置，可以在发现频率高了，web直接推送验证码，比喻图形验证码、滑块验证码，这种可能对用户体验度不好，产品那边不同意，还有就是推js，后台用发送一些js逻辑，这个逻辑需要浏览器去解析运算，得到的结果跟着下一次请求发送到后端，一般的脚本刷接口就可以屏蔽掉了，可是现在selenium、chrome driver一些自动化软件的使用，这种也是可以绕过的，只不过成本比较高了，测试中发现，某云的接口防刷功能也是不严谨，触发后浏览器算出这个字符串在半个小时内是有效的，那么这半个小时对于攻击者来说，就没什么门槛了，有点像csrf token也是这样一种逻辑，就看攻击者的技术能力了。具体还是看业务场景吧，这种我感觉和业务场景依赖比较高。

3、安全分析平台建设

关于这方面，一个人的经历是有限的，没有人员的支撑，我可能就只能做一部分，搭建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也没用了。这样发现率就会提升很多，告警出来，再人工的去核对，就相对单一维度告警，误报会降低很多。

======

可能还有几个小问题忘记了，忘记就忘记了吧，权当记录一下，我就搞不明白了，就一基层的小安全工程师，天天工作在最前线，做着最累的活，哪来这么多的问题，拿来应用系统、主机服务器，会攻击就完了，一把梭搞定，多爽。

●编号958，输入编号直达本文

●输入m获取文章目录

推荐↓↓↓