摘要:Patterns & Practices一直有着高质量和实用可靠的名声。其口号叫做Proven practices for predictable results. 今天最新的一本350页的书名为Web Service Security： Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0. 您可以在线浏览，或者下载（4M）到本地。...[阅读全文]

摘要:在NT-Bugtraq的邮件列表上首先报告的Security bug in .NET Forms Authentication适用于ASP.NET 1.0 (RTM, SP1, SP2, SP3)和ASP.NET 1.1 (RTM, SP1).   当Form Authentication被使用时，匿名用户在试图访问被保护的页面如http://localhost/WebApplication2/secret.aspx时会被redirect到登录网页如http://localhost/WebApplication2/login.aspx?ReturnUrl=%2fWebApplication2%2fsecret.aspx.   但是如果使用Mozilla，匿名用户可以这样未经认证就访问被保护的页面：http://localhost/WebApplication2\secret.aspx；对IE，可以使用%5C达到类似的效果：http://localhost/WebApplication2%5Csecret.aspx   微软在10月5日发布了What You Should Know About a Reported Vulnerability in Microsoft ASP.NET网页以提供针对此安全漏洞的对策。当前的对策主要是如KB887459所描述的那样在Global.asax或其Code-Behind中在Application_BeginRequest中增加检查      if (Request.Path.IndexOf('\\') >= 0 ||        System.IO.Path.GetFullPath(Request.PhysicalPath) != Request.PhysicalPath) {        throw new HttpException(404, "not found");    } 显然每个Application都需要有这样的检查以应对此安全漏洞。微软还会提供其他的对策，请关注What You Should Know About a Reported Vulnerability in Microsoft ASP.NET网页更新。   对ASP.NET 2.0 Beta1，并没有此漏洞而是得到404错误。   贴子以"现状"提供且没有任何担保也没有授予任何权利...[阅读全文]

摘要:假设某公司Dev部门.NET开发小组正在开发一个Full Trust将被部署到每个客户机的GAC上的Library.该小组内部CAS教程中有下列的一些要点。请问那几条是完全正确的？ 1）对所有CodeAccessPermission-derived Classes的构造函数如public FileIOPermission(PermissionState state); 可以接受PermissionState.None和PermissionState.Unrestricted作为参数值，否则会throw InvalidEnumArgumentException. 2）如果一个函数中使用了Assert如FileIOPermission.Assert, 必须在函数体结束前调用静态函数CodeAccessPermission.RevertAssert（或者CodeAccessPermission.RevertAll). 3）Full Trust的Assembly,即使登录用户帐号不具有“管理员(Administrator)”的权限，还是Full Trust的. 4）使用托管代码无需担心Buffer Overrun. 贴子以"现状"提供且没有任何担保也没有授予任何权利。...[阅读全文]

摘要:下面的Console应用程序在运行时会产生System.Security.SecurityException，请问从Demand No1到Demand No4,哪一个是造成这个SecurityException的语句，为什么？ using System; using System.Security.Permissions; [assembly:FileIOPermission(SecurityAction.RequestRefuse, Read="C:\\")] namespace SecurityRequestRefuseDemo {       class Class1       {         [STAThread]         static void Main(string[] args)         {             FileIOPermission fileIOPermission = new FileIOPermission(FileIOPermissionAccess.Write, @"C:\");             fileIOPermission.Demand();     //Demand No.1             Testme1();             fileIOPermission = new FileIOPermission(FileIOPermissionAccess.Read, @"C:\");             fileIOPermission.Demand();     //Demand No.2             Testme2();         }         private static void Testme1()         {             FileIOPermission fileIOPermission = new FileIOPermission(FileIOPermissionAccess.Write, @"C:\");             fileIOPermission.Demand();     //Demand No.3         }         private static void Testme2()         {             FileIOPermission fileIOPermission = new FileIOPermission(FileIOPermissionAccess.Read, @"C:\");             fileIOPermission.Demand();     //Demand No.4         }       } }   贴子以"现状"提供且没有任何担保也没有授予任何权利。...[阅读全文]

摘要:一个public API必须Validate输入参数的正确性，绝大多数安全问题都归结于trusting input。从昨天对Security随笔（4）的评论可以清楚的看到，网络是恶意代码和黑客大量存在的地方。要写出安全的代码，决不可信任输入。发现不合法的输入，就要throw ArgumentException或者其他合适的异常。 Debug.Assert是不适用于这个场合的。因为Debug.Assert只存在Debug Build之中。那么什么时候用Debug.Assert呢？ 不管是在public API还是protected/private API中，如果某些条件必定满足，而且API就是在假定这些条件满足的前提下才可以正确运作，那么就不妨使用Debug.Assert将条件显式的表达出来。 毫无疑问，如果不通过Debug Build进行测试，则Debug.Assert就没有用处。当一个程序在正常运行的时候出现Assert,这就意味者原先认为理所当然的条件并不成立，这往往暗示了一个bug。 贴子以"现状"提供且没有任何担保也没有授予任何权利。...[阅读全文]

摘要:在银行或者别的金融机构申请网上交易的便利之后，对账号内容和未授权交易的保护往往就只依赖在用户的帐号名和密码上了。 如果用户的密码一旦被窃取，其后果是很严重的。如果这个用户对不同的帐号上使用同一密码，就更可怕了。 所以安全性专家往往告诫大家：要用难以猜测的密码，要每个月更换密码，不要重复使用密码。但是，究竟有多少用户做到了这一点？ （当然，不要把密码贴在计算机屏幕上或者钱包里面，这一点大家都应该做到！） 今天看到的新闻Hacking sparks need for complex passwords提供了一个使得密码复杂化的方法。银行寄给客户包含50个不同代码的卡片，每次sign in除了传统的帐号名和密码外还需要顺序使用一个代码。等到用户的卡片代码将用尽的时候，银行会寄出新的卡片。 这个方法会很有效的保护用户帐号。虽然麻烦一些，但是利大于弊。 贴子以"现状"提供且没有任何担保也没有授予任何权利。...[阅读全文]

摘要:上一篇随笔将“缓冲区溢出”翻译成“Buffer Overflow”，但是在微软程序员必读书Writing Secure Code 书写安全代码(2nd Edition)之中，“缓冲区溢出”是翻译成“Buffer Overrun”的。我个人的理解是两者有着相同的意思。 从google上搜索这2个术语，结果"Buffer Overflow"有859,000个搜索结果而"Buffer Overrun"只有116,000。有趣的是，当将搜索限制在www.microsoft.com的site上，Buffer overrun的使用频度是buffer overflow的2倍。 为了和来自微软的资料一致，我将在以后的随笔中使用buffer overrun. 贴子以"现状"提供且没有任何担保也没有授予任何权利。...[阅读全文]

摘要:可经验证(Verifiable)的托管(managed)代码是不会出现缓冲区溢出的问题的。但是在下列情况下，仍然要防止Buffer Overflow： Unsafe C#； COM Interop； Platform Invokes (P/Invoke)； 使用不可验证（Unverifiable）的语言，如Managed C++. 举个例子，下面这个private函数完全可能造成Buffer Overflow，调用它的函数必须防止这个问题。private unsafe static void PrivateCopyUnguarded(byte[] src, int srcIndex, byte[] dest, int destIndex, int length){  fixed(byte* srcPointer = src, destPointer = dest)  {      byte* srcPosition = srcPointer + srcIndex;    byte* destPosition = destPointer + destIndex;    while (length-- > 0)   {      *destPosition++ = *srcPosition++;    }  } } 下面是调用InternalCopyUnguarded的public方法：public static void MemoryCopy(byte[] src, int srcIndex,  byte[] dest, int destIndex, int length){  if ((length < 0) || (srcIndex < 0) || (destIndex < 0) || (srcIndex + length > src.Length) || (destIndex + length > dest.Length))   {    throwErrorException();  }  PrivateCopyUnguarded(src, srcIndex, dest, destIndex, length);}可是：MemoryCopy的实现有问题么？敬请评论。 贴子以"现状"提供且没有任何担保也没有授予任何权利。...[阅读全文]

摘要:重粒子评论道：希望增加一些关于安全性的随笔。You wish for it, and you get it. 看下面这个代码，其中 _position, _length等都是private field. _mem包括了用户感兴趣的信息。每一次调用ReadByte, 或者因为错误条件而得到Exception, 或者如愿得到下一个值，或者在_position已经超过总_length的情况下得到-1. 仅从Race Conditon的角度去看，当有2个或者多个线程(thread)使用该函数时，会再什么情况下出问题？ public unsafe int ReadByte() {    if (!_hasInternalError)  {    throwErrorException();  }  if (_position >= _length)  {    return -1;   }  return _mem[_position++]; } 这个代码的主要问题就在_position++上。如果几个thread都通过了_position >= _length的检查而连续调用_mem[_position++]就有可能访问到超出_length的地址空间。因为没有对每个Thread都可以改变的_position提供保护，就会造成Race Condition. 如何避免这个问题？可以使用一个新的局部变量pos来保存_position的值。如下： public unsafe int ReadByte() {    if (!_hasInternalError)  {    throwErrorException();  }  int pos = _position;   if (pos >= _length)  {    return -1;   }  _position = pos + 1;  return _mem[pos]; } 别的方法，如lock, 和重粒子刚刚评论的[MethodImplAttribute(MethodImplOptions.Synchronized)]也是可以避免Race Condition,但是代价会比上面的解法大。 贴子以"现状"提供且没有任何担保也没有授予任何权利。...[阅读全文]

摘要:任何计算机安全系统（包括.NET的CAS）的保证都可以在人为的破坏下荡然无存。 比如说GAC文件夹（其位置在%windir%\assembly）继承了%windir%的ACL(Access Control List)。这就保证了一般用户不可以任意往GAC中添加程序集(assembly)。由于这个保证，.NET运行时对GAC中的assembly自动赋予Full Trust的权限，而且略过Strong Name Signature Verification. （安装在GAC中的assembly必须被“强名称[strong name]”签名） 可是，如果ACL被人为改变，这里的安全保证就不存在了。  ...[阅读全文]