Web应用程序开发是一个很宽泛的话题。本文仅讨论Web应用开发者应当避免的安全错误。这些错误涉及到任何开发者都不应当忽视的基本安全原则。
开发者应当注意哪些基本的安全原则?应当避免哪些安全错误?为回答这些问题，下面的建议可以回答上述问题。
自以为是：开发自己的安全方法
有些开发者错误地认为自己的算法或认证方法更安全：毕竟黑客从未见识过这种方法，所以他们在破解时会更困难。果真如此吗?
答案是否定的。开发者自己开发认证或登录方法是一个错误，因为他会犯一个或一些黑客能够发现的错误。开发者应当依靠现有的经过完全测试的安全方法，原因在于它们已经被安全社团反复测试过了。因此，这些方法不太可能包含被开发者忽视的重大安全漏洞。有安全专家指出，任何人都可以发明一种他们自己无法破解的加密算法，但要开发一种别人无法破解的方法就困难多了。所以，开发者还是老老实实地用经认证或安全测试的方法吧。
粗心大意：直接使用用户提供的信息访问数据库
在开发应用程序特别是在开发Web应用程序时，许多开发者没有充分地验证从用户那儿接收到的输入数据。这种做法存在安全问题，因为它允许非法的数据进入客户的数据库，并且还有更大的安全隐患。不能对用户的输入进行验证(无论是来自Web还是来自API)会导致SQL注入、跨站脚本攻击、命令劫持、缓冲区溢出，以及被攻击者利用的其它Web应用程序漏洞。
这种错误在Web应用程序的开发中是最常见的。如果没有保护这些程序，用户就有可能利用输入字段将恶意脚本注入到应用程序或者访问数据库的私密数据。当然，多数用户不会有什么恶意企图，但开发者必须用防御的心态和方法来处理用户输入。
开发者不应当轻易相信用户输入，而要在客户端和服务器端进行双重验证。否则，就有可能产生严重的漏洞，如：跨站脚本攻击和SQL注入等。
忽视全局：关注组件而非整个系统
大型的开发项目往往是由多个开发者开发应用程序的不同部分，因而开发人员就容易关注个别组件。当然，如此开发的应用程序，其每个小部分可能很安全，但开发者是否考虑过整体的安全性?
许多安全问题并非产生于组件自身，而是在数据和过程从业务进程的一部分流动到另一部分时才会出问题。开发者一般都承担着一项业务进程的一部分，并且一般不理解业务过程的其它部分。这种认知缺乏会导致不安全的数据传递，从而将数据暴露给各种攻击和威胁，如中间人攻击、数据完整性问题、信息泄露等。
开发者对企业的业务服务有一个系统的观点是至关重要的，只有这样才能理解所有的组件如何协作，以及如何保证合并后的应用程序的安全。#p#
后期修补：在开发后期增加安全功能
有的网站或Web应用在构建时并没有内建安全性。记住：安全并不是以后增加的东西，它应当是整个应用架构的整体功能的一部分。架构是应用开发的最重要的方面，因为它会影响应用程序的所有其它方面，其中就包括安全性。
这种错误的表现(如漏洞和错误配置)可以追溯到开发阶段：开发者最后将安全作为一种额外增加的特性或功能。如有的开发团队有这样的认识：不错，所有的功能都正常运行，现在开始解决安全性问题吧。这种思想会带来应用程序架构上的安全漏洞从而增加风险。在应用程序完全部署后，任何人都很难去解决跨站请求伪造(CSRF)及大量的SQL注入漏洞了。所以，开发者应当在开发和构建Web应用程序的整个生命周期中构建安全性。
放任用户：允许用户生成弱口令
每当有攻击者破解网站或Web应用并暴露用户口令时，一个明确的事实都会随之浮出水面：用户们的安全习惯太差。例如，用户们的最常用的口令是“abcde”或“12345678”之类。Web应用的开发者不应当允许用户创建弱口令。开发者应当要求用户的口令达到足够的长度，确保其易于记忆但又难以猜测(例如，强口令至少应当包含字母、数字及特殊字符，长度达10个字符以上)。最好的口令未必是最复杂的。强迫用户使用过度复杂的口令往往导致用户一些不安全的做法，例如把口令写下来然后再贴到电脑的一个地方。
忽视加密：以纯文本存储用户口令和数据
Web应用开发者最常犯的错误是没有保证用户认证凭据的安全。用户们想当然地认为网站或Web应用会做得很安全，但不幸的是，太多的网站或Web应用没有做好。从总体上说， Web应用或网站在处理和保存口令方式上往往存在漏洞。
问题是：怎样才能正确地保存口令?这里重点谈一个最常见却很不安全的做法：以明文保存口令。许多大公司也有可能犯这样的错误。对企业数据库的任何损害都不应当使用户数据遭受风险，尤其是用户们使用的口令。因而，企业的应用程序应当对用户的口令和其它细节进行加密，然后才将其保存在一个数据库中。
企业应用的开发者必须思考，在黑客取得企业数据库的访问权时，他们能怎样轻易地窃取数据?如果开发者加密数据，就会导致个人和企业信息的大量泄露。
仅仅因为数据库引擎要求用户名和口令并不意味着黑客无法窃取数据文件和获取其中的信息。数据的安全性依赖于数据库引擎的安全性，如果黑客利用了数据库引擎的漏洞，就可以轻松地访问数据库。这正是许多大型游戏和电子商务网站遭受破解的原因，也是包含信用卡数据在内的所有个人信息失窃的原因。#p#
“明修栈道”：通过URL路径名传递变量
还有一种危险但常见的做法：许多开发者把变量放在URL中，这会为黑客打开利用其它应用或数据的大门。这种错误的风险非常巨大。
开发者绝对不能允许用户与之交互的变量成为文件路径的一部分。如果URL中包含下载文件的路径，攻击者就可以修改URL，使其引用另一个文件，从而可能下载包含用户口令的文件。由此，攻击者用一个链接(例如，该链接允许用户下载应用程序的免费版)就达到了利用漏洞的目的。
正所谓开发者“明修”了“栈道”，却被攻击者“暗渡”了“陈仓”。
顾此失彼：仅在客户端执行授权
如今，越来越多的开发者日渐重视客户端。这种趋势会使应用程序更快更强大，但如果开发者不能正确地解决程序的授权问题，就会带来安全隐患。
很多Web应用的开发者依赖客户端的浏览器去完成以前在服务器完成的任务。从安全的观点看，这种做法缺少了许多控制，因为开发者并不了解客户端的种类。客户端甚至有可能并非浏览器。开发者不应当轻易地相信发生在客户端的操作，不应当仅依赖JavaScript或客户端代码来实现关键功能，对于涉及到付款信息和其它敏感信息的功能，尤其要注意。
盲目乐观：认为自己不可能出问题
在开发Web应用程序时，开发人员容易犯的错误是：想当然地认为自己的应用程序不会遭到攻击，或者认为自己不会犯错误。这些想法都会导致安全问题。开发者应当总是设想自己的程序会遭受攻击，而且自己也会犯安全方面的错误。这种思想有助于开发者避免或减少安全风险，从而避免公司遭受损失。
谁都会犯错。如果开发者在黑客找到漏洞之前自己先找到了问题，问题还不算大。在开发者和软件测试者测试和审计Web应用程序时，或在企业投入使用程序之前，开发者或测试者不妨使用著名的开源工具OWASP ZAP来扫描企业的应用程序，查找一些常见的漏洞和错误。
结束语
此文谈到了一些最基本的却是很重要的一些安全错误。希望开发者在此基础上能够进一步发现和总结在Web应用开发过程中的其它问题，构建更坚实的安全保障。
