Testing Goals and ResponsibilitiesO

Testing Goals and Responsibilities
Often, there are numerous people within an organization who influence the security concerns and operational infrastructure; these individuals make up an organization’s security team.Asecurity team may include the following: ■■ Policymakers, who define security requirements that enhance user and producer confidence in system security defenses. ■■ Network administrators, who design and implement security measures to provide security at the operational level. ■■ Software developers, who design and implement security defenses at the application level (to meet security requirements). ■■ Software testers, who are responsible for testing the systems to uncover functionality, interoperability, configuration, and compatibility errors as they are related to security implementation (primarily at the application level and perhaps at the operational level as well), and discovering potential problems introduced by security design flaws. ■■ Security experts and consultants, who help test and maintain your security programs as well as handle security breaches. Often, this group of people consists of reformed attackers-for-hire. Former attackers, who developed their domain of expertise through practice over the years, are responsible for conducting penetration tests (designed to evaluate the effectiveness of Web system defenses through the use of a combination of attack tools, security and attacking expertise, and IT knowledge) prior to the deployment of a system as well as on an ongoing basis. Unless your organization does not have an expert to handle penetration testing, it’s often not expected that a typical software tester or developer would have this responsibility. The main focus of our goals as testers should be testing the Web site and Web application security at the application level. It means that we should seek out vulnerabilities and information leaks caused primarily by programming practice and, to a certain extent, by misconfiguration of Web servers and other application-specific servers. We should test for the security side effects or vulnerabilities caused by the functionality implementation. At the same time, we should also test for functional side effects caused by security implementation (see Figures 18.10 and 18.11).
Functionality Side Effect: An Error-Handling Bug Example Applications often are not aware of the actual causes of failure conditions they experience. Errors may be due to session time-outs, absence of available disk
446 Chapter 18
space, incomplete downloads, or browser security settings that prevent the downloading of active content (Java applets, ActiveX controls, etc.). An application might misinterpret an error condition and, in turn, display a misleading error message for all such error conditions. Figure 18.10 shows the Internet Explorer safety-level screen. Note that Medium has been selected as the active content security setting, which means (among other things) that ActiveX controls cannot be downloaded. This application is a Web-based e-mail reader. It requires an ActiveX control to be downloaded before it can download attachments. Because the security level is set to medium, the ActiveX control cannot be downloaded. However, the application presents an erroneous error message in this scenario, such as that shown in Figure 18.11. Based on the advice given in the message, the user has two choices: (1) continue to wait or (2) click on the Reload button to reload the control; but either choice will fail to download the ActiveX control because, in reality, the browser’s security setting is the cause of this error condition. Specifically, the following areas should be considered as our testing responsibilities: ■■ Test the security prevention implementation. Seek out vulnerabilities and various means to exploit them so they can be fixed. ■■ Test the security detection implementation. Help determine the information that should be logged and mechanisms to track; alert and trap suspicious activities. ■■ Test the requirements and designs.
Figure 18.10 Internet Explorer safety-level settings.
Web Security Testing 447
Figure 18.11 Inaccurate error message.
■■ Test the code and programming practices. ■■ Test interoperability with third-party components with specific focus on known vulnerabilities. ■■ Test for misconfiguration. ■■ Test the deployment. ■■ To a certain extent, do penetration testing. Other common goals of Web system security measures—and, therefore, their associated testing considerations—follow. These goals are particularly appropriate for e-commerce systems: ■■ Interactions and transactions between buyers and your company’s system should be confidential. ■■ Data integrity should be preserved. ■■ Buyers and your company’s system should be able to verify each other’s identities (at least, electronically). ■■ Transaction records should be in a form that can withstand scrutiny in a court of law. As a producer of Web-based systems, your company should be protected from the following: ■■ Exposing private network access to unauthorized external and internal intruders. ■■ Losing confidential data and proprietary technology through attack activities. ■■ Losing data due to hardware and software errors, natural disasters, and theft. As a side issue, although many of the security protection measures via browser settings on the client-side are designed to protect users, users do have the responsibility of protecting themselves from vulnerabilities by properly controlling these settings. Users of Web-based systems can be protected from the following:
448 Chapter 18
■■ Exposure to virus attacks via active contents, plug-ins, cabinet files (.CAB), executables (.EXEs), DLLs, ActiveX controls, and other components ■■ Exposure to offensive contents ■■ Exposure of private information to third parties, either in violation of the Web site’s stated policy or as an unauthorized data capture by a third party that is independent of the intent of the Web site owner
Testing for Security
Though much of the security responsibility is at the corporate IT level, the application tester is also involved. As explained earlier in the chapter, the most prevalent security weakness is the buffer overflow bug, which, you’ll recall, is solely a coding problem within a program. The problem exists regardless of design considerations, operating systems, or implementation language. It is, simply put, a coding oversight, and it plays a part in over half of all reported problems. That said, it is possible to uncover and rectify buffer overflow bugs if you use the proper security testing strategy, so we’ll begin this discussion on security testing to see how to accomplish this. In testing the security of Web-based applications, it is best to assume that attackers have skill, luck, and time on their side, and to recognize that the attacker might be one lone “script kiddy” or a major international espionage organization. Another aspect of the testing management’s risk assessment is to determine how much value will be lost if the application is attacked. The more valuable the assets maintained by the application, the more likely that someone will spend a significant amount of time and effort to break in.
Testing the Requirements and Design
Requirements Are Key Every system is built using a set of requirements. Sometimes these requirements are written clearly, but often they are vague statements only partially defined. The product manager may state, for example, “The application must be secure.” But what does “secure” mean and just how much should be spent making it secure? Security has been defined as a trade-off between risk and reward. Deciding how much risk is a question for management to answer. For example, a very large Web site hosted on hardware that is not connected to the
Web Security Testing 449
corporate intranet, and consisting of hundreds of pages and welcoming thousands of external visitors every day, might require little security because all of the available data is public knowledge. In this case, there is little reason for anyone to deface the Web site. The Gutenberg Project’s Web site is just such a place. In contrast, a very small Web application that tracks company sales and is restricted to only the sales staff of a single company could be a major target. How many attackers would like this information on IBM or Microsoft? The point is, in order to provide “just enough” testing, the test team must understand how much the system is worth, both to the organization using the application and to the possible attackers of the application.
Trusted Computational Base (TCB) As noted previously in the subsection titled “Exploiting the Trust Computational Base,” inside a secure system is a “community” of components (hardware, operating systems, utility programs, and applications) that trust each other. The members of this community all have established boundaries for untrusted programs. In order to test your application, you will need to determine where those boundaries lie and what data can be transferred across those boundaries. This is the Trusted Computational Base (TCB). For example, a client’s browser is almost always untrusted. The user can easily control data sent from a browser to the application. The application can rarely maintain control of the browser software. Trust is also often extended to disk files residing on the server. However, other users can modify these files. Understanding what is inside and what is outside your TCB enables you to build power scenarios for the application. Be aware that the TCB can change over time. Network configurations change. Data files that were once secure can become insecure. Passwords expire. On some systems, once a person logs on to the system, he or she may never log off. We all know people who have gone on vacation and have left their system logged on, and have n

Kết quả (Việt) 1:

Kiểm tra mục tiêu và trách nhiệmThông thường, có rất nhiều người trong một tổ chức ảnh hưởng đến mối quan tâm an ninh và cơ sở hạ tầng hoạt động; những cá nhân tạo nên đội bảo vệ của tổ chức. Asecurity nhóm có thể bao gồm: ■■ hoạch định chính sách, người xác định yêu cầu bảo mật nâng cao sự tự tin của người dùng và nhà sản xuất trong hệ thống an ninh bảo vệ. ■■ nhà quản trị mạng, người thiết kế và thực hiện các biện pháp an ninh để cung cấp bảo mật ở mức độ hoạt động. ■■ phát triển phần mềm, thiết kế và thực hiện an ninh bảo vệ ở cấp ứng dụng (nhằm đáp ứng yêu cầu bảo mật). ■■ phần mềm thử nghiệm, những người có trách nhiệm để thử nghiệm hệ thống để khám phá chức năng, khả năng tương tác, cấu hình và khả năng tương thích lỗi như họ có liên quan đến an ninh thực hiện (chủ yếu ở cấp độ ứng dụng và có lẽ ở cấp độ hoạt động), và phát hiện vấn đề tiềm năng được giới thiệu bởi lỗ hổng bảo mật thiết kế. ■■ bảo mật chuyên gia và tư vấn, những người giúp kiểm tra và duy trì chương trình an ninh của bạn cũng như xử lý vi phạm an ninh. Thông thường, nhóm người này bao gồm cải cách kẻ tấn công cho thuê. Kẻ tấn công trước đây, đã phát triển của lĩnh vực chuyên môn thông qua thực hành trong những năm qua, có trách nhiệm thực hiện các bài kiểm tra thâm nhập (được thiết kế để đánh giá hiệu quả của trang Web hệ thống phòng thủ bằng cách sử dụng một sự kết hợp của các công cụ tấn công, bảo mật và tấn công chuyên môn, và nó kiến thức) trước khi triển khai một hệ thống cũng như trên cơ sở liên tục. Trừ khi tổ chức của bạn không có một chuyên gia để xử lý thâm nhập thử nghiệm, nó thường không dự kiến rằng một điển hình phần mềm tester hoặc phát triển sẽ có trách nhiệm này. Mục tiêu chính của chúng tôi mục tiêu như xét nghiệm nên kiểm tra trang Web và Web ứng dụng bảo mật độ ứng dụng. Nó có nghĩa rằng chúng tôi nên tìm ra lỗ hổng và rò rỉ thông tin gây ra chủ yếu bởi lập trình thực hành và, đến một mức độ nhất định, bởi các lỗi cấu của máy chủ Web và máy chủ dành riêng cho ứng dụng khác. Chúng tôi nên kiểm tra an ninh tác dụng phụ hoặc lỗ hổng gây ra bởi việc thực hiện chức năng. Cùng lúc đó, chúng tôi cũng nên kiểm tra cho chức năng các tác dụng phụ do an ninh thực hiện (xem số liệu 18,10 và 18.11). Các tác dụng phụ chức năng: Một quản lý lỗi lỗi ví dụ ứng dụng thường không nhận thức được nguyên nhân thực tế của sự thất bại điều kiện họ kinh nghiệm. Lỗi có thể là do phiên thời gian-outs, sự vắng mặt của đĩa446 chương 18không gian, không đầy đủ tải, hoặc cài đặt an ninh trình duyệt ngăn chặn tải nội dung hiện hoạt (Java applet, ActiveX điều khiển, vv). Một ứng dụng có thể giải thích sai một điều kiện lỗi, và lần lượt, Hiển thị một thông báo lỗi gây hiểu lầm cho tất cả các điều kiện lỗi như vậy. Con số 18,10 Hiển thị màn hình an toàn cấp Internet Explorer. Lưu ý rằng phương tiện đã được chọn làm các thiết lập hoạt động an ninh nội dung, có nghĩa là (trong số những thứ khác) điều khiển ActiveX không thể được tải về. Ứng dụng này là một người đọc email dựa trên Web. Nó đòi hỏi một điều khiển ActiveX được tải trước khi nó có thể tải về tập tin đính kèm. Bởi vì mức độ bảo mật được thiết lập để vừa, điều khiển ActiveX không thể được tải về. Tuy nhiên, các ứng dụng trình bày một thông báo lỗi sai trong trường hợp này, chẳng hạn như hiển thị trong hình 18.11. Dựa trên những lời khuyên trong thư, người dùng có hai lựa chọn: (1) tiếp tục chờ hoặc (2) nhấp vào nút tải lại để tải lại sự kiểm soát; nhưng một trong hai sự lựa chọn sẽ không tải điều khiển ActiveX bởi vì, trong thực tế, thiết lập bảo mật của trình duyệt là nguyên nhân của tình trạng lỗi này. Cụ thể, các lĩnh vực sau đây cần được coi là trách nhiệm của chúng tôi kiểm tra: ■■ kiểm tra việc thực hiện công tác phòng chống bảo mật. Tìm ra các lỗ hổng và các phương tiện khác nhau để khai thác chúng để họ có thể được cố định. ■■ kiểm tra an ninh phát hiện thực hiện. Xác định các thông tin cần được ghi lại và các cơ chế theo dõi; cảnh báo và cái bẫy hoạt động đáng ngờ. ■■ kiểm tra các yêu cầu và thiết kế.Thiết đặt mức độ an toàn của con số 18,10 Internet Explorer.Web bảo mật thử nghiệm 447Các thông báo lỗi không chính xác con số 18.11.■■ kiểm tra mã và thực hành lập trình. ■■ kiểm tra khả năng tương tác với các bên thứ ba thành phần với các tập trung cụ thể vào lỗ hổng được biết đến. ■■ kiểm tra lỗi cấu. ■■ kiểm tra việc triển khai. ■■ Đến một mức độ nhất định, làm thâm nhập thử nghiệm. Các mục tiêu chung của các biện pháp an ninh hệ thống Web — và, do đó, là của họ liên quan đến thử nghiệm cân nhắc-làm theo. Các mục tiêu này là đặc biệt thích hợp cho các hệ thống thương mại điện tử: ■■ tương tác và giao dịch giữa người mua và hệ thống của công ty bạn nên được bảo mật. ■■ toàn vẹn dữ liệu cần được bảo tồn. ■■ người mua và hệ thống của công ty bạn sẽ có thể để xác minh danh tính của nhau (ít, điện tử). Bản ghi của giao dịch ■■ nên trong một hình thức mà có thể chịu được giám sát ở một tòa án của pháp luật. Là một nhà sản xuất của hệ thống dựa trên Web, công ty của bạn cần được bảo vệ từ sau: truy cập vào mạng riêng Exposing ■■ kẻ xâm nhập trái phép của bên ngoài và nội bộ. ■■ Mất dữ liệu bí mật và các công nghệ độc quyền thông qua các hoạt động tấn công. ■■ Mất dữ liệu do lỗi phần cứng và phần mềm, thảm họa thiên nhiên, và trộm cắp. Như một vấn đề phụ, mặc dù nhiều người trong số các biện pháp bảo vệ an ninh thông qua thiết lập trình duyệt phía khách hàng được thiết kế để bảo vệ người dùng, người dùng có trách nhiệm bảo vệ bản thân từ lỗ hổng bằng đúng cách kiểm soát các thiết đặt này. Sử dụng Web dựa trên hệ thống có thể được bảo vệ từ sau đây:448 Chapter 18■■ Exposure to virus attacks via active contents, plug-ins, cabinet files (.CAB), executables (.EXEs), DLLs, ActiveX controls, and other components ■■ Exposure to offensive contents ■■ Exposure of private information to third parties, either in violation of the Web site’s stated policy or as an unauthorized data capture by a third party that is independent of the intent of the Web site ownerTesting for SecurityThough much of the security responsibility is at the corporate IT level, the application tester is also involved. As explained earlier in the chapter, the most prevalent security weakness is the buffer overflow bug, which, you’ll recall, is solely a coding problem within a program. The problem exists regardless of design considerations, operating systems, or implementation language. It is, simply put, a coding oversight, and it plays a part in over half of all reported problems. That said, it is possible to uncover and rectify buffer overflow bugs if you use the proper security testing strategy, so we’ll begin this discussion on security testing to see how to accomplish this. In testing the security of Web-based applications, it is best to assume that attackers have skill, luck, and time on their side, and to recognize that the attacker might be one lone “script kiddy” or a major international espionage organization. Another aspect of the testing management’s risk assessment is to determine how much value will be lost if the application is attacked. The more valuable the assets maintained by the application, the more likely that someone will spend a significant amount of time and effort to break in.Testing the Requirements and DesignRequirements Are Key Every system is built using a set of requirements. Sometimes these requirements are written clearly, but often they are vague statements only partially defined. The product manager may state, for example, “The application must be secure.” But what does “secure” mean and just how much should be spent making it secure? Security has been defined as a trade-off between risk and reward. Deciding how much risk is a question for management to answer. For example, a very large Web site hosted on hardware that is not connected to theWeb Security Testing 449corporate intranet, and consisting of hundreds of pages and welcoming thousands of external visitors every day, might require little security because all of the available data is public knowledge. In this case, there is little reason for anyone to deface the Web site. The Gutenberg Project’s Web site is just such a place. In contrast, a very small Web application that tracks company sales and is restricted to only the sales staff of a single company could be a major target. How many attackers would like this information on IBM or Microsoft? The point is, in order to provide “just enough” testing, the test team must understand how much the system is worth, both to the organization using the application and to the possible attackers of the application.Trusted Computational Base (TCB) As noted previously in the subsection titled “Exploiting the Trust Computational Base,” inside a secure system is a “community” of components (hardware, operating systems, utility programs, and applications) that trust each other. The members of this community all have established boundaries for untrusted programs. In order to test your application, you will need to determine where those boundaries lie and what data can be transferred across those boundaries. This is the Trusted Computational Base (TCB). For example, a client’s browser is almost always untrusted. The user can easily control data sent from a browser to the application. The application can rarely maintain control of the browser software. Trust is also often extended to disk files residing on the server. However, other users can modify these files. Understanding what is inside and what is outside your TCB enables you to build power scenarios for the application. Be aware that the TCB can change over time. Network configurations change. Data files that were once secure can become insecure. Passwords expire. On some systems, once a person logs on to the system, he or she may never log off. We all know people who have gone on vacation and have left their system logged on, and have n

Kết quả (Việt) 2:

Kiểm tra các mục tiêu và trách nhiệm
thường, có rất nhiều người trong một tổ chức người ảnh hưởng đến các mối quan tâm an ninh và cơ sở hạ tầng hoạt động; những cá nhân tạo nên đội team.Asecurity an ninh của một tổ chức có thể bao gồm những điều sau đây: ■■ hoạch định chính sách, người xác định yêu cầu an ninh tăng cường người dùng và nhà sản xuất tin tưởng vào hệ thống phòng thủ an ninh. ■■ quản trị mạng, người thiết kế và thực hiện các biện pháp an ninh để đảm bảo an ninh tại các cấp hoạt động. ■■ các nhà phát triển phần mềm, những người thiết kế và thực hiện phòng thủ an ninh ở mức ứng dụng (để đáp ứng yêu cầu về bảo mật). ■■ thử nghiệm phần mềm, người có trách nhiệm kiểm tra các hệ thống để phát hiện ra các chức năng, khả năng tương tác, cấu hình, và các lỗi tương thích như họ có liên quan đến an ninh thực hiện (chủ yếu ở mức ứng dụng và có lẽ ở cấp độ hoạt động là tốt), và phát hiện vấn đề tiềm năng giới thiệu bởi lỗ hổng bảo mật thiết kế. ■■ chuyên gia và tư vấn an ninh, người giúp thử nghiệm và duy trì các chương trình an ninh của bạn cũng như vi phạm xử lý an ninh. Thông thường, nhóm người này bao gồm những kẻ tấn công-cho-thuê được cải tổ. Cựu kẻ tấn công, người đã phát triển miền chuyên môn của họ thông qua thực hành trong những năm qua, có trách nhiệm tiến hành kiểm tra thâm nhập (được thiết kế để đánh giá hiệu quả của việc bảo vệ hệ thống Web thông qua việc sử dụng một sự kết hợp của các công cụ tấn công, chuyên môn bảo mật và tấn công, và kiến thức CNTT) trước khi việc triển khai một hệ thống cũng như trên cơ sở liên tục. Trừ khi tổ chức của bạn không có một chuyên gia để xử lý thử nghiệm thâm nhập, nó thường không mong đợi rằng một thử nghiệm phần mềm điển hình hoặc phát triển sẽ phải chịu trách nhiệm này. Trọng tâm chính của mục tiêu của chúng tôi là thử nghiệm nên thử nghiệm các trang Web và bảo mật ứng dụng Web ở mức ứng dụng. Nó có nghĩa là chúng ta nên tìm ra các lỗ hổng và rò rỉ thông tin gây ra chủ yếu bởi thực hành lập trình, và ở một mức độ nhất định, do cấu hình sai của các máy chủ web và máy chủ ứng dụng cụ thể khác. Chúng ta nên kiểm tra cho các tác dụng phụ hoặc các lỗ hổng bảo mật gây ra bởi việc thực hiện chức năng. Đồng thời, chúng ta cũng nên kiểm tra các tác dụng phụ chức năng do an ninh thực hiện (xem hình 18.10 và 18.11).
Chức năng Side Effect: An Error-Xử lý lỗi Ví dụ ứng dụng thường không nhận thức được những nguyên nhân thực tế của điều kiện thất bại họ trải nghiệm. Lỗi có thể do phiên time-outs, sự vắng mặt của đĩa có sẵn
446 Chương 18
không gian, download không hoàn thiện, hoặc thiết lập bảo mật của trình duyệt mà ngăn chặn việc tải các nội dung hoạt động (applet Java, ActiveX Controls, vv). Một ứng dụng có thể hiểu sai một điều kiện lỗi và, đến lượt nó, hiển thị một thông báo lỗi gây hiểu nhầm cho tất cả các điều kiện lỗi như vậy. Hình 18.10 cho thấy màn hình an toàn cấp Internet Explorer. Lưu ý rằng trung bình đã được chọn làm bối cảnh an ninh nội dung hoạt động, có nghĩa là (trong số những thứ khác) mà điều khiển ActiveX không thể được tải về. Ứng dụng này là một người đọc e-mail trên nền web. Nó đòi hỏi một điều khiển ActiveX được tải về trước khi nó có thể tải file đính kèm. Bởi vì mức độ bảo mật được thiết lập để vừa, các điều khiển ActiveX không thể được tải về. Tuy nhiên, các ứng dụng trình bày một thông báo lỗi sai trong kịch bản này, như được chỉ ra trong hình 18.11. Dựa trên những lời khuyên được đưa ra trong các tin nhắn, người dùng có hai lựa chọn: (1) tiếp tục chờ đợi hay (2) nhấp vào nút Reload để nạp lại sự kiểm soát; nhưng một trong hai lựa chọn sẽ thất bại để tải về kiểm soát ActiveX bởi vì, trong thực tế, thiết lập bảo mật của trình duyệt là nguyên nhân của tình trạng lỗi này. Cụ thể, các khu vực sau đây cần được coi là trách nhiệm của chúng tôi kiểm tra: Kiểm tra việc thực hiện ■■ phòng an ninh. Tìm ra các lỗ hổng và phương tiện khác nhau để khai thác chúng để họ có thể được cố định. ■■ Kiểm tra việc thực hiện phát hiện an ninh. Giúp xác định các thông tin cần đăng nhập và cơ chế để theo dõi; các hoạt động đáng ngờ và cảnh báo bẫy. ■■ Kiểm tra các yêu cầu và thiết kế.
Hình 18.10 Internet Explorer cài đặt an toàn cấp.
Web Security Testing 447
Hình 18.11 thông báo lỗi không chính xác.
■■ Kiểm tra thực hành mã và lập trình. ■■ thử nghiệm khả năng tương tác với các thành phần của bên thứ ba với trọng tâm cụ thể về các lỗ hổng được biết đến. ■■ thử nghiệm cho lập sai. ■■ Kiểm tra việc triển khai. ■■ Đến một mức độ nhất định, làm thử nghiệm thâm nhập. Mục tiêu chung khác của các biện pháp an ninh và hệ thống Web, do đó, thử nghiệm liên quan của họ cân nhắc-sau. Những mục tiêu này đặc biệt thích hợp cho các hệ thống thương mại điện tử: ■■ tương tác và giao dịch giữa người mua và hệ thống của công ty bạn được giữ bí mật. ■■ toàn vẹn dữ liệu cần được bảo tồn. ■■ Người mua và hệ thống của công ty bạn sẽ có thể để xác minh danh tính của nhau (ít nhất, điện tử). ■■ hồ sơ giao dịch phải ở trong một hình thức có thể chịu được sự giám sát tại một tòa án của pháp luật. Là một nhà sản xuất của hệ thống trên nền web, công ty của bạn cần được bảo vệ khỏi những điều sau đây: Phơi bày ■■ truy cập mạng tới những kẻ xâm nhập từ bên ngoài và nội bộ không được phép. ■■ Mất dữ liệu bí mật và công nghệ độc quyền thông qua các hoạt động tấn công. ■■ Mất dữ liệu do phần cứng và phần mềm lỗi, thiên tai, và trộm cắp. Như một vấn đề phụ, mặc dù nhiều người trong số các biện pháp bảo vệ an ninh thông qua các thiết lập trình duyệt trên client-side được thiết kế để bảo vệ người dùng, người sử dụng không có trách nhiệm bảo vệ mình khỏi các lỗ hổng bằng cách kiểm soát các thiết lập đúng cách. Người dùng hệ thống trên nền web có thể được bảo vệ khỏi những điều sau đây:
448 Chương 18
■■ Tiếp xúc với vi rút tấn công thông qua các nội dung hoạt động, plug-ins, các tập tin nội các (.CAB), file thực thi (.exe), các file DLL, ActiveX Controls, và khác thành phần ■■ Tiếp xúc với nội dung xúc phạm ■■ Tiếp xúc của các thông tin cá nhân cho bên thứ ba, hoặc vi phạm các chính sách đã nêu cho các website hoặc như là một thu thập dữ liệu trái phép của một bên thứ ba độc lập với mục đích của các chủ sở hữu trang web
kiểm tra cho an ninh
Mặc dù phần lớn trách nhiệm bảo mật là ở cấp độ doanh nghiệp CNTT, các thử nghiệm ứng dụng cũng tham gia. Như đã giải thích ở chương trước, các điểm yếu bảo mật phổ biến nhất là lỗi tràn bộ đệm, trong đó, bạn sẽ nhớ lại, chỉ là một vấn đề mã hóa trong một chương trình. Vấn đề tồn tại bất kể cân nhắc thiết kế, hệ điều hành, hoặc ngôn ngữ thực hiện. Đó là, chỉ cần đặt, một giám sát mã hóa, và nó đóng một phần trong hơn một nửa của tất cả các vấn đề báo cáo. Điều đó nói rằng, nó có thể phát hiện ra và khắc phục lỗi tràn bộ đệm nếu bạn sử dụng các chiến lược thử nghiệm bảo mật thích hợp, vì vậy chúng tôi sẽ bắt đầu thảo luận này về kiểm tra an ninh để xem làm thế nào để thực hiện điều này. Trong thử nghiệm sự an toàn của các ứng dụng trên nền web, tốt nhất là để cho rằng những kẻ tấn công có kỹ năng, may mắn, và thời gian ở bên họ, và để nhận ra rằng những kẻ tấn công có thể là một đơn độc "kịch bản Kiddy" hoặc một tổ chức gián điệp quốc tế lớn. Một khía cạnh khác của việc đánh giá rủi ro quản lý thử nghiệm là để xác định có bao nhiêu giá trị sẽ bị mất nếu ứng dụng bị tấn công. Càng có giá trị tài sản được duy trì bởi các ứng dụng, nhiều khả năng rằng một người nào đó sẽ dành một số lượng đáng kể thời gian và nỗ lực để phá vỡ trong.
Kiểm tra các yêu cầu và thiết kế
Yêu cầu là Key Mỗi hệ thống được xây dựng bằng cách sử dụng một tập hợp các yêu cầu. Đôi khi, những yêu cầu này được viết rõ ràng, nhưng thường họ là các câu lệnh định nghĩa mơ hồ chỉ một phần. Quản lý sản phẩm có thể được nhà nước, ví dụ, "Ứng dụng này phải được an toàn." Nhưng những gì không "an toàn" có ý nghĩa và chỉ có bao nhiêu nên dành làm cho nó an toàn? An ninh đã được xác định là một thương mại-off giữa rủi ro và phần thưởng. Quyết định bao nhiêu rủi ro là một câu hỏi dành cho quản lý để trả lời. Ví dụ, một trang web rất lớn lưu trữ trên phần cứng mà không được kết nối với các
thử nghiệm Web Security 449
mạng nội bộ của công ty, và bao gồm hàng trăm trang và chào đón hàng ngàn du khách bên ngoài mỗi ngày, có thể đòi hỏi ít bảo mật bởi vì tất cả các dữ liệu có sẵn là kiến thức công cộng. Trong trường hợp này, có rất ít lý do cho bất cứ ai từ đó thay đổi các trang Web. Trang Web của Dự án Gutenberg chỉ là một nơi như vậy. Ngược lại, một ứng dụng Web rất nhỏ mà theo dõi doanh số bán hàng của công ty và được giới hạn chỉ có các nhân viên bán hàng của một công ty duy nhất có thể là một mục tiêu lớn. Làm thế nào nhiều kẻ tấn công muốn nhận thông tin này trên IBM hay Microsoft? Vấn đề là, để cung cấp "vừa đủ" thử nghiệm, nhóm nghiên cứu thử nghiệm phải hiểu được bao nhiêu hệ thống là có giá trị, cả hai để tổ chức sử dụng các ứng dụng và để những kẻ tấn công có thể có của các ứng dụng.
Trusted Computational Base (TCB) Như đã nói trước đây trong các tiểu mục có tiêu đề "Khai thác các tính toán cơ sở Trust," bên trong một hệ thống an toàn là một "cộng đồng" của các thành phần (phần cứng, hệ điều hành, các chương trình tiện ích, và các ứng dụng) mà tin tưởng lẫn nhau. Các thành viên của cộng đồng này tất cả đã thiết lập ranh giới cho các chương trình không đáng tin cậy. Để thử nghiệm ứng dụng của bạn, bạn sẽ cần phải xác định nơi các ranh giới nói dối và những dữ liệu có thể được truyền qua những ranh giới. Đây là cơ sở tính toán đáng tin cậy (TCB). Ví dụ, trình duyệt của khách hàng là hầu như luôn luôn không tin cậy. Người dùng có thể dễ dàng kiểm soát dữ liệu được gửi từ một trình duyệt để áp dụng. Ứng dụng có thể hiếm khi duy trì kiểm soát của phần mềm trình duyệt. Trust cũng thường được mở rộng đến file đĩa nằm trên máy chủ. Tuy nhiên, những người khác có thể sửa đổi những tập tin này. Hiểu những gì bên trong và những gì là bên ngoài TCB của bạn cho phép bạn xây dựng kịch bản năng lượng cho các ứng dụng. Hãy nhận biết rằng TCB có thể thay đổi theo thời gian. Cấu hình mạng thay đổi. Các tập tin dữ liệu đã được một lần an toàn có thể trở thành không an toàn. Mật khẩu hết hạn. Trên một số hệ thống, một khi một người đăng nhập vào hệ thống, người đó không bao giờ có thể log off. Chúng ta đều biết những người đã đi vào kỳ nghỉ và đã rời khỏi hệ thống của họ đăng nhập, và có n