《Web安全开发指南》试读:1.1  明确Web应用威胁

对于任何公司来说,数据都是最重要的资源。可以说,除了数据,公司的任何部分都可以被取代。当数据被篡改、破坏、窃取或删除时,公司会遭受严重的损失。事实上,如果某公司的数据发生了足够多的错误,那么该公司很可能会因此而不复存在。所以,谈到安全的时候,焦点不在于黑客、应用程序、网络或其他任何别人可能告诉过你的东西,而在于数据。因此,这本书是关于数据安全的,其中包括了许多其他话题,但当阅读这些话题时,你需要明白你真正要保护的是什么。 不幸的是,数据孤独地呆在黑暗中时并没有多少用处。无论你的服务器有多高档,或者你的数据库有多强大的存储能力,直到你利用数据时,数据才会有价值。我们需要使用应用程序来管理数据,这就是本章要讨论应用环境的原因。 然而,在进一步阅读之前,很重要的一件事是,要先明确应用和数据是如何交互的,因为如果对此没有了解,那本章余下的内容对你不会有太大用处。一个应用程序无论多么复杂,它只会对数据进行四种操作。你可以用CRUD 这个缩写来指代这四种操作。 创建(Create) 读取(Read) 更新(Update) 删除(Delete) 接下来会讨论与Web 环境有关的数据、应用程序和CRUD。你会发现数据安全是如何影响Web 开发中这三个方面的。记住,虽然数据是重点,但所需的CRUD 任务是由应用程序来执行的。保证数据安全意味着要理解应用程序的运行环境,进而理解应用程序管理的数据所面临的威胁。 1.1  明确Web应用威胁 你可以在互联网上找到Web 应用威胁的清单。其中有一些是全面而不带偏见的,有一些论述了作者认为的最重要的威胁,还有一些会告诉你哪些是最常见的威胁,此外你还可以找到各种各样的其他清单。所有这些清单的问题在于,它们的作者并不了解你的应用程序。比如,SQL 注入攻击只在应用程序以某种方式使用SQL 时才会成功,但你的应用程序可能并未采用这种方式。 很明显,你需要知道在哪些场景下应该检查什么,而这些清单确实是个好的起点。然而, 你需要根据自己的应用程序来考虑这些清单的内容。此外,不要只依赖一份清单,尽量参考多份,这样你能对可能的威胁有更好的认识。带着这样的需求,下面列出了现在最常见的一些Web 应用威胁。 缓冲区溢出 攻击者试图将足够多的数据发送到输入缓冲区中,以便让应用程序或输出缓冲区溢出, 从而导致在缓冲区外的内存数据被损坏。某些形式的缓冲区溢出能使攻击者执行看起来不可能完成的任务,因为受影响的内存中保存着可执行的代码。解决这种问题最好的办法是,对应用程序处理的所有数据都执行边界和大小检查,无论是输入还是输出。你可以在网页http://www.upenn.edu/computing/security/swat/SWAT_Top_Ten_A5.phphttps://www.owasp.org/index.php/Buffer_Overflows 上看到更多关于Web 应用程序缓冲区溢出的内容。 代码注入 一个实体以中间人攻击(man-in-the-middle-attack)的形式将代码添加到服务器和客户端(如浏览器)之间的数据流中。被攻击方经常会将这种注入代码视为原始页面的一部分,但它可能包含任何东西。当然,被攻击方甚至看不到这些注入的代码。它可能潜伏在后台,随时准备给应用程序制造各种各样的问题。解决该攻击的一种好方法是确保使用了加密的数据流、HTTPS 协议和代码验证(如果可能)。提供客户端反馈机制也是一个好主意。 代码注入往往发生得比你想象的频繁。在某些情况下,代码注入甚至不算攻击的一部分,虽然也可能是。最近有一篇文章(http://www.infoworld.com/article/ 2925839/net-neutrality/code-injection-new-low-isps.html)讨论了互联网服务提供商(Internet service provider,ISP)如何将JavaScript 代码注入到数据流中以便在页面上放置悬浮广告。而为了确定要投放哪一类广告,ISP 还会监听数据传输。 跨站脚本(cross-site scripting,XSS) 攻击者将JavaScript 脚本或其他可执行代码注入到应用程序的输出流中。接收者会将你的应用程序看作感染源,但其实它并不是。大多数时候,不应该在没有严格验证的情况下允许用户通过你的应用程序直接将数据发送给其他用户。对于像博客这样的应用程序来说,采取审核机制是很有必要的,以此确保你的应用程序最终不会沦为病毒的宿主, 或者出现更糟糕的情况:被掺入看似无害的数据。 很少有专家会提醒你检查输出数据。但是,你并不能准确地知道自己的应用程序是否值得信赖。黑客有可能破解应用程序并污染输出数据。验证核查应涵盖输入数据和输出数据。 文件上传 即使看上去是无害的,但每一次的文件上传也应该被认为是可疑的。黑客有时候会利用服务器的文件上传功能来上传后门程序,这些文件会包含一些很危险的东西。如果可能,应禁止服务器的文件上传。当然,我们通常无法提供这种级别的安全性,所以你需要限制允许上传的文件类型,然后扫描这些文件,检查它们是否有问题。尽可能验证文件始终是一个好主意。例如,一些文件会在头部包含一段签名信息,你可以用它来判断这个文件的合法性。不要单纯依赖文件扩展名进行排除,黑客经常会将一个文件伪装成另一种类型来绕过服务器的安全验证。 硬编码的认证 出于测试目的,开发人员经常将认证信息放在应用程序的初始化文件中。我们需要去掉这些硬编码的认证信息,以集中式存储的安全信息替代。将数据存储在安全的位置而不是Web 应用服务器上是很重要的,这样黑客就不能轻易地查看到可用于访问应用程序的凭据。如果你的应用程序确实需要一些初始化文件,那么要确保这些文件放在Web 根目录以外的地方,以防止黑客偶然发现它们。 发现隐藏或受限制的文件/ 目录 当应用程序允许输入一些特殊字符(比如斜杠或反斜杠)时,黑客就有可能发现隐藏或受限制的文件和目录。这些地方可能包含各种有助于黑客攻击你的系统的信息。尽可能禁止使用特殊字符是一个很好的主意。除此之外,请把重要的文件放在Web 根目录之外且操作系统能直接控制的地方。 缺少认证或者认证不正确 知道谁正在使用应用程序是很重要的,特别是在你处理敏感数据的时候。许多Web 应用程序依赖公共账户来执行某些任务,这意味着不可能知道是谁访问了这个账户。应该避免因为任何原因而使用访客账户,并为每一个用户分配独立的账户。 缺少授权或者授权不正确 即使知道了谁正在使用你的应用,还有一件重要的事:只为用户提供执行特定任务时所需要的权限。此外,授权应该反映用户的访问方式,比如一个桌面系统通过本地网络访问应用程序可能比一部智能手机在当地咖啡店里访问应用程序更安全。依靠安全提升来协助处理敏感任务,能够让你在处理任务之外的时间里维持最低的授权。任何降低用户权限的行为都有助于维持一个安全的环境。 缺少加密或者加密不正确 使用加密技术在两个终端之间传输数据可以防止黑客监听通信。重点是要跟进最新的加密技术,并且依靠用户环境所能支持的最好加密算法。例如,三重加密算法(Triple Data Encryption,3DES)已经不再安全了,但一些组织仍在使用它。高级加密标准(Advanced Encryption Standard,AES)目前仍然是安全的,但你要尽可能用最长的密钥来加大破解难度。 操作系统命令注入 攻击者会修改应用程序使用的操作系统命令来执行特定的任务。你的Web 应用程序一开始可能就不应该使用系统调用。但是,如果必须使用,请确保你的应用程序在一个沙盒环境中运行。 有些专家会强调在某些使用场景中需要校验输入数据,但对其他的使用场景不作此要求。请始终对从任意数据源接收到的任何数据进行校验。你无法知道黑客会用什么工具来侵入系统或以怎样的方式来制造损害。输入数据总是可疑的,即使该数据来自你自己的服务器。当你处理安全相关的任务时,变得多疑是件好事。 参数篡改 黑客会对作为请求头或URL 一部分的参数进行尝试。例如,使用Google 搜索时,你可以通过改变URL 来改变搜索结果。请确保加密你在浏览器和服务器之间传递的任何参数。此外,在传递参数时,使用安全的网络传输协议,比如HTTPS。 如果有足够的时间和精力,黑客仍然能操纵参数。仔细定义好参数的取值范围和数据类型也很重要,这能减少此种攻击带来的潜在问题。 远程代码包含 如今的很多Web 应用程序依赖包含外部库、框架和API。大多数情况下,包含语句会含有一个相对路径或者使用一个记录着硬编码路径的变量,这样做是为了方便以后更换远程代码的位置。当黑客能够获取到这些路径信息并更改它们的时候,远程代码包含就可能被指向黑客想要包含的任何代码,从而使得黑客可以完全掌控你的系统。避免这种问题的最佳方法就是尽量使用硬编码的完整路径,尽管这会使代码维护变得困难。 许多专家会建议你使用经过审核的库和框架来执行有风险的任务。但是, 这些添加的插件不过是更多的代码而已。黑客总能发现破坏和规避这些库以及框架的方法。你仍然需要确保应用程序和所有它依赖的代码能够安全地与外界交互,这意味着需要有额外的测试。使用外部库和框架确实能降低维护成本并且能提供及时的bug 修复,但是bug 仍旧会存在并且你仍需要保持警惕。保证数据安全没有万全之策。第6 章包含了更多关于使用外部库和框架的内容。 会话劫持 每次用户登录到你的Web 服务器,服务器就会为其创建一个唯一的会话。会话劫持者会侵入到会话中并拦截用户与服务器之间传输的数据。含有劫持会话所需信息的三个最常见的地方是:cookie、URL 重写和隐藏域。黑客会在这些地方查找会话信息。只要保持会话信息是加密的,你就能降低会话被劫持的风险。例如,确保使用HTTPS 协议来登录。你也应该避免使用可被预测的会话ID。 SQL 注入 攻击者会修改由应用程序创建的查询,而这个查询是由用户或其他输入引起的。大部分SQL 注入的情况是,应用程序需要的是用于查询的数据,但它实际接收到的却是一些SQL 片段。其他形式的SQL 注入攻击与使用了转义字符或其他意想不到的字符或字符串有关。一个避免SQL 注入攻击的好办法是避免动态查询。 看起来我们周围存在着许多不同的网络威胁,但如果在网上搜索的时间足够长,你会轻易地将这份清单的长度变成现在的3 倍,然而这些也只是众多黑客攻击手段中的一小部分。当继续读这本书时,你会碰到更多种类的网络威胁并开始了解解决它们的方法。不用担心,大部分情况的解决方案都是一些常识,并且一个方案能解决不止一个问题。例如,再看看上面的清单,你会发现仅仅使用HTTPS 就可以解决其中的多个问题。 考虑隐私安全问题 当一家公司涉足安全时,它往往会首先关注自己的数据安全,毕竟,如果公司的数据丢失、被损坏、被修改或以别的方式变得不可用,那它可能会面临破产。公司下一个级别的安全考虑通常涉及第三方,比如合作伙伴。用户数据的安全性通常是最后才考虑的,并且,很多公司根本不考虑客户数据的安全。问题是,许多用户和客户把他们的数据安全看得非常重要。所有的隐私问题都归结于用户数据的保护,在没有经过用户同意或用户不知情的情况下,不能滥用或暴露用户信息。总之,在构建应用程序时, 必须把用户数据的隐私作为一个重要的安全问题纳入考虑范围。最近的一篇文章(http://www.infoworld.com/article/2925292/internet-privacy/feds-vs-silicon-valley-who-do-you-trust-less.html)指出,用户和客户把科技行业视为糟糕的数据受托方。事实上,科技行业确实在这方面已落后于政府,人们相信政府会更好地保护他们的信息。许多科技公司公开支持其他实体(比如政府)提出的增强安全性的策略,但私底下却用各种方式侵犯用户和客户的隐私。这种两面派的做法比起科技行业公开承认侵犯用户和客户的数据更糟糕。要创建一个真正安全的应用程序,必须涵盖安全的每一个方面,包括用户和客户的数据。这要求应用程序只获取和管理其执行相关任务所需的数据,而不去涉及那些不再需要的数据。只有对操作的所有数据都遵循相同的原则,不管它们从何而来,应用程序才会收获信任。

>Web安全开发指南

Web安全开发指南
作者: [美] John Paul Mueller
isbn: 7115454086
书名: Web安全开发指南
页数: 268
译者: 温正东
定价: 69.00元
出版社: 人民邮电出版社
装帧: 平装
出版年: 2017-6