Blackboard 提供一项强有力的安全性计划,其不仅能防止出现安全问题,还能对问题加以解决。Blackboard 在代码级别(静态分析)和应用程序级别(动态分析)执行持续内部安全性测试,以确保其符合 Blackboard 和客户的期望。

此外,为了定期了解应用程序的最新情况,Blackboard 会从第三方安全供应商处获得安全性渗透测试。发现的任何问题都会得到快速修复。

Blackboard 的安全性计划实践在不断发展,且日趋成熟,认识到这一点非常重要。我们会持续不断地做出改进,从而提升 Blackboard Learn 的安全特性和稳定性。


设计中考虑了安全性

Blackboard 致力于向我们的客户提供安全的应用程序。我们根据许多组织(如开放 Web 应用程序安全性项目 (OWASP))生成的一组安全性工程准则(包括针对 OWASP 前十大漏洞的特定对策)来开发 Blackboard Learn。Blackboard 将这些安全性实践溶入软件开发生命周期 (SDLC) 的每一阶段中。

Blackboard 利用多种方法来保护我们的应用程序,包括通过威胁建模和分析进行的“自顶向下”安全评估,以及通过静态分析、动态分析和手动渗透测试进行的“自底向上”代码级别威胁检测。

Blackboard 遵循许多组织的最佳实践指导,帮助增强 Blackboard Learn 产品和方案的安全性。我们在下方列出了其中一些组织:

  • 美国国家标准技术局 (NIST)
  • 欧洲网络与信息安全局 (ENISA)
  • SANS Institute
  • 开放 Web 应用程序安全性项目 (OWASP)
  • 云安全联盟 (CSA)

威胁建模

在开发新功能时,安全性团队通过执行威胁建模来评估需求和系统设计,从而帮助降低风险。威胁建模是一个结构化过程,在这个过程中会发现与正在审核的功能相关的安全性威胁,以便识别和应用相应的安全对策。


安全编码和 OWASP 前十大漏洞

Blackboard 产品是根据 OWASP 生成的一组开发准则(包括针对 2013 年 OWASP 前十大漏洞的特定对策)开发出来的。

A1:注入(SQL/DOM/LDAP 注入)我们的编码标准是,使用绑定变量并避免转录为 SQL 语句的文本。在应用程序的任何地方都不使用 Xpath;LDAP 功能仅限于验证。
A2:中断的验证和会话管理我们采取多项措施来避免会话 Cookie 遭到入侵。自 2014 年 4 月以来,Learn 仅在 TLS 下运行,因此,所有 Cookie 都设置了安全标记。此外,我们还尝试在客户端状态下检测意外变化(如来自意外 IP 地址的会话)。与会话管理相关的 Cookie 都设置成了 HttpOnly(注意:JSESSIONID 不用于会话管理,因此不具有 HttpOnly 标记)。
A3:跨站点脚本 (XSS)通过使用共享库(如 ESAPI 和开发标准)降低跨站点脚本攻击风险。所有用户提交的文本输入都通过杀毒软件进行传递;任何其他类型的输入(日期、选择/选项值)都通过键入的域对象生成,而不是直接通过用户输入进行转录。
A4:不安全的直接对象引用所有应用程序对象都通过经常映射到主键的“ids”进行引用。但是,所有对象映射和所有安全性检查都是针对“上下文”执行的。例如,某个请求可能会引用是课程讨论区帖子的“消息 ID”。Blackboard 标准是,对附加到用户在课程中的角色的权限执行授权检查。如果该标准未能正确执行,则补救措施非常简单,因为系统中所有受保护的数据实体均会映射到安全上下文(课程或域)。
A5:错误的安全配置需要系统管理员引起特别考虑时,Blackboard Learn 会采用版本说明和文档来遵循安全默认的策略。Blackboard 鼓励客户遵循安全配置最佳实践指南。

基础结构

鼓励客户使用 Apache™ 2.x,通过文档建议仅采用高强度密码来进行传输层保护。Blackboard 定期检查与 Blackboard Learn 采用的基础结构相关的安全公告,以确保其不受安全问题的影响。

安全性审计

安全事件记录在三个特定于安全的日志之一中。安全事件框架提供一组标准事件代码、标准日志格式、字段详细信息和责任制。记录在每个事件代码的事件集在不断扩大。

凭证

在安装时,要求系统管理员设置密码。

信息泄露和错误处理

标准错误处理适用于所有页面(通过标准页面模板和标记库),从而导致所有错误的标准输出,特别是未被识别的错误。标准输出包括堆栈跟踪(少量信息泄漏),但是此类数据在请求失败时不会得到处理,只有具有管理员级别访问权限的人员才能看到此类数据。未授权用户(如学生)无法看到详细的堆栈跟踪。
A6:敏感数据暴露用户密码经过哈希处理,未经过加密。从 Blackboard Learn 9.1 Service Pack 12 版本开始,用户密码默认采用 SHA-512 进行哈希加密。Blackboard Learn 产品安全性路线图计划处理用于应用程序启动的系统密码,以便受到操作系统和文件系统访问控制的默认保护。Blackboard Learn 支持通过 SSL 运行;但是,部署人员应负责正确配置 SSL。SSL 卸载也受 Blackboard Learn 9.1 Service Pack 8 及更高版本的支持。
A7:缺失功能级别访问控制这在两个级别进行管理,以要求业务逻辑执行授权检查,并确保 QA 测试用例涵盖不同屏幕的授权需求。所有屏幕/链接都有可能呈现;没有要求手动输入的“隐藏”URL。因此,在尝试呈现此类对象之前,应用程序将会获取对 URL 的屏幕访问权限。
A8:跨站点请求伪造 (CSRF)我们的安全框架遵循 OWASP 对每个请求 nonce 值和仅 POST 语义的建议。AJAX 请求使用每个会话的 nonce 值。DWR 使用每个会话 nonce 值的双 Cookie 提交。
A9:使用含有已知漏洞的组件通过对我们的基础结构和第三方软件包执行常规漏洞扫描,发现含有已知漏洞的组件并制定路线图来升级含可用补丁的此类软件包,从而降低该漏洞风险。
A10:未经验证的重定向和转发Blackboard Learn 安全编码标准要求重定向和转发验证其是否为本地地址。我们定期测试该漏洞。

以前的 OWASP 前十大漏洞类别

恶意文件执行从不将非特权最终用户上传的文件用作可执行文件。但是,特权用户(如系统管理员)可以上传用于扩展系统功能的可执行文件包(名称为 Building Block)。我们假定,系统管理员了解风险,并遵循有关任何第三方 Building Block 安装的可靠供应商审核和更改管理实践。

关于未来预期的任何声明、Blackboard 的计划和前景均代表公司当前的观点。由于各种重要因素的影响,实际结果可能会有很大的不同。公司预计,随后的事件和发展将使公司的观点发生变化。然而,尽管公司可能会在未来的某个时候选择更新这些声明,但公司明确表示没有任何义务这样做。