: 敏感信息的明文传输 If your software sends sensitive information across a network, such
as private data or authentication credentials, that information
crosses many different nodes in transit to its final destination.
Attackers can sniff this data right off the wire, and it doesn't
require a lot of effort. All they need to do is control one node
along the path to the final destination, control any node within
the same networks of those transit nodes, or plug into an available
interface. Trying to obfuscate traffic using schemes like Base64
and URL encoding doesn't offer any protection, either; those
encodings are for normalizing communications, not scrambling data
to make it unreadable.
如果你所使用的软件通过网络传输诸如隐私数据、身份证明之类的敏感信息，而通常这些信息在送到最终目的地之前会经过很多不同节点，攻击者可以不费吹灰之力在传输线路上进行侦听。他们要做的不过是控制路径上的一个节点甚至只是与传输节点在同一网络内的任一节点，或者是在可用接口上插入侦听设备。使用base64编码或者URL编码都不能提供任何保护。因为这些编码是用于一般通信，而不是使数据不可读。
: 伪造跨站请求 (CSRF) You know better than to accept a package from a stranger at the
airport. It could contain dangerous contents. Plus, if anything
goes wrong, then it's going to look as if you did it, because
you're the one with the package when you board the plane.
Cross-site request forgery is like that strange package, except the
attacker tricks a user into activating a request that goes to your
site. Thanks to scripting and the way the web works in general, the
user might not even be aware that the request is being sent. But
once the request gets to your server, it looks as if it came from
the user, not the attacker. This might not seem like a big deal,
but the attacker has essentially masqueraded as a legitimate user
and gained all the potential access that the user has. This is
especially handy when the user has administrator privileges,
resulting in a complete compromise of your application's
functionality. When combined with XSS, the result can be extensive
and devastating. If you've heard about XSS worms that stampede
through very large web sites in a matter of minutes, there's
usually CSRF feeding them.
由于脚本语言和web整体的工作方式，一旦请求到达，从服务器看来，请求是客户而非攻击者发出的。这看起来不是一件什么大不了的事，但是攻击者基本上是通过伪装成合法用户然后取得用户的所有权限。尤其是当该用户拥有管理者权限时，会导致应用功能被完全损害。当与XSS结合起来使用时，它的破坏结果会更广泛，更具毁灭性。如果你听说过XSS蠕虫在几分钟之内使大批的网站瘫痪，这其中通常是CSRF在提供原料。
:竞争状态 Traffic accidents occur when two vehicles attempt to use the exact
same resource at almost exactly the same time, i.e., the same part
of the road. Race conditions in your software aren't much
different, except an attacker is consciously looking to exploit
them to cause chaos or get your application to cough up something
valuable. In many cases, a race condition can involve multiple
processes in which the attacker has full control over one process.
Even when the race condition occurs between multiple threads, the
attacker may be able to influence when some of those threads
execute. Your only comfort with race conditions is that data
corruption and denial of service are the norm. Reliable techniques
for code execution haven't been developed - yet. At least not for
some kinds of race conditions. Small comfort indeed. The impact
can be local or global, depending on what the race condition
affects - such as state variables or security logic - and whether
it occurs within multiple threads, processes, or systems.
软件中的竞争状态与交通中的竞争差不多，区别就是有攻击者不断地利用它来制造混乱或者获取有价值的信息。大多数情况下，一个竞争状态涉及到很多进程，而攻击者对其中一个进程完全掌控。甚至当竞争状态发生在多个线程之间时，攻击者也可以在其中一些线程执行时发挥影响。唯一的安慰是数据损坏和服务拒绝都是标准的。让代码可靠地执行的技术目前还没有开发出来。影响可能是局部的或整体的，这取决于造成竞争状态的因素，比如声明变量或安全逻辑以及是多线程、多进程还是多系统。
: 错误消息信息泄露 If you use chatty error messages, then they could disclose secrets
to any attacker who dares to misuse your software. The secrets
could cover a wide range of valuable data, including personally
identifiable information (PII), authentication credentials, and
server configuration. Sometimes, they might seem like harmless
secrets that are convenient for your users and admins, such as the
full installation path of your software. Even these little secrets
can greatly simplify a more concerted attack that yields much
bigger rewards, which is done in real-world attacks all the time.
This is a concern whether you send temporary error messages back to
the user or if you permanently record them in a log file.
使用口语化的错误消息会给那些想滥用你的软件的攻击者泄露秘密。这些秘密涉及大量有价值的数据，包括私人认证信息、认证凭证和服务器配置信息。有时这些数据看起来是方便用户和管理者的无害信息，比如软件安装完全路径等。但就是这些小秘密可以极大地使一个更大的攻击变得简单，这在现实世界的攻击中一直发生。将错误消息临时返回用户还是永久记录在文件里是需要考量的。
: Failure to Constrain Operations within the Bounds of a Memory Buffer 限制操作在内存缓冲区界限中失败 Buffer overflows are Mother Nature's little reminder of that law of
physics that says: if you try to put more stuff into a container
than it can hold, you're going to make a mess. The scourge of C
applications for decades, buffer overflows have been remarkably
resistant to elimination. One reason is that they aren't just
about using strcpy() incorrectly, or improperly checking the length
of your inputs. Attack and detection techniques continue to
improve, and today's buffer overflow variants aren't always obvious
at first or even second glance.
You may think that you're completely immune to buffer overflows
because you write your code in higher-level languages instead of C.
But what is your favorite "safe" language's interpreter written in?
What about the native code you call? What languages are the
operating system API's written in? How about the software that
runs Internet infrastructure? Thought so.
