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

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

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

1. 一张图看懂 URL 的骨架

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

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

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:：点击会唤起邮件客户端；钓鱼邮件里经常用来引导用户发送敏感信息。
• 一些下载工具的私有协议（例如电驴、迅雷等）：更多出现在社工/钓鱼引导里。

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 等默认文件返回。

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

参数格式大家都熟：

?key1=value1&key2=value2

关键点有三个：

1. 编码：特殊字符需要 URL 编码（例如空格 %20）。很多绕过都发生在“编码/解码次数不一致”上。
2. 多参数与重复参数：a=1&a=2 这种叫参数污染（Parameter Pollution），不同组件取值策略不同，容易被利用。
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
• 单页应用：https://example.com/#/settings

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

图 2：fragment 的“边界”

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

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

1. 浏览器解析 URL → 得到 scheme/host/port/path/query
2. DNS 把域名解析成 IP
3. 建立 TCP 连接；若是 HTTPS 再进行 TLS 握手
4. 发送 HTTP 请求（请求行、请求头、Cookie 等）
5. 服务端返回响应（状态码、响应头、Set-Cookie、正文）
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 的各个部分（端口、路径、参数、编码方式），观察服务端真实反应。