网站与应用安全评估：测试Web安全

需积分: 10 187 浏览量更新于2024-07-27 收藏 2.61MB PDF 举报

"《Testing Web Security》是Steven Splaine撰写的一本书，由Wiley Publishing, Inc.于2002年出版。这本书专注于评估网站和应用程序的安全性，旨在帮助读者理解并测试网络安全性。" 在《Testing Web Security》中，作者Steven Splaine深入探讨了如何评估和测试网络应用的安全性，这涵盖了对网站和应用程序进行安全审计的关键方面。书中可能涵盖了以下几个重要的知识点： 1. **Web应用安全基础**：介绍Web应用的基本结构，包括HTTP协议、Web服务器和客户端交互，以便理解攻击者可能利用的弱点。 2. **威胁模型与攻击类型**：详述常见的网络安全威胁，如SQL注入、跨站脚本(XSS)、跨站请求伪造(CSRF)、文件包含漏洞、零日攻击等，以及这些攻击的原理和防范措施。 3. **渗透测试**：解释渗透测试的步骤，包括信息收集、漏洞扫描、漏洞利用和报告编写，以及如何在不破坏系统的情况下模拟黑客攻击。 4. **安全编码实践**：强调开发阶段的安全性，讨论安全编程原则，如输入验证、输出编码、错误处理和数据加密，以防止代码中的安全漏洞。 5. **身份验证与授权**：讨论用户认证和权限管理的复杂性，包括会话管理、凭证存储和多因素认证，以及如何防止未授权访问。 6. **Web应用防火墙与入侵检测系统**：介绍如何使用WAF和IDS来增强Web应用的防护，以及它们的工作机制和配置策略。 7. **安全配置与管理**：讨论服务器和应用的配置最佳实践，如操作系统加固、软件更新管理和日志审查，以减少被利用的风险。 8. **法律与合规**：简述与网络安全相关的法律法规，如数据保护法和隐私政策，以及企业如何遵守这些法规以避免法律风险。 9. **应急响应与事故处理**：介绍在安全事件发生时应采取的步骤，包括快速响应、事件调查和事后修复。 10. **持续监控与改进**：强调持续的安全监控和漏洞管理，以及通过安全审计和性能测试不断改进安全性的方法。通过这本书，读者不仅可以学习到Web应用安全的理论知识，还能获得实用的工具和技巧，以提高其在实际工作中检测和防御网络安全威胁的能力。书中可能还包括实际案例研究和练习，帮助读者将所学应用于实际场景。对于网络安全专业人员或对此领域感兴趣的人来说，这是一本不可多得的参考资料。

Summary

With the heightened awareness for the need to securely protect an organization's electronic

assets, the supply of available career security veterans is quickly becoming tapped out,

which has resulted in an influx of new people into the field of security testing. This book

seeks to provide an introduction to Web security testing for those people with relatively little

experience in the world of information security (infosec), allowing them to hit the ground

running. It also serves as an easy-to-use reference book that is full of checklists to assist

career veterans such as the growing number of certified information systems security

professionals (CISSPs) in making sure their security assessments are as comprehensive

as they can be. Bragg (2002), Endorf (2001), Harris (2001), Krutz et al. (2001 and 2002),

Peltier (2002), the CISSP Web portal (www.cissp.com), and the International Information

Systems Security Certifications Consortium (www.isc2.org) provide additional information

on CISSP certification.

Chapter 2: Test Planning

Failing to adequately plan a testing effort will frequently result in the project's sponsors

being unpleasantly surprised. The surprise could be in the form of an unexpected cost

overrun by the testing team, or finding out that a critical component of a Web site wasn't

tested and consequently permitted an intruder to gain unauthorized access to company

confidential information.

This chapter looks at the key decisions that a security-testing team needs to make while

planning their project, such as agreeing on the scope of the testing effort, assessing the

risks (and mitigating contingencies) that the project may face, spelling out any rules of

engagement (terms of reference) for interacting with a production environment, and

specifying which configuration management practices to use. Failing to acknowledge any

one of these considerations could have potentially dire consequences to the success of the

testing effort and should therefore be addressed as early as possible in the project. Black

(2002), Craig et al. (2002), Gerrard et al. (2002), Kaner et al. (1999, 2001), the Ideahamster

Organization (www.ideahamster.org), and the Rational Unified Process (www.rational.com)

provide additional information on planning a testing project.

Requirements

A common practice among testing teams charged with evaluating how closely a system will

meet its user's (or owner's) expectations is to design a set of tests that confirm whether or

not all of the features explicitly documented in a system's requirements specification have

been implemented correctly. In other words, the objectives of the testing effort are

dependent upon on the system's stated requirements. For example, if the system is

required to do 10 things and the testing team runs a series of tests that confirm that the

system can indeed accurately perform all 10 desired tasks, then the system will typically be

considered to have passed. Unfortunately, as the following sections seek to illustrate, this

process is nowhere near as simple a task to accomplish as the previous statement would

lead you to believe.

Clarifying Requirements

Ideally, a system's requirements should be clearly and explicitly documented in order for the

system to be evaluated to determine how closely it matches the expectations of the

system's users and owners (as enshrined by the requirements documentation).

Unfortunately, a testing team rarely inherits a comprehensive, unambiguous set of

requirements; often the requirements team-or their surrogates, who in some instances may

end up being the testing team-ends up having to clarify these requirements before the

testing effort can be completed (or in some cases started). The following are just a few

situations that may necessitate revisiting the system's requirements:

 Implied requirements. Sometimes requirements are so obvious (to the

requirements author) that the documentation of these requirements is deemed to be a

waste of time. For example, it's rare to see a requirement such as "no spelling

mistakes are to be permitted in the intruder response manual" explicitly documented,

but at the same time, few organizations would regard spelling mistakes as desirable.

 Incomplete or ambiguous requirements. A requirement that states, "all the Web

servers should have service pack 3 installed," is ambiguous. It does not make it clear

whether the service pack relates to the operating system or to the Web service

(potentially different products) or which specific brand of system software is required.

 Nonspecific requirements. Specifying "strong passwords must be used" may

sound like a good requirement, but from a testing perspective, what exactly is a

strong password: a password longer than 7 characters or one longer than 10? To be

considered strong, can the password use all uppercase or all lowercase characters,

or must a mixture of both types of letters be used?

 Global requirements. Faced with the daunting task of specifying everything that a

system should not do, some requirements authors resort to all-encompassing

statements like the following: "The Web site must be secure." Although everyone

would agree that this is a good thing, the reality is that the only way the Web site

could be made utterly secure is to disconnect it from any other network (including the

Internet) and lock it behind a sealed door in a room to which no one has access.

Undoubtedly, this is not what the author of the requirement had in mind.

Failing to ensure that a system's requirements are verifiable before the construction of the

system is started (and consequently open to interpretation) is one of the leading reasons

why systems need to be reworked or, worse still, a system enters service only for its users

(or owners) to realize in production that the system is not actually doing what they need it to

do. An organization would therefore be well advised to involve in the requirements

gathering process the individuals who will be charged with verifying the system's capability.

These individuals (ideally professional testers) may then review any documented

requirement to ensure that it has been specified in such a way that it can be easily and

impartially tested.

More clearly defined requirements should not only result in less rework on the part of

development, but also speed the testing effort, as specific tests not only can be designed

earlier, but their results are likely to require much less interpretation (debate). Barman

(2001), Peltier (2001), and Wood (2001) provide additional information on writing security

requirements.

Security Policies

Documenting requirements that are not ambiguous, incomplete, nonquantifiable, or even

contradictory is not a trivial task, but even with clearly defined requirements, a security-

testing team faces an additional challenge. Security testing is primarily concerned with

testing that a system does not do something (negative testing)-as opposed to confirming

that the system can do something (positive testing). Unfortunately, the list of things that a

system (or someone) should not do is potentially infinite in comparison to a finite set of

things that a system should do (as depicted in Figure 2.1). Therefore, security requirements

(often referred to as security policies) are by their very nature extremely hard to test,

because the number of things a system should not do far exceeds the things it should do.

Figure 2.1: System capabilities.

When testing security requirements, a tester is likely to have to focus on deciding what

negative tests should be performed to ascertain if the system is capable of doing something

it should not do (capabilities that are rarely well documented-if at all). Since the number of

tests needed to prove that a system does not do what it isn't supposed to is potentially

enormous, and the testing effort is not, it is critically important that the security-testing team

not only clarify any vague requirements, but also conduct a risk analysis (the subject of

Chapter 10) to determine what subset of the limitless number of negative tests will be

performed by the testing effort. They should then document exactly what (positive and

negative tests) will and will not be covered and subsequently ensure that the sponsor of the

effort approves of this proposed scope.

The Anatomy of a Test Plan

Once a set of requirements has been agreed upon (and where needed, clarified), thereby

providing the testing team with a solid foundation for them to build upon, the testing team

can then focus its attention on the test-planning decisions that the team will have to make

before selecting and designing the tests that they intend to execute. These decisions and

the rationale for making them are typically recorded in a document referred to as a test

plan.

A test plan could be structured according to an industry standard such as the Institute of

Electrical and Electronics Engineers (IEEE) Standard for Software Documentation-Std. 829,

based on an internal template, or even be pioneering in its layout. What's more important

than its specific layout is the process that building a test plan forces the testing team to go

through. Put simply, filling in the blank spaces under the various section headings of the

test plan should generate constructive debates within the testing team and with other

interested parties. As a result, issues can be brought to the surface early before they

become more costly to fix (measured in terms of additional resources, delayed release, or

system quality). For some testing projects, the layout of the test plan is extremely important.

For example, a regulatory agency, insurance underwriter, or mandated corporate policy

may require that the test plan be structured in a specific way. For those testing teams that

are not required to use a particular layout, using an existing organizational template or

industry standard (such as the Rational's Unified Process [RUP]) may foster better

剩余296页未读，继续阅读

luckybird00

粉丝: 0
资源: 2

网站与应用安全评估：测试Web安全

"研究计算机mysql模型驱动的web应用SQL注入安全漏洞渗透测试

"详解现代Web应用的服务器端模板注入RCE：2015年黑帽大会精要

Web开发者整体信息安全指南与实践

Web Security Testing Cookbook

websecurity - Web Security Testing Framework 超级牛B扫描器

OWASP Web Security Testing Guide 中文版

Web安全测试[Web Security Testing Cookbook] 英文版 ebook

Information Security (Web Security,Penetration Testing Direction) Interview Questions,Solutions .zip

Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast

OWASP Web Application Security Testing Checklist.pdf

最新资源