网络安全之Web入侵场景

1. 背景简介

1.1 Web入侵定义与行业现状

Web入侵是攻击者利用Web应用程序的漏洞或配置不当的安全机制，获取未经授权的访问权限，进而操纵、破坏系统或窃取敏感信息的行为。随着互联网技术的快速发展，Web应用已成为众多企业核心业务的基础，这也使得Web入侵攻击愈发常见且复杂多样。

1.2 常见攻击手段分类

• 漏洞利用：探测并利用未修补漏洞，如SQL注入、文件上传、RCE等，获取系统控制权或敏感数据。
• 错误配置和弱密码：不当系统配置、默认账户密码、缺乏安全加固等，成为攻击者的切入点。
• 社会工程攻击：通过欺骗手段诱导用户点击恶意链接（如CSRF），泄露登录凭证或执行恶意操作。

1.3 多漏洞链条攻击趋势

随着攻防对抗的深入，攻击者不再局限于单一漏洞利用，而是倾向于组合多个漏洞发起攻击。这种多漏洞链条利用大幅增加了攻击的复杂性和成功率，给防御方的检测与响应带来更大挑战。

---

2. 核心攻击方式详解

2.1 SQL注入

SQL注入的核心原因是应用程序对用户输入缺乏合法性校验或过滤不严，攻击者可在正常查询语句后添加额外SQL语句，欺骗数据库执行非授权操作。若支持堆叠查询，还可直接获取服务器权限。

示例恶意数据包：

formid=1'+(SELECT E WHERE 1=1 AND 1 IN (SELECT (^+(SELECT SUBSTRING((ISNULL(CAST (DB_NAME() AS NVARCHAR(4000)), )),1,1024))+^)))+

拼接后获取数据库信息的请求：

?sql=%20select%20categoryids%20from%20project%20where%20id=%27%27%20and%201=2%20union%20all%20select%20@@version&isworkflow=true

检测与防御方式

• 提取关键字特征：包括闭合字符（'、"、(、)、;及对应URL编码%27、%22等）、连接字符（空格、+及URL编码%20、%2b）。
• 拦截危险关键字：SQL查询关键字select，增删改查关键字insert、update、delete，组合语句关键字from、count等，以及sleep、updatexml等特殊函数。

2.2 文件上传漏洞

文件上传攻击是攻击者通过应用程序的上传功能，绕过校验机制上传WebShell或木马文件，执行恶意代码以获取服务器权限。无任何校验过滤的上传接口，可直接被用于上传恶意文件。

检测与防御方式

• 校验文件合法性：禁止php、jsp、aspx等可执行后缀及变形后缀（php5、pHp等），验证MIME类型与文件内容特征字节。
• 优化存储机制：重命名上传文件和路径，将文件存储在不可执行目录，避免被当作脚本执行。
• 隔离存储环境：使用第三方存储桶服务，将上传文件与本地业务环境隔离。

2.3 反序列化漏洞

反序列化漏洞发生在应用程序处理序列化数据的过程中，攻击者构造恶意序列化数据，在Java、PHP、Python等语言中，反序列化会自动恢复对象，进而注入恶意对象或命令，获取系统权限。

示例：Java反序列化时利用ObjectInputStream，注入java.lang.Runtime对象直接执行系统命令。

检测与防御方式

• 控制数据来源：避免对不可信数据进行反序列化，仅在内部通信中使用该功能。
• 选择安全格式：替换内置反序列化方案，使用Json、XML等不会自动执行代码的格式。
• 启用白名单机制：只允许反序列化预定义的可信对象类型，防止恶意对象注入。

2.4 模板注入

模板注入是应用程序使用Jinja2、Twig等模板引擎生成动态内容时，未校验用户输入就直接传递给模板渲染，导致服务器执行预期外代码的漏洞。

示例：向某OA系统嵌入恶意模板，直接写入内存马模块。

检测与防御方式

• 输入输出转义：对用户输入和模板输出进行严格转义，确保内容仅作为普通文本处理。
• 启用模板沙箱：限制模板中表达式的执行权限，阻止恶意代码注入。

---

3. 处置与溯源流程

3.1 应急响应核心思路

Web入侵的最终目的多为写入WebShell或内存马控制服务器，应急响应可围绕两条核心线索展开：

• 时间线索：确认入侵时间范围，排查对应时段可疑日志，还原攻击操作过程。
• 文件线索：以攻击者留下的后门文件为突破口，结合日志反推攻击路径。

3.2 WebShell排查与日志分析

日志统计分析命令

# IP统计
grep '23/May/2019' /www/logs/access.2019-02-23.log | awk '{print $1}' | awk -F'.' '{print $1"."$2"."$3"."$4}' | sort | uniq -c | sort -r -n | head -n 10

# 网段统计
cat /www/logs/access.2019-02-23.log | awk '{print $1}' | awk -F'.' '{print $1"."$2"."$3".0"}' | sort | uniq -c | sort -r -n | head -n 200

# 域名统计
cat /www/logs/access.2019-02-23.log |awk '{print $2}'|sort|uniq -c|sort -rn|more

# HTTP请求状态统计
cat /www/logs/access.2019-02-23.log |awk '{print $9}'|sort|uniq -c|sort -rn|more

# URL统计
cat /www/logs/access.2019-02-23.log |awk '{print $7}'|sort|uniq -c|sort -rn|more

# 文件流量统计
cat /www/logs/access.2019-02-23.log |awk '{sum[$7]+=$10}END{for(i in sum){print sum[i],i}}'|sort -rn|more
grep ' 200 ' /www/logs/access.2019-02-23.log |awk '{sum[$7]+=$10}END{for(i in sum){print sum[i],i}}'|sort -rn|more

# URL访问量统计
cat /www/logs/access.2019-02-23.log | awk '{print $7}' | egrep '\?|&' | sort | uniq -c | sort - rn | more

# 筛选慢速脚本
grep -v 0$ /www/logs/access.2019-02-23.log | awk -F '\" ' '{print $4" " $1}' web.log | awk '{print $1"，"$8}' | sort -n -k 1 -r | uniq > /tmp/slow_url.txt

文件排查命令

# 查询特殊权限文件
find / *.jsp -perm 4777

# 查找24小时内修改的文件
find ./ -mtime 0 -name "*.jsp"

# 按指定时间反推变更文件
ls -al /www | grep "Feb 27"

# 按时间排序查看目录文件
ls -alt /www | head -n 10

# 查看文件详细信息
stat webshell.jsp

3.3 内存马排查方法

若未发现恶意文件但捕获到异常网络请求，需排查内存马：

• 分析请求特征：筛选URL相同但参数不同的请求日志，检测哥斯拉、冰蝎等工具的流量特征。
• 验证URL有效性：对比返回200状态码的URL，若页面不存在却返回200，大概率为内存马。
• 排查中间件漏洞：若Web日志无异常，检查业务组件是否存在已公开漏洞，结合请求日志、错误日志进一步定位。

---

4. 实战案例分析

4.1 案例1：企业Web业务服务器内存马注入事件

4.1.1 背景介绍

某企业通过相关情报得知其Web业务服务器被攻击者获取主机权限，应急响应中心应企业要求，对该入侵事件展开全面分析与处置。

4.1.2 初步分析与攻击入口判断

首先梳理涉事主机网络环境特征，为攻击入口定位提供依据：

• 对外仅映射Web业务，无其他公开服务端口。
• 未对外映射RDP高危端口，且RDP登录仅允许通过堡垒机访问。

通过堡垒机日志及本地RDP登录记录排查（可使用"saft工具"查询本机RDP登录情况），未发现事件当天有合法登录记录，因此排除RDP暴力破解等入侵路径，推断攻击者通过Web相关漏洞获取主机权限。

由于缺乏完整流量日志（受HTTPS加密、流量镜像未覆盖等条件限制），本次分析以主机本地access日志为核心，结合内存马排查思路展开------优先检索恶意文件痕迹与WebShell/内存马访问特征。

内存马攻击的日志特征规律：

• 攻击语句执行失败时，服务器返回5xx状态码；注入成功后连接内存马路径，返回200状态码。
• Webshell连接工具访问内存马时，常先发起1次GET请求，后续伴随大量POST请求。
• 内存马注入未成功前，访问目标路径返回404；注入成功后访问则返回200。

4.1.3 事件溯源分析过程

1. 日志筛选与时间范围锁定：提取Web业务当天的access访问日志，按上述特征排查发现异常状态码变化：

   • 23/Jul/2024:13:42:05，攻击者首次访问"/resource/"路径，服务器返回404（资源未存在）。
   • 23/Jul/2024:13:44:02，攻击者再次访问该路径，服务器返回200（资源已存在）。
     据此锁定内存马注入时间窗口为23/Jul/2024:13:4x左右。
     

2. 内存马扫描佐证：使用深信服应急响应工具库中的内存马扫描工具（MSI），扫描后将内存中的恶意class输出至result文件，确认存在内存马注入行为。
   

3. 可疑接口定位：根据注入时间窗口过滤access日志中的POST请求，发现23/Jul/2024:13:43:51的可疑接口"/sys/profile/sysProfileCuxTemplateAction.do"。
   

4. 攻击链路还原：

   对该接口进行分析，发现该接口，接收key参数(决定文件名)、config参数(决定jsp文件内容)，可直接拼接上传形如

   "xxx_config.jsp "的文件。（该接口需管理员权限才可访问，在此不进行赘述。）
   

   对日志进行检索，发现仅有23/Jul/2024:13:43:53，访问了 "/login_single_horizontal_config.jsp"。所以攻击者使用

   key=4，进行传参。
   

由此确定应该存在落地恶意文件情况("/login_single_horizontal_config.jsp")，分析该文件主要内容，为base64解码后，

反射动态加载解码后的内容，来完成真实恶意功能文件⸺内存马的加载。

综上，其通过文件上传接口"/sys/profile/sysProfileCuxTemplateAction.do"，成功上传 "/login_single_horizon

tal_config.jsp" 后，访问该文件，成功加载内存马于"/resource/"，被攻击者用于后续控制。

4.1.4 处置方式

1. 紧急漏洞与恶意文件处置：

   • 删除恶意文件"login_single_horizontal_config.jsp"，结合业务情况评估后重启服务器，彻底清除内存马。
   • 临时通过防火墙禁用高危接口：上传接口"/sys/profile/sysProfileCuxTemplateAction.do"、落地文件接口"*_config.jsp"、内存马接口"/resource"（不影响"/resource/xxx/xxx"等正常子接口）。
   • 联系组件厂商，及时修复文件上传漏洞。

2. 遗留恶意进程排查：

   • 使用深信服应急响应工具库中的恶意进程扫描工具（MRK_HW专版），扫描护网常用远控工具特征，发现攻击者提权后拉起的rundll32.exe进程（属于Cobaltstrike远控）。
   • 直接结束该恶意进程，重启扫描确认无复发，阻断攻击者后续控制通道。

4.1.5 事件结论

• 攻击者针对企业高危Web组件，可能利用0day漏洞突破入口，将服务器作为代理跳板机，意图开展内网横向渗透。
• 防御核心建议：通过零信任架构收敛高危组件访问权限，覆盖浏览器-无端、浏览器-有端、移动端APP等场景，降低外部攻击面；若无法收敛，需确保AF防火墙防护有效性，采用多厂商防火墙串联，并保障流量设备解密能力及端侧行为日志的监控有效性。

4.2 案例2：财务系统SQL注入攻击事件

4.2.1 背景介绍

某用户反馈其财务系统存在针对"财务数据库"的攻击行为，攻击者疑似尝试通过xp_cmdshell执行系统命令，但未捕获到直接对应的攻击流量数据包。应急响应中心应用户需求，启动事件分析与处置工作。

4.2.2 初步分析与攻击路径假设

首先梳理涉事系统网络架构与业务特征，锁定潜在攻击路径：

• 对外仅映射Web端"财务系统"，无其他公开服务暴露。
• 财务系统与财务数据库存在正常SQL数据交互，具备数据流转通道。

结合上述特征，推断两种可能的攻击路径：

• 路径一：攻击者先获取财务服务器控制权，窃取数据库账号密码后直接连接数据库，执行恶意SQL语句。
• 路径二：财务系统存在SQL注入漏洞，攻击者通过正常业务接口注入恶意SQL，由系统拼接后向数据库发起执行请求。

由于MSSQL数据库默认未开启登录成功日志（本次排查确认未启用），无法通过数据库登录记录验证路径一。因此优先假设攻击路径为SQL注入，聚焦业务服务器的access日志，排查对应时间窗口的接口访问情况。

4.2.3 溯源分析过程

1. 日志排查与可疑接口锁定：查看财务系统服务器的access访问日志，在攻击者尝试执行xp_cmdshell命令的对应时间，发现大量针对"/services/operOriztion"接口的访问请求。其中一条URL包含"AND UNION SELECT"关键字，明确符合SQL注入攻击特征。
   

2. 漏洞验证（黑盒测试）：

   • 该系统使用axis2 Web服务，通过SoapUI工具（http://www.soapui.org/）访问接口，可直接获取所有输入参数及参数类型。
   • 采用通用SQL注入Payload（';waitfor delay '00:00:02'--），逐个传入接口参数进行测试，最终确认"kjnd"参数未做严格校验，存在SQL注入漏洞。
     

3. 代码审计佐证（白盒验证）：

   • 定位源码路径classes/com/ufgov/midas/pt/service/OperOriztion.class，查看getGsbmfaByKjnd方法。
   • 发现该方法未对"kjnd"参数进行过滤处理，直接将参数代入SQL语句拼接执行，最终导致SQL注入漏洞利用成功。
     

4.2.4 处置方式

1. 漏洞紧急处置：

   • 临时通过防火墙禁用存在SQL注入的"/services/operOriztion"接口，阻断攻击者后续利用通道。
   • 联系系统厂商修复漏洞，核心要求为增加"kjnd"参数的合法性校验，过滤SQL注入关键字与特殊字符。

2. 遗留恶意进程排查：

   • 使用深信服应急响应工具库中的MRK_HW专版工具，对主机进程进行一键扫描，排查是否存在攻击者遗留的远控后门。
   • 扫描发现攻击者拉起的powershell进程，经特征匹配确认属于Cobaltstrike远控，直接终止该进程，重启扫描后未发现复发。

4.2.5 事件结论

• 本次攻击的核心诱因是代码层安全防护缺失，"kjnd"参数未做校验即直接参与SQL拼接，给攻击者提供了可乘之机。
• 防御核心建议：增强代码开发规范性，在需求分析阶段明确安全要求，对所有用户输入进行严格验证与过滤；强制使用参数化查询或预编译语句，避免用户输入影响SQL逻辑；在生产环境部署异常行为监控系统，实时捕获SQL注入相关的高危操作；建立安全反馈机制，联动开发、测试与用户，持续优化安全防护措施。

---

5. 总结与防御建议

Web入侵攻击手段多样且持续迭代，从上述两个实战案例可见，文件上传漏洞、SQL注入等传统高危漏洞仍是攻击者的核心突破口，且攻击后常通过内存马、远控进程等方式维持权限，给企业安全带来持续威胁。

防御核心在于构建"漏洞防护+行为检测+应急响应"的全流程闭环：

• 漏洞防护层面：定期开展漏洞扫描与安全加固，规范代码开发流程，对用户输入严格校验，避免直接拼接SQL、随意接收文件上传等高危操作。
• 行为检测层面：部署日志分析与异常监控系统，重点关注SQL注入关键字、可疑文件上传、异常进程拉起等高危行为，做到早发现、早预警。
• 应急响应层面：建立标准化处置流程，配备专业工具与人员，攻击发生后快速溯源攻击路径、清除恶意文件与进程，阻断攻击链延伸。

企业需结合自身业务场景，针对性强化Web应用安全防护，才能有效抵御各类入侵威胁，保障核心业务与数据安全。

参考资料：

《网络安全事件应急指南》深信服提供