谈谈构造

很奇怪，有如此之多的安全指导文档提示人们注意危险的函数。在 C 和 C++ 中，很少有危险的函数，不过，有一件事是肯定的，有许多危险的开发人员正在使用 C 和 C++。

因此，您可能会问，“Michael，您究竟要讨论什么？”

我得承认，我听腻了一些文档说的所谓某些函数是危险的，您应该使用更安全的类型来代替它们。例如，“不要使用 strcpy，它是危险的。您应该改用 strncpy，因为它是安全的。”没有什么比这更远离实际情况的了。有可能使用 strcpy 的代码是安全的，而调用 strncpy 的却是不安全的代码。

像 strcpy 这样的函数是有潜在 危险的，因为源数据比目标缓冲区大，并且它来自不受信任的源。如果源数据来自一个受信任的源，并且在复制之前经过了有效性测试，则调用 strcpy 就是安全的：

void func(char *p) {
   const int MAX = 10;
   char buf[MAX + 1];
   memset(buf,0,sizeof(buf));

   if (p && strlen(p) <= MAX) 
      strcpy(buf,p);
}

信不信由您，我正好要在某处用到这个例子。有一种常常被忽略的构造可能会导致缓冲区溢出，它不是函数调用。它是这样的：

while () 
   *d++ = *s++;

此处没有函数调用，这是 DCOM 中导致出现 Blaster worm 蠕虫病毒的编码构造。在 Buffer Overrun In RPC Interface Could Allow Code Execution 中，您可以读到更多关于此病毒的修复程序的内容。

该代码如下所示：

HRESULT GetMachineName(WCHAR *pwszPath) {
    WCHAR  wszMachineName[N + 1]) 
    LPWSTR pwszServerName = wszMachineName;
    while (*pwszPath != L'//' )
        *pwszServerName++ = *pwszPath++;   
    ...
}

这里的问题在于，while 循环是以源字符串中的一些字符为界的。它没有为目标缓冲区的大小所限制。换句话说，如果源数据不受信任，就会出现缓冲区溢出。

我编写了一段简单的 Perl 脚本来搜索 C 和 C++ 代码中这些类型的构造。请注意，这段脚本标记的每个实例并不是一个缺陷，您需要确定是否源数据是受信任的。

use strict;
use File::Find;

my $RECURSE = 1;

###################################################
foreach(@ARGV) {
  next if /^-./;
  if ($RECURSE) {
      finddepth(/&processFile,
很奇怪，有如此之多的安全指导文档提示人们注意危险的函数。在 C 和 C++ 中，很少有危险的函数，不过，有一件事是肯定的，有许多危险的开发人员正在使用 C 和 C++。
因此，您可能会问，“Michael，您究竟要讨论什么？” 
我得承认，我听腻了一些文档说的所谓某些函数是危险的，您应该使用更安全的类型来代替它们。例如，“不要使用 strcpy，它是危险的。您应该改用 strncpy，因为它是安全的。”没有什么比这更远离实际情况的了。有可能使用 strcpy 的代码是安全的，而调用 strncpy 的却是不安全的代码。 
像 strcpy 这样的函数是有潜在 危险的，因为源数据比目标缓冲区大，并且它来自不受信任的源。如果源数据来自一个受信任的源，并且在复制之前经过了有效性测试，则调用 strcpy 就是安全的：
void func(char *p) {
   const int MAX = 10;
   char buf[MAX + 1];
   memset(buf,0,sizeof(buf));

   if (p && strlen(p) <= MAX) 
      strcpy(buf,p);
}

信不信由您，我正好要在某处用到这个例子。有一种常常被忽略的构造可能会导致缓冲区溢出，它不是函数调用。它是这样的：
while () 
   *d++ = *s++;

此处没有函数调用，这是 DCOM 中导致出现 Blaster worm 蠕虫病毒的编码构造。在 Buffer Overrun In RPC Interface Could Allow Code Execution 中，您可以读到更多关于此病毒的修复程序的内容。 
该代码如下所示：
HRESULT GetMachineName(WCHAR *pwszPath) {
    WCHAR  wszMachineName[N + 1]) 
    LPWSTR pwszServerName = wszMachineName;
    while (*pwszPath != L'//' )
        *pwszServerName++ = *pwszPath++;   
    ...
}

这里的问题在于，while 循环是以源字符串中的一些字符为界的。它没有为目标缓冲区的大小所限制。换句话说，如果源数据不受信任，就会出现缓冲区溢出。
我编写了一段简单的 Perl 脚本来搜索 C 和 C++ 代码中这些类型的构造。请注意，这段脚本标记的每个实例并不是一个缺陷，您需要确定是否源数据是受信任的。
___FCKpd___3
注这段脚本只查找 *p++ 构造，而不查找 *++p 构造。 
假定您发现了一个缺陷，使代码更安全的一种方法是限制被复制的数据不大于目标缓冲区：
HRESULT GetMachineName(WCHAR *pwszPath) {
    WCHAR  wszMachineName[N + 1]) 
    LPWSTR pwszServerName = wszMachineName;

    size_t cbMachineName = N;
    while (*pwszPath != L'//' && --cbMachineName)
        *pwszServerName++ = *pwszPath++;   
    ...
}

最后，对不为目标缓冲区的大小所限制的任何内存复制函数或构造都应该进行严格检查。
 
);
  } else {
      find(/&processFile,
很奇怪，有如此之多的安全指导文档提示人们注意危险的函数。在 C 和 C++ 中，很少有危险的函数，不过，有一件事是肯定的，有许多危险的开发人员正在使用 C 和 C++。
因此，您可能会问，“Michael，您究竟要讨论什么？” 
我得承认，我听腻了一些文档说的所谓某些函数是危险的，您应该使用更安全的类型来代替它们。例如，“不要使用 strcpy，它是危险的。您应该改用 strncpy，因为它是安全的。”没有什么比这更远离实际情况的了。有可能使用 strcpy 的代码是安全的，而调用 strncpy 的却是不安全的代码。 
像 strcpy 这样的函数是有潜在 危险的，因为源数据比目标缓冲区大，并且它来自不受信任的源。如果源数据来自一个受信任的源，并且在复制之前经过了有效性测试，则调用 strcpy 就是安全的：
void func(char *p) {
   const int MAX = 10;
   char buf[MAX + 1];
   memset(buf,0,sizeof(buf));

   if (p && strlen(p) <= MAX) 
      strcpy(buf,p);
}

信不信由您，我正好要在某处用到这个例子。有一种常常被忽略的构造可能会导致缓冲区溢出，它不是函数调用。它是这样的：
while () 
   *d++ = *s++;

此处没有函数调用，这是 DCOM 中导致出现 Blaster worm 蠕虫病毒的编码构造。在 Buffer Overrun In RPC Interface Could Allow Code Execution 中，您可以读到更多关于此病毒的修复程序的内容。 
该代码如下所示：
HRESULT GetMachineName(WCHAR *pwszPath) {
    WCHAR  wszMachineName[N + 1]) 
    LPWSTR pwszServerName = wszMachineName;
    while (*pwszPath != L'//' )
        *pwszServerName++ = *pwszPath++;   
    ...
}

这里的问题在于，while 循环是以源字符串中的一些字符为界的。它没有为目标缓冲区的大小所限制。换句话说，如果源数据不受信任，就会出现缓冲区溢出。
我编写了一段简单的 Perl 脚本来搜索 C 和 C++ 代码中这些类型的构造。请注意，这段脚本标记的每个实例并不是一个缺陷，您需要确定是否源数据是受信任的。
___FCKpd___3
注这段脚本只查找 *p++ 构造，而不查找 *++p 构造。 
假定您发现了一个缺陷，使代码更安全的一种方法是限制被复制的数据不大于目标缓冲区：
___FCKpd___4
最后，对不为目标缓冲区的大小所限制的任何内存复制函数或构造都应该进行严格检查。
 
);
  }
}
###################################################
sub processFile {
  my $FILE;
  my $filename = 
很奇怪，有如此之多的安全指导文档提示人们注意危险的函数。在 C 和 C++ 中，很少有危险的函数，不过，有一件事是肯定的，有许多危险的开发人员正在使用 C 和 C++。
因此，您可能会问，“Michael，您究竟要讨论什么？” 
我得承认，我听腻了一些文档说的所谓某些函数是危险的，您应该使用更安全的类型来代替它们。例如，“不要使用 strcpy，它是危险的。您应该改用 strncpy，因为它是安全的。”没有什么比这更远离实际情况的了。有可能使用 strcpy 的代码是安全的，而调用 strncpy 的却是不安全的代码。 
像 strcpy 这样的函数是有潜在 危险的，因为源数据比目标缓冲区大，并且它来自不受信任的源。如果源数据来自一个受信任的源，并且在复制之前经过了有效性测试，则调用 strcpy 就是安全的：
void func(char *p) {
   const int MAX = 10;
   char buf[MAX + 1];
   memset(buf,0,sizeof(buf));

   if (p && strlen(p) <= MAX) 
      strcpy(buf,p);
}

信不信由您，我正好要在某处用到这个例子。有一种常常被忽略的构造可能会导致缓冲区溢出，它不是函数调用。它是这样的：
while () 
   *d++ = *s++;

此处没有函数调用，这是 DCOM 中导致出现 Blaster worm 蠕虫病毒的编码构造。在 Buffer Overrun In RPC Interface Could Allow Code Execution 中，您可以读到更多关于此病毒的修复程序的内容。 
该代码如下所示：
HRESULT GetMachineName(WCHAR *pwszPath) {
    WCHAR  wszMachineName[N + 1]) 
    LPWSTR pwszServerName = wszMachineName;
    while (*pwszPath != L'//' )
        *pwszServerName++ = *pwszPath++;   
    ...
}

这里的问题在于，while 循环是以源字符串中的一些字符为界的。它没有为目标缓冲区的大小所限制。换句话说，如果源数据不受信任，就会出现缓冲区溢出。
我编写了一段简单的 Perl 脚本来搜索 C 和 C++ 代码中这些类型的构造。请注意，这段脚本标记的每个实例并不是一个缺陷，您需要确定是否源数据是受信任的。
___FCKpd___3
注这段脚本只查找 *p++ 构造，而不查找 *++p 构造。 
假定您发现了一个缺陷，使代码更安全的一种方法是限制被复制的数据不大于目标缓冲区：
___FCKpd___4
最后，对不为目标缓冲区的大小所限制的任何内存复制函数或构造都应该进行严格检查。
 
;
  
  if (!$RECURSE && ($File::Find::topdir ne $File::Find::dir)) {
    $File::Find::prune = 1;
    return;
  } 
  
  # Only accept C/C++ and header extensions
  return if (!(//.[ch](?:pp|xx)?$/i));
     
  warn "$!/n" unless open FILE, "<" . $filename;
  
  # reset line number
  $. = 0;

  while () {
    chomp;
    s/^/s+//;
    s//s+$//;

  if (//*/w+/+/+/s{0,}=/s{0,}/*/w+/+/+) {
   print $filename . " " . 
很奇怪，有如此之多的安全指导文档提示人们注意危险的函数。在 C 和 C++ 中，很少有危险的函数，不过，有一件事是肯定的，有许多危险的开发人员正在使用 C 和 C++。
因此，您可能会问，“Michael，您究竟要讨论什么？” 
我得承认，我听腻了一些文档说的所谓某些函数是危险的，您应该使用更安全的类型来代替它们。例如，“不要使用 strcpy，它是危险的。您应该改用 strncpy，因为它是安全的。”没有什么比这更远离实际情况的了。有可能使用 strcpy 的代码是安全的，而调用 strncpy 的却是不安全的代码。 
像 strcpy 这样的函数是有潜在 危险的，因为源数据比目标缓冲区大，并且它来自不受信任的源。如果源数据来自一个受信任的源，并且在复制之前经过了有效性测试，则调用 strcpy 就是安全的：
void func(char *p) {
   const int MAX = 10;
   char buf[MAX + 1];
   memset(buf,0,sizeof(buf));

   if (p && strlen(p) <= MAX) 
      strcpy(buf,p);
}

信不信由您，我正好要在某处用到这个例子。有一种常常被忽略的构造可能会导致缓冲区溢出，它不是函数调用。它是这样的：
while () 
   *d++ = *s++;

此处没有函数调用，这是 DCOM 中导致出现 Blaster worm 蠕虫病毒的编码构造。在 Buffer Overrun In RPC Interface Could Allow Code Execution 中，您可以读到更多关于此病毒的修复程序的内容。 
该代码如下所示：
HRESULT GetMachineName(WCHAR *pwszPath) {
    WCHAR  wszMachineName[N + 1]) 
    LPWSTR pwszServerName = wszMachineName;
    while (*pwszPath != L'//' )
        *pwszServerName++ = *pwszPath++;   
    ...
}

这里的问题在于，while 循环是以源字符串中的一些字符为界的。它没有为目标缓冲区的大小所限制。换句话说，如果源数据不受信任，就会出现缓冲区溢出。
我编写了一段简单的 Perl 脚本来搜索 C 和 C++ 代码中这些类型的构造。请注意，这段脚本标记的每个实例并不是一个缺陷，您需要确定是否源数据是受信任的。
___FCKpd___3
注这段脚本只查找 *p++ 构造，而不查找 *++p 构造。 
假定您发现了一个缺陷，使代码更安全的一种方法是限制被复制的数据不大于目标缓冲区：
___FCKpd___4
最后，对不为目标缓冲区的大小所限制的任何内存复制函数或构造都应该进行严格检查。
 
 . "/n";
  }
}

注这段脚本只查找 *p++ 构造，而不查找 *++p 构造。

假定您发现了一个缺陷，使代码更安全的一种方法是限制被复制的数据不大于目标缓冲区：

___FCKpd___4

最后，对不为目标缓冲区的大小所限制的任何内存复制函数或构造都应该进行严格检查。