可利用的 C # 函数

这个问题类似于 可利用的 PHP 函数。

受污染的数据来自用户，或者更具体地说来自攻击者。当受污染的变量到达接收器函数时，您就有了一个漏洞。例如，执行 sql 查询的函数是一个接收器，GET/POST 变量是污染源。

C # 中所有的接收器函数是什么？我正在寻找的功能，引入一个漏洞或 软件缺陷。我对远程代码执行漏洞特别感兴趣。是否存在黑客想要影响的包含令人讨厌的功能的整个类/库？人们是如何意外地编写危险的 C # 代码的？

18324 次浏览
小开

首先想到的是 Process.Start 。

我确信 WindowsIdentity和大部分 System.Security也可以用来作恶。

当然，也有 SQL 注入攻击，但我不认为这是您的意思(尽管可以通过 SQLServer 进行远程执行)。

小开

我看到过用户可以设置数据库中函数调用的名称和参数的代码。然后系统将通过反射执行命名函数，而不需要检查任何东西..。

小开

使用任何类型的不安全代码都可能导致指针等问题。Microsoft 在这里提供了一篇关于不安全代码的好文章: http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

小开

IMO: nr 1可利用的功能，看起来很无害，但是不经思考使用时非常危险。

在 ASP.Net Response.Write或快捷方式:

  <%= searchTermFromUser %>

在 ADO.Net:

  • string +操作员:
    var sql = "SELECT * FROM table WHERE name = '" + searchTermFromUser + "'"
小开

除了前面提到的显而易见的 Process.Start()之外，我还可以看到一些潜在的间接利用方式。

  • WinAPI 通过 PInvoke 调用 CreateProcess()等等。
  • 使用 Assembly.Load()和其他类似的重载的任何类型的动态装配加载机制。如果受损的程序集到达系统并加载。
  • 如果运行在完全信任的一般。
  • 如果具有正确的权限，任何注册表操作都可能使您处于危险之中。

我现在只想到这个。

小开

系统里有很多东西。Net、 System.XML、 System.IO (任何采用 URI 和/或文件路径并实际处理它们标识的资源的东西)。反射，系统。安全系统。网络，系统。资料及系统。线程命名空间可能是危险的，因为它们可能被用来做坏事，而不仅仅是扰乱当前的执行。太多了，以至于我们需要花费大量的时间去识别每一个。

当然，除非另有说明，否则所有第三方程序集中的每个方法都必须假定是危险的。又浪费时间了。

我也不认为这是一个特别有成效的方法。生成一个函数检查表只能在有限的库中工作，或者在使用 C # 这样的语言的库中的大量内容都在语言本身中的大型语言中工作。

有一些经典的危险例子，比如 Process.Start()或者任何直接执行另一个进程的东西，但是它们都是非常明显的危险。即使是一个相对鲁莽和不称职的程序员在使用这种方法时也会小心谨慎，而不会对转向其他方法的数据进行过滤。

与任何函数列表相比，数据卫生是一个更有成效的事情。数据是否经过验证可以删除明显不正确的输入(这可能是由于攻击，或者可能只是一个错误) ，是否以给定层的适当方式进行编码和转义(有太多关于“危险”字符序列的讨论，'从来没有伤害任何人，它的 '没有正确转义为 SQL，这可能会伤害当它确实在 SQL 层——确保数据正确地进入那里所需的工作是相同的，以避免利用)。与代码之外的东西进行通信的层是否牢固。URI 是否使用未经检查的输入构造，例如-如果不是，您可以转动一些更常用的 System。Net 和 System.XML 方法的漏洞。

小开

反射、发射和代码域

编辑 :

允许使用线程的插件或第三方库可能会导致整个应用程序崩溃，除非您将这些库/插件加载到单独的应用程序域中。

小开

您从用户(或任何其他外部来源)获得并传递给另一个系统或另一个用户的任何数据片段都是一个潜在的漏洞。

如果您从用户那里获得一个字符串，并在不使用 HtmlEncode 的情况下将其显示给另一个用户，那么这是一个潜在的漏洞。

如果您从用户那里获得一个字符串并使用它来构造 SQL，这是一个潜在的 SQL 注入。

如果您从用户那里获得一个字符串，并使用它为 Process 约定一个文件名。启动或组装。加载它是一个远程执行漏洞

你明白了，危险来自于使用未经过消毒的数据，如果你从来没有将用户输入传递给外部系统而没有消毒它(例如: HtmlEncode)或使用注入安全的接口(例如: SQL 参数) ，你是相对安全的——一旦你忘记消毒一些看起来最无害的方法可能成为一个安全漏洞。

注意: cookies、 html 头和其他通过网络传递的数据也是来自用户的数据，在大多数情况下，甚至数据库中的数据也是来自用户的数据。

小开

任何使用正则表达式的东西(特别是正则表达式验证器)。要查看这一点，使用正则表达式 ^(\d+)+$运行一个轩尼诗表达式验证器，并给它30位数字和一个字母字符以进行验证。

一些职位:

这就是所谓的正则表达式分布式拒绝服务攻击攻击，它可以让一个网站屈服。

小开

可能一半的框架包含非常可怕的函数。我自己认为 File.WriteAllText()是非常可怕的，因为它可以覆盖当前用户可以访问的任何文件。

处理这个问题的另一种方法是如何管理安全性。http://ondotnet.com/pub/a/dotnet/2003/02/18/permissions.html上的文章包含有关。NET 安全系统，其 系统，安全，许可命名空间包含所有权限。NET 提供。您还可以查看 http://msdn.microsoft.com/en-us/library/5ba4k1c5.aspx以获得更多信息。

简而言之。NET 允许您限制进程可以拥有的权限，例如拒绝更改磁盘上数据的方法。然后可以检查这些权限，并根据进程是否具有这些权限进行操作。

小开

即使是简单的字符串比较也可能是一个问题。

如果应用程序建立信任 根据这个结果作出决定 比较操作的结果 这个决定可能会被 改变当前的文化

看看 例子很容易被忽略

小开
最佳答案

在基于 Web 的方面，C # (更一般地说，是 ASP.NET)通常容易受到以下因素的影响(OWASP 2013年度最佳10名列出的项目)。我知道你们主要对接收器函数感兴趣，我会介绍其中的一些，但是你们确实问过人们是如何意外地编写危险的 C # 代码的，所以希望我在这里提供了一些见解。

A1-注射

SQL 注入

通过字符串串联生成查询。

var sql = "SELECT * FROM UserAccount WHERE Username = '" + username "'";
SqlCommand command = new SqlCommand(sql , connection);
SqlDataReader reader = command.ExecuteReader();

这个问题通常可以通过 参数化查询解决，但是如果您使用的是 IN条件，则 目前是不可能的不需要字符串串联。

LDAP 注射液

例如

searcher.Filter = string.Format("(sAMAccountName={1})", loginName);

可以使应用程序易受攻击。更多信息 给你。

操作系统命令注入

这段代码很容易受到命令注入的影响，因为 Process.Start的第二个参数可以使用 &字符将额外的命令传递给它，以批处理多个命令

string strCmdText= @"/C dir c:\files\" + Request.QueryString["dir"];
ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText);
Process.Start(info);

例如 foldername && ipconfig

A2-中断身份验证和会话管理

登出

默认的 FormsAuthentication登记方法不更新任何服务器端，允许继续使用捕获的身份验证令牌。

调用 SignOut 方法只会删除窗体身份验证 Cookie。Web 服务器不存储有效的和过期的身份验证票据以供以后比较。如果恶意用户获得了有效的表单身份验证 Cookie，这将使您的站点容易受到重播攻击。

使用会话状态进行身份验证

如果用户使用了 用于身份验证的会话状态，则可能存在 会话固定漏洞。

A3-跨网站脚本程式(XSS)

缺省情况下，Response.Write(和快捷方式 <%= =>)是脆弱的，除非开发人员记得对输出进行 HTML 编码。最近的快捷方式 <%: HTML 默认编码，尽管一些开发人员可能使用这种方式将值插入到 JavaScript 中，这样它们仍然可以被攻击者转义。即使使用现代的 剃刀引擎，也很难做到这一点:

var name = '@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';

NET 默认启用 请求确认，它将阻止来自 cookies、查询字符串和可能具有潜在恶意的 POST 数据(例如 HTML 标签)的任何输入。这似乎可以很好地处理来自特定应用程序的输入，但是如果数据库中有内容是从其他来源插入的，比如从使用其他技术编写的应用程序插入的，那么仍然有可能输出恶意脚本代码。另一个弱点是在属性值中插入数据。例如:。

<%
alt = Request.QueryString["alt"];
%>
<img src="http://example.com/foo.jpg" alt="<%=alt %>" />

这可以在不触发请求验证的情况下利用:

如果 alt是

" onload="alert('xss')

然后这个渲染

<img src="http://example.com/foo.jpg" alt="" onload="alert('xss')" />

在旧版本的。NET 对于一个开发人员来说，确保他们的输出正确地使用一些默认的 web 控件进行编码有点像 雷区。

不幸的是，数据绑定语法还没有包含内置的编码语法; 它将在 ASP.NET 的下一个版本中出现

例如:

  <asp:Repeater ID="Repeater1" runat="server">
<ItemTemplate>
<asp:TextBox ID="txtYourField" Text='<%# Bind("YourField") %>'
runat="server"></asp:TextBox>
</ItemTemplate>
</asp:Repeater>

易受伤害:

<asp:Repeater ID="Repeater2" runat="server">
<ItemTemplate>
<%# Eval("YourField") %>
</ItemTemplate>
</asp:Repeater>

A4-不安全的直接对象引用

MVC 模型绑定允许将 添加到 POST 数据的参数映射到数据模型上。这可能是无意中发生的，因为开发人员没有意识到恶意用户可能会以这种方式修改参数。Bind属性可用于 阻止这一切。

A5-安全错误配置

有许多配置选项可以削弱应用程序的安全性。例如，将 customErrors设置为 On或启用跟踪。

像 ASafaWeb这样的扫描仪可以检查这种常见的错误配置。

A6-敏感资料暴露

默认哈希

ASP.NET 中的默认密码哈希方法有时并不是最好的。

A7-缺少函数级访问控制

未能限制 URL 访问

在集成管道模式下。NET 可以看到每个请求和句柄可以授权每个请求，甚至对非。NET 资源(例如 .js和图像)。但是，如果应用程序 i 在经典模式下运行，。NET 只看到对诸如 .aspx这样的文件的请求，因此其他文件可能意外地不安全。有关差异的更多细节，请参见 这个答案。

例如，虽然有 变通办法，但在以经典模式运行的应用程序中，www.example.com/images/private_photograph_user1.jpg更容易受到攻击。

A8-跨站请求伪造(CSRF)

尽管由于需要攻击者伪造 View State 和 事件验证值，遗留的 Web 表单应用程序通常对 CSRF 更加安全，但是新的 MVC 应用程序可能会受到攻击，除非开发人员手动实现了 防伪代币防伪代币。注意，我并不是说 web 表单不容易受到攻击，只是简单地传递一些基本参数比较困难——不过有一些修复程序，比如 集成用户密钥到 View State 值中。

当 EnableEventValification 属性设置为 true 时，ASP.NET 验证控件事件是否源自该控件呈现的用户界面。控件在呈现期间注册其事件，然后在回发或回调处理期间验证事件。例如，如果列表控件在呈现页时包含编号为1、2或3的选项，并且如果收到指定选项4的回发请求，则 ASP.NET 将引发异常。ASP.NET 中的所有事件驱动控件都默认使用此特性。

[ EnableEventValification ]特性降低了未经授权或恶意回发请求和回调的风险。强烈建议不要禁用事件验证。

A10-未验证-重定向和转发

添加以下代码，如

Response.Redirect(Request.QueryString["Url"]);

将使您的网站易受攻击。攻击可以通过向包含链接的用户发送钓鱼电子邮件来启动。如果用户是警惕的，他们可能已经双重检查的域名的 URL 之前点击。但是，由于该域将与用户信任的域匹配，他们将单击该链接，而不知道页面将把用户重定向到攻击者的域。

验证应该在 Url上进行，以确保它是一个相对的、允许的 URL 或您自己允许的域和页面之一的绝对 URL。例如，您可能希望检查某人没有将您的用户重定向到 /Logout.aspx。虽然没有什么可以阻止攻击者直接链接到 http://www.example.com/Logout.aspx，但是他们可以使用重定向来隐藏 URL，这样用户就更难理解正在访问哪个页面(http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78)。

其他人

其他单程证类别包括:

  • A9-使用具有已知漏洞的组件

我想不出有什么是 C #/ASP.NET 特有的。我会更新我的答案，如果我想到任何(如果你认为他们有关你的问题)。


提交答案