网站权限漏洞最常见的入口不是那些花哨的0day，而是目录遍历、越权访问、文件上传限制缺失和后台弱口令。很多站点上线时功能测试都通过了，但权限模型从一开始就没有按“最小权限原则”设计，导致攻击者一旦拿到一个低权限账号，就能通过修改URL参数、直接访问受限路径或猜测接口地址来获取本不该看到的数据。修复这类问题不能只靠打补丁，必须从权限校验逻辑、服务端配置、文件系统权限和访问控制策略四个层面同时收紧。

先检查目录遍历漏洞。很多Web服务器在配置不当时，访问一个没有默认首页的目录会直接列出文件列表。攻击者利用这个行为可以枚举上传目录、备份目录和配置文件路径。修复方法很直接：在Nginx中关闭目录索引，在Apache中移除Indexes选项。Nginx配置如下：

location / {
    autoindex off;
    try_files $uri $uri/ =404;
}

Apache则在站点配置或.htaccess中确保不包含Indexes：

Options -Indexes

但仅关闭目录索引还不够。很多站点的上传目录虽然不能列出文件，却可以猜测文件名直接下载。比如用户上传的身份证照片、合同扫描件，如果文件名是按用户ID或时间戳生成的，攻击者可以遍历ID批量抓取。这类问题的本质是文件访问缺少鉴权。上传文件不应该存放在Web根目录下直接通过静态URL访问，而应该放在Web根目录之外，通过一个鉴权脚本来读取并输出文件内容。脚本中必须校验当前登录用户的身份与请求文件的归属关系，不能只判断是否登录。

越权访问是权限漏洞中危害最大也最容易被忽视的一类。典型场景是用户A通过修改订单详情页URL中的订单号，就能看到用户B的订单。很多开发者只在页面加载时判断了用户是否登录，却没有在后端接口中校验该资源是否属于当前用户。修复越权漏洞的核心是：所有涉及资源ID的接口，都必须在服务端验证资源归属。不要依赖前端隐藏按钮或禁用链接，因为前端限制可以被轻易绕过。例如在用户查询订单接口中，SQL查询条件必须带上当前用户ID：

SELECT * FROM orders WHERE order_id = ? AND user_id = ?

而不是先查出订单再判断归属。如果是管理员接口，则需要单独的角色校验中间件，且管理员权限不能通过前端可修改的字段来判断。很多系统把用户角色放在cookie或localStorage中，这是极其危险的。角色信息必须由服务端在会话中维护，每次请求都从服务端重新获取，不能信任客户端传来的任何角色参数。

文件上传功能是另一个重灾区。即使你限制了扩展名，攻击者依然可能通过双重扩展名、大小写混淆、空字节截断或MIME类型伪造来上传可执行脚本。更隐蔽的是上传一个包含恶意代码的图片，配合本地文件包含漏洞执行。修复上传漏洞要同时做五件事：第一，文件扩展名白名单，只允许明确的类型如jpg、png、pdf，不允许php、jsp、asp等任何可执行后缀；第二，服务端校验文件MIME类型和文件头，不能只依赖客户端传来的Content-Type；第三，重命名文件，使用随机字符串作为新文件名，避免保留用户原始文件名；第四，限制上传目录的执行权限，在Nginx中对上传目录单独配置，禁止解析任何脚本：

location /uploads/ {
    location ~ \.(php|php5|php7|jsp|asp|aspx)$ {
        deny all;
    }
}

第五，如果条件允许，将上传文件存储在对象存储或独立文件服务器中，与Web应用服务器隔离，这样即使文件内容包含恶意代码也无法在应用服务器上执行。

后台管理入口的权限加固同样关键。很多后台系统使用弱口令，或者登录接口没有失败次数限制，攻击者可以暴力破解。修复方案包括：强制使用强密码策略，登录失败超过5次锁定账号15分钟，后台入口限制访问IP白名单，启用双因素认证。后台路径本身也不应该使用常见的/admin或/manager，虽然隐藏路径不是安全措施，但可以降低自动化扫描的命中率。更重要的是，后台所有操作必须记录日志，包括登录成功、登录失败、敏感操作和数据导出，这样即使发生入侵也能追踪。

还有一个经常被忽略的权限漏洞是API接口的未授权访问。很多前后端分离的项目，后端API只在前端路由做了跳转控制，接口本身没有鉴权。攻击者直接调用API就能获取数据或执行操作。修复方法是所有API统一经过鉴权中间件，除登录、注册等公开接口外，其余接口默认拒绝访问，只有显式声明为公开的接口才放行。同时API响应中不要返回多余字段，比如用户密码哈希、内部ID、服务器路径等，避免信息泄露。

跨站请求伪造也是权限漏洞的一种表现。攻击者诱导已登录用户点击恶意链接，利用用户的会话执行非本意的操作，比如修改密码、转账、删除数据。修复CSRF需要在所有状态变更请求中校验随机Token，并校验请求来源。对于敏感操作，还应该要求二次验证，比如输入密码或验证码。SameSite Cookie属性也可以作为辅助防线，将Cookie设置为Lax或Strict，减少跨站请求携带Cookie的风险。

服务端的文件系统权限同样需要加固。Web应用运行所使用的系统账户，不应该对网站根目录拥有写权限，只有上传目录和缓存目录需要写权限。配置文件、数据库连接文件、日志文件应该设置为只读，且不允许通过Web访问。在Linux系统中，可以使用chmod和chown来收紧权限，例如网站文件属主为专门的部署用户，Web服务器账户只读：

chown -R deploy:www-data /var/www/site
find /var/www/site -type d -exec chmod 750 {} \;
find /var/www/site -type f -exec chmod 640 {} \;

上传目录和运行时目录单独设置写权限，并且禁止脚本执行。这样即使Web应用被攻破，攻击者也无法修改核心文件或写入Webshell到不可写目录。

数据库权限同样要遵循最小权限原则。应用连接数据库的账户不应该拥有DROP、ALTER、CREATE等DDL权限，只授予必要的SELECT、INSERT、UPDATE、DELETE权限。对于不同业务模块，可以创建不同的数据库账户，进一步隔离风险。数据库管理后台不应该暴露在公网，只允许内网访问，并且使用强密码和IP白名单。

权限漏洞修复后需要持续验证。建议建立定期的权限审计机制，每次功能上线前，测试人员必须覆盖越权测试用例，包括水平越权、垂直越权、未授权访问和文件上传绕过。可以使用自动化安全扫描工具辅助发现常见问题，但人工代码审查仍然是发现逻辑漏洞的关键。对于已经发现的权限漏洞，修复后要回归测试，确认没有影响正常业务功能，同时检查是否有其他接口存在相同模式的漏洞。

最后强调一点，权限加固不是一次性工作。随着业务迭代，新的接口和功能会不断引入新的权限风险。把权限校验做成统一的中间件或服务层组件，让开发人员默认使用安全的权限模型，比每次事后修补要有效得多。只有在架构层面把权限控制作为基础设施来建设，才能真正降低网站被越权攻击的风险。