我知道SQL注入是一个......其他的......
答案 0 :(得分：18)
OWASP.org保留一份清单。从OWASP top ten开始。
答案 1 :(得分：11)
其他人已经这样说了，但是......
基本上所有安全漏洞都来自数据。如果您的程序不处理任何数据，那么它可能是安全的。它也可能毫无用处:)。
这导致了我认为使代码安全的核心概念：
不要相信您的数据。永远。
尽可能消毒一切。您可以依赖平台的安全保证（例如，您不太可能在Java或C＃等托管语言中看到基于字符串的经典缓冲区溢出），但您需要验证应用程序中的所有内容。
答案 2 :(得分：6)
从不存储明文密码。 （我不能告诉你我为我的公司评估了多少商业套餐 - 当我打电话给他们时，我对它采取了冷淡态度。我最喜欢的借口来自CRM供应商：“你的最终用户通常会有企业管理器或查询分析器在他们的桌面上？“）
答案 3 :(得分：3)
Here是十大安全编码实践列表。这是一个好的开始。特别考虑＃8，深度防御。
答案 4 :(得分：2)
在处理之前按摩并过滤所有输入到您的程序。
永远不要在没有过滤和截断的情况下处理输入。
-R
答案 5 :(得分：1)
Buffer overflows是经典的，因为它们通常允许攻击者执行任意代码。
答案 6 :(得分：1)
这是针对网络的东西，但是因为你把它打开了......
JavaScript注入。如果您允许来自任何输出源的任何输入，可以在输入中键入JavaScript，然后在输出时（除非正确编码/解码），它将输出原始javascript。
答案 7 :(得分：1)
你可以认为本书的章节是一个非常好的清单......
答案 8 :(得分：1)
简单的防守计划。对于每个函数/方法/过程/子例程，考虑“预期输入是什么？当输入偏离时，我该怎么办？我怎样才能最容易地确保输入不会偏离该输入。”知道你的意见;知道你的输出。不要过分，但也要明白数据库中的数据可能已被泄露。如果可以某种特定方式约束特定数据集，则选择要播放的数据类型和变量。保持数字的数字。
每当我在程序中看到一个String对象时，我就会问：“如果这个字符串包含Gilbert和Sullivan歌曲的歌词会怎么样？”在函数开头简单的if-else检查和过早返回语句可以防止这类事情在以后造成严重破坏。
答案 9 :(得分：1)
我喜欢用Threat Modeling Tools建模我的系统。这个特定的应用程序允许您为不同的应用程序建模，并根据模型以及一些缓解措施及其风险为您提供有关适用的威胁类型的所有类型的信息。它还让您在整个开发过程中跟踪这些风险。生命周期提出缓解计划。它太酷了。 ：）
答案 10 :(得分：1)
我的建议是：19 Deadly Sins of Software Security
这不仅仅是一个清单，阅读它以了解软件安全的许多方面。有些是广泛的项目，让您了解许多不同安全问题背后的原因。
答案 11 :(得分：0)
发送纯文本密码而不先加密它们永远不是一个好主意。
答案 12 :(得分：0)
避免发送纯文本用户名。
答案 13 :(得分：0)
如何验证用户输入？例如，你期望一个10位数的电话号码，但你得到“800OHNOES！”
答案 14 :(得分：0)
除了关于OWASP的精彩指导外，还可以查看SANS / CWE。