1、目的
发布本文档所列标准的目的是为了保护学校网站和相关信息资产，本标准的目标是为了确保:
按照现有最佳的实践经验，在全校统一部署安全控制措施，以消除或者最低限度的减少系统漏洞和其他安全隐患。
学校能在信息安全的完善方面更方便的有据监管、理解风险和评估改进。
所有的院系部门和网站开发人员都能了解相应的安全需求。
2、范围
所列标准适用于学校所有的web网站服务器,包括：学校内部或第三方建设、采购、部署、修改和维护的。
具体为：
所有仅限内部和面向公共的web服务器
所有由外部供应商托管的面向公共的web服务器
所有通过学校或者代表学校的web服务器建设、采购、部署、修改和维护的
3、责任
以下学校实体具体的信息安全责任
学校信息化委员会
信息安全部门领导
信息安全小组应支撑学校满足信息安全功能和防护的各项要求。
学院和部门领导对所在部门的信息安全负有义务和责任。
Web服务器用户对其处理的信息负有安全责任。
4、Web服务器安全要求
4.1总则
4.1.1基于风险分析的深度信息安全防范手段应被采用，包括：
4.1.1.1安全控件在Web服务器的每一层次上都应部署，以避免过度依赖单一安全防护手段。
4.1.1.2在所有Web服务器上应部署最基本的安全控制措施，以解决常见风险。
4.1.1.3安全控制措施应该是务实的、易于部署、有效和可以衡量的。
4.1.2在虚拟化环境中,所有能考虑到的安全因素都应当适用于主机系统、虚拟机管理层和虚拟化管理工具.
4.1.3渗透性测试每年至少执行一次，并且在重要系统架构部署、应用升级或修改后,都应测试.
4.1.4每季度应执行一次漏洞扫描。
4.2、网络安全
4.2.1安全控制措施应涵盖每一个活跃版本的网络协议，包括IPv4和IPv6。
4.2.2Web服务器都应分配相应的静态IP地址，除了需要部署动态域名系统技术以实现负载均衡的服务器。
4.2.3只使用唯一可信的授权DNS来源,避免受到DNS劫持和攻击。
4.2.4所有的非console口管理员级别的访问应使用高强度加密手段进行加密。
4.3、流量过滤
4.3.1只有从Internet到特定的IP地址和授权的公共可用服务、协议和端口的入站流量是允许的。
4.3.2从Web服务器的非授权出站流量是禁止的。
4.3.3加固TCP/IP堆栈能保护Web服务器抵御拒绝服务攻击，可以采用类似禁用ICMP重定向,SYN攻击保护和禁用IP源路由这些手段.
4.4、合规性
4.4.1所有相关监管和法律要求应当予以鉴别和记录。
4.5、数据保护
4.5.1、应用程序数据(Web内容）和操作系统文件（Web服务器软件）应当分别存储在不同的磁盘逻辑分区或物理分区.
4.5.2、数据存储在数量和时间上的限制应根据法律要求、管理规定和业务要求，并要遵守相关的数据留存规定。
4.5.3、保密数据(包括日志文件）在文件访问和共享上应最小权限，这些数据文件包括：
4.5.3.1、验证文件；
4.5.3.2、日志文件；
4.5.3.3、备份文件；
4.5.3.4、保密的应用程序数据；
4.5.3.5、灾难恢复文件.
4.5.4、任何数据库都应禁止直接访问，所有的访问都应通过编程化的方法.
4.5.5、只有数据库管理员有权限直接访问和查询数据库。
4.5.6、数据库应用程序的ID只能被应用程序本身所使用。
4.5.7、保密和内部数据(包括所有的验证数据）在传输过程中应使用强加密保护。
4.5.8、所有启用了SSL的资源都应禁用HTTP访问.
4.5.9、所有的SSL弱密码都应在服务器上禁用.
4.5.10、在密钥的交换和存储中应采用安全密钥管理流程。
4.5.11、只有来自可信源的SSL认证才能被使用。
4.5.12、不再需要的旧数据和备份文件应当删除。
4.5.13、已删除的文件应在操作系统级别彻底删除。
4.5.14、服务器硬件硬盘在废弃或移作他用之前，应对其使用低格式化工具，磁化或物理损毁来安全消除数据，防止数据内容被重建恢复。
4.5.15、所有非必要的共享（包括默认管理员共享）应被移除，基于角色的接入共享应被禁止。
4.6、输入和输出管理
4.6.1、应使用参数化SQL查询以防止SQL注入攻击。
4.6.2、所有用户输入的字段都应验证。
4.6.3、为防止跨站请求伪造，应在所有的请求中添加唯一的token并验证。
4.6.4、上传文件的大小、类型和内容都应验证，以确保不覆盖已有文件的目标路径.
4.6.5、内容安全策略或者跨站脚本在http头中验证防护应部署，以抵御普通的反射性跨站脚本攻击。
4.6.6、应根据当前漏洞管理的最佳做法(如OWASP指南,乌云平台等），对其他普遍漏洞提供适当的防护。
4.7、安全代码/应用/插件
4.7.1、应评估第三方应用的安全性,其应用部署需得到相关服务拥有者的批准。
4.7.2、开发人员在代码安全技术上应有必要的培训，包括如何避免普通代码漏洞和理解敏感数据如何在内存中处理。
4.7.3、应用程序的开发应基于《安全代码指南》。4.7.4自定义代码在部署到生产环境之间应审核代码漏洞。
4.7.5、测试程序和脚本不应部署在生产服务器上。
4.7.6、所有的供应商开发的应用程序安装的默认脚本和测试文件都应删除。
4.7.7、如果应用程序需要匿名访问，应使用创建的最低权限匿名账号。
4.7.8、匿名账户在Web内容目录上不应有写入权限，不能执行命令行工具。
