威胁级别	数量	安全问题名称
严重问题	5	管理后台弱口令
		管理后台sql注入
		任意用户密码重置
		存储型xss
		任意文件上传
中等问题	3	用户名枚举
		广告轰炸发布
		修改注册信息处CSRF

整体而言，系统在本次渗透测试实施期间的安全风险状况为“紧急状态”。(系统安全风险状况等级的含义及说明详见附录A)。

项目信息
1. 委托单位信息

单位名称
委托项目名称
单位地址
邮政编码		传真
联系人		联系电话
联系人E-MAIL

1. 测评单位信息

单位名称
单位地址
单位网址
邮政编码		传真
联系人		联系电话
联系人E-MAIL
参与本次测试小组成员有：

项目概述
1. 测试目的

通过本项目的成功实施，在坚持科学、客观、公正原则的基础上，全面、完整地了解当前的安全状况，分析系统所面临的各种风险，模拟攻击者可能利用的漏洞，根据测试结果发现系统存在的安全问题，并对严重的问题提出加固的建议。

本次测试预期达到的目标为：

发现授权渗透测试目标系统的安全漏洞
针对发现的漏洞提供加固方案及防护建议
1. 测试范围

本次渗透测试的范围如下：

序号	名称	备注
1	http://192.168.100.200:8201/

1. 测试依据

安全测试服务将参考下列规范进行工作。

信息安全技术信息安全风险评估规范（GB/T 20984-2007）
信息技术信息安全管理实用规则（GB/T 19716-2005)(ISO/IEC 17799:2000)
信息技术安全技术信息安全管理实用规则（GB/T 22081-2016 ）
GB T 31509-2015 信息安全技术信息安全风险评估实施指南
信息系统审计标准（ISACA）
OWASP OWASP_Testing_Guide_v3
OWASP OWASP_Development_Guide_2005
OWASP OWASP_Top_10_2010_Chinese_V1.0
1. 测试工具
拓扑分析工具：DNS Sweep、Nslookup 等
自动化扫描工具：Nessus、AppScan、AWVS 等
端口扫描、服务检测：Nmap、SuperScan 等
嗅探分析工具：Ethereal、Entercap、Dsniff 等
Exploiting 利用工具：Metasploit Framework 等
应用缺陷分析工具：SQLMAP、BURPSUITE等

问题归纳
1. 后台暴露弱口令
  1. 风险级别

威胁级别	严重	■	中度		轻度

- 1. 漏洞概述

http://192.168.100.200:8201/admin/login.php 进入管理后台：

尝试弱口令admin admin，成功登入：

- 1. 修复建议

修改弱口令并在登录接口处添加有效验证码防止暴力破解。

1. sql注入
  1. 风险级别

威胁级别	严重	■	中度		轻度

- 1. 漏洞概述

管理员用户后台管理-公告信息管理、帮助信息管理处参数b 存在SQL注入

url=http://192.168.100.200:8201/admin/help_manage.php

- 1. 修复建议

对输入严格过滤和转义，预编译和参数化，部署waf

1. 用户名可枚举导致暴力破解
  1. 风险级别

威胁级别	严重		中度	■	轻度

- 1. 漏洞概述

用户注册用户名时前端反馈信息不一致，用户名可枚举导致暴力破解：

- 1. 修复建议

统一身份验证失败时的响应，如：用户名或密码错误。

1. 任意用户密码重置
  1. 风险级别

威胁级别	严重	■	中度		轻度

- 1. 漏洞概述

找回密码功能，拦截响应数据包修改相关参数值为 yes 可跳过邮箱验证，重置密码：

- 1. 修复建议

服务端对验证码进行验证，结果为true时直接跳到下一步，无需向客户端单独返回验证结果；

每一个步骤都要对前一个步骤进行验证；最后提交新密码时应对当前用户名、验证码进行二次匹配验证。

1. 发布广告任意文件上传
  1. 风险级别

威胁级别	严重	■	中度		轻度

- 1. 漏洞概述

http://192.168.100.200:8201/user/advadd.php存在图片上传点。

上传一句话木马2.php抓包修改后缀，绕过校验造成任意文件上传：

- 1. 修复建议

隐藏上传路径，检查MIME类型，白名单方式服务端检查文件扩展名。

1. 广告轰炸发布
  1. 风险级别

威胁级别	严重		中度	■	轻度

- 1. 漏洞概述

广告图片上传成功后发布时未进行有效性校验，导致广告轰炸发布

- 1. 修复建议

广告发布前校验文件是否已经成功上传并限制60秒内不准重复发送

1. 用户修改注册信息处存在CSRF漏洞
  1. 风险级别

威胁级别	严重		中度	■	轻度

- 1. 漏洞概述

http://192.168.100.200:8201/user/manage.php 构造html页面，用户点击后可触发用户信息修改

- 1. 修复建议

检查Referer Header，拒绝来自非本网站的直接URL请求；避免在URL中明文显示特定操作的参数内容；使用同步令牌（Synchronizer Token）,检查客户端请求是否包含令牌及其有

效性

1. 公司简介存储型xss
  1. 风险级别

威胁级别	严重	■	中度		轻度

- 1. 漏洞概述

http://192.168.100.200:8201/user/manage.php 修改注册信息，公司简介存在存储型xss

payload: </td><script>alert(1)</script>

点击我的展厅，访问 http://192.168.100.200:8201/zt/show.php?id=3 触发

- 1. 修复建议

输入做过滤，输出做转义。只允许http和https协议，htmlspecialchars()函数用来对输入过滤，把预定义的字符转换成html实体

1. 安全风险总结
  1. 安全概况

总体风险描述：

因此，我们认为系统总体安全状态为“紧急状态”。

- 1. 安全管理方面
- 进一步落实口令管理制度，建议使用独立的、随机生成的满足强度要求的口令，严禁使用弱口令、统一口令管理服务器，及时销毁临时、测试账户；
- 进一步加强人员安全意识教育，预防攻击事件发生。例如周期性的修改信息系统口令、尽可能的使用客户端收发电子邮件、退出使用WEB邮箱系统时一定要注意注销用户而不是关闭浏览器等等；
- 信息系统上线前增加安全验收环节，保证系统安全上线
- 信息系统下线后增加安全退出环境，保证相关信息、防火墙规则、数据的安全处理。
  1. 安全技术方面
运行环境部署需要进行加固处理，Web应用访问数据库的用户需要采用最小权限原则，防止攻击者利用数据库缺陷进行权限提升等操作，同时对中间件软件，如WEBSPHERE、TOMCAT、JBOSS等，应进行降权运行处理，防止脚本木马直接获得系统权限；
关注各个应用系统所使用程序、组件、第三方插件等安全现状，及时更新相应的补丁版本，如本次测试过程中所发现的OWA、jQuery等；
加强对敏感服务器、配置文件、目录的访问控制，以免敏感配置信息泄露；
加强信息系统安全配置检查工作。
- 1. 开发过程管理
在系统开发与运行维护的所有阶段（如：计划需求、设计、编码、测试、运行和维护）强制实施严格的变更控制，对变更的申请、审核、测试、批准、执行计划与具体实施提出明确要求，确保系统安全性与控制措施不被损害；

变更控制包括以下内容：

- 审查变更控制措施和流程的完整性，确保未被修改和破坏；
- 确保操作系统的更改不会对应用系统的安全性和完整性造成不良影响；
- 确保系统文档在每次修改后得到及时更新，并确保旧文档被正确归档和处置；
- 做好软件升级的版本控制，如保存历史版本；
- 保留所有变更的审计跟踪记录；
- 确保操作文档以及用户程序能在必要时被修改；
- 确保及时更新业务连续性计划。
针对开发人员对源代码的管理，应严禁将源代码信息上传至互联网上的网络磁盘或源代码仓库，如GITHUB、网盘等；建议建立自运营的代码管理仓库，如有必要上传至互联网上，应对敏感关键信息进行屏蔽，如API地址、IP地址、数据库密码等，防止信息泄露；
应尽量避免修改厂商提供的软件包，如必须修改，应注意以下几点：
- 评估软件包内置的控制措施和完整性流程遭受破坏的风险；
- 应征得原厂商的同意，由原厂商提供标准的升级程序来实现软件包的更改。
在软件的原始采购、开发、使用和维护过程中，应采取如下防范控制措施：
- 仅从信誉卓著的厂商处购买软件；
- 尽量购买提供源代码的软件，以便进行检验，在投入使用之前检查所有源代码；
- 使用通过权威机构评估测试的软件产品；
- 一旦安装完毕，控制对源代码的访问和修改；
- 安装并正确使用有关后门的检测和查杀工具。
  1. 安全架构设计基本原则

在应用系统软件开发设计的过程中，对应用系统的总体设计应当满足如下安全原则：

原则	说明
最小权限原则 Least Privilege	应用软件的每个模块如进程、用户只能访问当下所必需的信息或者资源。赋予每一个合法动作最小的权限，以保护数据以及功能避免受到错误或者恶意行为的破坏。
权限分离原则 Separation of Duties	对业务的操作、管理和审计权限应该由软件中的不同角色的用户分别承担；普通用户和管理员用户信息应该存放在不同的数据表中。
深度防御原则 Defense in Depth	在应用程序对业务数据进行处理的每个阶段都要考虑安全性问题，不能仅在某个阶段做安全防御，这样单点防御一旦被突破将造成安全风险。
容错保护原则 Fail Secure	当程序出现故障时或系统异常当系统失败时，可以进入到一个失败保护的状态。如果用户请求失败，系统仍可保障安全。
单点异常终止原则 Single Point of Failure	当用户提交数据超出预期时，应立即终止程序的执行，不要试图加以修正并继续执行下去。
外来代码安全原则 Least Third Party Components	严格控制第三方函数与插件的使用，对外来代码必须进行详细的安全测试。
代码重用原则 Leveraging Existing Components	尽可能的重用软件已有的模块，这样可以降低引入新的漏洞和攻击界面的可能性。
数据保护原则 Data Protection	对用户数据的保护功能应涵盖用户数据存储的完整性、用户数据传输保密性、数据传输的访问控制、剩余信息的保护、数据反转操作等内容；应对系统中关键数据（如用户密码等）的存储和网络传输时应采用加密保护，实用加密加密算法应该符合国际标准、国家标准和业界标准。
可审计原则 Auditing	在应用系统中设计审计日志记录的功能，并对应用系统产生的日志增加完备的审计功能。
开放设计原则 Open Design	开放设计与“不开放即安全”的原则相对而言，认为设计本身不应具有神秘感。这一原则的具体表现可以参见应用于加密设计的Kerchoff定律，“系统不应单纯依赖私密性，若落入敌人手中则毫无优势可言”；开放设计以提高系统兼容性和可扩展性。
抗抵赖原则 Anti Repudiation	对于涉及支付交易等重要的业务场景，系统设计应有效地防止通信双方抵赖，如采用电子证书签名等方式。
规范性 Standardization	系统设计所采用的安全技术和安全产品应符合国际标准、国家标准和业界标准，为系统的扩展升级、与其他系统的互联提供良好的基础。
可扩展性 Scalability	以当前业务安全需求为基础，充分考虑发展的需要，安全功能模块子系统以插件或接口方式以方便未来的扩展。
实用性 Practicable	安全功能设计需要尽可能的考虑投入产出比，同时尽量控制对用户体验的影响。
符合性 Regulatory Compliance	安全功能的设计尽可能的要符合国家规范、行业规范以及业界的通用标准，如等级保护等规范。

安全风险状况等级说明

安全风险状况说明
良好状态	信息系统处于良好运行状态，没有发现或只存在零星的低风险安全问题，此时只要保持现有安全策略就满足了本系统的安全等级要求。
预警状态	信息系统中存在一些漏洞或安全隐患，此时需根据评估中发现的网络、主机、应用和管理等方面的问题对进行有针对性的加固或改进。
严重状态	信息系统中发现存在严重漏洞或可能严重威胁到系统正常运行的安全问题，此时需要立刻采取措施，例如安装补丁或重新部署安全系统进行防护等等。
紧急状态	信息系统面临严峻的网络安全态势，对组织的重大经济利益或政治利益可能造成严重损害。此时需要与其他安全部门通力协作采取紧急防御措施。

漏洞等级状况说明

安全风险状况说明
低危漏洞	对系统造成较小的影响，攻击成本高，攻击场景较为苛刻，不会直接影响到系统的正常运行，攻击者可能无法通过该漏洞获得权限。
中危漏洞	对系统造成一般的影响，攻击成本一般，在特定场景下将可影响系统的正常运行，攻击者需要配合其他安全漏洞方可间接获得权限。
高危漏洞	对系统造成严重的影响，攻击成本低，一般情况下可直接利用而无需特定场景和要求，攻击者可直接利用该漏洞获得权限。

阅读剩余

THE END