网络安全学习笔记:URL网址
- 2026-03-25 14:08:14
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:pass@ftp.example.com/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. 编码：特殊字符需要 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#chapter5• 单页应用： https://example.com/#/settings
重点：fragment 不会出现在 HTTP 请求里。也就是说服务端日志、WAF、后端框架通常看不到 # 后面的内容。
图 2：fragment 的“边界”
安全补充：有些 OAuth 老方案会把 token 放在
#后面（避免被服务端日志记录）。但这并不等于绝对安全——前端脚本若被 XSS 控制，仍然可以读到 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 的各个部分（端口、路径、参数、编码方式），观察服务端真实反应。
结尾：URL 安全排查清单（精简版）
拿到一个可控 URL（或可控跳转/回调地址）时，我一般按这个顺序过一遍：
1. scheme 是否可控？能不能变成 file:、javascript:（如业务允许）或非预期协议2. host 是否可控？是否可能 SSRF 到内网/云元数据 3. port 是否可控？是否能打到管理端口/内网服务 4. path 是否存在规范化绕过、目录穿越、路由误判 5. query 是否存在注入、越权、开放重定向、参数污染 6. fragment 是否被前端读取并参与敏感逻辑（前端路由、token 等）
如果你希望我再写一篇更偏“攻防实操”的延伸，可以把一个真实案例的 URL（脱敏即可）发我，我可以按上述清单带你从 DevTools/Burp 一步步拆解它的风险点与验证方法。
· 今 日 鉴 图 ·
