Web应用开发人员最易犯的九个安全错误

Web应用程序开发是一个很宽泛的话题。本文仅讨论Web应用开发者应当避免的安全错误。这些错误涉及到任何开发者都不应当忽视的基本安全原则。

开发者应当注意哪些基本的安全原则?应当避免哪些安全错误?为回答这些问题,下面的建议可以回答上述问题。

自以为是:开发自己的安全方法

有些开发者错误地认为自己的算法或认证方法更安全:毕竟黑客从未见识过这种方法,所以他们在破解时会更困难。果真如此吗?

答案是否定的。开发者自己开发认证或登录方法是一个错误,因为他会犯一个或一些黑客能够发现的错误。开发者应当依靠现有的经过完全测试的安全方法,原因在于它们已经被安全社团反复测试过了。因此,这些方法不太可能包含被开发者忽视的重大安全漏洞。有安全专家指出,任何人都可以发明一种他们自己无法破解的加密算法,但要开发一种别人无法破解的方法就困难多了。所以,开发者还是老老实实地用经认证或安全测试的方法吧。

粗心大意:直接使用用户提供的信息访问数据库

在开发应用程序特别是在开发Web应用程序时,许多开发者没有充分地验证从用户那儿接收到的输入数据。这种做法存在安全问题,因为它允许非法的数据进入客户的数据库,并且还有更大的安全隐患。不能对用户的输入进行验证(无论是来自Web还是来自API)会导致SQL注入、跨站脚本攻击、命令劫持、缓冲区溢出,以及被攻击者利用的其它Web应用程序漏洞。

这种错误在Web应用程序的开发中是最常见的。如果没有保护这些程序,用户就有可能利用输入字段将恶意脚本注入到应用程序或者访问数据库的私密数据。当然,多数用户不会有什么恶意企图,但开发者必须用防御的心态和方法来处理用户输入。

开发者不应当轻易相信用户输入,而要在客户端和服务器端进行双重验证。否则,就有可能产生严重的漏洞,如:跨站脚本攻击和SQL注入等。

忽视全局:关注组件而非整个系统

大型的开发项目往往是由多个开发者开发应用程序的不同部分,因而开发人员就容易关注个别组件。当然,如此开发的应用程序,其每个小部分可能很安全,但开发者是否考虑过整体的安全性?

许多安全问题并非产生于组件自身,而是在数据和过程从业务进程的一部分流动到另一部分时才会出问题。开发者一般都承担着一项业务进程的一部分,并且一般不理解业务过程的其它部分。这种认知缺乏会导致不安全的数据传递,从而将数据暴露给各种攻击和威胁,如中间人攻击、数据完整性问题、信息泄露等。

开发者对企业的业务服务有一个系统的观点是至关重要的,只有这样才能理解所有的组件如何协作,以及如何保证合并后的应用程序的安全。

后期修补:在开发后期增加安全功能

有的网站或Web应用在构建时并没有内建安全性。记住:安全并不是以后增加的东西,它应当是整个应用架构的整体功能的一部分。架构是应用开发的最重要的方面,因为它会影响应用程序的所有其它方面,其中就包括安全性。

这种错误的表现(如漏洞和错误配置)可以追溯到开发阶段:开发者最后将安全作为一种额外增加的特性或功能。如有的开发团队有这样的认识:不错,所有的功能都正常运行,现在开始解决安全性问题吧。这种思想会带来应用程序架构上的安全漏洞从而增加风险。在应用程序完全部署后,任何人都很难去解决跨站请求伪造(CSRF)及大量的SQL注入漏洞了。所以,开发者应当在开发和构建Web应用程序的整个生命周期中构建安全性。

放任用户:允许用户生成弱口令

每当有攻击者破解网站或Web应用并暴露用户口令时,一个明确的事实都会随之浮出水面:用户们的安全习惯太差。例如,用户们的最常用的口令是“abcde”或“12345678”之类。Web应用的开发者不应当允许用户创建弱口令。开发者应当要求用户的口令达到足够的长度,确保其易于记忆但又难以猜测(例如,强口令至少应当包含字母、数字及特殊字符,长度达10个字符以上)。最好的口令未必是最复杂的。强迫用户使用过度复杂的口令往往导致用户一些不安全的做法,例如把口令写下来然后再贴到电脑的一个地方。

忽视加密:以纯文本存储用户口令和数据

Web应用开发者最常犯的错误是没有保证用户认证凭据的安全。用户们想当然地认为网站或Web应用会做得很安全,但不幸的是,太多的网站或Web应用没有做好。从总体上说, Web应用或网站在处理和保存口令方式上往往存在漏洞。

问题是:怎样才能正确地保存口令?这里重点谈一个最常见却很不安全的做法:以明文保存口令。许多大公司也有可能犯这样的错误。对企业数据库的任何损害都不应当使用户数据遭受风险,尤其是用户们使用的口令。因而,企业的应用程序应当对用户的口令和其它细节进行加密,然后才将其保存在一个数据库中。

企业应用的开发者必须思考,在黑客取得企业数据库的访问权时,他们能怎样轻易地窃取数据?如果开发者加密数据,就会导致个人和企业信息的大量泄露。

仅仅因为数据库引擎要求用户名和口令并不意味着黑客无法窃取数据文件和获取其中的信息。数据的安全性依赖于数据库引擎的安全性,如果黑客利用了数据库引擎的漏洞,就可以轻松地访问数据库。这正是许多大型游戏和电子商务网站遭受破解的原因,也是包含信用卡数据在内的所有个人信息失窃的原因。

“明修栈道”:通过URL路径名传递变量

还有一种危险但常见的做法:许多开发者把变量放在URL中,这会为黑客打开利用其它应用或数据的大门。这种错误的风险非常巨大。

开发者绝对不能允许用户与之交互的变量成为文件路径的一部分。如果URL中包含下载文件的路径,攻击者就可以修改URL,使其引用另一个文件,从而可能下载包含用户口令的文件。由此,攻击者用一个链接(例如,该链接允许用户下载应用程序的免费版)就达到了利用漏洞的目的。

正所谓开发者“明修”了“栈道”,却被攻击者“暗渡”了“陈仓”。

顾此失彼:仅在客户端执行授权

如今,越来越多的开发者日渐重视客户端。这种趋势会使应用程序更快更强大,但如果开发者不能正确地解决程序的授权问题,就会带来安全隐患。

很多Web应用的开发者依赖客户端的浏览器去完成以前在服务器完成的任务。从安全的观点看,这种做法缺少了许多控制,因为开发者并不了解客户端的种类。客户端甚至有可能并非浏览器。开发者不应当轻易地相信发生在客户端的操作,不应当仅依赖JavaScript或客户端代码来实现关键功能,对于涉及到付款信息和其它敏感信息的功能,尤其要注意。

盲目乐观:认为自己不可能出问题

在开发Web应用程序时,开发人员容易犯的错误是:想当然地认为自己的应用程序不会遭到攻击,或者认为自己不会犯错误。这些想法都会导致安全问题。开发者应当总是设想自己的程序会遭受攻击,而且自己也会犯安全方面的错误。这种思想有助于开发者避免或减少安全风险,从而避免公司遭受损失。

谁都会犯错。如果开发者在黑客找到漏洞之前自己先找到了问题,问题还不算大。在开发者和软件测试者测试和审计Web应用程序时,或在企业投入使用程序之前,开发者或测试者不妨使用著名的开源工具OWASP ZAP来扫描企业的应用程序,查找一些常见的漏洞和错误。

作者:佚名


来源:51CTO

时间: 2022-12-18

Web应用开发人员最易犯的九个安全错误的相关文章

开发者必看:最易犯的Top 10加密错误,你中枪了吗?

本文讲的是开发者必看:最易犯的Top 10加密错误,你中枪了吗?, 在对小型初创企业和大型银行和电信公司进行了数百次安全代码审查,并阅读了数百个在安全社区发布的堆栈溢出的帖子之后,我们列出了开发人员最容易犯的十大加密错误. 不幸的现实是,错误的加密方式随处可见.正确加密的次数远远低于我们发现的错误加密的次数,许多问题是由于复杂的加密API在默认的情况下是不安全的.另一个原因是,我们需要训练有素的专家进行手动代码分析才能发现问题.根据我的经验,流行的静态分析工具在寻找加密问题方面并不出色,此外,黑

C#开发人员应该知道的13件事情

本文讲述了C#开发人员应该了解到的13件事情,希望对C#开发人员有所帮助. 1. 开发过程 开发过程是错误和缺陷开始的地方.使用工具可以帮助你在发布之后,解决掉一些问题. 编码标准 遵照编码标准可以编写出更多可维护的代码,特别是在由多个开发人员或团队编写和维护的代码库中.例如FxCop,StyleCop和ReSharper等,就是常用的实施编码标准的工具. 开发人员:在压缩代码之前,请使用工具仔细检查是否违反了标准,并且对结果进行分析.使用工具发现的代码路径问题,不比你预期的少. 代码审查 代码

使用decj简化Web前端开发(一)

声明式Javascript动态加载和浏览器事件绑定 引言 Web前端开发中,开发人员经常需要处理一些常规问题,如: 在页面中引用多个相互存在依赖关系的Javascript文件 在页面中引用CSS文件 浏览器事件绑定 表单的数据填充.数据打包提交.数据校验和格式化 页面初始化逻辑 采用传统的命令式编程范式来处理这些问题时,开发人员不得不反复地通过编写代码调用相关API来完成这些常规任务.事实上,开发人员的主要精力应该集中在业务逻辑实现上,而非在这些常规任务上过多消耗时间.声明式编程范式可以帮助开发

为什么ASP.NET开发人员要了解Azure行动服务?

Azure 行动服务为行动应用程序开发人员提供了以云平台为基础的后端解决方案,现在这项服务除了可以使用 JavaScript (Node.js) 来客制化后端平台之外,也支持了使用 ASP.NET Web API 的技术来客制后端平台的运算逻辑,所以对于要开发给行动装置应用程序 API 的 ASP.NET 开发人员来说,Azure 行动服务是相当有吸引力的: 适用于所有行动平台的完整后端平台以及 SDK 解决方案.透过 Azure 行动服务,您可以迅速地为您的 iOS, Android, Win

《HTML5和JavaScript Web应用开发》——2.2 决定支持

2.2 决定支持 基于目前移动领域的局面,我们必须支持多种平台和浏览器.当你使用HTML5的核心API时,你就被绑定到目标设备所支持的特性上,所以理解当今的移动浏览器及其发展方向至关重要. 编写跨越所有平台和浏览器的Web应用是一个很大的工程.以前,Web应用开发人员不关心桌面电脑是否连接了摄像头或者加速计,Web应用和操作系统及桌面硬件的能力也没有关系.现在,移动Web为我们构建的应用增加了另一方面的支持,浏览器和设备的分裂也令人兴奋,我们现在必须创建兼容不同浏览器.平台和设备的应用.例如,A

Web前端开发中的MCRV模式

摘要 针对前端开发中基于ajax的复杂页面开发所面临的代码规模大,难以组织和维护,代码复用性.扩展性和适应性差等问题,本文尝试以MVC思想为基础,结合Web前端开发中"内容-结构-表现-行为"相分离的开发标准,提出一种将Web页面代码分为视图(View,页面静态部分,包括内容.结构.表现).模型(Model,负责数据缓存.数据校验与本地逻辑处理.发起ajax请求).控制器(Controller,负责用户和系统事件响应.模型和渲染器调度).渲染器(Renderer,对视图的渲染,控制器与

看似简单!解读C#程序员最易犯的7大错误

编程时犯错是必然的,即使是一个很小的错误也可能会导致昂贵的代价,聪明的人善于从错误中汲取教训,尽量不再重复犯错,在这篇文章中,我将重点介绍C#开发人员最容易犯的7个错误. 格式化字符串 在C#编程中,字符串类型是最容易处理出错的地方,其代价往往也很昂贵,在.NET Framework中,字符串是一个不可变的类型,当一个字符串被修改后,总是创建一个新的副本,不会改变源字符串,大多数开发人员总是喜欢使用下面这样的方法格式化字符串: string updateQueryText = "UPDATE E

如何做到测试人员心中好的开发人员

作者在这篇文章中, 列出了七个项目, 指出怎样的开发人员, 才是测试人员心中的好的RD. 1. 不要考验你的测试人员 即使你和测试人员的关系不好, 也不要故意制造bug, 来考验你测试人员的程度. 2. 自己做自己的验收测试 通常开发人员知道要去进行单元测试, 但是往往忽略了GUI测试以及usability testing. 建议开发人员每次要记得去进行小规模的验收测试, 来及早发现一些usability的issues 3. 不要一直犯同样的错误 测试人员最讨厌的是开发人员老是一直犯样的错误.

一起谈.NET技术,看似简单!解读C#程序员最易犯的7大错误

编程时犯错是必然的,即使是一个很小的错误也可能会导致昂贵的代价,聪明的人善于从错误中汲取教训,尽量不再重复犯错,在这篇文章中,我将重点介绍C#开发人员最容易犯的7个错误. 格式化字符串 在C#编程中,字符串类型是最容易处理出错的地方,其代价往往也很昂贵,在.NET Framework中,字符串是一个不可变的类型,当一个字符串被修改后,总是创建一个新的副本,不会改变源字符串,大多数开发人员总是喜欢使用下面这样的方法格式化字符串: string updateQueryText = "UPDATE E