Phpweb安全开发实战

一、背景团队最近频繁遭受网络攻击，引起了部门技术负责人的重视，笔者在团队中相对来说更懂安全，因此花了点时间编辑了一份安全开发自检清单，觉得应该也有不少读者有需要，所以将其分享出来。二、自检清单检查类型说明检查项输入验证概述任何来自客户端的数据,如URL和参数、HTTP头部、 Javascript戓其他嵌入代码提交的信息,都属于不可信数据。在应用外部边界或内部每个组件或功能边界,都将其当做潜在的恶意输入来校验 白名单不可信数据可以设定白名单校验的,应接受所有和白名单匹配的数据,并阻止其他数据 黑名单不可信数据中包含不良输入字符时,如空字节(%00)、换行符(%0d,%0a,r, n)、路径字符(../ 或 ..)等,建议直接阻止该数据,若需要接受该数据,则应做不同方式的净化处理 规范化不可信数据的净化和校验前翯进行规范化,如将目录遍历(./或)等相对路径转化成绝对路径URL解码等。 净化不可信数据需实施各种净化处理时,应彻底删除恶意字符,只留下已知安全的字符,或者在处理前对它们进行适当编码或"转义",如数据输出到应用页面时对其进行HTML编码可防止脚本攻击 合法性校验不可信数据的合法性校验包括:数据类型如字符.数字、日期等特征;数据范國;数据长度等 防范SQL注入不可信数据进入后端数据库操作前,建议使用正角的参数化查询来处理,避免出现SQL注入 文件校验不可信数据为解压缩的文件时,如果文件位于服务目录外或文件大小超过限制,应拒绝处理 访问控制不可信数据通过上述校验后,还应确认所提交的内容是否与用户的身份匹配,避免越权访问输出验证概述考虑目标编译器的安全性，对所有输出字符进行正确编码 编码场景不可信数据输出到前后端页面时,根据输出场景对其进行相关编码,如HTML实体编码、UR编码 净化场景针对操作系统命令、SQL和LDAP查询,净化所有输出的敏感信息,如银行卡、手机号、系统信息等身份验证概述所有对非公开的网页和资源的访问,必须在后端服务上执行标准的、通用的身份验证过程 提交凭证用户凭据必须经过加密且以POST方式提交,建议用HTPS协议来加密通道、认证服务端 错误提示安全地处理失败的身份校验,如使用"用户名或密码错误"来提示失败,防止泄露过多信息 异常处理登录入口应具有防止暴力或撞库猜解(利用已泄露的密码字典进行批量登录尝试)的措施,超过1次验证失败自动启用图灵测试,超过多次验证失败自动启用账户锁定机制限制其访问 二次验证在执行关键操作(如账户密码修改、资料更新、交易支付等)时,先启动图灵测试,再对用户身份进行二次验证。交易支付过程还应该形成完整的证据链,待交易数据应经过发起方数字签名 多因子验证高度敏感或核心的业务系统,建议使用多因子身份验证机制,如短信验证码、软硬件 Token等。短信验证验证码生成复杂度至少6位数字或字母,一次一用,建议有效期不超过180秒。 验证码限制前后端设置用户获取频率为60秒一次,建议每个用户每天获取的短信最多10条 安全提示增加安全提示:至少含本次操作的功能、验证码发送编号、是否是个人自己操作的风险等信息。 凭证校验禁止在响应中返回验证码,服务器端同时校验密码、短信验证码等凭证信息,防止出现多阶段认证绕过的漏洞。图灵测试验证码生成复杂度至少4位数字或字母,或者采用拼图等验证方式,一次一用,建议有效期不超过180秒 验证码使用建议从用户体验和安全角度出发,可设计为当用户输错1次密码后自动弹出验证码输入框验证 验证码校验禁止在响应中返回验证码,验证码校验应在服务端进行密码管理密码设置密码设置时,应该满足8位及以上长度,含大小写字母、数字及特殊字符等的要求。用户密码设置必须经过后端验,不允许设置不满定复杂度要求的感密码。 密码存储用户密码存储时,应采用哈希算法(如SHA1)计算用户密码和唯一随机盐值(Salt)的摘要值保存其摘要和Sat值,建议分开存储这两个值 密码修改用户修改密码时,修改操作需要通过手机号或者邮箱地均进行一次身份验证。密码变更时,应短信或者邮件通知如用户是否是本人操作,告知其安全风险 密码找回用户密码找回时,后端需要对注册手机号或邮箱进行二次验证,验证码和验证链接应发送至预先注册的地址,并设置有效期以防止暴力破解。密保问题,应当支持尽可能随机的问题提问。在多个验证操作中,要对各验证机制进行排序,以防出现跳过前面验证机制直接到最后步认证的安全风险 密码使用应用开发中禁止设置万能密码、硬编码明文的密 码、使用数据库管理员账户操作、不同用户公用账 户操作或者将密码输出到日志文件或者控制台.会话安全防止会话劫持在应用程序进行身份验证时,建议持续使用HTTPS连接,认证站点使用HTTPS协议。如果连接是从防止会话劫持HTTP跳转到HTTPS,需要重新生成会话标识符。禁止在HTTP和HTTPS之间来回转换,这可能会导致会话被劫持 会话标识符安全设置会话 Cookie时,正确设置" Httponly’属性(禁止程序加5脚本等读取 Cookie信息)" Secure’属性(禁Cookie安全设置止Cookie通过HTTP连接传递到服务器端进行验证);" Domain"属性(跨域访问时可指定的授权访问域名),“Path"属性(授权可访问的目录路径)。 Cookie安全设置会话标识符应放置在HTP或HTPS协议的头信息安全中,禁止以GET参数进行传递、在错误信息和日志中记录会话标识符 防止CSRF攻击服务器端执行了完整的会话管理机制,保证每个会防止CSRF话请求都执行了合法的身份验证和权限控制,防止攻击发生跨站点请求伪造(CSRF)漏洞。 会话有效期会话应在平衡风险和功能需求的基础上设置有效期。定期生成一个新的会话标识符并使上一个会话会话有效期标识符失效,这可以缓解那些因原会活标识符被盗而产生的会话劫持风险。 会话注销注销功能应用于所有受身份验证保护的网页,用户会话注销登出后应立即清理会话相关信息,终止相关的会话连接访问控制控制方法将访问控制的逻辑代码与应用程序其他代码分开服务端根据会话标识来进行访问控制管理。 控制管理限制只有授权的用户才能访问受保护的URL、文件、服务、应用数据、配置、直接对象引用等 接口管理限制只有授权的外部应用程序或接口才能访问受保护的本地程序或资源等 权限变更当权限发生变更时,应记录日志,并通知用户是否是本人操作,告知存在的安全风险SQL注入概述用户的输入进入应用程序的SQL操作前,对输入进行合法性校验。 参数化处理用参数化查询(PHP用PDO,Java用 PreparedStatement,C#用 Sqlparameter)方法对敏感字符如"进行转义,然后再进行SQL操作。 最小化授权为每个应用配置最小化数据库操作权限,禁止用管理员权限进行数据库操作,限制操作连接数。 敏感数据加密敏感信息都采用了加密、哈希或混淆等方式进行保密存储,降低可能漏洞带来的数据泄露风险. 禁止错误回显禁止系统开启 Debug模式或异常时返回包含敏感信息的提示,建议使用自定义的错误信息模板异常信息应存放在日志中用于安全审计XSS注入输入校验对输入的数据进行过滤和转义,包含但不限于<>“9%0&+V"等危险特殊字符 输出编码输入数据输出到不同场景中进行不同形式的编码,如输出到HTML标签中则进行HTML编码输出到URL中则进行URL编码,输出到JS中则行 Script编码,输出到 Stylet中则进行CSs编码XML注入输入校验在XML文档内部或外部引用数据时,过滤用户提交的参数,如<、>&等特殊字符。禁止加载外部实体,禁止报错 输出编码建议对XML元素属性或者内容进行输出转义敏感信息敏感信息传输敏感信息传输时,禁止在GET请求参数中包含敏感信息,如用户名、密码、卡号等。建议为所有敏感信息采用TSL加密传输。 客户端保存客户端保存敏感信息时,禁止其表单中的自动填充功能、以明文形式保存敏感信息 服务端保存服务端保存敏感信息时,禁止在程序中硬编码敏感信息,明文存储用户密码、身份证号、银行卡号、持卡人姓名等敏感信息,临时写入内存或文件中的敏感数据,应及时清除和释放 敏感信息维护敏感信息维护时,禁止将源码或SQL库上传到开源平台或社区,如 Github、开源中国等。 敏感信息展示敏感信息展示时,如果是展示在web页面上,应在后端服务器上进行敏感字段的脱敏处理。CSRF跨站请求伪造Token使用在重要操作的表单中增加会话生成的 Token字段次一用,提交后在服务端校验该字段 二次验证在关键表单提交时,要求用户进行二次身份验证如密码、图片验证码、短信验证码等 Referer验证检验用户请求中 Referer:字段是否存在跨域提交的情况文件上传安全身份校验进行文件上传时,在服务端对用户的身份进行合法性校验 合法性校验进行文件上传时,在服务端对文件属性进行合法性校验,白名单形式检查文档类型(如文件的后缓名、文件头信息校验等)和大小(图片校验长、宽和像素等)。 存储环境设置进行文件保存时,保存在与应用环境独立的文档服务器中(配置独立域名),保存的目录权限应设置为不可执行 隐藏文件路径进行文件保存时,成功上传的文件需要进行随机化重命名,禁止给客户端返回保存的路径信息。 文件访问设置进行文件下载时,应以二进制形式下载,建议不提供直接访问(防止木马文件直接执行)接口安全网络限制调用方网络限制,比如通过防火墙、主机host和Nginx deny等技术措施进行校验。 身份认证调用方身份认证,比如key、 secret、证书等技术措施进行校验,禁止共享凭证 完整性校验调用的数据安全,对全部参数使用SHA1等摘要运算进行数字签名,识别数据被篡改 合法性校验调用的参数检查,如参数是否完整,时间戳和Token是否有效,调用权限是否合法等 可用性要求调用的服务要求,调用满足等幂性即保持数据一致性,对调用频率和有效期进行限制 异常处理调用的异常处理,调用行为实时检测,发现异常及时阻拦I/O操作共享环境文件安全在多用户系统中创建文件时应指定合适的访问许可,以防止未授权的文件访问,共享目录中文件的读/写/可执行权限应该使用白名单机制,实现最小化授权。 数据访问检查防止封装好的数据对象被未授权使用,设置合理的据缓存区大小以防止耗尽系统资源, 应用文件处理应用程序运行过程中创建的文件,需设置问权限(读、写、可执行),临时文件使及时删除运行环境最小化开放端口关闭操作系统不需要的端口和服务 后台服务管理后台(如数据缓存和存储、监控、业务管理等)务限内部网络访问,开放在公网的必须设置身份验证和访问控制。 环境配置使用安全稳定的操作系统版本、Web股务器软件各种应用框架、数据库组件等 敏感代码处理将客户端敏感代码(如软件包签名、用户名密码校验等)都放在o等软件包中防止篡改。 关闭调试通道生产代码不包含任何调试代码或接口 通信安全配置网站的HTTPS证书或其它加密传输措施。异常处理容错机制在应用实现时应包含完整的功能异常捕获机制如try-catch块,典型位置:文件、网络、数据库、命令操作等。一旦出现异常,应该在日志中完整记录异常的发生时间、代码位置、报错详情、触发错误的可能用户等,重要系统的严重异常应该有报警的机制,及时通知系统运营者及时排查并修复题 自定义错误信息在生产环境下,应用程序不应在其响应中返回任何系统生成的消息或其他调试信息,配置应用服务器使其以自定义的方式处理无法处理的应用程序错误,返回自定义错误信息 隐藏用户信息禁止在系统异常时泄露用户的隐私信息,典型的有:身份信息、个人住址、电话号码、银行账号、通讯记录、定位信息等 隐藏系统信息禁止在系统异常时泄露系统的敏感信息(用户账户和密码、系统开发密钥、系统源代码、应用架构、系统账户和密码、网络拓扑等)。 异常状态恢复方法发生异常时要恢复到之前的对象状态,如业务操作失败时的回滚操作等,对象修改失败时要恢复对象原来的状态,维持对象状态的一致性日志规范记录原则确保日志记录包含了重要的应用事件,但禁止保存敏感信息,如会话标识,账户密码、证件等 事件类型记录所有的身份验证、访问操作、数据变更、关键操作、管理功能、登出记录等事件。 事件要求日志一般会记录每个事件的发生时间、发出请求的IP地址和用户账户(如果已通过验证)。 日志保护日志受到严格保护,避免未授权的读取或写入访问。三、图书推荐如果对笔者的文章较为感兴趣，可以关注笔者新书《PHP Web安全开发实战》，现已在各大平台上架销售，封面如下图所示作者：汤青松日期：2018-11-13微信：songboy8888 ...

背景公司上市不到两周，便遭受到了黑客攻击，其中笔者团队的验证码比较容易识别，攻击者通过ORC识别刷了10几万的短信，除了造成一笔资金开销外，也给服务器带来了很大的压力；并且在阿里云的控制台当中每天都能看到很多攻击信息，却没有拦截，原因是没有购买WAF防火墙，售后也频繁催促购买其安全设施；所以技术负负责人也开始重视起安全问题来，笔者因为懂一些安全技术，所以老大希望笔者在这方面做一些规划指导，周末花了点时间根据公司的现状做了一下规划设想，下文便是当时的口述汇报，后来整理成了文字版，给读者做一些参考吧。一、网络安全威胁提到安全可能直觉上会想到安全漏洞，代码安全等问题，不过安全一般比直觉上的范围更广泛，主要有来自于六个方面：网络安全、主机安全、应用安全、数据安全、运维安全、法律风险等。1.1 网络层拒绝服务攻击，分布式拒绝服务攻击（DDoS），是最暴力、血腥、有效的攻击方式，可直接导致企业云上业务系统带宽堵塞。DDOS攻击防御有两个核心点，首先是识别谁是恶意攻击，另外就是要有足够的带宽和服务器性能来处理这些请求，DDOS攻击是在太野蛮，应对的方法也比较被动，可以使用云平台的防DDOS产品，但也会有误伤，所以遇到这种攻击也只能使用这种无奈的处理来应对。1.2 主机层云主机入侵攻击，云主机是企业云上业务系统的重要承载，攻击者通过暴力破解或配置漏洞等缺陷入侵云主机，用以构建僵尸网络、窃取数据及敲诈勒索等。主机层的风险通常是一些通用漏洞的风险，比如2016年心脏滴血事件全球的服务器都会受到此影响，因此到相对好处理，我们可以使用阿里云的安骑士产品，一键修复系统中的安全漏洞。1.3 应用层Web应用漏洞攻击，企业云上业务系统对外提供服务的诸多系统采用HTTP/S应用协议（Web），攻击者利用Web服务可能存在的诸多漏洞进行攻击，窃取业务系统数据或权限等。应用层变更最为频繁，每家的应用特点都有一些差异，所以通常应用层受攻击的可能性最大，要防御此风险需要持续不断的进行跟进，比如对开发的安全意识，安全开发进行培训，对项目上线前的测试增加安全测试部分。1.4 数据层数据窃取或篡改云上业务系统数据在传输过程中经过互联网，可能被中途窃取或篡改，造成数据完整性和机密性受到影响。数据层相对范围比较广，比如代码是否泄漏，是否有数据泄漏，以及页面挂马，网站的留言的黄赌毒关键词筛选等，因为这些数据泄漏的途径会随着应用层的变化而变化，因此数据层也同样需要持续跟进。1.5 运维层运维人员违规风险操作企业云上业务系统需要内部人员进行运维操作，如何防范高风险的运维操作至关重要。不过运维层的操作风险倒也是各个厂家的一些通用风险，因此解决方案也相对较多，比如使用堡垒机在可视化界面上分配权限，这个权限可以让一个账户指定开启多长时间，并且还可以全程监控，以及操作记录回查，因此风险不大。1.6 合规层国家等级保护2017年6月，国家网络安全法开始实施，企业安全建设不仅仅是内部驱动，同时也有法律驱动。包括实名制，以及日至留存，制定相应的企业安全防护策略等。二、安全制度大多数人可能想到安全是从安全技术上来解决，实际上安全问题不仅仅靠的是技术层面，更多的是从制度上去解决的；2.1 安全工程化这里提一下SDL，SDL是英文字母的缩写，中文名称是安全开发生命周期，他是一套安全的生成流程。最开始来自于微软，在微软2004年以前windows系统和office中存在大量安全漏洞，为了解决这些问题提出了SDL，当使用了SDL之后office、windows的安全漏洞大量降低，后来被各个厂商推广。SDL从 安全培训-》需求分析-》设计-》实施-》安全验证-》发布-》响应 这7个方面入手，每一个环节有相应的安全标准，不过微软标准版的SDL推广并不是很顺利，原因很多，但标准版SDL比较繁重是一个重要的因素，因此各家都有自己的一套SDL标准，在这方面我们也可以进行一些借鉴，制定一套自己的SDL标准，这个标准的制定一定要符合可执行可落地来为依据，可以参考我下面的落地实施部分。2.2 对外沟通2016年前以前，白帽子发现漏洞在乌云网报告，乌云网通知到各个公司，2016年7月之后乌云网关闭，一批白帽子被抓，导致白帽子发现漏洞不敢报告；不过后来各家开始组建自己的漏洞报告平台，2017年6月安全法出来之后，大部分公司要合规，因此大一些的公司通常都有自己的安全团队，比如教育行业好未来的应急响应中心；现在大家发现漏洞通常会报告给对应的平台的SRC；比如教育行业的好未来SRC：http://src.100tal.com/瓜子二手车的SRC：https://security.guazi.com/以及更多的SRC平台，如下图2.3 安全落地上面提到了安全工程化，不过SDL的标准对于我们现阶段太过于理想，所以需要针对实际情况制定一些可落地的方案安全编程规范将一些可能带来安全风险的操作写入规范当中去，比如参数的输入输出，服务器的安全配置，以及代码的安全发布流程等。安全培训很多时候开发者并不重视安全，又或许对安全缺乏了解，比如系统中有哪些安全漏洞，漏洞的危害和原理是什么样的，怎么去防止这些漏洞等等，大部分开发者的安全意识还是很弱，和互联网技术不重视安全也有关系，可能一些开发者知道一些SQL注入、XSS，但是一深入去问一下，就不知所以然，而开发者对安全起了至关重要的作用，所以很有必要对开发者进行安全意识和安全基础技术的培训，这样才能从源头解决安全问题。代码审计这个不管是对于安全的角度还是对于减少BUG的角度都是很有必要的一个环节，对每个项目设定一个代码审计人员，可以对此这些审计人员组织一次代码审计指导；安全测试目前我们项目上线做了充足的功能测试，但是安全测试相对偏少，或者说并不全面，可以专门针对测试的人进行一些安全工具的测试的指导。三、安全产品阿里云提供的安全产品比较齐全，不过价格比较贵，而目前我们没有专门负责安全的人来维护，因此选择的安全产品方向为能直接提升安全，这样才能发挥最大价值，否则便成了手有宝刀，却无刀法，下面是三个必要的安全产品：1. 安骑士前面提到了主机安全，主机安全不会经常变动，因此应对的是一些通用风险，安骑士提供一键修复通用主机漏洞的能力，可以快速修补主机安全，避免人工去修复并不知道如何去修，或者修复不及时。2. WAF防火墙WAF防火墙对应的是应用层安全，可以针对一些代码级的安全漏洞做一些安全防护，应用层变化最大，因此必要性比较大，不过要注意的是WAF防火墙只能处理代码级的漏洞，而逻辑层的却无能为力，比如上次的刷验证码，防火墙则只能将频率非常高的IP封锁，但无法阻挡刷验证码的漏洞问题。3. CA证书CA证书的作用是HTTPS，是用来对传输过程加密，比如服务器提交数据到服务器过程不被攻击者拦截，又或者我们服务器的数据不被一些网络运营商插入广告等，因此重要性也是十分重要。另外针对阿里云的安全产品较贵的，可以参考也可以参考其他家的安全产品，比如百度的云加速，就带有了WAF防火墙和防DDOS功能，地址为 su.baidu.com四、新书推荐如果对笔者的实战文章较为感兴趣，可以关注笔者新书《PHP Web安全开发实战》，现已在各大平台上架销售，封面如下图所示作者：汤青松日期：2018-11-13微信：songboy8888