大型企业渗透测试个人去做怎么做？

我认为步骤应该是信息搜集，扫描，入侵，内网渗透这么个思路，实际上他在问的时候，我并不知道他想让我回答什么内容。我刚提到信息搜集，就开始下一个问题了。

安全模式下绕过php的disable fuction

DL函数，组件漏洞，环境变量。

这个当时没答出来。

SQL头注入点

UA

REFERER

COOKIE

IP

php中命令执行涉及到的函数

eval()、assert()、popen()、system()、exec()、shell_exec()、passthru()、pcntl_exec()等函数

反引号，花括号嵌套

文件包含可能导致命令执行

正则表达式 /e 修饰

creat_fuction

金融行业常见逻辑漏洞

单针对金融业务的，我认为除了通用性以外的，主要是数据的篡改(涉及金融数据，或部分业务的判断数据)，由竞争条件或者设计不当引起的薅羊毛，交易/订单信息泄露，水平越权对别人的账户查看或恶意操作，交易或业务步骤绕过。其他我也不太清楚

SSRF漏洞的成因 防御 绕过

成因：模拟服务器对其他服务器资源进行请求，没有做合法性验证。

利用：构造恶意内网IP做探测，或者使用其余所支持的协议对其余服务进行攻击。

防御：禁止跳转，限制协议，内外网限制，URL限制。

绕过：使用不同协议，针对IP，IP格式的绕过，针对URL，恶意URL增添其他字符，@之类的。301跳转+dns rebindding。

FFMPEG 本地文件读取漏洞原理

我认为简而言之就是通过调用加密API将payload加密放入一个会被执行的段字节中。但是具体回答工程中我只回答了SSRF老洞，m3u8头，偏移量，加密，还有其他部分模糊的提及了一下。感觉还应该提一个文件格式的问题。面试官问我这是不是去年的FFMPEG的漏洞，我也不知道是我说的不对还是他听的不对。

常用WEB开发JAVA框架

STRUTS,SPRING

常见的java框架漏洞

其实面试官问这个问题的时候我不太清楚他要问什么，我提到struts的045 048，java常见反序列化。然后面试官说RMI什么什么的，当时这段话没太听清，由于我不知道他想问什么我就提了知道的几个漏洞。

045 错误处理引入了ognl表达式

048 封装action的过程中有一步调用getstackvalue递归获取ognl表达式

反序列化 操作对象，通过手段引入。apache common的反射机制、readobject的重写，其实具体的我也记不清楚，然后这部分就结束了

小结

刚和大佬交流了一下，可能存在的问题还是对知识点的掌握和心态上。笔试和面试是不一样的。平时如果只是看paper的话，可能对一些基本的点会知道，但是对复现过程中的坑点和整个的逻辑就会有问题，别人一问你就知道只看过paper没深入过。经验的话我自己觉得还是多去做，多遇到不同类型的情况，心里对这个比较熟了在回答的时候才能回答的完善，如果经常性的不接触会导致一下子想不起来吧。

同源策略

同源策略限制不同源对当前document的属性内容进行读取或设置。

不同源的区分：协议、域名、子域名、IP、端口，以上有不同时即不同源。

DOM型和反射型的区别是什么，根本区别是什么？如果针对DOM型XSS做扫描器，怎么去做，人工确认DOM型XSS，怎么去确认。给客户做XSS的时候，怎么提修补建议？

DOM型和反射型的区别

反射型XSS：通过诱导用户点击，我们构造好的恶意payload才会触发的XSS。

反射型XSS的检测我们在每次请求带payload的链接时页面应该是会带有特定的畸形数据的。

DOM型：通过修改页面的DOM节点形成的XSS。

DOM-based XSS由于是通过js代码进行dom操作产生的XSS，所以在请求的响应中我们甚至不一定会得到相应的畸形数据。

根本区别在我看来是输出点的不同。

对于XSS怎么提修补建议

输入点检查：对用户输入的数据进行合法性检查，使用filter过滤敏感字符或对进行编码转义，针对特定类型数据进行格式检查。针对输入点的检查最好放在服务器端实现。

输出点检查：对变量输出到HTML页面中时，对输出内容进行编码转义，输出在HTML中时，对其进行HTMLEncode，如果输出在Javascript脚本中时，对其进行JavascriptEncode。

对使用JavascriptEncode的变量都放在引号中并转义危险字符，data部分就无法逃逸出引号外成为code的一部分。还可以使用更加严格的方法，对所有数字字母之外的字符都使用十六进制编码。此外，要注意在浏览器中，HTML的解析会优先于Javascript的解析，编码的方式也需要考虑清楚，针对不同的输出点，我们防御XSS的方法可能会不同，这点可能在之后的文章会做下总结。

除此之外，还有做HTTPOnly对Cookie劫持做限制。

DOM型XSS 自动化测试或人工测试

人工测试思路：找到类似document.write、innerHTML赋值、outterHTML赋值、window.location操作、写javascript:后内容、eval、setTimeout 、setInterval 等直接执行之类的函数点。找到其变量，回溯变量来源观察是否可控，是否经过安全函数。

自动化测试参看道哥的博客，思路是从输入入手，观察变量传递的过程，最终检查是否有在危险函数输出，中途是否有经过安全函数。但是这样就需要有一个javascript解析器，否则会漏掉一些通过js执行带入的部分内容。

在回答这段问题的时候，由于平时对客户的检测中，基本是凭借不同功能点的功能加上经验和直觉来进行检测，对不同类型的XSS检测方式实际上并没有太过细分的标准化检测方式，所以回答的很烂。。。

CSRF中，token和referer做横向对比，谁安全等级高？对referer的验证，我们应该从什么角度去做？如果我们做，怎么杜绝刚才提出的问题，怎么发出空referer头的请求？针对token，对token测试会注意哪方面内容，会对token的哪方面进行测试？

token和referer做横向对比，谁安全等级高？

token安全等级更高，因为并不是任何服务器都可以取得referer，如果从HTTPS跳到HTTP，也不会发送referer。并且FLASH一些版本中可以自定义referer。

但是token的话，要保证其足够随机且不可泄露。(不可预测性原则)

对referer的验证，从什么角度去做？如果做，怎么杜绝问题

对header中的referer的验证，一个是空referer，一个是referer过滤或者检测不完善。

`

为了杜绝这种问题，在验证的白名单中，正则规则应当写完善。

针对token测试会注意哪方面内容，会对token的哪方面进行测试？

引用一段请教前辈的回答：

针对token的攻击，一是对它本身的攻击，重放测试一次性、分析加密规则、校验方式是否正确等，二是结合信息泄露漏洞对它的获取，结合着发起组合攻击

信息泄露有可能是缓存、日志、get，也有可能是利用跨站

很多跳转登录的都依赖token，有一个跳转漏洞加反射型跨站就可以组合成登录劫持了

另外也可以结合着其它业务来描述token的安全性及设计不好怎么被绕过比如抢红包业务之类的

如何生成一个安全的随机数？

引用之前一个学长的答案，可以通过一些物理系统生成随机数，如电压的波动、磁盘磁头读/写时的寻道时间、空中电磁波的噪声等。

Jsonp安全攻防技术，怎么写Jsonp的攻击页面？

涉及到Jsonp的安全攻防内容

JSON劫持、Callback可定义、JSONP内容可定义、Content-type不为json。

攻击页面

JSON劫持，跨域劫持敏感信息，页面类似于

function wooyun(v){

alert(v.username);

}

Content-type不正确情况下，JSONP和Callback内容可定义可造成XSS。

JSONP和FLASH及其他的利用参照知道创宇的JSONP安全攻防技术。

XSS，能打到后台，但是后台系统处于内网，怎么做内网探测？

简单的方法是使用beef得到一个shell，然后结合msf使用。

除此之外的方法目前还没找到，等过两天找找相关文章再看。

宽字节注入产生原理以及根本原因

产生原理

在数据库使用了宽字符集而WEB中没考虑这个问题的情况下，在WEB层，由于0XBF27是两个字符，在PHP中比如addslash和magic_quotes_gpc开启时，由于会对0x27单引号进行转义，因此0xbf27会变成0xbf5c27,而数据进入数据库中时，由于0XBF5C是一个另外的字符，因此\转义符号会被前面的bf带着呗"吃掉"，单引号由此逃逸出来可以用来闭合语句。

根本原因

character_set_client(客户端的字符集)和character_set_connection(连接层的字符集)不同,或转换函数如，iconv、mb_convert_encoding使用不当。

解决办法

统一数据库、Web应用、操作系统所使用的字符集，避免解析产生差异，最好都设置为UTF-8。

或对数据进行正确的转义，如mysql_real_escape_string+mysql_set_charset的使用。

sql注入中，盲注是什么？怎么盲注？

盲注是在SQL注入攻击过程中，服务器关闭了错误回显，我们单纯通过服务器返回内容的变化来判断是否存在SQL注入和利用的方式。盲注的手段有两种，一个是通过页面的返回内容是否正确(boolean-based)，来验证是否存在注入。

一个是通过sql语句处理时间的不同来判断是否存在注入(time-based)，在这里，可以用benchmark，sleep等造成延时效果的函数，也可以通过构造大笛卡儿积的联合查询表来达到延时的目的。

SSL握手过程

建立TCP连接、客户端发送SSL请求、服务端处理SSL请求、客户端发送公共密钥加密过的随机数据、服务端用私有密钥解密加密后的随机数据并协商暗号、服务端跟客户端利用暗号生成加密算法跟密钥key、之后正常通信。

总结与反思：

基本问的大部分问题都可以在《白帽子讲Web安全》中看到，但是当时在面试的时候却回答的不是很理想。事后想想有几个原因，一是紧张，在面试官提问后到回答的一段时间中无法正常冷静思考；

二是对这次面试的准备不充分，本来打算看书复习的计划并没有在这之前进行完，很多专业词汇想不起来。还有就是有很多书中的基础部分在前面看的时候可能没太注意或者没彻底明白，一些知识点就掌握得很模糊，能知道个大概，具体去怎么描述却不知道怎么描述；

最后就是知识网络的分散，之前没对这方面有过整合。做的无非也是针对某个知识点，某个漏洞情况进行一些相关零碎知识的收集。对比前辈的回答，思路清晰，知识面扩展广、完善，相对来说我的回答只针对于面试官问的那一个漏洞，那一种情况，这是境界的差别；

接下来就打算重新看书，加上另一个vps上的知识总结，构造自己的知识网络，把已经掌握的知识点扩充到面。

总之，这次面试情况有点不尽人意，但是也从这次面试和前辈的沟通中学到了比面试结果更重要的东西。多想，细思考。

声明：该文章仅用于学术交流

感兴趣的小伙伴

扫描下方二维码