常见漏洞整改建议(长期更新)

#本文提供了一些日常工作中发现的一些常见漏洞的整改建议及措施。

XSS:

每个提交信息的客户端页面、通过服务器端脚本(JSP,ASP,ASPX,PHP等)生成的客户端页面、 提交的表单 (FORM) 或发出的链接请求中包含的所有变量, 必须对变量的值进 行检查, 过滤其中包含的特殊字符, 或对字符进行转义处理。 特殊字符如下:

  • HTML标签的< 、”、’、%等, 以及这些符号的 Unicode值;
  • 客户端脚本 (JavaScript, VBScript) 关键字: JavaScript, script等
    此外, 对于信息搜索功能, 不应在搜索结果页面中回显搜索内容。 同时应设置出错页面, 防止 Web 服务器发生内部错误时,将错误信息返回给客户端。 具体建议如下:
  • 定义允许的行为,确保Web应用程序根据预期结果的严格定义来验证所有输入参数 (Cookie, 标头, 查询字符串、 表单、 隐藏字段等)。
  • 检查POST和GET请求的响应,以确保返回的对象是预期的内容且有效。
  • 通过对用户提供的数据进行编码,从用户输入中移除冲突的字符、括号和单双引号。 这将防止插入的脚本以可执行的格式发送给最终用户。
  • 只要可能,就应将客户端提供的所有数据限制为字母数字数据。使用此过滤机制时, 如果用户输入数据为 <script>alert(document.cookie)</scrip>, 将缩为 scriptalertdocumentcookiescript. 如果必须使用非字母数字字符, 请先将其编码为 HTML 实体, 然后再将其用在 HTTP 响应中, 这样就无法将它们用于修改HTML 文档的结构。
  • 使用双因素客户身份验证机制, 而非单因素身份验证。
  • 在修改或使用脚本之前, 验证脚本的来源。
  • 不要完全信任其他人提供的脚本并用在自己的代码中(不论是从Web上下载的, 还是熟人提供的)。

越权:

  • 对于开发者而言, 一定要有安全意识, 时刻保持警惕。
  • 永远不要相信来自客户端 ( 用户) 的输入, 对于可控参数进行严格的检查与过滤。
  • 执行关键操作前必须验证用户身份, 多阶段功能的每一步都要验证用户身份.
  • 对于直接对象引 用, 加密资源ID, 以防止攻击者对ID进行枚举。
  • 在前端实现的验证并不可靠, 前端可以验证用户的输入是否合规, 要在服务端对请求的数据和当前用户身份做校验。 检查提交CRUD 请求的操作者 (Session)与目标对象的权限所有者 (查数据库) 是否一致, 如果不一致则阻断。
  • 在调用功能之前, 验证当前用户身份是否有权限调用相关功能 (推荐使用过滤器, 进行统一权限验证)。
  • 把属主、 权限、 对象、 操作的场景抽象成一个统一的框架, 在框架内统一实现权限的管理和检查。

CSRF:

  • 在 HTTP 请求中以參数的形式添加一个随机产生的 token,并在服务器端建立一个拦截器来验证这个 token,假设请求中没有 token 或者 token 内容不对,则觉得可能是 CSRF 攻击而拒绝该请求。
  • token须要足够随机
  • 敏感的操作应该使用POST。而不是GET,以form表单的形式提交。能够避免token泄露。

任意文件下载:

  • 过滤”../“符号。并进行循环过滤,防止攻击者构造….//这样的字符在过滤一次后仍为../的情况。使用户在url中不能回溯上级目录
  • 正则严格判断用户输入参数的格式
  • 建议严格限制文件访问目录及可下载的后缀类型;

越权修改密码:

  • 对密码找回的各个环节进行梳理,记录分析所有交互数据, 避免密码找回凭证等敏感信息直接返回给客端。
  • 对服务端密码重置Token 的生成算法进行审计, 避免使用容易被攻击者破解的简单算法。
  • 密码重置凭证应与账户严格绑定, 并设置有效时间, 避免攻击者通过修改账户 ID 的方式重置他人密码。
  • 对客户端传入的数据要进行严格的校验, 手机号、 邮箱地址等重要信息应和后台数据库中已存储的信息进行核对, 不应从客户端传入的参数中直接取用。 避免攻击者通过篡改传入数据的方式重置他人密码。
  • 对用户注册、 手机邮箱绑定等业务逻辑进行审计, 避免攻击者通过用户重复注册和越权绑定等漏洞间接重置他人密码

SQL注入:

代码层最佳防御sql漏洞方案:采用sql语句预编译和绑定变量,是防御sql注入的最佳方法。

  • 所有的查询语句都使用数据库提供的参数化查询接口,参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口,使用此接口可以非常有效的防止SQL注入攻击。
  • 对进入数据库的特殊字符(’”<>&*;等)进行转义处理,或编码转换。
  • 确认每种数据的类型,比如数字型的数据就必须是数字,数据库中的存储字段必须对应为int型。
  • 数据长度应该严格规定,能在一定程度上防止比较长的SQL注入语句无法正确执行。
  • 网站每个数据层的编码统一,建议全部使用UTF-8编码,上下层编码不一致有可能导致一些过滤模型被绕过。
  • 严格限制网站用户的数据库的操作权限,给此用户提供仅仅能够满足其工作的权限,从而最大限度的减少注入攻击对数据库的危害。
  • 避免网站显示SQL错误信息,比如类型错误、字段不匹配等,防止攻击者利用这些错误信息进行一些判断。

任意文件上传:

  • 采用白名单后缀文件上传方式,规定上传文件后缀类型。避免解析漏洞。
  • 采用独立文件服务器或文件目录。将上传文件与Web目录隔离。
  • 采用Base64编码方式上传文件,避免上传漏洞。
  • 设置文件目录权限,禁止执行权限。
  • 对上传后的文件统一随机命名,不允许用户控制扩展名