我最近被要求写一篇关于网络应用安全错误的文章。这是非常容易的；以下就是我经常看见的一些错误：
- 盲目地相信在URL中从cookies和参数中返回的信息。
- 不检查从屏幕输入的内容
- 提前确认帐号
- 不限制用户的行为
- 错误创建网络文件夹的访问权限
- 获取敏感的信息
- 安装网络服务器的范例（如同IIS默认安装一样）
- 忘记修改数据库后台的默认密码
- 没有下载安全补丁
- 开放网络管理的端口
以下是对于前五个常见错误的简单描述：
相信但是要确
“相信但是要确认”这句话是我所尊敬的一个老板的座佑铭。对于网络开发者和程序员而言，这个座佑铭应该被很好地采纳。当cookies和URL参数给开发者们带来了很大好处的时候，传送过来的数据应该需要经常验证。
许多和网络有关的商业人士很难接受使用这个观点来解释“购物卡弱点”，所谓的“购物卡弱点”就是源于一些人通过修改购物卡上的金额而带来的问题。购物卡无非就是一个基于文本的cookie。通过检查，服务器可以计算出在cookie上的金额总数。假设――如果客户对价格有着完全的控制能力。可以相信，如果服务器没有验证数据的能力，商家们就会经历一次强烈的打击。
最好的检查方法就是清除所有的cookies，运行应用程序，查看写到磁盘上的cookies。我经常查看我的cookies，确保我的敏感信息并没有存放在其中，所谓的敏感信息如用户名和密码。
命令等同于控制
我曾经看过一个系统，它通过URL参数传送程序控制。当我在查看源代码的时候，我注意到了一个很平常的线程。系统级的命令被嵌入到URL中，如下：“action='do something.'”
在测试中，我创建了一对用户的URL，看看系统将如何处理。结果，我就可以通过我传递的命令（"action='cat xxx >> /etc/passwd.'"）来控制系统，当然，这是系统没有料到的。
如果你的参数是通过URL来传递的，将它们分裂到无效的内容中去。设置一些参数限制，这样如果有一个预料之外的值传递过来，你的应用程序就可以很好的处理它。这也使测试变得非常的容易――调整URL的地址栏，看看应用程序将如何处理。
请务必检查
我经常看到有的区域的输入数据没有经过验证。对于缓冲溢出和SQL攻击者来说，这是一个绝好的机会。在测试中，我打开记事本，创建一个超过500个字符的字符串，然后剪切并将它们粘贴到密码行区域。如果系统不限制输入的字符串，那么大多的系统都会死机或崩溃。
接下来我要通过将嵌入的正确条件（如，"OR 'x'='x'"）填充到密码输入区中来测试确认规则。很多的系统都会允许未授权用户访问，由于SQL的声明的创建方式的缘故，使用一个“OR
TRUE”条件就可以愚弄系统，使系统允许非授权用户进入。这里是一个可以操纵的SQL声明的例子
Select userid, passwd from USERS where userid = :uid_entered and passwd = pwd_entered
假设用户在用户名中输入admin，而在密码域中输入"OR 'x'='x'"，SQL声明就会将这个用户名和密码解释成"select userid, passwd
from USERS where
userid=admin and
passwd=password OR 'x'='x'”。这显然不是开发者所希望的。
