可开发的C＃函数
这个问题类似于可开发的PHP函数 。
受感染的数据来自用户，或者更具体地说是攻击者。 当受污染的variables达到吸收function，那么你有一个漏洞。 例如，一个执行sql查询的函数是一个接收器，GET / POSTvariables是污点的来源。
C＃中所有的接收器函数是什么？ 我正在寻找引入漏洞或软件缺陷的function 。 我特别感兴趣的是远程执行代码漏洞。 是否有整个类/库包含黑客想要影响的function上的讨厌？ 人们如何不小心做出危险的C＃代码？
在基于Web的事物方面，C＃（更一般地说，ASP.NET）通常容易受到以下（ OWASP Top 10 2013中列出的项目）的影响。 我意识到你主要对sink函数感兴趣，其中我涵盖了一些，但是你曾经问过人们如何不小心做出危险的C＃代码，所以我希望在这里提供一些见解。
A1-注射
SQL注入
通过string连接生成查询。
var sql = "SELECT * FROM UserAccount WHERE Username = '" + username "'"; SqlCommand command = new SqlCommand(sql , connection); SqlDataReader reader = command.ExecuteReader(); 这通常可以通过参数化查询来解决，但是如果您使用的是IN条件，那么当前不可能没有string连接。
LDAP注入
代码如
searcher.Filter = string.Format("(sAMAccountName={1})", loginName);
可能使应用程序易受攻击。 更多信息在这里 。
OS命令注入
此代码易受命令注入的影响，因为Process.Start的第二个参数可以使用&字符来传递额外的命令来批量处理多个命令
string strCmdText= @"/C dir c:\files\" + Request.QueryString["dir"]; ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText); Process.Start(info);
例如foldername && ipconfig
A2-损坏的authentication和会话pipe理
登出
默认的表单身份validationSignOut方法不会更新任何服务器端，允许继续使用捕获的身份validation令牌。
调用SignOut方法只会删除表单身份validationCookie。 Web服务器不存储有效和过期的身份validation票据以供以后比较。 如果恶意用户获得有效的表单身份validationcookie，这会使您的站点容易受到重播攻击。
使用会话状态进行身份validation
如果用户使用会话状态进行身份validation ，则会出现会话修复漏洞。
A3跨站点脚本（XSS）
Response.Write （和快捷键<%= => ）默认是脆弱的，除非开发人员已经记住HTML编码输出。 最近的快捷方式<%: HTML默认编码，尽pipe一些开发人员可能会使用它来将值插入到JavaScript中，攻击者仍然可以将其转义。 即使使用现代Razor引擎 ，也很难做到这一点：
var name = '@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';
ASP.NET默认启用请求validation ，这将阻止任何来自cookie，查询string和可能是恶意的POST数据的input（例如HTML标签）。 这似乎很好地处理了通过特定应用程序的input，但是如果数据库中的内容是从使用其他技术编写的应用程序等其他来源插入的，则可能仍然会输出恶意脚本代码。 数据插入属性值的另一个弱点是 例如
<% alt = Request.QueryString["alt"]; %> <img src="http://example.com/foo.jpg" alt="<%=alt %>" />
这可以被利用，而不触发请求validation：
如果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-安全configuration错误
有许多configuration选项可能会削弱应用程序的安全性。 例如，将customErrors设置为On或启用跟踪。
扫描仪如ASafaWeb可以检查这种常见的错误configuration。
A6敏感数据曝光
默认哈希
ASP.NET中的默认密码哈希方法有时不是最好的。
- HashPasswordForStoringInConfigFile（） – 如果它被用来散列没有添加盐的普通密码，这也可能是坏的。
- 文章“ 我们的密码散列没有衣服 ”关于.NET 4中的ASP.NET成员资格提供程序。
A7缺失function级别访问控制
未能限制URL访问
在集成pipe道模式下，.NET可以看到每个请求和句柄都可以授权每个请求，甚至是非.NET资源（例如.js和图像）。 但是，如果应用程序以经典模式运行，.NET只能看到诸如.aspx文件的请求，所以其他文件可能会意外不安全。 看到这个答案更详细的差异。
例如www.example.comhttp://img.dovov.comprivate_photograph_user1.jpg在经典模式下运行的应用程序中更容易受到攻击，尽pipe有解决方法 。
A8-跨站点请求伪造（CSRF）
尽pipe由于要求攻击者伪造视图状态和事件validation值，传统的Web窗体应用程序通常对CSRF更安全，但除非开发人员手动实现了防伪标记，否则较新的MVC应用程序可能易受攻击。 注意我并不是说Web表单不是脆弱的，只是简单地传递一些基本参数比较困难，但是有一些修复，比如将用户键集成到View State值中。
当EnableEventValidation属性设置为true时，ASP.NET将validation控件事件源于该控件呈现的用户界面。 控件在渲染过程中注册事件，然后在回发或callback处理过程中validation事件。 例如，如果列表控件包含页面呈现时编号为1,2或3的选项，并且如果收到指定选项编号4的回发请求，ASP.NET将引发exception。 ASP.NET中的所有事件驱动控件默认使用此function。
[EnableEventValidation]function降低了未授权或恶意回发请求和callback的风险。 强烈build议您不要禁用事件validation。
A10-未经validation – redirect和转发
添加如
Response.Redirect(Request.QueryString["Url"]);
将使您的网站易受攻击。 可以通过向包含链接的用户发送networking钓鱼电子邮件来启动攻击。 如果用户保持警惕，他们可能会在点击之前再次检查URL的域名。 但是，由于该域名将与您所信任的域名相匹配，因此他们会点击链接，而不会意识到该页面会将用户redirect到攻击者的域名。
validation应在Url进行，以确保它是相对的，允许的URL或绝对URL到您自己允许的域和页面之一。 例如，您可能希望检查某人是否将您的用户redirect到/Logout.aspx 。 尽pipe可能没有任何东西阻止攻击者直接链接到http://www.example.com/Logout.aspx ，但他们可以使用redirect来隐藏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的东西。 我会更新我的答案，如果我想到任何（如果你认为他们与你的问题有关）。
任何使用正则expression式的东西（特别是RegularExpressionValidator）。 要看到这个，用正则expression式^(\d+)+$运行一个RegularExpressionValidator，并给它30个数字和一个字符来validation。
一些post：
- http://msdn.microsoft.com/en-us/magazine/ff646973.aspx
- http://www.abemiester.com/abemiester/post/RegEx-DOS-attack-Regular-Expressions-Now-you-have-3-problems.aspx （这是从我自己的博客博客文章进入更多的细节MSDN文章）。
这被称为正则expression式拒绝服务攻击，它可以使网站瘫痪。
Process.Start是第一个想到的人。
我相信WindowsIdentity和System.Security大部分内容也可以用于邪恶。
当然，也有SQL注入攻击，但我不认为这就是你的意思（尽pipe可以通过SQL Server进行远程执行）。
除了已经提到的显而易见的Process.Start() ，我可以看到一些潜在的间接开发方法。
- WinAPI通过PInvoke调用
CreateProcess()和什么。 - 任何使用
Assembly.Load()和其他types的重载的dynamic程序集加载机制。 如果一个受损的程序集将其加载到系统并加载。 - 一般来说如果完全信任的话。
- 有了正确的权限，任何registry操作都可能使您处于危险之中。
现在想到的就是这一切。
国际海事组织：第1号可开发的function，是无辜的看，但非常危险的使用时，没有思想。
在ASP.Net Response.Write或快捷方式：
<%= searchTermFromUser %>
在ADO.Net中：
-
string+运算符：
var sql = "SELECT * FROM table WHERE name = '" + searchTermFromUser + "'"
从用户（或任何其他外部源）获得的任何数据并传递给另一个系统或另一个用户是一个潜在的漏洞。
如果你从用户那里得到一个string，而不使用HtmlEncode将其显示给另一个用户，这是一个潜在的漏洞。
如果你从用户那里得到一个string并用它来构造SQL，那么这是一个潜在的SQL注入。
如果从用户那里得到一个string，并使用它来收缩Process.Start或Assembly.Load的文件名，则这是一个远程执行漏洞
你明白了，危险来自于使用unsanitized数据，如果你永远不把用户input传递给外部系统（例如：HtmlEncode）或使用注入安全接口（例如：SQL参数），那么你是相对安全的 – 忘记清理一下最无辜的方法可能成为一个安全漏洞。
注意：cookies，html头文件和其他通过networking传递的数据也是来自用户的数据，大多数情况下甚至数据库中的数据都是来自用户的数据。
System.Net，System.XML，System.IO，（任何需要一个URI和/或文件path，并实际处理它们识别的资源）的东西很多System.Reflection，System.Security，System.Web，System .Data和System.Threading命名空间可能是危险的，因为它们可以用来做不好的事情，而不仅仅是搞乱当前的执行。 如此多的试图识别每一个都会花费很多时间。
当然，除非另有说明，否则所有第三方assembly中的每种方法都将被认为是危险的。 再花费更多的时间。
我也不认为这是一个特别有成效的方法。 生成一个函数清单只能用在一个有限的库中，或者用一个大型的语言来工作，在C语言中，像C＃这样的语言库中的大量语言本身就是这样。
有一些经典的危险的例子像Process.Start()或者任何直接执行另一个进程的东西，但是它们被相当明显的危险所平衡。 即使是一个相对来说十分鲁莽，无能的编码人员，在使用这种编码器时也会小心谨慎，同时将数据传给其他方法。
数据卫生是一个比任何function清单更有成效的东西。 数据validation是否清除了明显不正确的input（可能是由于攻击导致的，或者可能只是一个错误），并且是以适当的方式对给定图层进行编码和转义的（关于“危险”字符序列的讨论太多， '从来没有伤害任何人，它没有正确逃脱的SQL，这可能会伤害，当它确实是在一个SQL层 – 确保数据正确的工作所需的工作是相同的，以避免利用）。 与代码之外的东西进行通信的层是否是固定的。 例如URI是否使用未经检验的input构build – 如果不是，则可以将一些更常用的System.Net和System.XML方法转换为空洞。
使用任何types的不安全的代码可能会导致问题，如指针。 Microsoft在这里提供了有关不安全代码的好文章： http : //msdn.microsoft.com/zh-cn/library/aa288474(VS.71).aspx
Reflection.Emit和CodeDom
编辑 ：
允许使用线程的插件或第三方库可以将整个应用程序closures，除非您将这些库/插件加载到单独的appdomain中。
可能有一半的框架包含非常可怕的function。 我自己认为File.WriteAllText()是非常可怕的，因为它可以覆盖当前用户有权访问的任何文件。
这个问题的另一种方法是如何pipe理安全性。 http://ondotnet.com/pub/a/dotnet/2003/02/18/permissions.html中的文章包含有关;.NET安全系统的基本描述，包含所有权限的System.Security.Permissions命名空间。使可用。 您也可以查看http://msdn.microsoft.com/en-us/library/5ba4k1c5.aspx获取更多信息。;
简而言之，.NET允许您限制进程的权限，例如拒绝在磁盘上更改数据的方法。 然后，您可以检查这些权限，并根据进程是否拥有这些权限进行操作。
即使是简单的string比较也是一个问题。
如果一个应用根据这个String.Compare操作的结果做出了一个信任决定，那么这个决定的结果可以通过改变CurrentCulture
看看这个例子 。 相当容易错过
我见过代码，用户可以在数据库中设置函数调用的名称和参数。 然后系统将通过reflection执行命名的function而不检查任何东西…
