风险评估-代码审计技术方案.docx

代码审计技术方案 编号 编制 审核 批准 密级 发布日期 变更记录 版本 修订时间 修订人 修订类型 修订章节 修订内容 ★修订类型分为：A-ADDED，M-MODIFIED，D-DELETED 注：对该文件内容增加、删除或修改均需填写此记录，详细记载变更信息，以保证其可追溯性 测试工具 反编译java类 如果项目中未提供所有java源代码，只提供编译后的class文件，可以运行jd-gui，选择菜单File---Open File，对class文件进行反编译 选择class文件或者jar包，点击打开按钮，即可查看反汇编后的java源代码 Eclipse环境审计 使用Eclipse的Import功能将程序代码导入workspace，打开任一java源文件，选择Source Analyse菜单下的条目进行关键方法搜索，搜索结果在窗口下面显示，然后进行人工分析。 认证管理 图形验证码 用户登录过程是否有图形验证码保护，防止自动化程序猜测密码 验证码复杂度是否符合要求（干扰、变形） 验证码在使用过一次后是否会自动刷新 验证码明文是否会被传送给客户端（页面或Cookie） 验证码是否在被保护的操作进行前来验证（无验证或无效验证） 认证实现 用户认证过程中，用户名和密码合法性的检查方式是否符合要求 较安全的做法为先校验验证码，再检查用户名，最后比对密码的密文 是否具备用户注销功能 用户注销时是否清理了当前用户会话 是否会将密码作为重定向的一部分进行传送 在统一认证SSO模式下，有的实现并非使用Token来交换认证信息，而是通过客户端直接传递账号、密码，这种情形下有可能在URL中直接传递明文密码。 认证过程中对于用户名错误和密码错误提示是否相同 统一用户名和密码错误提示，可以降低账号、密码被猜解的风险 检查用户认证页面是否对认证失败的次数进行了限制 授权管理 授权实现 应用的用户是否具有角色的区分 明确用户的角色定义、授权访问的范围，分析哪种情况下可能会导致越权 应用是否具备统一的（或独立）的权限控制模块 大部分的大型应用都会采用统一的权限控制模块 应用的权限控制模块是否存在漏洞 页面/功能是否使用了权限控制（模块） 识别出需要和无需权限控制的页面/功能，逐一进行验证。验证过程中需要考虑到用户的角色划分。 页面的权限控制是否正确 部分应用的权限控制（模块）的使用上存在缺陷，攻击者可能通过一些隐蔽的途径绕过鉴权，访问非授权资源 授权管理 高权限用户分析 分析系统高权限用户（例如：管理员用户）的分配情况及密码复杂度等 默认用户分析 分析系统是否存在默认用户、密码，密码复杂度等。 输入/输出验证 SQL注入防护 是否存在全局过滤器 过滤器配置、过滤函数等 过滤器是否可以过滤所有查询请求 请求是否都按要求经过过滤器处理 过滤器的过滤是否符合要求 初期检查可以依据PHPIDS的规则库，后期根据收集的情况予以补充 是否使用了预查询机制 预查询是指在将数据传入SQL语句前明确指定传输数据的类型，以执行必要的转换。在Java中预查询的调用方式为prepareStatement。 是否存在SQL语句拼接 某些特殊的查询（特别复杂的组合查询）难免用到SQL语句拼接，遇到这种情况，就需要检查拼接是否有可能导致注入。 跨站攻击防护 是否存在全局XSS过滤器(论坛的过滤库) 过滤器的过滤是否符合要求 是否存在需过滤和不需过滤两种输出，页面是否控制恰当（*） 某些情况下可能存在两种输出，文本输出和富文本（HTML）输出，要强制文本输出，只需要调用HTMLEncode()对内容进行编码后输出即可；但是富文本本身就需要使用html来进行格式的控制，简单的编码就无法使用，这时需要在此类内容从客户端输入（用户提交）或输出给客户端（显示）时进行危险代码过滤。 输出的时候是否进行编码（HTML、JS） CSRF攻击防护 Web表单是否使用了Token（或验证码） Web表单提交（成功或不成功）后token（或验证码）是否重置 检查Token的生成算法是否安全 可以从测试环境来检查生成的验证码是否符合复杂性要求，如是否有干扰线/点、字符变形等。 检查服务器获取Web表单参数值的方式 如果在操作时不严格区分GET和POST，在没有Token（或验证码）的辅助下很容易导致CSRF的发生。 文件上传防护 是否限制了上传文件的扩展名 以白名单形式指定允许上传的扩展名；以黑名单形式指定禁止上传的文件名 是否对上传文件进行了重命名操作 重命名操作是否安全，防止重命名过程中产生二次风险 是否对上传文件的存放位置禁止了脚本执行 文件下载防护 是否存在客户端指定文件名的下载功能 直接指定文件名的下载是否允许客户端指定路径 对于不同用户的文件在下载时是否进行了权限控制 文件下载功能中是否对用户的权