研发人员平时的问题（研发人员与安全相关的那些事）

花终凋落

收藏 赞 分享

提到安全这个话题，相信大家肯定不会陌生，某些互联网公司被拖库，代金券、优惠券被薅羊毛，以及一些第三方的框架存在安全漏洞等，可以说安全与我们的生活息息相关很多时候在未发生安全事件时，安全方案推进落地往往困难重重；而当发生安全事件时，安全方案的重要性被抬的很高，希望能够快速上线止损，今天小编就来说说关于研发人员平时的问题?下面更多详细答案一起来看看吧!

研发人员平时的问题（研发人员与安全相关的那些事）

研发人员平时的问题

概述

提到安全这个话题，相信大家肯定不会陌生，某些互联网公司被拖库，代金券、优惠券被薅羊毛，以及一些第三方的框架存在安全漏洞等，可以说安全与我们的生活息息相关。很多时候在未发生安全事件时，安全方案推进落地往往困难重重；而当发生安全事件时，安全方案的重要性被抬的很高，希望能够快速上线止损。

安全性是软件开发中最复杂，最广泛和最重要的方面之一。在开发周期结束时，软件安全性也经常被忽视，或者被简化为仅需进行少量调整。虽然目前各大互联网功能有安全工程师这个岗位，对于技术研发人员来说了解安全方面的知识还是非常有必要的。

安全设计原则默认安全原则

在设计安全方案时，最基本最重要的原则就是Secure By Default，在任何时候都需要牢记该原则，该原则有2层含义：

第一层含义是“白名单、黑名单原则”：可以解释为“巧用白名单，慎用黑名单”，如果机场安检采用黑名单原则：“哪类人不可以进入机场”，那么有可能无法穷举所有有危险特征的人，当安检采用白名单原则，哪类人可以进入机场，这就简单很多了，只要符合机场安检部门定义的安全项即可。同样放在系统设计中，遵循白名单原则，比如哪些端口允许对外提供服务，其他端口一律关闭就是好的产品设计。

第二层含义是“最小权限原则”：这条相对来说好理解，授予主体必要的权限，不要过度授权。比如申请权限可以申请1年，但是不要申请长期；申请线上机器正常情况下申请guest权限，但是不要申请root权限；最小权限原则的意义是保护权限过大带来的误操作、恶意行为。

纵深防御原则

古代的城市保卫战中，若所有兵力只防守一个城门，结果只有一个：城市很快被攻陷。所以我们在电视剧中看到的城市保卫战，都是全城防御，涉及各城门，城墙，防空，城内巡视，低下通道等，虽然最终可能被攻陷，但是让供方付出了很多的努力和成本。而我们线上系统和城市一样，要求我们以一种全面的视角看问题，在正确的地方做正确的安全方案，避免疏漏，方案间相互配合，形成一个整体。

线上系统一般有哪些特点呢？比如数据传输、中心化、信息私密性、架构分层等，以上不是一个维度的分类，但却可以为我们提供防御设计的切入点。比如数据传输可以做好数据传输的加密，加签等；针对中心化的特点，做好防DDos攻击，避免大流量打趴系统；针对信息私密性需要我们做好权限隔离或验权设计；针对架构分层，在各层部署安全方案，比如服务层不开放80端口，WEB层做输入输出的过滤等。

数据和代码分离原则

这一原则广泛适用于各种由于“注入”而引发安全问题的场景，从漏洞成因角度提炼出的安全设计原则。脱离该原则引发安全问题的原因是程序把用户的输入作为代码来执行，比如常见的XSS漏洞：

<html> <head> 展示用户名字</test> <body> $name </body> </html>

如果name字段未做编码或过滤，html页面在渲染的时候会去解释$name，如果name是<script>alert(1)</script>，会把<script>当作代码来解释，则显然不是开发者希望看到的结果。

如果实现上要求alert（name），那么根据数据和代码分离原则，html代码应该如下：

<html> <head> 展示用户名字</test> <body> alter($name) </body> </html>

不可预测性原则

如果说数据和代码分离是从漏洞成因上设计（比如避免xsss漏洞）、纵深防御原则是从全局防御视角，避免单个薄弱点带来整个系统被攻陷；那么不可预测性原则是从让攻击者失效的角度来进一步保护系统的安全，比如接口调用中的关键参数（如ID、email）进行加密、APP登录使用的随机Token等，都是为了让攻击者找不到攻击的规律，使得攻击失效，在实施时可能需要用到加密算法、随机函数、哈希函数。为了进一步提升攻击失效，还可以对加密串，Token进行过期失效保护。

安全设计

整个系统的安全取决于系统运行物理环境的安全性、服务器及网络的安全性、操作系统的安全性、应用系统的安全性及应用数据的安全性等，通过设计实施整体的安全策略，对安全策略的实施结果进行评估，及时采取修复补救措施，调整安全预防策略，综合动态地进行系统安全管理。

安全合规

对于我们的业务来讲，政策合规性一般不存在问题。但从设计上，也应当留有多个方面的合规审计空间。

  • 操作审计

记录用户的操作对象和操作历史。

  • 权限审计

对权限的分配和变更，做严格的控制和记录，避免授予的权限不必要的扩大。同时对于已经失效的用户，应当即使回收权限。

  • 数据审计

对关键数据的读、写，都应当有权限和审批流程进行控制。实际的示例比如 HRC 和 TOF 中，对员工信息的读取，是需要进行权限申请和审批的。

  • 敏感词审计

应当接入或建立敏感词库，对于 UGC 内容，务必确保拦截和过滤敏感词，以避免不合规的内容展示到系统中，导致政策和舆论风险。

网络安全

系统构建在企业内部网络，部署遵循企业网络架构，不同功能层/区之间的访问严格按照点对点进行访问控制，比如阿里巴巴有严格的网络设计遵循七网隔离，包括开发、测试、生产以及办公网等。

网络中安装防火墙，进行访问检测、监测、控制、审查分析，阻止非法恶意攻击入侵，高级别的保护可以禁止一些服务，如视频流，Java、ActiveX、JavaScript脚本等，阻止恶意代码进入。

互联网安全

系统与外联系统的数据传输网络安全严格遵照执行外联网络建设相关规范的安全要求，同时复用已有的互联网连接及其安全控制措施：

  • 传输加密

般开放 Web 访问，走 HTTP 协议。要对外公开接口或页面时，面向外网应当以 HTTPS 的形式公开。

  • 网络隔离

通过网络互不连通来防止入侵，这是最严格也是最暴力的安全解决方案。在我们的生产实践中，主要体现在如下几个方面：

不公开服务的机器，不分配外网 IP

办公网络和生产网络相互不可以直接通信

网关：设计独立的接入层专门负责网络请求的接入，不得将非接入层的机器公开出去。

  • 容器

我们的应用目前主要基于容器部署。在启动容器时，我们应当为每个不同的项目创建和指定不同的网络，从而隔离不同的项目服务。

  • 网络端口
  • 严格开放网络端口，比如互联网只需要开放80端口，同时遵循只入不出或只出不入。
  • 外联单位业务主机必须通过安全控制设备（如防火墙）访问网络，外联单位系统必须与外联区的业务前置机进行数据交换，不得直接访问内部网。
  • 在内网区部署一台内网数据中转服务器，由该服务器统一实现内网服务器与各业务前置机的数据交换，保障内网数据安全。
  • 采取层次防护、区域控制的策略，通过边界防护和核心防护保护外联网络系统安全。
  • 通过NAT技术，对外隐藏内部网络结构。
  • 采用静态路由，限制外联单位访问。
  • 同一个平台的多个业务流用ACL进行严格的隔离，使每一个业务流严格地按照规定的静态路由传输。
  • 通过IDS系统对外联区进行入侵检测和行为审计。
  • 对外联平台使用的网络设备、安全设备和服务器进行严格的访问控制，保障设备的运行安全。
  • 定期分析、评估防火墙和IDS的日志，及时处理各级报警信息，并采取有效措施进行解决。对发现的恶意入侵事件应及时处理并立即上报。
服务器与客户端系统安全

为避免单点故障，应用服务器、数据库服务器等需采用集群或HA配置。

对于服务器操作系统，进行相应的安全配置维护管理，及时打补丁，安装反病毒程序，定期查杀病毒，根据实际情况及时进行安全策略调整，定期进行有关系统的数据备份。

对于数据库系统，进行相应的安全配置维护管理，根据实际情况及时进行安全策略调整，定期进行数据库系统的有关备份。

由于客户端计算机用途很开放，很容易受到病毒感染、恶意攻击等，可能会进一步影响到服务器，因此，对客户端计算机也要采取安全措施，进行相应的安全配置管理，如设置有效的系统密码，设置较高的浏览器级别，及时打补丁，安装反病毒程序，定期查杀病毒，根据实际情况及时采取安全措施。

终端准入机制

系统具备终端准入机制，只能允许已经注册认证的合法终端才能够访问系统服务。

系统根据IP设置接入应用的黑白名单。

主机安全身份认证与标识、鉴别

系统SSH登录需要接入堡垒机，同时有登录session过期机制，确保安全。

系统提供完备的权限管理、用户认证、密钥管理方案。

系统支持多种认证机制，目前已在使用的有密码、指纹。

系统支持用户认证失败超过指定次数后的锁定机制，用户锁定后需要主管用户对其进行解锁，用户忘记密码可以向管理员申请重置密码。

用户密码认证支持有效期，超过有效期后，会要求用户修改密码。

系统可控制用户登陆地点，通过机构下可使用IP地址范围，限定不在IP地址范围内终端不得登陆。

平台可采用SSL加密传输的方式，用户和服务方之间在网络上传输的所有数据全部用会话密钥加密，直到用户退出系统为止，而且每次会话所使用的加密密钥都是随机产生的。

鉴别机制（采用用户名和口令机制）

• 输入口令字时以“*”回显；

• 用户的口令是以密文方式存在数据库中；

• 用户认证通过后，如果在一定时间内（该时间可以通过配置文件设定）无操作，需要重新认证；

鉴别失败处理

• 当用户连续鉴别错误次数超过门限条件时（该次数可以通过配置文件设定），将该用户锁定，该用户必须通过管理员解锁；

• 返回有限的失败信息(“用户名或密码错”）；

应用系统中的口令规范

• 系统限制口令长度至少六位；

• 口令存储的密码技术使用与密码支持按本页密码支持的要求；

• 系统初始化用户时，默认密码为指定字符串，用户第一次登录系统时强制要求修改初始密码；

• 强制口令一定期限内（此期限是在参数中定义的）更新，默认为30天；

资源利用

系统能够对应用系统的最大并发会话连接数进行限制；

运维安全

理想状况下我们不应当登录服务器进行任何操作，但实际生产却不是这样的。由于运维工具功能的不完善和滞后性，我们往往不得不直接登录到服务器上去直接执行命令，进行日志维护、服务进程维护、服务器维护等操作。由于已经直接触达服务器本身，因此这也是整个系统安全最高危的部分。

  • 运行账户

为减少由于我们的服务被攻击之后造成的损失，减小影响面。在运行应用时，不得以 root 权限运行，而应当另外创建专有用户，并授予最小权限。这样即使应用本身被攻击成功，黑客也需要有一个提权的过程，提高了攻击的门槛。

  • 运维账户和运维审计

对于运维操作，账户本身应当得到严密的管控，严密管控 root 账号。每一个运维人员都应该采用实名登录，并且在每一次登录、操作、登出都进行完善的记录以备审计。

对于高危操作，需要提升运维人员的意识，避免发生由于粗心大意造成的严重后果。

  • 高危命令

谨慎执行高危命令，在必要时使用alias指令重命名高危命令。

  • 容器隔离

容器化部署时，我们往往会挂载外部目录到容器中。此时我们应当确保：

尽可能使用稳定、可靠的云存储，避免单机故障

同一个挂载目录不应当跨容器共享，而应当由单个容器独占

租户隔离：随着 SaaS 化系统越来越多，我们也采用了更多的多租户设计。在系统交互、数据读写方面，务必强要求区分租户。不得因为租户信息被泄露，导致跨租户的其他数据被泄露，必须严控影响面。

数据安全数据传输安全

系统支持数据存储、数据传输、密钥管理等方面的安全功能。系统与其他系统间的数据交互，采用数据接口文件方式进行，系统之间数据库不互相开放。与其他系统间批量数据文件传输通过企业数据集成平台进行，传输过程中建议对数据进行压缩、加密，实现数据安全可控传输。

用户客户端与WEB、应用服务器间支持采用HTTPS协议，对数据传输过程进行加密。

数据备份策略

数据库运行在归档日志模式，可以联机在线进行备份，不影响数据库的访问。数据表采用定期归档、备份策略：

定期（如：每个月进行）将数据表进行清理，将过期数据导入归档数据库，并对归档库进行备份；

同时，对在线库进行定期（全备可以定为每月）全备，并结合每天增量备份的方式，归档、备份时不影响系统运行。

备份时间应该避开数据处理繁忙时间段，可在每天批处理完成后进行备份。

备份数据异地保存，并配置灾备软硬件环境，每日备份数据预先恢复到灾备环境，当灾难发生时，只需要做切换工作，以保障业务中断不超过4小时的RTO目标。

一般性数据恢复时首先确定恢复数据和时点，并从备份数据中先恢复全量备份，再恢复之后的增量备份，完成恢复。

对于灾难性恢复，则通过恢复最近一次的数据备份及源系统数据进行数据追补。日常备份最小时间间隔不大于1 天，以保障灾难发生时数据丢失小于24小时的RPO目标。

应用安全输入验证SQL注入

当应用程序将用户输入的内容，拼接到SQL语句中，一起提交给数据库执行，就会产生SQL注入威胁。

由于用户的输入，也是SQL语句的一部分，所以攻击者可以利用这部分可以控制的内容，注入自己定义的语句，改变SQL语句执行逻辑，让数据库执行任意自己需要的指令。通过控制部分SQL语句，攻击者可以查询数据库中任何自己需要的数据，利用数据库的一些特性，可以直接获取数据库服务器的系统权限。

开发原则

  1. 防SQL注入基本原则：所有用户输入都必须进行合法性校验。所有数据库SQL操作必须参数化。
  2. 回收开发人员等操作生产库权限：减少开发人员、非DBA操作生产库的权限；数据库数据查询要有权限分级和审核。
  3. 尽量使用PreparedStatement代替Statement，一方面，在大多数情况下，使用PreparedStatement的性能将优于使用Statement，另外一方面，可以最大限度的减少SQL注入发生的可能行。
  4. 用户提交的数据都应该做合法性校验，避免用户输入‘，““，-，%，#,&,|，@， 等有可能导致SQL注入的危险字符给系统造成危害。
跨站脚本攻击(XSS)

Web应用程序从用户处获得输入，不经验证，直接在Web页面上输出。漏洞类型：

  1. 存储型XSS / 持久型
  2. 反射型XSS / 非持久型
  3. DOM based XSS

开发原则：

  1. 一切的输入/输出都是有害的，不要信任任何输入/输出数据。
  2. 所有传递过程都不能保障无侵入，执行前、存储前、显示前都要进行“数据清洗”。
  3. 所有的数据校验、处理工作要在前端和服务器端两次进行。
  4. 目前所有的XSS通过XSSUtil来过滤。
跨站请求伪造(CSRF)

攻击者在用户浏览网页时，利用页面元素（例如img，的src），强迫受害者的浏览器向Web应用程序发送一个改变用户信息的请求。

一句话理解：攻击者借你的cookie（登陆权限）让你亲自完成attacker布置的操作(添加/删除/修改)并且你并不知道这个过程。

开发原则：

  1. 所有敏感请求，都使用POST方式提交
  2. 重要操作做二次验证，如短信认证，二次密码认证，验证码、生物验证等。

注：所有的验证码必须与实际参与业务的参数在同一请求内提交服务端，例：修改密码时，需要确保验证码、新密码、旧密码在同一请求内提交，避免验证码绕过。

所有验证码不能传递到客户端，指标：客户端右键“查看源码”看不到验证码。

  1. 使用token防御

用户交互时，设置一个具有超时机制的随机token，种植在用户的cookie 中。当用户提交表单时，生成隐藏域，值为cookie中随机token，用户提交表单后匹配两处token值，来判断是否为用户提交。

  1. 不要靠验证referer的方式预防CSRF

验证用户提交数据的referer 信息，当为提交页时，说明为用户提交，当为其他页面时，说明为csrf 攻击。但是referer是很容易被篡改的，所以不要靠验证referer方式预防CSRF。

  1. 二次验证、token验证、referer验证，三种验证的安全度：二次验证>token验证>referer验证，正常请求使用token验证，重要请求使用二次验证。
XML外部实体攻击(XXE)

XXE漏洞全称XML External Entity Injection 即xml外部实体注入漏洞，XXE漏洞发生在应用程序解析XML输入时，没有禁止外部实体的加载，导致可加载恶意外部文件和代码，造成任意文件读取、命令执行、内网端口扫描、攻击内网网站、发起Dos攻击等危害。

XXE漏洞触发的点往往是可以上传xml文件的位置，没有对上传的xml文件进行过滤，导致可上传恶意xml文件。

开发原则：

  1. 使用开发语言提供的禁用外部实体的方法
  2. 过滤用户提交的XML数据
实体（bean、JSON）注入

在前后端进行数据交互时，数据形式以JSON、Bean为主。其中JSON可通过API直接转换成Bean实体；Bean可以通过spring mvc或struts等框架由前台表单参数自动填充属性值，组成Bean实体。如果没有对这两种类型参数做限制，可能产生Bean的属性数据被篡改或者覆盖的情况，严重时可更改用户密码等私密数据。

同样，用于显示在前端的Bean属性如果没有做限制，那么默认所有属性都将返回前端，暴露给用户，间接造成敏感数据泄露。

开发原则：

  1. Bean操作：无论bean由前端填充到后端还是由后端返回前端显示，都禁止直接操作整个bean，而是操作我们实际需要的那几个属性。
  2. 对于JSON注入，需要对传入的JSON key值做重复性验证。
HTTP响应截断

与许多软件安全漏洞一样，Header Manipulation是达到目的的手段，而不是目的本身。

简单讲，在以下情况下会出现HTTP头操作漏洞：

  1. 数据通过不受信任的来源进入Web应用程序，最常见的是HTTP请求。
  2. 数据包含在发送给Web用户的HTTP响应头中，而不进行验证。

最常见的HTTP头操作漏洞是HTTP Response Splitting。假如应用程序允许CR（回车符，也由％0d或\ r \ n）和LF（换行符，也由％0a或\ n）字符输入，那么不仅使攻击者能够控制应用程序打算发送的响应的标题和正文，而且还允许它们完全在其控制下创建其他响应。

开发原则：

任何由用户控制的即将加入HTTP响应头信息的输入都需要经过验证。

文件上传

Web应用程序在处理用户上传的文件操作时，如果用户上传文件的路径、文件名、扩展名成为用户可控数据，就会导致直接上传脚本木马到web服务器上，直接控制web 服务器。

开发规则：

  1. 由程序自定义上传文件的文件名称。
  2. 只接受指定类型的文件（如zip、图片等），并验证上传文件类型。
  3. 检查上传文件文件大小。
  4. 文件存储采用单独的文件服务器，或者使用阿里云的OSS或开源的minio。
  5. 重要目录设置文件访问权限，如果使用阿里云的OSS，需要设置bucket的权限为private，不建议设置为public。
  6. 所有涉及路径的操作验证路径安全性。
文件下载

当用户通过web下载文件时，所下载文件及路径为变量形式传给程序，例：http://www.abc.com/download.action?file=centos.iso，若程序未对下载文件及路径做检测，就会导致用户可随意输入下载地址，造成任意文件下载漏洞的出现。

开发规则：

  1. 要下载的文件地址保存至数据库中，让用户提交文件对应ID下载文件。
  2. 下载文件之前做权限判断。
  3. 文件放在web无法直接访问的目录下。
  4. 记录文件下载日志。
  5. 不允许提供目录遍历服务。所有涉及路径的操作验证路径安全性。
其他注入

根据代码业务的不同，应用系统可能还会面临以下注入类漏洞的攻击：

  1. 命令注入：用户输入可能控制系统命令
  2. 代码注入：系统需要执行一段由用户控制的代码，例：eval、setTimOut等方法
  3. 配置操纵：用户输入可能控制各种系统设置（例：各种配置文件中内容，db、cache（Redis）、log、activeMQ等）
  4. 资源注入：用户可能控制用于访问系统资源的标识符和连接网络资源的端口号。例如：根据用户输入的端口号建立一个socket。
  5. LDAP注入：用户输入可能控制LDAP的语法、内容或者命令，类似SQL注入
  6. OGNL注入：存在于Struts2框架，struts将http的请求参数对应为OGNL表达式，恶意用户可能修改系统变量或执行任意代码等。
  7. XPath注入：用户输入可能构建动态的XPath语法进行恶意操作，与SQL注入类似，只不过XPath注入的目标是XML数据库，语言是XPath。

以上类型的注入漏洞不多见，只是因为以上类型的开发不常用到，而不是不易被攻击，所以只要应用系统中包含了以上类型的代码开发，就可能产生对应风险。

开发规则：

  1. 禁止由用户输入来动态构成系统命令、各种script执行代码、系统配置、资源链接等。
  2. 针对以上注入类型，例如命令注入、代码注入、配置操纵这种类型可以通过设置白名单的方式，或者通过代码与标识映射关系提供给用户选择；不能够设置白名单的，需要进行相应的、严格的输入验证。以下说明：

a) 命令注入：";"、"&"、" " "、" ' "、"\xOA"、"\xFF"、"|"

b) 代码注入：根据语言不同，确定需要验证的特殊字符，例：javaScript、php

c) 配置操纵、资源注入：设立用户可操作白名单。（强制）

d) LDAP注入：用户输入可能控制LDAP的语法、内容或者命令，类似SQL注入

e) OGNL注入：升级框架版本，最低：OGNL3.0.21、Struts2.3.35，或验证特殊字符："#"、"\u0023"、" " "、" ' "、"%"、"="、"["、"]"

f) XPath注入："/"、"@"、" " "、" ' "、"%"、"="、"["、"]"、"："、"//"、" "("、" ')"、","

安全特性身份认证与会话管理

攻击者可以利用认证或会话管理功能中的泄露或漏洞（比如暴露的账户、密码、或会话ID）来假冒用户, 这些漏洞可能会导致部分或全部账户遭受攻击。一旦成功，攻击者能执行受害用户的任何操作。

失效身份认证-开发规则：

a) 强制性的强密码策略认证，密码设置时,应该满足8位及以上长度,含大小写字母、数字及特殊字符等的要求。用户密码设置必须经过后端验,不允许设置不满定复杂度要求的感密码。

b) 防止短期内密码重用，比如新密码和老密码一样

c) 密码有效期，比如设置3个月更换一次密码

d) 当登录失败次数超过限定值时，需账户锁定，如自动锁定30分钟或人工申请解锁

e) 不要使用与个人隐私相关的数据，如生日，妻子生日，姓名缩写，英文名，手机号码QQ号码等

f) 重要应用要求强密码策略，并考虑双因素认证

g) 密码存储必须以不可逆的加密算法，如Hash算法等，加密之后存储在数据库，使用高级的密码哈希算法，如Bcrypt

失效会话管理-开发规则：

a) 使用应用容器提供的标准的SessionID机制

b) 使用推荐使用的加密机制，比如SHA1 SHA2等

c) 确保用户凭证和SessionID在使用过程中，都处于SSL/TLS的保护下

d) 会话Cookie在浏览器端 的安全配置，如HTTPOnly、Secure、限定域和作用范围、最大存活时间

e) 针对敏感操作，需要使用二次认证的机制来确保安全

f) 在任何权限变更之后，需重置新的会话，如多用户登录或账户切换

g) 设置登出功能，并在登出操作之后，确保该用户Session被销毁

h) 自动会话过期机制

i) 空闲超时，比如30分钟未使用，进行过期操作

敏感信息泄露

对于敏感信息都必须保障其私密性。在页面显示、操作交互中不可避免的会有一些如用户的标识信息、密码、帐号信息、涉及的金额信息等敏感数据(保密性的数据)的存在。为保障这些数据不被曝露而提高安全性，我们要做到所有敏感信息必须进行加密处理，不能以明文的形式存在于任何网络、内存及其它持久化介质中(如：数据库、文件磁盘系统等)。

开发规则：

  1. 重要数据使用强加密算法加密，传输使用https（SSL）
  2. http表单提交选择POST方式，servlet处理请求使用doPost()方法；重要数据输入框禁止填充、禁止缓存：autocomplete="off"
  3. 日志系统禁止记录用户信息，有关用户信息的debug、测试代码禁止遗留
  4. 配置出现异常的统一访问页面，禁止系统异常信息流出
  5. 登陆等认证功能失败后，要提供一般性提示信息，禁止提供明确错误信息，防止攻击者“对症下药”，例：登陆认证失败，提示“用户名密码错误”，而不是“用户名不存在”。
  6. 密码字段优先选择StringBuffer、数组存储，使用后清除
  7. 永远不要相信隐藏域，禁止将敏感信息毫无保留的明文放于隐藏域
  8. 涉及敏感信息的页面都需要禁止页面缓存。
访问控制（数据越权访问）

数据越权访问主要分为垂直越权和水平越权，比如界面上有个连接，点击该连接指向张三的详细信息，url中有张三的id为参数，在地址栏中将张三的id修改为李四的id就看到了李四的数据。严重的情况会导致看到隐私的数据，这属于水平越权。垂直越权是指不同用户级别之间的越权，如普通用户执行管理员用户的权限。

开发规则：

  1. 对平行越权漏洞防护中，增加访问与操作对象的用户属性，在对目标对象进行访问与操作时，服务端校验会话与对象的用户属性，在校验通过后才能执行读取和操作。
  2. 对垂直越权漏洞防护中，所有访问采取默认拒绝机制，采取基于角色访问控制，对于各个功能的访问，规定不同角色拥有不同的访问权限，当用户在使用该功能时，系统要校对用户的权限和访问控制机制是否与规定相同，通过校对者才能使用，否则拒绝使用该功能。
  3. url参数必须要通过urlDecode和urlEncode处理或者加密处理
  4. 如果可能设计url参数防篡改策略
不安全的加密存储

攻击者通常不直接攻击加密系统，被正确加密的数据是难以破解的。不安全的加密算法或方式更容易被预测或破解从而被攻击者获取重要数据。

开发规则：

  1. 用于加密或者数据模糊化的随机数生成器要选择SecuRandom
  2. 所有密码禁止在代码中硬编码，在代码或配置文件中明文存储
  3. 各种加密表现形式及安全度
    • 最基本加密：对密码做hash salt处理，确保salt安全存储以及做完善的访问控制，选择SHA2哈希算法系列。
    • 高级加密：hash算法有一定的安全性，但不能代替加密算法。对密码应该使用更高级的加密算法。
  1. 【强制】选择使用高安全性加密算法的组件，并且密钥存储于数据库进行隔离，若在配置文件中存储密钥需加密或混淆保存，秘钥长度也要满足需求。其中AES秘钥最低128位，RSA最低2048位。
开发框架与组件黑名单

应用中使用的一些组件，比如：库文件、框架和其他软件模块等，如果这些组件有漏洞，且以最高权限运行，可以造成严重的数据泄露或完全控制服务器。

比如fastjson、xstream、hessian某些版本都存在安全漏洞，需要升级到指定安全版本。

开发规则：

  1. 仅从官网渠道获取组件并且在有条件的情况下尽可能采用单一包来避免被恶意篡改的风险；
  2. 很多老的不再支持的库和组件并没有安全升级，这种情况下，可以考虑使用虚拟补丁技术去检查；
  3. 对使用的组件持续监控如CVE和NVD等漏洞中心，可以使用自动化工具来完成此功能；
,
展开全文

免责声明：本文仅代表文章作者的个人观点，与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺，请读者仅作参考，并自行核实相关内容。文章投诉邮箱：anhduc.ph@yahoo.com

猜您喜欢

    热门推荐

    Copyright © 2013-2024 秒懂生活 站务投诉邮箱：anhduc.ph@yahoo.com

    分享
    投诉
    首页