首页金莎娱乐官网最全网站 › 卡巴斯基2017年企业信息系统的安全评估报告,如何能够保护用户凭证和会话ID等会话管理资产呢

卡巴斯基2017年企业信息系统的安全评估报告,如何能够保护用户凭证和会话ID等会话管理资产呢

虽然“对管理接口的网络访问不受限制”不是一个漏洞,而是一个配置上的失误,但在2017年的渗透测试中它被一半的攻击向量所利用。57%的目标企业可以通过管理接口获取对信息资源的访问权限。

接下来的问题是,你怎么检测哈希传递攻击?

- 1. 设置httponly属性.

httponly是微软对cookie做的扩展,该值指定 Cookie 是否可通过客户端脚本访问,
解决用户的cookie可能被盗用的问题,减少跨站脚本攻击,主流的大多数浏览器已经支持此属性。

  • asp.net全局设置:

//global中设置有所的cookie只读
protected void Application_EndRequest(Object sender, EventArgs e)
        {
            foreach(string sCookie in Response.Cookies)
            {
                Response.Cookies[sCookie].HttpOnly = true;
                Response.Cookies[sCookie].Secure = true;
            }

        }
  • JAVA

httpOnly是cookie的扩展属性,并不包含在servlet2.x的规范里,因此一些javaee应用服务器并不支持httpOnly,针对tomcat,>6.0.19或者>5.5.28的版本才支持httpOnly属性,具体方法是在conf/context.xml添加httpOnly属性设置

<Context useHttpOnly="true"> ... </Context>

另一种设置httpOnly的方式是使用Tomcat的servlet扩展直接写header

response.setHeader( "Set-Cookie", "name=value; HttpOnly");

详情请参考这里

使用单独的数据访问程序集

如果您可以进行选择,请避免将数据访问逻辑直接放在 ASP.NET
页或代码隐藏文件中。如果将数据访问逻辑放在一个单独的程序集中,并实现一个与应用程序的业务和表示逻辑分开的逻辑数据访问层,就会带来安全性、重复使用和维护好处。

从安全的角度看,您可以:

对程序集使用强名称以提供可防篡改功能。

使用沙盒技术来隔离数据访问代码,如果您的代码需要支持部分信任调用方(例如,部分信任 Web 应用程序),这一点十分重要。

使用那些按照代码标识权限需求向调用代码授权的数据访问方法和类。

对于深层防御,请按照业务组件中的主体权限需求来执行基于主体的授权,并按照代码标识权限需求来为调用数据访问逻辑的代码授权,如图
14.2 所示。

图片 1

图 14.2
表示层、业务层和数据访问层的分离

有关数据访问代码授权的详细信息,请参阅本模块后面的授权部分。

图片 2返回页首

2017年我们的Web应用安全评估表明,政府机构的Web应用最容易受到攻击(所有Web应用都包含高风险的漏洞),而电子商务企业的Web应用最不容易受到攻击(28%的Web应用包含高风险漏洞)。Web应用中最常出现以下类型的漏洞:敏感数据暴露(24%)、跨站脚本(24%)、未经验证的重定向和转发(14%)、对密码猜测攻击的保护不足(14%)和使用字典中的凭据(13%)。

“拒绝从网络访问此计算机”

失效的身份认证和会话管理

与身份认证和回话管理相关的应用程序功能往往得不到正确的实现,这就导致了攻击者破坏密码、密钥、会话令牌或攻击其他的漏洞去冒充其他用户的身份(暂时或永久的)。

图片 3

失效的身份认证和会话管理

“本地系统”帐户

确保连接字符串的安全

如果您需要使用 SQL
身份验证,连接字符串中将包含用户名和密码。如果攻击者利用 Web
服务器上的源代码泄漏这一漏洞或设法登录到该服务器,则攻击者可以检索连接字符串。同样,能够合法登录到该服务器的任何用户都可以查看它们。使用加密机制确保连接字符串的安全。

*本文作者:vitaminsecurity,转载请注明来自 FreeBuf.COM返回搜狐,查看更多

补充:

本模块内容

数据访问是使用几个可用的 ADO.NET 数据提供程序之一从 ASP.NET Web
应用程序访问数据库的过程。

此数据库是应用程序级攻击的主要目标。应用程序级攻击用于利用数据访问代码中的漏洞并获取对数据库未授权的访问。如果所有其他攻击方法都已失效,应用程序的前门(即端口
8)将变成攻击者窃取、操纵和破坏数据的可选路径。

本模块说明如何构建安全的数据访问代码,以及如何避免常见的漏洞和缺陷。本模块提供了一系列对策和防御技术,您可以在自己的数据访问代码中使用它们来减少与数据访问有关的主要威胁。

图片 4返回页首

参考来源

登录类型:3

- 2. 验证成功后更换sessionID

在登录验证成功后,通过重置session,使之前的匿名sessionId失效,这样可以避免使用伪造的sessionId进行攻击。代码如下

protected void doPost(HttpServletRequest request, HttpServletResponse response) throwsServletException, IOException { 
    String username=request.getParameter("username"); 
    Stringpassword=request.getParameter("password");
    if("admin".equals(username) &&"pass".equals(password)){ //使之前的匿名session失效 
          request.getSession().invalidate(); 
          request.getSession().setAttribute("login", true);  
          response.sendRedirect("hello.jsp"); 
    }
    else{ 
          response.sendRedirect("login.jsp");
   } 
}

本指南是用于规划策略以在 Microsoft® Windows Server™ 2003 和 Windows® XP
操作系统中安全地运行服务的重要资源。它解决了设置为使用可能的最大权限运行的
Windows
服务的常见问题,攻击者可能会利用这些服务来获取对计算机或域,甚至整个目录林的完全和不受限制的访问权限。它介绍了几种方法来确定可使用较小权限运行的服务,并且说明了如何有系统地将这些权限降级。本指南可以帮助您评估当前的服务基础结构,并在规划以后的服务部署时帮助您做出一些重要决策。

使用 LIKE 子句

请注意,如果您使用 LIKE
子句,通配符仍需要转义符。下面的代码片断阐释了这种技术:

s = s.Replace("[", "[[]");
s = s.Replace("%", "[%]");
s = s.Replace("_", "[_]");

图片 5返回页首

图片 6

为了检测到这一点,我们首先需要确保我们有适当的组策略设置。我们需要将帐户登录设置为“成功”,因为我们需要用事件日志4624作为检测的方法。

攻击案例场景

  • 场景#1:机票预订应用程序支持URL重写,把会话ID放在URL里:
    http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii
    该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们,并不知道自己已经泄漏了自己的会话ID。当他的朋友们使用上面的链接时,他们将会使用他的会话和信用卡。
  • 场景#2:应用程序超时设置不当。用户使用公共计算机访问网站。离开时,该用户没有点击退出,而是直接关闭浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。盐
  • 场景#3:内部或外部攻击者进入系统的密码数据库。存储在数据库中的用户密码没有被哈希和加盐,
    所有用户的密码都被攻击者获得。

“网络服务”帐户是一种特殊的内置帐户,它具有较少的权限,与经过身份验证的用户帐户类似。如果攻击者利用单个服务或进程,这种受限的访问权限有助于保护计算机。以“网络服务”帐户运行的服务使用计算机帐户的凭据来访问网络资源,这与“本地系统”服务访问网络资源的方式相同。该帐户的实际名称是
NT AUTHORITY\NetworkService,并且它不包含管理员需要管理的密码。

使用受限制的 ACL 确保 UDL 文件的安全

如果您的应用程序结合使用外部通用数据链接 (UDL) 文件和面向 OLE DB 的
ADO.NET 托管数据提供程序,请使用 NTFS 权限来限制访问。使用以下受限制的
ACL:

管理员:完全控制
进程帐户:读取

注意 UDL 文件未进行加密。一个更安全的方法是,使用 DPAPI
加密连接字符串,并将其存储在受限制的注册表项中。

20%的漏洞是跨站脚本类型的漏洞。攻击者可以利用此漏洞获取用户的身份验证数据(cookie)、实施钓鱼攻击或分发恶意软件。

密钥长度:0 –
这是会话密钥长度。这是事件日志中最重要的检测特征之一。像RDP这样的东西,密钥长度的值是
128位。任何较低级别的会话都将是0,这是较低级别协议在没有会话密钥时的一个明显的特征,所在此特征可以在网络中更好的发现哈希传递攻击。

我存在会话劫持漏洞吗?

如何能够保护用户凭证和会话ID等会话管理资产呢?以下情况可能产生漏洞:
1.用户身份验证凭证没有使用哈希或加密保护。
2.认证凭证可猜测,或者能够通过薄弱的的帐户管理功能(例如账户创建、密码修改、密码恢复,
弱会话ID)重写。
3.会话ID暴露在URL里(例如, URL重写)。
4.会话ID容易受到会话固定(session fixation)的攻击。
5.会话ID没有超时限制,或者用户会话或身份验证令牌特别是单点登录令牌在用户注销时没有失效。
6.成功注册后,会话ID没有轮转。
7.密码、会话ID和其他认证凭据使用未加密连接传输。

“本地服务”帐户

SQL 注入

当应用程序使用输入内容来构造动态 SQL 语句以访问数据库时,会发生 SQL
注入攻击。如果代码使用存储过程,而这些存储过程作为包含未筛选的用户输入的字符串来传递,也会发生
SQL 注入攻击。SQL
注入可能导致攻击者能够使用应用程序登录在数据库中执行命令。如果应用程序使用特权过高的帐户连接到数据库,这种问题会变得很严重。

注意 传统的安全措施(如使用 SSL 和 IPSec)不能防止 SQL 注入攻击。

大多数被利用的漏洞都是2017年发现的:

下面我们要查看所有登录类型是3(网络登录)和ID为4624的事件日志。我们正在寻找密钥长度设置为0的NtLmSsP帐户(这可以由多个事件触发)。这些是哈希传递(WMI,SMB等)通常会使用到的较低级别的协议。另外,由于抓取到哈希的两个唯一的位置我们都能够访问到(通过本地哈希或通过域控制器),所以我们可以只对本地帐户进行过滤,来检测网络中通过本地帐户发起的传递哈希攻击行为。这意味着如果你的域名是GOAT,你可以用GOAT来过滤任何东西,然后提醒相应的人员。不过,筛选的结果应该去掉一些类似安全扫描器,管理员使用的PSEXEC等的记录。

如何防止?

1、区分公共区域和受限区域
  站点的公共区域允许任何用户进行匿名访问。受限区域只能接受特定用户的访问,而且用户必须通过站点的身份验证。考虑一个典型的零售网站。您可以匿名浏览产品分类。当您向购物车中添加物品时,应用程序将使用会话标识符验证您的身份。最后,当您下订单时,即可执行安全的交易。这需要您进行登录,以便通过SSL
验证交易。
  将站点分割为公共访问区域和受限访问区域,可以在该站点的不同区域使用不同的身份验证和授权规则,从而限制对
SSL 的使用。使用SSL
会导致性能下降,为了避免不必要的系统开销,在设计站点时,应该在要求验证访问的区域限制使用
SSL。
2、对最终用户帐户使用帐户锁定策略
  当最终用户帐户几次登录尝试失败后,可以禁用该帐户或将事件写入日志。如果使用
Windows 验证(如 NTLM
或Kerberos协议),操作系统可以自动配置并应用这些策略。如果使用表单验证,则这些策略是应用程序应该完成的任务,必须在设计阶段将这些策略合并到应用程序中。
  请注意,帐户锁定策略不能用于抵制服务攻击。例如,应该使用自定义帐户名替代已知的默认服务帐户(如IUSR_MACHINENAME),以防止获得
Internet 信息服务
(IIS)Web服务器名称的攻击者锁定这一重要帐户。
3、支持密码有效期
  密码不应固定不变,而应作为常规密码维护的一部分,通过设置密码有效期对密码进行更改。在应用程序设计阶段,应该考虑提供这种类型的功能。
4、能够禁用帐户
  如果在系统受到威胁时使凭证失效或禁用帐户,则可以避免遭受进一步的攻击。5、不要在用户存储中存储密码
  如果必须验证密码,则没有必要实际存储密码。相反,可以存储一个单向哈希值,然后使用用户所提供的密码重新计算哈希值。为减少对用户存储的词典攻击威胁,可以使用强密码,并将随机salt
值与该密码结合使用。
5、要求使用强密码
  不要使攻击者能轻松破解密码。有很多可用的密码编制指南,但通常的做法是要求输入至少
8位字符,其中要包含大写字母、小写字母、数字和特殊字符。无论是使用平台实施密码验证还是开发自己的验证策略,此步骤在对付粗暴攻击时都是必需的。在粗暴攻击中,攻击者试图通过系统的试错法来破解密码。使用常规表达式协助强密码验证。
6、不要在网络上以纯文本形式发送密码
  以纯文本形式在网络上发送的密码容易被窃听。为了解决这一问题,应确保通信通道的安全,例如,使用
SSL 对数据流加密。
7、保护身份验证 Cookie
  身份验证
cookie被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护验证票证。另外,还应限制验证票证的有效期,以防止因重复攻击导致的欺骗威胁。在重复攻击中,攻击者可以捕获cookie,并使用它来非法访问您的站点。减少
cookie 超时时间虽然不能阻止重复攻击,但确实能限制攻击者利用窃取的
cookie来访问站点的时间。
8、使用 SSL 保护会话身份验证 Cookie
  不要通过 HTTP 连接传递身份验证 cookie。在授权 cookie 内设置安全的
cookie 属性,以便指示浏览器只通过HTTPS
连接向服务器传回
cookie。
9、对身份验证 cookie 的内容进行加密
  即使使用 SSL,也要对 cookie 内容进行加密。如果攻击者试图利用 XSS
攻击窃取cookie,这种方法可以防止攻击者查看和修改该
cookie。在这种情况下,攻击者仍然可以使用 cookie
访问应用程序,但只有当cookie 有效时,才能访问成功。
10、限制会话寿命
  缩短会话寿命可以降低会话劫持和重复攻击的风险。会话寿命越短,攻击者捕获会话
cookie并利用它访问应用程序的时间越有限。
11、避免未经授权访问会话状态
  考虑会话状态的存储方式。为获得最佳性能,可以将会话状态存储在 Web
应用程序的进程地址空间。然而这种方法在
Web场方案中的可伸缩性和内涵都很有限,来自同一用户的请求不能保证由同一台服务器处理。在这种情况下,需要在专用状态服务器上进行进程外状态存储,或者在共享数据库中进行永久性状态存储。ASP.NET支持所有这三种存储方式。
  对于从 Web 应用程序到状态存储之间的网络连接,应使用 IPSec 或 SSL
确保其安全,以降低被窃听的危险。另外,还需考虑Web
应用程序如何通过状态存储的身份验证。
  在可能的地方使用
Windows验证,以避免通过网络传递纯文本身份验证凭据,并可利用安全的
Windows帐户策略带来的好处。

下面三个常用的帐号,以及他们所拥有的权限,请仔细阅读

使用筛选例程

用来防止 SQL 注入攻击的另一种方法是开发筛选例程,以便向具有特殊 SQL
含义的字符添加转义符,如单撇号字符。下面的代码片断阐释了一个用来添加转义符的筛选例程:

private string SafeSqlLiteral(string inputSQL)
{
return inputSQL.Replace("'", "''");
}

这种例程存在着一定的问题,而且您不应完全依赖它们,因为攻击者可以使用
ASCII
十六进制字符来回避检查。但是应该筛选输入内容,并将其作为深层防御策略的一部分。

注意 不要依赖筛选输入。

改进Web应用安全性的建议

我不会在本文深入剖析哈希传递的历史和工作原理,但如果你有兴趣,你可以阅读SANS发布的这篇优秀的文章——哈希攻击缓解措施。

“本地服务”帐户是一种特殊的内置帐户,它具有较少的权限,与经过身份验证的本地用户帐户类似。如果攻击者利用单个服务或进程,这种受限的访问权限有助于保护计算机。以“本地服务”帐户运行的服务作为空会话来访问网络资源;即,它使用匿名凭据。该帐户的实际名称是
NT AUTHORITY\LocalService,并且它不包含管理员需要管理的密码。

配置管理

数据库连接字符串是针对数据访问代码主要考虑的配置管理问题。应认真考虑这些字符串的存储位置以及如何保护它们(特别是当它们包括凭据时)。要提高加密管理安全性:

使用 Windows 身份验证。

确保连接字符串的安全。

使用受限制的 ACL 确保 UDL 文件的安全。

第二步

接下来,我们看到登录过程是NtLmSsp,密钥长度为0.这些对于检测哈希传递非常的重要。

Microsoft 已测试了 Windows Server 2003 和 Windows XP
操作系统提供的服务使用其默认登录帐户运行的情况,以确保它们以可能的最低权限级别运行并且具有足够高的安全性。不需要修改这些服务。本指南的重点是确保并非由操作系统提供的服务的安全性,如作为其他
Microsoft 服务器产品的组件而提供的服务:例如,Microsoft SQL Server™ 或
Microsoft Operations Manager
(MOM)。随第三方软件应用程序和内部开发的业务线应用程序一起安装的服务可能需要额外的安全增强功能。

使用最小特权帐户

您的应用程序应该使用在数据库中具有有限权限的最小特权帐户。请确保对应用程序的数据库登录进行了适当的授权和限制。有关详细信息,请参阅本模块后面的授权。

使用最小特权帐户可以降低风险,并在您的帐户发生泄漏或者注入了恶意代码时限制潜在的损害。对于
SQL
注入,该命令将在由应用程序登录定义的安全上下文中执行,并遵守该登录在数据库中拥有的相关权限。如果您使用特权过高的帐户(例如,作为
SQL Server sysadmin
角色的成员)进行连接,攻击者能够在服务器上的任何数据库中执行任意操作。这包括插入、更新和删除数据;删除表;执行操作系统命令。

要点 不要使用 sa 帐户或者 SQL Server sysadmin
db_owner 角色的任何成员帐户连接到 SQL Server。

安全级别为高对应于在客户的网络边界只能发现无关紧要的漏洞(不会对公司带来风险)的情况。

主机名
:(注意,这不是100%有效;例如,Metasploit和其他类似的工具将随机生成主机名)。你可以导入所有的计算机列表,如果没有标记的计算机,那么这有助于减少误报。但请注意,这不是减少误报的可靠方法。并不是所有的工具都会这样做,并且使用主机名进行检测的能力是有限的。

“本地系统”帐户是预定义的本地帐户,它可以启动服务并为该服务提供安全上下文。这是一个功能强大的帐户,它具有计算机的完全访问权限,在用于域控制器上运行的服务时,它还包含对目录服务的访问权限。该帐户用作网络上的主机帐户,因此,就像任何其他域帐户一样可以访问网络资源。在网络上,该帐户显示为
DOMAIN\<计算机名>$。如果某个服务使用域控制器上的“本地系统”帐户进行登录,则它具有该域控制器本身的“本地系统”访问权限,如果域控制器受到攻击,则可能会允许恶意用户随意更改域中的内容。默认情况下,Windows
Server 2003 将一些服务配置为作为“本地系统”帐户登录。该帐户的实际名称是
NT AUTHORITY\System,并且它不包含管理员需要管理的密码。

不要将 Persist Security Info 设置为“True”或“Yes”

如果在连接字符串中包括 Persist Security Info 属性,将导致
ConnectionString
属性在密码返回给用户之前,将密码从连接字符串中去除。在建立与数据库的连接之后,默认设置
false(等同于忽略 Persist Security Info 属性)会丢弃该信息。

我们将企业的安全等级划分为以下评级:

哈希传递对于大多数企业或组织来说仍然是一个非常棘手的问题,这种攻击手法经常被渗透测试人员和攻击者们使用。当谈及检测哈希传递攻击时,我首先开始研究的是先看看是否已经有其他人公布了一些通过网络来进行检测的可靠方法。我拜读了一些优秀的文章,但我没有发现可靠的方法,或者是这些方法产生了大量的误报。

本指南的主要目标是,帮助管理员减少主机操作系统上被操纵的服务造成的影响。本指南以
Microsoft 安全卓越中心 (SCoE) 在客户环境中获得的经验为基础,代表了
Microsoft 最佳做法。

目标

使用本模块可以实现:

设计、构建和部署安全的数据访问代码。

使用代码访问安全性和基于角色的安全性可以限制未经授权的调用方或代码的访问。

安全地验证用户的身份。

防止 SQL 注入攻击。

确保数据库连接字符串的安全。

使用加密机制来保护存储在数据库中的数据。

确保通过网络发送到数据库以及从数据库发送的数据的安全。

使用带有salt 的哈希值将密码安全地存储在数据库中。

实现安全的异常处理。

了解如何使用代码访问安全性,允许中等信任 Web 应用程序使用 OLE DB、Oracle 和 ODBC 数据提供程序(这些提供程序需要完全信任)。

了解应使用哪些对策来解决常见的数据访问威胁,包括 SQL 注入、配置数据泄露、敏感的应用程序数据泄露、数据库架构和连接详细信息的泄露、未授权的访问和网络窃听。

图片 7返回页首

第五步

图片 8

“网络服务”帐户

设计注意事项

在开始编写代码之前,需要在设计时考虑许多重要的问题。主要的注意事项包括:

使用 Windows 身份验证。

使用最小特权帐户。

使用存储过程。

保护所存储的敏感数据。

使用单独的数据访问程序集。

最常见漏洞的Web应用比例

另外一个好处是这个事件日志包含了认证的源IP地址,所以你可以快速的识别网络中哈希传递的攻击来源。

敏感应用程序数据的泄漏

许多应用程序都存储敏感的数据(如客户的信用卡号),一定要保护此类数据的私密性和完整性。

漏洞

下列编码做法可能会导致泄漏敏感的应用程序数据:

存储没有加密的数据

弱授权

弱加密

对策

要防止泄漏敏感的应用程序数据:

使用强加密机制来确保数据的安全。

在执行数据访问之前先为每个调用方授权,以便用户只能看到其各自的数据。

根据测试期间获得的访问级别来划分目标企业

最后,我们看到这是一个基于帐户域和名称的本地帐户。

使用参数批处理

通常会产生如下误解:如果将几个 SQL
语句连接在一起,以便在单个往返中向服务器发送一批语句,则不能使用参数。但是,如果您能确保参数名不重复,则可以使用这种技术。通过在
SQL
文本连接过程中,向每个参数名中添加一个数字或其他某个唯一值,可以方便地执行此操作。

敏感数据暴露漏洞(根据OWASP分类标准),包括Web应用的源码暴露、配置文件暴露以及日志文件暴露等。

图片 9

数据库架构和连接详细信息的泄露

如果您的代码向客户端返回异常详细信息,恶意用户可能会使用这些信息来攻击服务器。数据访问代码中的异常可能会透露敏感信息,如数据库架构详细信息、数据存储的特性以及
SQL 代码片断。

漏洞

下列漏洞可能会导致信息泄漏:

不充分的异常处理

薄弱的 ASP.NET 配置(允许未经处理的异常详细信息返回到客户端)

对策

要防止这种泄漏:

捕获、记录和处理数据访问代码中的数据访问异常。

向调用方返回一般的错误消息。这要求对 Web.config 或 Machine.config 配置文件中的 <customErrors> 元素进行适当的配置。

获取域管理员权限的示例

通过对成千上万个系统上的日志进行广泛的测试和分析,我们已经能够识别出在大多数企业或组织中的非常具体的攻击行为并且具有非常低的误报率。有许多规则可以添加到以下检测功能中,例如,在整个网络中查看一些成功的结果会显示“哈希传递”,或者在多次失败的尝试后将显示凭证失败。

结合使用 Parameters 集合和存储过程

下面的代码片断阐释了 Parameters 集合的用法:

SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
"@au_id", SqlDbType.VarChar, 11);
parm.Value = Login.Text;

在本例中,@au_id
参数被视为文本值,而非可执行代码。另外,还针对参数进行了类型和长度检查。在上例中,输入值不能长于
11 个字符。如果数据不遵循由参数定义的类型或长度,就会生成异常。

请注意,使用存储过程不一定会防止 SQL
注入。重要的是结合使用参数和存储过程。如果不使用参数,则在存储过程使用未筛选的输入内容时,它们很容易受到
SQL 注入攻击。例如,下面的代码片断很容易受到攻击:

SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure '" +
Login.Text + "'", conn);

要点 如果使用存储过程,请确保同时使用参数。

检测建议:

哈希传递仍然广泛的用于网络攻击并且是大多数企业和组织的一个共同的安全问题。有许多方法可以禁止和降低哈希传递的危害,但是并不是所有的企业和组织都可以有效地实现这一点。所以,最好的选择就是如何去检测这种攻击行为。

构建安全的数据访问

更新日期: 2004年04月12日

过时软件中的已知漏洞占我们实施的攻击向量的三分之一。

请注意,你可以(也可能应该)将域的日志也进行分析,但你很可能需要根据你的实际情况调整到符合基础结构的正常行为。比如,OWA的密钥长度为0,并且具有与基于其代理验证的哈希传递完全相同的特征。这是OWA的正常行为,显然不是哈希传递攻击行为。如果你只是在本地帐户进行过滤,那么这类记录不会被标记。

配置数据泄露

数据访问代码所使用的最敏感的配置数据是数据库连接字符串。如果泄漏的连接字符串包括用户名和密码,后果将不堪设想。

漏洞

下列漏洞会增加与泄漏的配置数据相关的安全风险:

使用 SQL 身份验证,这要求在连接字符串中指定凭据

代码中嵌入的连接字符串

配置文件中的明文连接字符串

无法加密连接字符串

对策

要防止配置数据的泄漏:

使用 Windows 身份验证,以便连接字符串中不包含凭据。

加密连接字符串,并限制对已加密数据的访问。

建议:

图片 10

使用存储过程

存储过程提供性能、维护和安全性好处。应尽可能使用参数化存储过程进行数据访问。安全性好处包括:

可以限制应用程序数据库登录,以便它只具有执行指定存储过程的权限。没有必要授予直接的表格访问权限。这有助于降低由 SQL 注入攻击造成的风险。

针对传递到存储过程的所有输入数据执行长度和类型检查。同样,不能将参数视为可执行代码。这也会降低 SQL 注入风险。

如果由于某种原因,您无法使用参数化存储过程,但是您需要动态构造 SQL
语句,请使用类型化参数和参数占位符来构造这样的语句,以确保检查输入数据的长度和类型。

获取对网络设备的访问权限有助于内网攻击的成功。网络设备中的以下漏洞常被利用:

【编辑推荐】

保护所存储的敏感数据

标识需要保证私密性和完整性的存储数据。如果您只是为了验证而将密码存储到数据库中,请考虑使用单向哈希。如果密码表发生泄漏,则不能使用哈希来获取明文密码。

如果您存储用户提供的敏感数据(如信用卡号),请使用强对称加密算法(如三重
DES (3DES))来加密数据。使用 Win32 数据保护 API (DPAPI) 加密 3DES
密钥,然后将已加密的密钥存储在具有受限 ACL
的注册表项中,只有管理员和应用程序进程帐户才能使用该注册表项。

漏洞的概括和统计信息是根据我们提供的每种服务分别总结的:

设置路径位于:

威胁与对策

要构建安全的数据访问代码,需要了解数据访问代码中的威胁是什么、常见漏洞是如何产生的以及如何使用适当的对策来降低风险。

数据访问代码面临的主要威胁包括:

SQL 注入

配置数据的泄漏

敏感应用程序数据的泄漏

数据库架构和连接详细信息的泄露

未授权的访问

网络窃听

图 14.1 阐明了这些主要威胁。

图片 11

图 14.1
数据访问代码面临的威胁和攻击

最常见漏洞和安全缺陷的统计信息

Computer ConfigurationWindowsSettingsSecurity SettingsLocal PoliciesUser Rights Assignment 

安全地存储加密的连接字符串

加密的连接字符串可以放在注册表中,也可以放在 Web.config 或
Machine.config 文件中。如果您使用 HKEY_LOCAL_MACHINE
下的注册表项,请将下面的 ACL 应用于该项:

管理员:完全控制
进程帐户:读取

注意 该进程帐户由运行数据访问程序集的进程来确定。这通常是 ASP.NET
进程,或者当您的解决方案使用企业服务中间层时,该进程是企业服务服务器进程。

还可以考虑使用
HKEY_CURRENT_USER,该注册表项提供受限制的访问。有关详细信息,请参阅模块
7 构建安全的程序集中的“注册表”部分。

注意 如果您使用 Microsoft Visual Studio® .NET
数据库连接向导,连接字符串将以明文属性值形式存储在 Web
应用程序代码隐藏文件或 Web.config 文件中。这两种方法都应该避免使用。

为了更容易部署,您可能希望将加密的字符串存储在 Web.config
中,尽管这可能不如使用受限制的注册表项安全。在本例中,将使用如下所示的自定义
<appSettings> 名称-值对:

<configuration>
<appSettings>
<add key="connectionString" value="AQA..bIE=" />
</appSettings>
<system.web>
...
</system.web>
</configuration>

要从 <appSettings> 元素访问密码文本,请使用如下所示的
ConfigurationSettings 类:

using System.Configuration;
private static string GetConnectionString()
{
return ConfigurationSettings.AppSettings["connectionString"];
}

本文的主要目的是为现代企业信息系统的漏洞和攻击向量领域的IT安全专家提供信息支持。

哈希传递的主要成因是由于大多数企业或组织在一个系统上拥有共享本地帐户,因此我们可以从该系统中提取哈希并移动到网络上的其他系统。当然,现在已经有了针对这种攻击方式的缓解措施,但他们不是100%的可靠。例如,微软修补程序和较新版本的Windows(8.1和更高版本)“修复”了哈希传递,但这仅适用于“其他”帐户,而不适用于RID为
500(管理员)的帐户。

网络窃听

大多数应用程序的部署体系结构中都包括数据访问代码与数据库服务器之间的物理隔离。因此,必须防止窃听者通过网络窃听敏感数据(如应用程序特定的数据或数据库登录凭据)。

漏洞

下列做法会增加网络窃听的漏洞:

在 SQL 身份验证过程中通过网络传递的明文凭据

进出数据库服务器的未加密敏感应用程序数据

对策

要限制网络窃听的漏洞:

使用 Windows 身份验证来避免通过网络发送凭据。

在数据库服务器上安装一个服务器证书。这会导致自动加密网络上的 SQL 凭据。

在 Web 服务器和数据库服务器之间使用 SSL 连接来保护敏感的应用程序数据。这需要一个数据库服务器证书。

在 Web 和数据库服务器之间使用 IPSec 加密通道。

图片 12返回页首

使用域帐户执行Kerberoasting攻击。获得SPN帐户的TGS票证

接下来,工作站名称肯定看起来很可疑;
但这并不是一个好的检测特征,因为并不是所有的工具都会将机器名随机化。你可以将此用作分析哈希传递攻击的额外指标,但我们不建议使用工作站名称作为检测指标。源网络IP地址可以用来跟踪是哪个IP执行了哈希传递攻击,可以用于进一步的攻击溯源调查。

SQL 注入

SQL
注入攻击利用易受攻击的数据访问代码,并允许攻击者在数据库中执行任意命令。如果应用程序使用数据库中不受限制的帐户,由于攻击者可以更自由地执行查询和命令,因此受到的威胁会更大。

漏洞

使数据访问代码容易受到 SQL 注入攻击的常见漏洞包括:

弱输入验证

在不使用类型安全的参数时动态构造 SQL 语句

使用特权过高的数据库登录

对策

要应对 SQL 注入攻击,请务必:

限制和净化输入数据。

使用类型安全的 SQL 参数进行数据访问。这些参数可以与存储过程一起使用,也可以是动态构造的 SQL 命令字符串。参数执行类型和长度检查,并同时确保注入数据库中的代码被视为文本数据(而非可执行语句)。

使用在数据库中具有有限权限的帐户。理想情况下,只应向数据库中的选定存储过程授予执行权限,且不提供直接的表格访问权限。

从Windows
SAM存储中提取的本地帐户NTLM哈希值可用于离线密码猜测攻击或哈希传递攻击。

检测哈希传递攻击是比较有挑战性的事情,因为它在网络中表现出的行为是正常。比如:当你关闭了RDP会话并且会话还没有关闭时会发生什么?当你去重新认证时,你之前的机器记录仍然还在。这种行为表现出了与在网络中传递哈希非常类似的行为。

使用 Windows 身份验证

Windows 身份验证不通过网络发送凭据。如果对 Web 应用程序使用 Windows
身份验证,请尽可能使用服务帐户或进程帐户(如 ASPNET
帐户)连接到数据库。Windows 和 SQL Server
都必须能够识别您在数据库服务器上使用的帐户。该帐户必须被授予 SQL Server
登录权限,而且需要具有与访问数据库相关的登录权限。

在使用 Windows
身份验证时,必须使用受信任连接。下面的代码片断显示了几个使用 Windows
身份验证的典型的连接字符串。

下例使用面向 SQL Server 的 ADO.NET 数据提供程序:

SqlConnection pubsConn = new SqlConnection(
"server=dbserver; database=pubs; Integrated Security=SSPI;");

下例使用面向 OLE DB 数据源的 ADO.NET 数据提供程序:

OleDbConnection pubsConn = new OleDbConnection(
"Provider=SQLOLEDB; Data Source=dbserver; Integrated Security=SSPI;" +
"Initial Catalog=northwind");

应定期对所有的公开Web应用进行安全评估;应实施漏洞管理流程;在更改应用程序代码或Web服务器配置后,必须检查应用程序;必须及时更新第三方组件和库。

接下来我们看到登录类型是3(通过网络远程登录)。

适用范围

本模块适用于下列产品和技术:

Microsoft® Windows® 2000 Server 和 Microsoft Windows Server™ 2003

Microsoft .NET Framework 1.1 和 ASP.NET 1.1

Microsoft SQL Server™

图片 13返回页首

在利用管理接口获取访问权限时利用过时软件中的已知漏洞是最不常见的情况。

安全ID:空SID – 可选但不是必需的,目前还没有看到为Null的
SID未在哈希传递中使用。

加密连接字符串

使用 DPAPI 加密连接字符串。使用 DPAPI
加密时,由于加密密钥由平台进行管理,并且绑定到特定的计算机或 Windows
用户帐户,因此可避免出现加密密钥管理问题。要使用 DPAPI,必须通过
P/Invoke 调用 Win32 DPAPI 函数。

有关如何构建托管包装类的详细信息,请参阅“Microsoft patterns &
practices
Volume I, Building Secure ASP.NET Web Applications:
Authentication, Authorization, and Secure Communication”的“How
To”部分中的“How To: Create a DPAPI
Library”,其网址为:(英文)。

第七步

让我们分解日志并且模拟哈希传递攻击过程。在这种情况下,我们首先想象一下,攻击者通过网络钓鱼获取了受害者电脑的凭据,并将其提升为管理级别的权限。从系统中获取哈希值是非常简单的事情。假设内置的管理员帐户是在多个系统间共享的,攻击者希望通过哈希传递,从SystemA(已经被入侵)移动到SystemB(还没有被入侵但具有共享的管理员帐户)。

为什么不使用 DPAPI?

尽管建议使用 DPAPI
来加密连接字符串和其他可在计算机出现故障时手动恢复和重新构造的机密(如帐户凭据),但仍不太适合存储信用卡号之类的数据。这是由于可恢复性问题(如果密钥丢失,则无法恢复加密数据)和
Web 场问题。相反,应该使用对称加密算法(如 3DES)并使用 DPAPI 加密密钥。

下面概述了造成 DPAPI 不太适合在数据库中存储敏感数据的主要问题:

如果 DPAPI 与计算机密钥一起使用,而且您将 CRYPTPROTECT_LOCAL_MACHINE 传递到 CryptProtectDataCryptUnprotectData 函数,则计算机帐户会生成加密密钥。这意味着 Web 场中的每台服务器都有一个不同的密钥,这会禁止一台服务器访问由另一台服务器加密的数据。同样,如果该 Web 服务器计算机被破坏,则密钥会丢失,而且加密的数据无法从数据库进行恢复。

如果使用计算机密钥方法,则该计算机上的任何用户都可以对数据进行解密(除非您使用其他加密机制)。

如果您将 DPAPI 与用户密钥一起使用,而且您使用的是本地用户帐户,就会为每台 Web 服务器上的每个本地帐户生成一个不同的安全标识符 (SID) 和一个不同的密钥,这会禁止一台服务器访问由另一台服务器加密的数据。

如果您将 DPAPI 与用户密钥一起使用,而且您在 Web 场中的计算机之间使用漫游用户配置文件,则所有数据都将共享相同的加密/解密密钥。但是,如果负责漫游用户配置文件帐户的域控制器被损害或被破坏,则无法重新创建具有相同 SID 的用户帐户,而且不能从数据库中恢复加密的数据。

另外,对于漫游用户配置文件,如果某人设法检索该数据,则只要攻击者能够在特定的用户帐户下运行代码,就可以在网络中的任何计算机上解密该数据。这会增加潜在攻击的范围,因此不建议这样做。

第一步

在这个例子中,我们将使用Metasploit
psexec,尽管还有很多其他的方法和工具可以实现这个目标:

输入验证

除了业务层需要确保数据库保持数据的有效性和一致性之外,还必须在将数据提交到数据库之前验证数据,以防
SQL
注入。如果数据访问代码从当前信任边界内部的其他组件接收其输入内容,而且您知道数据已经过验证(例如,由
ASP.NET
网页或业务组件验证),则数据访问代码会忽略广泛的数据验证。但是,请确保在数据访问代码中使用
SQL 参数,这些参数验证输入参数的类型和长度。下一部分将讨论 SQL
参数的用法。

图片 14返回页首

用于穿透网络边界的攻击向量

图片 15

保护 SQL 身份验证的凭据

如果必须使用 SQL
身份验证,请确保凭据不以明文形式通过网络发送,并确保加密包含凭据的数据库连接字符串。

要使 SQL Server
能够自动加密通过网络发送的凭据,请在数据库服务器上安装服务器证书。也可以在
Web 服务器和数据库服务器之间使用 IPSec
加密通道,来确保进出数据库服务器的所有通信的安全。要确保连接字符串的安全,请使用
DPAPI。有关详细信息,请参阅本模块后面配置管理部分中的“确保连接字符串的安全”。

图片 16

大多数企业或组织都没有能力实施GPO策略,而传递哈希可被利用的可能性却非常大。

使用 Windows 身份验证

理想情况下,在设计中应该使用 Windows 身份验证,以增加安全性好处。使用
Windows
身份验证,您不必存储具有嵌入凭据的数据库连接字符串,凭据不通过网络传递,而且您可以受益于安全帐户和密码管理策略。但是,您需要认真考虑在使用
Windows 身份验证时,将使用哪个帐户连接到 SQL Server。

有关详细信息,请参阅本模块后面的身份验证。

第四步

在这个例子中,攻击者通过传递哈希建立了到第二个系统的连接。接下来,让我们看看事件日志4624,包含了什么内容:

结合使用 Parameters 集合和动态 SQL

如果您不能使用存储过程,仍可以使用参数,如下面的代码片断所示:

SqlDataAdapter myCommand = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);
SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",
SqlDbType.VarChar, 11);
parm.Value = Login.Text;

图片 17

你可以禁止通过GPO传递哈希:

限制输入

验证输入内容的类型、长度、格式和范围。如果您不希望获得数值,则不要接受它们。应该考虑输入内容来自何处。如果它来自受信任源,而且您知道已针对该来源执行过彻底的输入验证,则可以选择在数据访问代码中忽略数据验证。如果数据来自不受信任源或者用于深层防御,则数据访问方法和组件应该验证输入。

获取域管理员权限的最小步骤数

安全ID:NULL
SID可以作为一个特征,但不要依赖于此,因为并非所有的工具都会用到SID。虽然我还没有亲眼见过哈希传递不会用到NULL
SID,但这也是有可能的。

使用类型安全的 SQL 参数

SQL 中的 Parameters 集合提供类型检查和长度验证。如果您使用
Parameters 集合,则输入内容将被视为文本值,SQL
不会将其视为可执行代码。使用 Parameters
集合还有一个好处,那就是可以强制进行类型和长度检查。超出范围的值会触发异常。这是深层防御的一个有力示例。

要点 SSL 不能防止 SQL
注入。对于任何应用程序来说,如果它在没有正确的输入验证和适当的数据访问技术的情况下访问数据库,都很容易受到
SQL 注入攻击。

尽可能使用存储过程,并使用 Parameters 集合来调用它们。

在所有的目标企业中,都发现网络流量过滤措施不足的问题。管理接口(SSH、Telnet、SNMP以及Web应用的管理接口)和DBMS访问接口都可以通过用户段进行访问。在不同帐户中使用弱密码和密码重用使得密码猜测攻击变得更加容易。

图片 18

限制数据库中的应用程序

首选方法是为应用程序用来连接到数据库的 Windows 帐户创建一个 SQL Server
登录权限,然后将 SQL Server
登录映射到数据库中的某个数据库用户。将该数据库用户放在用户定义的数据库角色中,并授予该角色相应的权限。理想情况下,应该只为该角色授予对应用程序所使用的存储过程的执行访问权限。

有关如何配置此方法的详细信息,请参阅模块 19 确保 ASP.NET 应用程序和 Web
服务的安全中的“为 ASP.NET 应用程序配置数据访问权限”。

图片 19返回页首

图片 20

登录过程:NtLmSsP

防止 SQL 注入

使用下列对策来防止 SQL 注入攻击:

限制输入。

使用类型安全的 SQL 参数。

NTLM中继攻击

图片 21

身份验证

当应用程序连接到 SQL Server 数据库时,可以在 Windows 身份验证或 SQL
身份验证之间进行选择。Windows 身份验证更安全。如果必须使用 SQL
身份验证(可能由于必须使用许多不同的帐户连接到数据库,并且希望避免调用
LogonUser),请执行其他几个步骤,以尽可能降低额外的风险。

注意 如果使用 LogonUser 创建模拟令牌,需要在 Microsoft Windows
2000
上具有功能强大的“作为操作系统的一部分工作”特权,因此应避免使用此方法。

考虑下面的建议:

使用 Windows 身份验证。

保护 SQL 身份验证的凭据。

使用最小特权帐户进行连接。

安全建议:

帐户名称和域名:仅警告只有本地帐户(即不包括域用户名的账户)的帐户名称。这样可以减少网络中的误报,但是如果对所有这些账户进行警告,那么将检测例如:扫描仪,psexec等等这类东西,但是需要时间来调整这些东西。在所有帐户上标记并不一定是件坏事(跳过“COMPUTER$”帐户),调整已知模式的环境并调查未知的模式。

限制未授权的代码

通过使用 .NET Framework
代码访问安全性(特别是代码标识需求),可以限制能够访问数据访问类和方法的程序集。

例如,如果您只希望由公司或特定开发组织编写的代码能够使用您的数据访问组件,请使用
StrongNameIdentityPermission
,并要求调用程序集具有一个带有指定公钥的强名称,如下面的代码片断所示:

using System.Security.Permissions;
. . .
[StrongNameIdentityPermission(SecurityAction.LinkDemand,
PublicKey="002...4c6")]
public void GetCustomerInfo(int CustId)
{
}

要提取给定程序集的公钥的文本表示形式,请使用下面的命令:

sn -Tp assembly.dll

注意–Tp 开关中使用大写的“T”。

因为 Web
应用程序的程序集是动态编译的,所以对于这些程序集不能使用强名称。这使得很难将数据访问程序集的使用限制在特定的
Web
应用程序上。最佳方法是开发一个自定义权限,并要求该权限来自数据访问组件。完全信任
Web
应用程序(或任何完全受信任代码)可以调用您的组件。但是,部分信任代码只有在被授予了自定义权限之后,才能调用您的数据访问组件。

有关自定义权限的示例实现,请参阅本指南“如何”部分中的如何:创建自定义加密权限。

最常见的漏洞和安全缺陷

图片 22

使用 Window 身份验证

使用 Windows
身份验证时,系统会为您管理凭据,而且凭据不会通过网络传输。还可以避免将用户名和密码嵌入到连接字符串中。

超过一半的漏洞都是由Web应用源代码中的错误引起的。其中最常见的漏洞是跨站脚本漏洞(XSS)。44%的漏洞是由配置错误引起的。配置错误导致的最多的漏洞是敏感数据暴露漏洞。

事件ID:4624

限制未授权的调用方

您的代码在连接到数据库之前必须基于角色或标识为用户授权。角色检查通常用在应用程序的业务逻辑中,但是,如果您不能清楚地区分业务逻辑和数据访问逻辑,请对数据库访问方法使用主体权限需求。

以下属性确保只有作为 Manager 角色成员的用户才能调用
DisplayCustomerInfo 方法:

[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Manager")]
public void DisplayCustomerInfo(int CustId)
{
}

如果需要其他授权粒度,并且需要在数据访问方法内部执行基于角色的逻辑,请使用命令性主体权限需求或显式的角色检查,如下面的代码片断所示:

using System.Security;
using System.Security.Permissions;
public void DisplayCustomerInfo(int CustId)
{
try
{
// 用来验证调用方是 manager 的命令性主体权限
// 角色检查
PrincipalPermission principalPerm = new PrincipalPermission(
null, "Manager");
// 仅在调用方是“Manager”角色的成员时才执行
// 随后的代码
}
catch( SecurityException ex )
{
. . .
}
}

下面的代码片断使用显式的程序设计角色检查来确保调用方是 Manager
角色的成员:

public void DisplayCustomerInfo(int CustId)
{
if(!Thread.CurrentPrincipal.IsInRole("Manager"))
{
. . .
}
}

检测建议:

总而言之,有许多方法可以检测环境中的哈希传递攻击行为。这个在小型和大型网络中都是有效的,并且基于不同的哈希传递的攻击方式都是非常可靠的。它可能需要根据你的网络环境进行调整,但在减少误报和攻击过程中溯源却是非常简单的。

如何使用本模块

为了充分理解本模块内容,请先阅读下列模块或与本模块结合起来阅读:

阅读模块 2 威胁与对策。这将使您更广泛深入地了解 Web 应用程序所面临的潜在威胁及其对策。

阅读模块 4 Web 应用程序安全设计指南。在本模块中,您将了解构建安全解决方案时所面临的体系结构和设计挑战,以及构建准则。

阅读模块 18 保证数据库服务器的安全。阅读模块 18 可了解如何确保数据库服务器的安全。

阅读模块 7 构建安全的程序集。模块 7 中构建安全程序集和开发安全托管代码的准则和建议同样应该适用于数据访问代码

使用评估模块。要在产品周期的不同阶段检查数据访问的安全性,请参见下列模块中的“Web 服务”部分:模块 5 安全性体系结构和设计审查、模块 21 代码审查以及模块 22 部署审查。

使用检查表。本指南“检查表”部分中的检查表:保护数据访问包括一个便于参考的检查表。可以将此基于任务的检查表用作本模块中各个建议的摘要。

请注意,在当前版本的 .NET Framework (1.1) 中,只有 ADO.NET SQL Server
数据访问提供程序才支持部分信任调用方,并且可以安全地用在部分信任 Web
应用程序中。OLE DB、Oracle 和 ODBC ADO.NET 数据提供程序需要完全信任。

图片 23返回页首

使用字典中的凭据

总之,攻击者需要从系统中抓取哈希值,通常是通过有针对性的攻击(如鱼叉式钓鱼或通过其他方法直接入侵主机)来完成的(例如:TrustedSec
发布的 Responder
工具)。一旦获得了对远程系统的访问,攻击者将升级到系统级权限,并从那里尝试通过多种方法(注册表,进程注入,磁盘卷影复制等)提取哈希。对于哈希传递,攻击者通常是针对系统上的LM/NTLM哈希(更常见的是NTLM)来操作的。我们不能使用类似NetNTLMv2(通过响应者或其他方法)或缓存的证书来传递哈希。我们需要纯粹的和未经过滤的NTLM哈希。基本上只有两个地方才可以获得这些凭据;第一个是通过本地帐户(例如管理员RID
500帐户或其他本地帐户),第二个是域控制器。

使用最小特权帐户进行连接

应用程序应该通过使用最小特权帐户连接到数据库。如果您使用 Windows
身份验证进行连接,则从操作系统的角度看,Windows
帐户应该是最小特权帐户,而且该帐户应该具有有限的特权和对 Windows
资源的有限的访问能力。另外,无论您使用 Windows 身份验证还是 SQL
身份验证,相应的 SQL Server 登录都应该受到数据库中的权限的限制。

有关如何创建最小特权数据库帐户以及使用 Windows 身份验证将 ASP.NET Web
应用程序连接到远程数据库的选项的详细信息,请参阅模块 19 确保 ASP.NET
应用程序和 Web 服务的安全中的“数据访问”。

图片 24返回页首

除了进行更新管理外,还要更加注重配置网络过滤规则、实施密码保护措施以及修复Web应用中的漏洞。

授权

如果用户能够检索和操纵特定的数据,就会建立授权过程。有两种方法:数据访问代码可以使用授权来确定是否执行请求的操作,数据库可以通过执行授权来限制应用程序所使用的
SQL 登录的功能。

在授权不足的情况下,用户也许能够看到另一个用户的数据,未授权的用户也许能够访问受限制的数据。要去除这些威胁:

限制未授权的调用方。

限制未授权的代码。

限制数据库中的应用程序。

图 14.3 概述了应该使用的授权点和技术。

图片 25

图 14.3
数据访问授权、程序集和数据库

注意数据访问代码如何按照权限需求为调用用户或调用代码授权。代码标识需求是
.NET 代码访问安全性的一个特性。

要为数据库中的应用程序授权,请使用只具有执行选定存储过程权限的最小特权
SQL
服务器登录。除非有特殊理由,否则不应为应用程序授予如下权限:直接针对任何表执行创建、检索、更新、破坏/删除
(CRUD) 操作。

注意
存储过程在数据库系统的安全上下文中运行。尽管您可以通过为应用程序分配对特定存储过程的权限来限制它的逻辑操作,但不能限制存储过程所执行的操作的结果。存储过程是受信任代码。必须使用数据库权限来确保存储过程的接口安全。

利用 Web应用中的漏洞发起的攻击

本页内容
本模块内容
目标
适用范围
如何使用本模块
威胁与对策
设计注意事项
输入验证
SQL 注入
身份验证
授权
配置管理
敏感数据
异常管理
构建安全的数据访问组件
代码访问安全性注意事项
部署注意事项
小结
其他资源

实施内网攻击常用的两种攻击技术包括NBNS欺骗和NTLM中继攻击以及利用2017年发现的漏洞的攻击,例如MS17-010
(Windows SMB)、CVE-2017-7494 (Samba)和CVE-2017-5638
(VMwarevCenter)。在永恒之蓝漏洞公布后,该漏洞(MS17-010)可在75%的目标企业的内网主机中检测到(MS17-010被广泛用于有针对性的攻击以及自动传播的恶意软件,如WannaCry和NotPetya/ExPetr等)。在86%的目标企业的网络边界以及80%的企业的内网中检测到过时的软件。

未授权的访问

在授权不足的情况下,用户也许能够看到另一个用户的数据,并且能够访问其他受限制的数据。

漏洞

下列做法可能会允许未授权的访问:

数据访问代码中缺乏授权,从而提供了不受限制的访问

数据库帐户的特权过高

对策

要防止未授权的访问:

按照主体权限需求为调用用户授权。

按照代码访问安全权限需求为调用代码授权。

使用受限制的权限来限制应用程序登录到数据库,并防止直接访问表格。

检测建议:

服务器端和客户端漏洞的比例

本节提供了漏洞的总体统计信息。应该注意的是,在某些Web应用中发现了相同类型的多个漏洞。

图片 26

Web应用安全评估

第七步

原标题:卡巴斯基2017年企业信息系统的安全评估报告

图片 27

建议禁用NBNS和LLMNR协议

攻击者通过NBNS欺骗攻击和NTLM中继攻击拦截管理员的NetNTLM哈希,并利用该哈希在域控制器上进行身份验证;

利用HP Data
Protector中的漏洞CVE-2011-0923,然后从lsass.exe进程的内存中提取域管理员的密码

转载本站文章请注明出处:金莎娱乐官网最全网站 http://www.djliuxue.com/?p=1085

上一篇:

下一篇:

相关文章