可利用的 C# 函数 [英] Exploitable C# Functions

问题描述

这个问题类似于 以便开发人员确保他们的输出使用一些默认的 Web 控件正确编码.

<块引用>

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

例如不易受攻击:

 <项目模板><asp:TextBox ID=txtYourField"Text='<%# Bind("YourField") %>'runat="server"></ItemTemplate></asp:中继器>

易受攻击:

<项目模板><%# Eval("YourField") %></ItemTemplate></asp:中继器>

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

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

A5-安全配置错误

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

ASafaWeb 等扫描程序可以检查这种常见的错误配置.

A6 敏感数据暴露

默认散列

ASP.NET 中的默认密码散列方法有时不是最好的.

• HashPasswordForStoringInConfigFile() - 这可以如果它用于散列未添加盐的普通密码，也会很糟糕.
• 文章 "我们的密码散列没有衣服"关于 .NET 4 中的 ASP.NET 成员资格提供程序.

A7-缺少功能级访问控制

未能限制 URL 访问

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

例如www.example.com/images/private_photograph_user1.jpg 在以经典模式运行的应用程序中更容易受到攻击，尽管有 解决方法.

A8 跨站请求伪造 (CSRF)

尽管由于要求攻击者伪造视图状态和 Event Validation 值，除非开发人员手动实现 反伪造令牌.请注意，我并不是说 Web 表单没有漏洞，只是简单地传递一些基本参数会更困难 - 不过有一些修复程序，例如 将用户密钥集成到视图状态值中.

<块引用>

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

[EnableEventValidation] 功能降低了未经授权或恶意回发请求和回调的风险.强烈建议您不要禁用事件验证.

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).

其他

其他 OWASP 类别是:

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

其中我想不出任何特定于 C#/ASP.NET 的内容.如果我想到任何答案(如果您认为它们与您的问题相关)，我会更新我的答案.

This question is similar to Exploitable PHP Functions.

Tainted data comes from the user, or more specifically an attacker. When a tainted variable reaches a sink function, then you have a vulnerability. For instance a function that executes a sql query is a sink, and GET/POST variables are sources of taint.

What are all of the sink functions in C#? I am looking for functions that introduce a vulnerability or software weakness. I am particularly interested in Remote Code Execution vulnerabilities. Are there whole classes/libraries that contain nasty functionally that a hacker would like to influence? How do people accidentally make dangerous C# code?

解决方案

On the web based side of things, C# (and more generally, ASP.NET) is commonly vulnerable to the following (items listed by OWASP Top 10 2013). I realise you were mainly interested in sink functions, of which I cover some, however you did ask how people accidentally make dangerous C# code so hopefully I've provided some insight here.

A1-Injection

SQL Injection

Generating queries by string concatenation.

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

This can often be solved by parameterised queries, but if you are using an IN condition it currently isn't possible without string concatenation.

LDAP Injection

Code such as

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

can make the application vulnerable. More information here.

OS Command Injection

This code is vulnerable to command injection because the second parameter to Process.Start can have extra commands passed to it using the & character to batch multiple commands

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

e.g. foldername && ipconfig

A2-Broken Authentication and Session Management

Sign Out

The default Forms Authentication SignOut method does not update anything server side, allowing a captured auth token to be continued to be used.

Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.

Using Session State for Authentication

A session fixation vulnerability could be present if a user has used session state for authentication.

A3-Cross-Site Scripting (XSS)

Response.Write (and the shortcut <%= =>) are vulnerable by default, unless the developer has remembered to HTML encode the output. The more recent shortcut <%: HTML encodes by default, although some developers may use this to insert values into JavaScript where they can still be escaped by an attacker. Even using the modern Razor engine it is difficult to get this right:

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

ASP.NET by default enables Request Validation, which will block any input from cookies, the query string and from POST data that could potentially be malicious (e.g. HTML tags). This appears to cope well with input coming through the particular app, but if there is content in the database that is inserted from other sources like from an app written using other technologies, then it is possible that malicious script code could still be output. Another weakness is where data is inserted within an attribute value. e.g.

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

This can be exploited without triggering Request Validation:

If alt is

" onload="alert('xss')

then this renders

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

In old versions of .NET it was a bit of a mine-field for a developer to ensure that their output was correctly encoded using some of the default web controls.

Unfortunately, the data-binding syntax doesn’t yet contain a built-in encoding syntax; it’s coming in the next version of ASP.NET

e.g. not vulnerable:

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

vulnerable:

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

A4-Insecure Direct Object References

MVC model binding can allow parameters added to POST data to be mapped onto the a data model. This can happen unintentionally as the developer hasn't realised that a malicious user may amend parameters in this way. The Bind attribute can be used to prevent this.

A5-Security Misconfiguration

There are many configuration options that can weaken the security of an application. For example setting customErrors to On or enabling trace.

Scanners such as ASafaWeb can check for this common misconfigurations.

A6-Sensitive Data Exposure

Default Hashing

The default password hashing methods in ASP.NET are sometimes not the best.

• HashPasswordForStoringInConfigFile() - this could also be bad if it is used to hash a plain password with no added salt.
• Article "Our password hashing has no clothes" regarding the ASP.NET membership provider in .NET 4.

A7-Missing Function Level Access Control

Failure to Restrict URL Access

In integrated pipeline mode .NET can see every request and handles can authorise each request, even to non .NET resources (e.g. .js and images). However, if the application i running in classic mode, .NET only sees requests to files such as .aspx so other files may be accidentally unsecured. See this answer for more detail on the differences.

e.g. www.example.com/images/private_photograph_user1.jpg is more likely to be vulnerable in an application that runs in classic mode, although there are workarounds.

A8-Cross-Site Request Forgery (CSRF)

Although the legacy web forms applications are usually more secure against CSRF due to requiring the attacker to forge the View State and Event Validation values, newer MVC applications could be vulnerable unless the developer has manually implemented anti forgery tokens. Note I am not saying that web forms is not vulnerable, just that it is more difficult that simply passing on a few basic parameters - there are fixes though, such as integrating the user key into the View State value.

When the EnableEventValidation property is set to true, ASP.NET validates that a control event originated from the user interface that was rendered by that control. A control registers its events during rendering and then validates the events during postback or callback handling. For example, if a list control includes options numbered 1, 2, or 3 when the page is rendered, and if a postback request is received specifying option number 4, ASP.NET raises an exception. All event-driven controls in ASP.NET use this feature by default.

[EnableEventValidation] feature reduces the risk of unauthorized or malicious postback requests and callbacks. It is strongly recommended that you do not disable event validation.

A10-Unvalidated - Redirects and Forwards

Adding code such as

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

will make your site vulnerable. The attack could be initiated by sending a phishing email to a user containing a link. If the user is vigilant they may have double checked the domain of the URL before clicking. However, as the domain will match your domain which the user trusts, they will click the link unaware that the page will redirect the user to the attacker's domain.

Validation should take place on Url to ensure that it is either a relative, allowed URL or an absolute URL to one of your own allowed domains and pages. You may want to check someone isn't redirecting your users to /Logout.aspx for example. Although there may be nothing stopping an attacker from directly linking to http://www.example.com/Logout.aspx, they could use the redirect to hide the URL so it is harder for a user to understand which page is being accessed (http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78).

Others

The other OWASP categories are:

• A9-Using Components with Known Vulnerabilities

of which I can't think of any to mind that are specific to C#/ASP.NET. I'll update my answer if I think of any (if you think they are relevant to your question).

这篇关于可利用的 C# 函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！