文章总结： 本文从网络安全视角深入解析URL各组件的安全风险，涵盖scheme、host、port、path、query、fragment等要素。详细阐述SSRF、开放重定向、注入攻击、越权访问等常见漏洞在URL层面的成因与利用方式，并提供实战排查清单与调试技巧。文章强调不同组件对URL解析差异导致的边界不一致是安全隐患主要来源，建议重点检查可控URL的协议、主机、端口、路径和参数部分。 综合评分： 83 文章分类： WEB安全,渗透测试,漏洞分析,安全建设

网络安全学习笔记：URL网址

原创

aiyou aiyou

Web安全工具库

2026年3月25日 11:25 河南

URL 不只是“网址”：站在网络安全角度把每个字符掰开揉碎

做 Web 安全久了会有一种直觉：很多漏洞不是“代码写错了”，而是输入的一串 URL 被不同组件用不同方式理解了——浏览器、反向代理、网关、应用框架、WAF、日志系统，各自解析一次，边界一旦不一致，就容易出事。

URL（Uniform Resource Locator，统一资源定位符）本质上是网络世界的“门牌号”。但它又不仅仅是地址：它还携带协议、认证信息、端口、路径规则、参数、页面内定位……你在地址栏输入的每一个符号，都可能影响最终请求长什么样、落到后端哪段逻辑上。

1. 一张图看懂 URL 的骨架

常见 URL 可以抽象成这样一条模板：

scheme://userinfo@host:port/path?query#fragment

实战提示：很多安全问题的根源，是“你以为这是路径，后端却当成参数”，或者“你以为 # 后面会发给服务器，结果它根本没出浏览器”。

2. scheme（协议）：不止 http/https，这里经常被用来“做文章”

2.1 HTTP vs HTTPS：差的不只是“有没有小锁”

• • HTTP 明文传输：账号、密码、Cookie、接口返回内容都有被旁路窃听的风险（同网段/恶意 Wi‑Fi/被劫持网关等）。
• • HTTPS = HTTP + TLS：解决了机密性、完整性和服务端身份校验。

端口上有个常识：

• • http 默认 80，https 默认 443，这两个端口在 URL 里通常可以省略。
• • 其它端口（比如 :8080、:8443）一般必须显式写出来。

2.2 其它常见协议：安全测试里也会遇到

• • ftp://：文件传输场景常见；历史遗留系统里仍可能出现弱口令、匿名访问。
• • file:///：访问本地文件。很多同学第一次遇到“PHP 文件怎么显示源代码不执行”，往往就是用 file:// 打开了本地文件——它只负责展示内容，不会让服务端解析执行。
• • mailto:：点击会唤起邮件客户端；钓鱼邮件里经常用来引导用户发送敏感信息。
• • 一些下载工具的私有协议（例如电驴、迅雷等）：更多出现在社工/钓鱼引导里。

安全建议：在业务系统里，如果出现“用户可控的跳转 URL”（例如回跳地址、第三方登录 redirect_uri），务必限制 scheme，只允许 https（必要时 http 仅限内网），否则很容易演变成开放重定向甚至更糟的利用链。

3. userinfo（账号密码）：现在少见，但一旦出现往往是风险点

典型格式：

ftp://user:[email protected]/dir/file.zip

这段 user:pass@ 在现代 Web 里已经很少用了，但你仍可能在：

• • FTP 地址
• • 老系统的 Basic Auth 链接
• • 配置文件、日志、告警信息里

风险主要在于：敏感信息会进入浏览器历史、代理日志、服务器日志、截图/录屏、分享链接。很多企业安全事件里，凭据泄露就是这么来的。

4. host（服务器地址）：域名、IP、以及那些 SSRF 常用的“花样”

host 可以是域名，也可以直接是 IP：

• • https://www.example.com/
• • https://47.106.8.175/

域名背后要经过 DNS 解析变成 IP。安全测试时，host 相关的关注点很多：

• • SSRF：如果应用允许你提交一个 URL 去“帮你抓取内容”（比如图片代理、Webhook、导入远程文件），攻击者会想方设法让 host 指向内网地址： http://127.0.0.1/、http://169.254.169.254/（云环境元数据）、http://localhost/ 等。
• • 域名欺骗/同形字符：IDN/Punycode 相关的视觉欺骗（更偏钓鱼）。
• • Host 头注入：URL 里的 host 最终会体现在 HTTP 请求的 Host 头（HTTP/1.1 必需字段）里；部分应用拿 Host 拼接回链、生成重置密码链接时，若校验不严会翻车。

5. port（端口）：一串数字决定你到底在跟谁说话

端口是“同一台服务器上不同服务的入口”。写错端口，经常表现为：

• • 连接失败 / 超时
• • 打开了“完全不是你以为的那个服务”（例如把管理后台暴露在高端口）

安全上常见的现实是： 业务对外宣称只开放 443，但实际在 :8080、:7001、:9000 上跑着测试接口、管理控制台、旧版服务。

6. path（路径）与“文件扩展名”：你看到的未必是服务器上的文件

很多人会把下面这种 URL 理解成“访问服务器上的某个文件”：

https://example.com/app/index.php

在静态站点里这通常成立；但在现代 Web 框架里，路径很可能只是路由映射：

• • /user/list 对应某个控制器方法
• • /article/12345.html 可能是“伪静态”，后端提取 12345 当参数查数据库，再渲染模板

所以别被 .do、.action、.html 之类的后缀迷惑——很多时候它只是“看起来像文件”的接口标识。

同时，Web 服务器通常还有“默认首页”规则：当你只写目录不写文件名时（例如访问 /dvwa/），服务端会按配置优先寻找 index.html、index.php 等默认文件返回。

安全关联：路径解析与规范化（/../、双斜杠、URL 编码的点和斜杠）是目录穿越、鉴权绕过、WAF 绕过的高发地带。测试时务必结合目标技术栈验证其规范化行为。

7. query（参数）：注入、越权、重定向……大量漏洞都从这里开始

参数格式大家都熟：

?key1=value1&key2=value2

关键点有三个：

1. 1. 编码：特殊字符需要 URL 编码（例如空格 %20）。很多绕过都发生在“编码/解码次数不一致”上。
2. 2. 多参数与重复参数：a=1&a=2 这种叫参数污染（Parameter Pollution），不同组件取值策略不同，容易被利用。
3. 3. 敏感信息不要放 URL：因为 URL 太容易被记录和泄露（浏览器历史、Referer、日志、分享链接）。

常见安全问题举例：

• • SQL 注入：?id=1' or '1'='1
• • 越权：?userId=1001 换成 1002 是否能看别人数据
• • 开放重定向：?redirect=https://evil.com
• • XSS：?q=<script>...（取决于反射位置与输出编码）

8. fragment（# 锚点）：只在浏览器里生效，不会发到服务器

# 后面的片段（fragment）用于页面内定位或前端路由：

• • 目录跳转：https://example.com/doc.html#chapter5
• • 单页应用：https://example.com/#/settings

重点：fragment 不会出现在 HTTP 请求里。也就是说服务端日志、WAF、后端框架通常看不到 # 后面的内容。

图 2：fragment 的“边界”

不发送

浏览器地址栏\nUnsupported markdown: link

实际发出的 HTTP 请求

GET /page?x=1 HTTP/1.1\nHost: a.com

#frag 仅浏览器使用\n用于滚动/前端路由

安全补充：有些 OAuth 老方案会把 token 放在 # 后面（避免被服务端日志记录）。但这并不等于绝对安全——前端脚本若被 XSS 控制，仍然可以读到 fragment 内容。

9. 从“输入 URL”到“页面显示”：中间发生了哪些事（以及安全检查点）

把整个过程串起来，大概是：

1. 1. 浏览器解析 URL → 得到 scheme/host/port/path/query
2. 2. DNS 把域名解析成 IP
3. 3. 建立 TCP 连接；若是 HTTPS 再进行 TLS 握手
4. 4. 发送 HTTP 请求（请求行、请求头、Cookie 等）
5. 5. 服务端返回响应（状态码、响应头、Set-Cookie、正文）
6. 6. 浏览器解析 HTML → 继续请求 CSS/JS/图片/接口 → 渲染页面

安全人员在这里常做的检查包括：

• • 是否全站 HTTPS、是否开启 HSTS
• • Cookie 是否设置 Secure、HttpOnly、SameSite
• • 是否存在不必要的重定向链、是否能被构造开放重定向
• • 关键接口是否有鉴权与越权控制（不仅看页面能不能打开）

10. 实战小技巧：如何确认“浏览器到底发了什么请求”

两种最常用的方法：

• • DevTools（F12）→ Network 刷新页面，点开首个 Document 请求，看 Request URL / Request Headers / Response Headers。尤其关注：Host、Cookie、Location、Set-Cookie。
• • Burp Suite 适合做拦截与重放：把浏览器流量代理到 Burp，修改 URL 的各个部分（端口、路径、参数、编码方式），观察服务端真实反应。

结尾：URL 安全排查清单（精简版）

拿到一个可控 URL（或可控跳转/回调地址）时，我一般按这个顺序过一遍：

1. 1. scheme 是否可控？能不能变成 file:、javascript:（如业务允许）或非预期协议
2. 2. host 是否可控？是否可能 SSRF 到内网/云元数据
3. 3. port 是否可控？是否能打到管理端口/内网服务
4. 4. path 是否存在规范化绕过、目录穿越、路由误判
5. 5. query 是否存在注入、越权、开放重定向、参数污染
6. 6. fragment 是否被前端读取并参与敏感逻辑（前端路由、token 等）

如果你希望我再写一篇更偏“攻防实操”的延伸，可以把一个真实案例的 URL（脱敏即可）发我，我可以按上述清单带你从 DevTools/Burp 一步步拆解它的风险点与验证方法。

·今 日 鉴 图·

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Web安全工具库 aiyou aiyou《网络安全学习笔记：URL网址》