Core Defense Mechanism

处理用户访问

Web应用程序采用的防御机制由以下几个核心因素构成

1.处理用户访问应用程序的数据与功能,防止用户获得未授权访问。

2.处理用户对应用程序功能的输入,防止错误输入造成不良行为。

3.防范攻击者,确保应用程序在成为直接攻击目标时能够正常运转,并采取适当的防御与攻击措施挫败攻击者。

4.管理应用程序本身,帮助管理员监控其行为,配置其功能。

处理用户访问:

1.身份验证

2.会话管理

3.访问控制

身份验证

身份验证是应用程序处理用户访问的最基本机制。验证用户是指确定用户的真实身份。在安全要求更高的情况下,基于客户端证书、智能卡或质询-响应令牌(challenge-response token)使用其他身份验证模型。身份验证除了支持登录以外,还需要支持自我注册、帐户恢复和密码修改工具。攻击Web应用程序时,渗透测试员应当投入大量精力,攻击应用程序采用各种与身份验证有关的功能。身份验证所存在的缺陷往往允许攻击者非法访问敏感数据与功能。

会话管理:

处理用户访问的下一项逻辑任务是管理通过验证用户的会话。通过HTTP cookie实现会话管理。会话管理机制的有效性基本取决于其令牌的安全性,绝大多数针对它的攻击都企图破坏其他用户的令牌。令牌生成过程中存在的缺陷是主要的漏洞来源,使攻击者能够推测发布给其他用户的令牌,随后攻击者再利用其缺陷截获其他用户的令牌。如果使用HTTP的内置身份验证机制,那么浏览器会自动在每个请求中重复提交用户证书,帮助应用程序识别这些请求用户。其他状态下,应用程序会将状态信息保存在客户端而非服务器上,还需要对其进行加密以防遭到破坏。

访问控制:

处理用户访问的最后一个逻辑步骤是做出并实施正确的决策,决定允许或拒绝每一个请求。访问控制需要让应用程序决定是否授权用户执行其所请求的操作或访问相关数据。访问控制机制一般需要实现某种精心设计的逻辑,并分别考虑各种相关应用程序领域与不同类型的功能。由于典型访问控制的要求相当复杂,因此这种机制一般存在大量的安全漏洞,使得攻击者能够获得对应程序的数据与功能的未授权访问。探查这些漏洞是一件费力的工作,因为需要对每一项功能重复进行相同的检查。然而,因为访问控制机制中存在大量漏洞,所以在测试Web应用程序时付出这样的努力总是值得的。

处理用户输入

输入多样性:应用程序需要对一些特殊的输入实行非常严格的确认检查。应用程序必须接受更广泛的输入。应用程序需要接受用户提交的任意输入。如果发现服务器上生成的数据遭到篡改,并且使用标准浏览器的普通用户根本不可能进行此类修改,那么极有可能是该用户正企图探查应用程序的漏洞。在这些情况下,应用程序应拒绝该类用户提交的请求,并将事件计入日志文件中,以便随后进行调查。

输入处理方法:

1.拒绝已知的不良输入:

这种方法一般使用一个黑名单,其中包含一组在攻击中使用的已知的字面量字符串或模式。确认机制阻止任何与黑名单匹配的数据,并接受其他数据。

2.接受已知的正常输入

这种方法适用一个白名单,其中包含仅与良性输入匹配的一组字面量字符串、模式或一组标准。确认机制接受任何与白名单匹配的数据,并阻止其他数据。

3.净化

这种方法认可有时需要接受无法保证其安全的数据。应用程序并不拒绝这种输入,相仿,它以各种方式对其进行净化,防止它造成任何不利的影响。对数据中可能存在的恶意字符被彻底删除掉,只留下一只安全的字符,或者在进一步处理前对他们进行适当编码或“转义”。

4.安全数据处理

以不安全的方式处理用户提交的数据,是许多Web应用程序漏洞形成的根本原因。通常,不需要确认输入本身,只需确保处理过程绝对安全,即可避免这些漏洞。有些时候,可使用安全的编程方法避免常见问题,例如,在数据库访问过程中正确使用参数化查询。在其他情况下,完全可以避免应用程序功能设计不安全的做法,如向操作系统命令解释程序提交用户输入。

5.语法检查:

在一些漏洞中,攻击者提交的输入与普通的非恶意用户提交的输入完全相同。之所为称为恶意输入,是因为攻击者提交的动机不同。例如,攻击者可能会修改通过隐藏表单字段提交的账号,企图访问其他用户的银行账户,这时,再多的语法确认也无法确别用户与攻击者的数据。为防止未授权访问,应用程序必须确认所提交的账号属于之前提交该账号的用户。

继续阅读“Core Defense Mechanism”

TensorFlow_Plane_Fitting

 

Web Application Security And Risk

常见的Web漏洞

1.不完善的身份验证措施。这类漏洞包括应用程序登陆机制中的各种缺陷,可能会使攻击者破解保密性不强的密码、发动蛮力攻击或完全避开登录。

2.不完善的访问控制措施。这一问题涉及的情况包括:应用程序无法为数据和功能提供全面保护,攻击者可以查看其他用户保存在服务器中的敏感信息,或者执行特权操作。

3.SQL注入。攻击者可用过这一漏洞提交专门设计的输入,干扰应用程序与后端数据库的交互活动。攻击者能够从应用程序中提取任何数据、破坏其逻辑结构,或者在数据库服务器上执行命令。

4.跨站点请求伪造。利用这种漏洞,攻击者可以诱使用户在无意中使用自己的用户权限对应用程序执行操作。恶意Web站点可以利用该漏洞,通过受害用户与应用程序进行交互,执行用户并不打算执行的操作。

核心安全问题:用户可提交任意输入

核心问题表现在许多方面:

1.用户可干预客户端与服务器间传送的所有数据,包括请求参数、cookie和HTTP信息头。可轻易避开客户端执行的任何安全控件,如输入确认验证。

2.用户可按任何顺序发送请求,并可在应用程序要求之外的不同阶段不止一次提交或根本不提交参数。用户的操作可能与开发人员对用户和应用程序交互方式做出的任何假设完全不同

3.用户并不限于仅使用一种Web浏览器访问应用程序。大量各种各样的工具可以协助攻击Web应用程序,这些工具即可整合在浏览器中,也可独立于浏览器运作。这些工具能够提出普通浏览器无法提交的请求,并能够迅速生成大量的请求,查找和利用安全问题达到自己的目的。

关键问题因素:

1.不成熟的安全意识

2.独立开发

3.欺骗性的简化

4.迅速发展的威胁形式

5.资源与时间限制

6.技术上强其所难

7.对功能的需求不断增强

Penetration Test All Stages

一、前期交互阶段

渗透测试的范围:这一部分需要确定渗透测试的范围并预估整个项目的工作量。

关于渗透范围的常规文档应该包含了如下问题的答案

1.目标组织最大的安全问题是什么

2.应该对哪些主机、网络地址范围或者应用程序进行测试?

3.在测试时,应该将哪些主机、网络地址范围或者应用程序排除在测试范围之外?

4.在测试范围内是否存在第三方系统或者网络?它们拥有了哪些系统(在渗透前是否需要获得目标组织的书面许可)

5.渗透测试是在现场实地环境中进行还是在虚拟测试环境中进行

6.渗透测试是否包括以下测试技术:使用ping对网络范围进行扫描、对目标主机进行端口扫描、对目标进行漏洞扫描、对目标进行渗透测试、应用程序级的操作、客户端Java/ActiveX逆向功能、物理渗透尝试、社会工程学。

7.渗透测试是否包括内部网络测试?如果包括的话,如何获取权限?

8.客户端/终端用户系统是否包含在测试范围内?如果包含的话,将会涉及多少客户?

9.是否允许使用拒绝服务攻击

10.是否可以使用具有破坏性的检查手段和渗透模块

渗透测试的目标:这一部分要商定本次渗透测试预期达到的主要和次要结果。

有关渗透目标的常见问题列举如下:

1.这次渗透测试的商业需求是什么

-出于审计和目标化的目的

-积极出动的内部决策以确定所有弱点

2.目标是什么

-列出目标的各种漏洞

-证明各种漏洞的存在

-测试各种响应事件

-对网络、系统或者应用程序漏洞的渗透模块开发。

-以上全部

渗透测试用到的术语和定义:

需要向客户介绍整个测试过程中出现的专业术语和定义,以便客户能够更好地理解整个渗透测试工作。

渗透测试的规定:这一部分要商定完成渗透测试的工期,具体工作展开的进度表,渗透攻击的授权许可,以及定期召开会议以跟进渗透测试进程中出现各种情况。

有关约定常规的常见问题列举如下:

1.希望在什么时候执行这些测试

-在工作时间

-下班之后

-在周末

-在系统维护期间

2.这个测试是在生产环境下进行的吗

3.如果生产环境不能瘦到影响,是否存在类似的环境(开发或者测试系统)可以用来进行渗透测试?

4.谁是技术要点的联系人

继续阅读“Penetration Test All Stages”

TensorFlow_Feature_Crosses