当前位置:  开发笔记 > 编程语言 > 正文

可利用的C#函数

如何解决《可利用的C#函数》经验,为你挑选了11个好方法。

此问题类似于可利用的PHP函数.

受污染的数据来自用户,或者更具体地来说是攻击者.当受污染的变量达到接收器功能时,您就会有漏洞.例如,执行sql查询的函数是接收器,而GET/POST变量是污点源.

C#中的所有接收器功能是什么?我正在寻找引入漏洞或软件弱点的功能.我对远程执行代码漏洞特别感兴趣.是否存在整个类/库,其中包含黑客想要影响的功能恶劣?人们如何不小心制作危险的C#代码?



1> Abe Miessler..:

任何使用正则表达式的东西(特别是RegularExpressionValidator).要查看此信息,请使用正则表达式运行RegularExpressionValidator,^(\d+)+$并为其提供30位数字和字母字符以进行验证.

一些帖子:

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

这被称为正则表达式拒绝服务攻击,它可以使网站瘫痪.


哦,那是一个很好的.适用于任何支持正则表达式的语言.
是的,我做到了,我完全同意.如果您使用未经审查的正则表达式,并且您对正则表达式了解很多*,那么您就会打开各种各样的蠕虫病毒.
有趣的奇怪,但这是完全答案的远距离.
所有正则表达式都不会导致此类问题.这个特别精心设计有这种问题.

2> SilverlightF..:

在基于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);

可以使应用程序易受攻击.更多信息在这里.

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-Broken认证和会话管理

登出

默认的Forms Authentication SignOut方法不会更新服务器端的任何内容,从而允许继续使用捕获的身份验证令牌.

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

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

甲会话固定如果一个用户已经使用漏洞可能存在会话状态以用于认证.

A3-Cross-Site脚本(XSS)

Response.Write(和快捷方式<%= =>)默认是易受攻击的,除非开发人员记住HTML编码输出.<%:默认情况下,最新的快捷方式HTML编码,尽管一些开发人员可能会使用此方法将值插入JavaScript中,攻击者仍然可以将其转义.即使使用现代的Razor引擎,也很难做到这一点:

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

ASP.NET默认启用请求验证,它将阻止来自cookie的任何输入,查询字符串以及可能是恶意的POST数据(例如HTML标记).这似乎可以很好地处理来自特定应用程序的输入,但如果数据库中的内容是从其他来源(例如使用其他技术编写的应用程序)插入的,则可能仍然可以输出恶意脚本代码.另一个缺点是数据是在属性值中插入的.例如

<%
alt = Request.QueryString["alt"];
%>
<%=alt %>

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

如果alt是的话

" onload="alert('xss')

然后这呈现


在旧版本的.NET中,对于开发人员来说,确保使用某些默认Web控件正确编码其输出是一个挖掘领域.

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

例如不易受伤害:

  
    
      
    
  

弱势:


  
    <%# Eval("YourField") %>
  

A4-不安全的直接对象参考

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

A5-安全配置错误

有许多配置选项可能会削弱应用程序的安全性.例如,设置customErrorsOn或启用跟踪.

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)

虽然遗留Web表单应用程序通常对CSRF更安全,因为要求攻击者伪造View State和Event Validation值,但除非开发人员手动实现防伪标记,否则较新的MVC应用程序可能容易受到攻击.注意我并不是说Web表单不容易受到攻击,只是传递一些基本参数更加困难 - 虽然有一些修复,例如将用户密钥集成到View State值中.

当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的内容.如果我想到的话,我会更新我的答案(如果你认为它们与你的问题相关).



3> Oded..:

Process.Start 是第一个浮现在脑海中的人.

我相信,WindowsIdentity大部分System.Security也可以用于邪恶.

当然,有SQL注入攻击,但我不认为这是你的意思(虽然远程执行可以通过SQL Server发生).


像SQL的用户名和密码的连接字符串这样的东西有点狡猾,当你使用静态字符串时,它们通常在反编译器中找到,所以如果它们包含私人信息,最好不要使用它们.

4> Jeff Mercado..:

除了Process.Start()已经提到的显而易见的,我可以看到几种潜在的间接剥削方式.

WinAPI通过PInvoke调用CreateProcess()以及诸如此类的东西.

任何类型的动态装配加载机制使用Assembly.Load()和其他这样的过载.如果受损组件进入系统并加载.

如果一般完全信任.

使用正确的权限,任何注册表操作都可能使您面临风险.

这就是现在想到的一切.



5> GvS..:

IMO:nr 1可利用的功能,看起来是无辜的,但在没有想到的情况下使用时非常危险.

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

  <%= searchTermFromUser %>

在ADO.Net中:

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


永远不要做那样的SQL语句.在查询中使用Command.AddParameter和参数名称.
@Xaqron:这是允许[跨站点脚本]的一条路径(http://en.wikipedia.org/wiki/Cross-site_scripting)

6> Nir..:

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

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

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

如果你从用户那里得到一个字符串并用它来收集Process.Start或Assembly.Load的文件名,那就是一个远程执行漏洞

您明白了,危险来自于使用未经过清理的数据,如果您从未将用户输入传递给外部系统而未对其进行消毒(例如:HtmlEncode)或使用注入安全接口(例如:SQL参数),那么您就相对安全了 - 一分钟忘记清理一些最无辜的方法可能会成为一个安全漏洞.

注意:cookie,html标头和通过网络传递的任何其他内容也是来自用户的数据,在大多数情况下,即使数据库中的数据也是来自用户的数据.



7> Jon Hanna..:

System.Net,System.XML,System.IO中的大量内容(任何采用URI和/或文件路径并实际处理它们识别的资源的东西)System.Reflection,System.Security,System.Web,System .Data和System.Threading命名空间可能很危险,因为它们可以用来做坏事,而不仅仅是弄乱当前的执行.这么多,尝试识别每个都是耗时的.

当然,除非另有说明,否则所有第三方组件中的每种方法都必须被认为是危险的.再次耗费时间.

我也不认为这是一种特别富有成效的方法.制作功能清单仅适用于有限的库,或者使用大型语言,其中C#语言库中的许多内容都在语言本身中.

有一些经典危险的例子Process.Start()或直接执行另一个过程的任何东西,但它们通过非常明显的危险来平衡.即使是一个相对愚蠢和无能的编码人员在使用它时也可能会小心,同时将未经过其他方法的数据留给他们.

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



8> kyndigs..:

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


"像指针这样的问题"
-1为限定指针作为问题......它们是什么类型的问题?

9> jgauffin..:

Reflection.Emit和CodeDom

编辑:

允许使用线程的插件或第三方库可以将整个应用程序关闭,除非您将这些库/插件加载到单独的应用程序域中.



10> Pieter van G..:

可能一半的框架包含非常可怕的功能.我自己认为这File.WriteAllText()非常可怕,因为它可以覆盖当前用户有权访问的任何文件.

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

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



11> jasper..:

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

如果应用程序根据此String.Compare操作的结果做出信任决策,则可以通过更改CurrentCulture来破坏该决策的结果

看看这个例子.相当容易错过

推荐阅读
小白也坚强_177
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有