在基于Web的方面，C＃（更常见的是ASP.NET）通常容易受到以下漏洞的影响（OWASP Top 10 2013列出的项目）。我知道您主要对接收器功能感兴趣，但其中有一些内容，但是您确实询问了人们是如何意外制作危险的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身份验证和会话管理中断
登出
默认的“表单身份验证签出”方法不会更新服务器端的任何内容，从而允许继续使用捕获的身份验证令牌。
调用SignOut方法只会删除表单身份验证cookie。Web服务器不存储有效的和过期的身份验证票证以供以后比较。如果恶意用户获得有效的表单身份验证cookie，这会使您的站点容易受到重放攻击。
使用会话状态进行身份验证
甲会话固定如果一个用户已经使用漏洞可能存在会话状态以用于认证。
A3跨站点脚本（XSS）
Response.Write（和快捷方式<%= =>）默认情况下容易受到攻击，除非开发人员记得对输出进行HTML编码。<%:默认情况下，较新的快捷方式HTML会默认编码，尽管某些开发人员可能会使用此快捷方式将值插入JavaScript，从而使攻击者仍然可以对其进行转义。即使使用现代的Razor引擎，也很难做到这一点：
var name = '@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';
默认情况下，ASP.NET启用请求验证，该请求验证将阻止来自cookie，查询字符串和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，图像）。但是，如果应用程序以经典模式运行，则.NET仅会看到对文件的请求，例如，.aspx因此其他文件可能会意外地不安全。有关差异的更多详细信息，请参见此答案。
例如www.example.com/images/private_photograph_user1.jpg，尽管有一些解决方法，但在以经典模式运行的应用程序中，它更容易受到攻击。
A8跨站请求伪造（CSRF）
尽管由于要求攻击者伪造“视图状态”和“事件验证”值，传统的Web表单应用程序通常更安全地抵御CSRF ，但除非开发人员手动实施了防伪令牌，否则更新的MVC应用程序可能会很容易受到攻击。请注意，我并不是说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类别是：
其中我想不出C＃/ ASP.NET特有的任何东西。如果有任何疑问（如果您认为与您的问题相关），我将更新我的答案。