internet是令人驚恐的地方
在過(guò)去的幾年里，internet恐怖故事幾乎持續(xù)出現(xiàn)在新聞中，我們看到病毒以驚人的速度傳播，大量危及安全的計(jì)算機(jī)被當(dāng)
作武器，從未結(jié)束的武裝與垃圾郵件作戰(zhàn)，以及許多從危及安全的網(wǎng)站鑒別盜竊的報(bào)導(dǎo)

作為好的web開(kāi)發(fā)人員，打擊這些黑暗勢(shì)力是我們的責(zé)任，每個(gè)web開(kāi)發(fā)人員需要把安全作為基本的web編程方面，不幸的是，
安全問(wèn)題看起來(lái)很棘手--攻擊者只需要找到一個(gè)單獨(dú)的弱點(diǎn)，但是防御者必須保護(hù)每個(gè)單獨(dú)的方面

Django嘗試減輕這個(gè)難點(diǎn)，它設(shè)計(jì)來(lái)自動(dòng)為你防護(hù)許多常見(jiàn)的新手(甚至有經(jīng)驗(yàn)的)web開(kāi)發(fā)人員容易犯的安全錯(cuò)誤，理解這些
問(wèn)題是什么仍然很重要，Django怎樣保護(hù)你，以及--更重要的--你讓你的代碼更安全的步驟
但是，首先，一個(gè)重要的不承諾:我們決不是這個(gè)領(lǐng)域的專家，所以我們不會(huì)嘗試全面的解釋每個(gè)弱點(diǎn)，相反，我們將給出適
合Django的安全問(wèn)題的一個(gè)簡(jiǎn)短的大綱

web安全的主題
如果你只從本章學(xué)習(xí)到一件事情，則讓它為這個(gè):
從不--在任何情況下--信任瀏覽器的數(shù)據(jù)
你從來(lái)不知道在HTTP連接的另一端是誰(shuí)，它可能是一個(gè)你的用戶，但是它也可能很容易為一個(gè)尋找漏洞的攻擊者或小腳本
來(lái)自于瀏覽器的任何類型的數(shù)據(jù)需要被當(dāng)作是偏執(zhí)狂的一副健康良藥，它保護(hù)"in band"的數(shù)據(jù)--即從web表單提交的數(shù)據(jù)--
和"out of band"--即HTTP頭部，cookies，以及其他請(qǐng)求信息，欺騙通常瀏覽器自動(dòng)添加的請(qǐng)求元數(shù)據(jù)是很微不足道的
本章討論的每個(gè)弱點(diǎn)都直接來(lái)自于信任來(lái)自于線上的數(shù)據(jù)然后在使用它之前清除數(shù)據(jù)失敗，你應(yīng)該讓不斷的問(wèn)"數(shù)據(jù)來(lái)自于何
處?"成為一般實(shí)踐

SQL注射
SQL注射是一個(gè)常見(jiàn)的開(kāi)拓，攻擊者改變Web頁(yè)面參數(shù)(例如GET/POST數(shù)據(jù)或URLs)來(lái)插入天真的Web程序直接在它的數(shù)據(jù)庫(kù)執(zhí)行
的任意的SQL片段，這可能是在瘋狂世界里最危險(xiǎn)的--不幸的是它是最常見(jiàn)的--弱點(diǎn)
這個(gè)弱點(diǎn)最容易出現(xiàn)在當(dāng)用戶手動(dòng)輸入結(jié)構(gòu)化SQL時(shí)，例如，設(shè)想寫(xiě)一個(gè)方法來(lái)從一個(gè)聯(lián)系搜索頁(yè)面收集聯(lián)系信息列表，為了
防止在你的系統(tǒng)里讀取每個(gè)單獨(dú)的郵件時(shí)遇到垃圾郵件，我們將強(qiáng)迫用戶在我們提供他們的email地址前輸入某人的用戶名:

def user_contacts(request):
    user = request.GET['username']
    sql = "SELECT * FROM user_contacts WHERE username = '%s';" % username
    # execute the SQL here...

注意，這個(gè)例子中，以及下面所有類似的"不要做這個(gè)"的例子中，我們故意保留了大部分用來(lái)讓方法真正工作的代碼，我們
不會(huì)讓這些代碼在某人偶然取走它們時(shí)工作
盡管起初這看起來(lái)不危險(xiǎn)，但它真的是這樣
首先，保護(hù)我們的整個(gè)郵件列表的嘗試將以一個(gè)聰明的結(jié)構(gòu)化查詢失敗，考慮如果一個(gè)攻擊者輸入"' OR 'a'='a"到查詢框里
這種情況下，字符串插補(bǔ)將構(gòu)建的查詢將為:

SELECT * FROM user_contacts WHERE username = '' OR 'a' = 'a';

由于我們?cè)谠撟址�串里允許不安全的SQL，攻擊者添加的OR子句確保每個(gè)單獨(dú)的行都返回
盡管如此，這是最小的引起驚慌的攻擊，設(shè)想一下如果攻擊者提交"'; DELETE FROM user_contacts WHERE 'a' = 'a"將發(fā)生
什么，我們將得到這個(gè)完整的查詢:

SELECT * FROM user_contacts WHERE username = ''; DELETE FROM user_contacts WHERE 'a' = 'a';

呀!我們的聯(lián)系列表哪里去了?

解決方案
盡管這個(gè)問(wèn)題很陰險(xiǎn)并且有時(shí)很難發(fā)現(xiàn)，解決方案卻很簡(jiǎn)單:從不信任用戶提交的數(shù)據(jù)，并且當(dāng)傳遞給SQL時(shí)一直escape它
Django數(shù)據(jù)庫(kù)API為你做這個(gè)，它根據(jù)你使用的數(shù)據(jù)庫(kù)服務(wù)器(例如PostgreSQL，MySQL)的引號(hào)慣例自動(dòng)escape所有特殊的SQL
參數(shù)，例如，在這個(gè)API調(diào)用中:

foo.get_list(bar__exact="' OR 1=1")

Django將相應(yīng)的escape輸入，結(jié)果是像這樣的語(yǔ)句:

SELECT * FROM foos WHERE bar = '\' OR 1=1'

這是完全無(wú)害的
這適合所有的Django數(shù)據(jù)庫(kù)API，帶有一些額外情況:
1，extra()方法的where參數(shù)(參考附錄XXX)，該參數(shù)設(shè)計(jì)時(shí)接受原始SQL
2，使用低級(jí)數(shù)據(jù)庫(kù)API來(lái)手動(dòng)進(jìn)行查詢
對(duì)于其中每種情況，很容易讓你自己受保護(hù)，每種情況下，避免字符串插補(bǔ)有利于傳遞"綁定參數(shù)"，即，這部分我們開(kāi)始的
例子應(yīng)該被寫(xiě)成:

from django.db import connection

def user_contacts(request):
    user = request.GET['username']
    sql = "SELECT * FROM user_contacts WHERE username = %s;"
    cursor = connection.cursor()
    cursor.execute(sql, [user])
    # ... do something with the results

低級(jí)execute方法使用SQL字符串和%s placeholders，并且自動(dòng)escape和插入作為第二個(gè)參數(shù)傳遞的列表參數(shù)，你應(yīng)該一直以
這種方式構(gòu)建自定義的SQL
不幸的是，你不能在SQL的每個(gè)地方使用綁定參數(shù)，它們不允許作為標(biāo)識(shí)符(即表名或者列名)，這樣，如果你需要，如從一個(gè)
POST變量動(dòng)態(tài)構(gòu)建表的列表，你將需要在你的代碼里escape該名字，Django提供了一個(gè)方法django.db.backend.quote_name
它將根據(jù)當(dāng)前數(shù)據(jù)庫(kù)的引號(hào)scheme來(lái)escape標(biāo)識(shí)符

跨站點(diǎn)腳本(XSS)
很可能最常見(jiàn)的web弱點(diǎn)，跨站點(diǎn)腳本，或者XSS，在渲染到HTML之前失敗于正確的escape用戶提交的內(nèi)容的web程序里發(fā)現(xiàn)
這允許攻擊者惡意的插入任意的通常是script標(biāo)簽格式的HTML
攻擊者通常使用XSS攻擊來(lái)竊取cookie和session信息，或者騙取用戶提供私有信息給錯(cuò)誤的人(也叫phishing)
這種類型的攻擊可以采用一些不同的形式，并且有幾乎無(wú)限的改變方式，所以我們將只看看一個(gè)典型的例子，讓我們看看一
個(gè)非常簡(jiǎn)單的"hello world"視圖:

def say_hello(request):
    name = request.GET.get('name', 'world')
    return render_to_response("hello.html", {"name" : name})

這個(gè)視圖簡(jiǎn)單的從GET參數(shù)讀取一個(gè)名字并傳遞名字給hello.html模板，我們可能像這樣為該視圖寫(xiě)一個(gè)模板:

<h1>Hello, {{ name }}!</h1>

所以如果我們?cè)L問(wèn)http://example.com/hello/name=Jacob，渲染的頁(yè)面將包含:

<h1>Hello, Jacob!</h1>

但是等等--如果我們?cè)L問(wèn)

http://example.com/hello/name=<i>Jacob</i>

會(huì)發(fā)生什么?
則我們會(huì)得到:

<h1>Hello, <i>Jacob</i>!</h1>

當(dāng)然，攻擊者不會(huì)使用像i標(biāo)簽的東西，他可以包含整個(gè)HTML集來(lái)用任意內(nèi)容截取你的頁(yè)面，這種類型的攻擊被用來(lái)欺騙用戶
輸入數(shù)據(jù)到看起來(lái)像它們的銀行網(wǎng)站，但是事實(shí)上是把你的帳號(hào)信息發(fā)送給攻擊者的XSS-截取表單
如果你把存儲(chǔ)該數(shù)據(jù)在數(shù)據(jù)庫(kù)中并且后面在你的站點(diǎn)上顯示則會(huì)更糟
例如，在某點(diǎn)上MySpace被發(fā)現(xiàn)對(duì)于這種類型的XSS攻擊有弱點(diǎn)，用戶插入javascript到他的當(dāng)你訪問(wèn)他的profile頁(yè)面時(shí)自動(dòng)
添加他為你的朋友的profile里，幾天之內(nèi)他有了幾百萬(wàn)的朋友
現(xiàn)在，這可能聽(tīng)起來(lái)良好，但是記住該攻擊者讓他的代碼--而不是MySpace的--運(yùn)行在你的電腦里，這違反了對(duì)于信任MySpa
ce上面的所有代碼都是事實(shí)上由MySpace所寫(xiě)的假設(shè)
MySpace非常幸運(yùn)這些惡意的代碼沒(méi)有自動(dòng)刪除訪問(wèn)者的帳號(hào)，更改他們的密碼，用垃圾郵件淹沒(méi)站點(diǎn)，或者其他任何該弱點(diǎn)
釋放的惡夢(mèng)般的情形
的情形

解決方案
解決方案非常簡(jiǎn)單:一直escape任何可能來(lái)自于用戶的內(nèi)容，如果我們像這樣簡(jiǎn)單的重寫(xiě)我們的模板:

<h1>Hello, {{ name|escape }}!</h1>

則我們不再易受攻擊了，你應(yīng)該當(dāng)在你的站點(diǎn)上顯示用戶提交的內(nèi)容時(shí)一直使用escape標(biāo)簽(或者一個(gè)相似物)
為什么Django不為你做這些?
修改Django來(lái)自動(dòng)escape所有顯示在模板中的變量是一個(gè)頻繁出現(xiàn)在Django開(kāi)發(fā)人員郵件列表中的討論主題
目前為止，Django的模板避免了這種行為，因?yàn)樗�敏銳而不可見(jiàn)的更改了應(yīng)該很直接的行為(顯示變量)，這是個(gè)狡猾的問(wèn)題
和一個(gè)很難評(píng)價(jià)的平衡，添加隱藏的行為與Django的核心理念相悖(以及Python的，對(duì)于這種問(wèn)題)，但是安全同等重要
然而，也存在公平的機(jī)會(huì)使得Django在未來(lái)添加某種形式的自動(dòng)escape(或者幾乎自動(dòng)escape)行為，它將一直比本書(shū)更新
(特別是最終樹(shù)版本)
即使Django添加了這個(gè)特性，你應(yīng)該仍然一直保有考慮"該數(shù)據(jù)從哪里來(lái)?"的習(xí)慣，沒(méi)有一直100%保護(hù)你的站點(diǎn)免受XSS攻擊
的自動(dòng)解決方案

跨站點(diǎn)請(qǐng)求偽造(CSRF)
CSRF當(dāng)惡意網(wǎng)站欺騙用戶未知的從一個(gè)他們已經(jīng)認(rèn)證的站點(diǎn)載入一個(gè)URL時(shí)發(fā)生--這樣，就可以使用他們的認(rèn)證狀態(tài)
Django由內(nèi)勁攻擊來(lái)防護(hù)這種類型的攻擊，攻擊本身和那些工具在第15章進(jìn)行了詳述

Session偽造/截取
這是一個(gè)特殊的攻擊，而不是對(duì)用戶的session數(shù)據(jù)的一般類型的攻擊，它可以有一些不同的形式:
1，中間人攻擊，其中攻擊者當(dāng)它在有線(或者無(wú)線)網(wǎng)絡(luò)上游走時(shí)竊聽(tīng)session數(shù)據(jù)
2，Session偽造，其中攻擊者使用偽造的session ID(可能通過(guò)中間人攻擊獲得)來(lái)假裝為另外一個(gè)用戶
這前兩種的例子是在咖啡店的攻擊者使用無(wú)線網(wǎng)絡(luò)來(lái)獲取一個(gè)session cookie，然后他可以使用這個(gè)cookie來(lái)模仿原始用戶
3，cookie偽造攻擊，其中攻擊者覆蓋存儲(chǔ)在cookie中的假定只讀的數(shù)據(jù)，第12章詳細(xì)解釋了cookies怎樣工作，其中一個(gè)突
出點(diǎn)是對(duì)瀏覽器和惡意用戶在你不知情的情況下更改cookies是微不足道的
網(wǎng)站存儲(chǔ)類似于IsLoggedIn=1或者甚至LoggedInAsUser=jacob的cookie有很長(zhǎng)的歷史，開(kāi)拓這種類型的攻擊者太容易了
但是對(duì)于在更微妙的級(jí)別，信任任何存儲(chǔ)在cookie中的東西從不是個(gè)好主意，你從不知道誰(shuí)正在翻找它們
4，Session定置，其中攻擊者欺騙用戶設(shè)置或者重設(shè)他們的session ID
例如，PHP允許session標(biāo)識(shí)符在URL中傳遞(即http://example.com/?PHPSESSID=fa90197ca25f6ab40bb1374c510d7a32)，欺騙
用戶點(diǎn)擊一個(gè)硬編碼了session ID的鏈接的攻擊者將導(dǎo)致用戶采用該session
這被用在phishing攻擊中來(lái)欺騙用戶輸入個(gè)人信息到攻擊者所有的帳號(hào)，它可以稍后登錄該帳號(hào)并得到那些數(shù)據(jù)
5，Session下毒，其中攻擊者注射潛在危險(xiǎn)的數(shù)據(jù)到用戶的session中--通常通過(guò)一個(gè)用戶提交來(lái)設(shè)置session數(shù)據(jù)的web表單
一個(gè)規(guī)范的例子是站點(diǎn)在cookie中存儲(chǔ)簡(jiǎn)單的用戶喜好(例如頁(yè)面背景顏色)，攻擊者可以欺騙用戶點(diǎn)擊一個(gè)連接來(lái)提交一個(gè)
事實(shí)上包含XSS攻擊的"顏色"，如果這個(gè)顏色沒(méi)有escape(參考上面的)用戶可能再次注射惡毒的代碼到用戶環(huán)境

解決方案
有一些可以防止遭受這些攻擊的一般原則:
1，從不允許session信息包含在URL中
Django的session框架(參考第12章)簡(jiǎn)單的不允許session包含在URL中
2，不要在cookies中直接存儲(chǔ)數(shù)據(jù)，相反，存儲(chǔ)映射到存儲(chǔ)在后端的session數(shù)據(jù)的session ID
如果你使用Django內(nèi)建的session框架(即request.session)，它可以自動(dòng)為你處理，session框架使用的唯一的cookie是一個(gè)
單獨(dú)的session ID，所有的session數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)中
3，如果你在模板中顯示session數(shù)據(jù)記得escape它，參考上面的XSS部分，并且記得它適合任何用戶創(chuàng)建的內(nèi)容，你應(yīng)該把
session信息當(dāng)作用戶創(chuàng)建的
4，預(yù)防任何可能的攻擊者竊取session IDs
盡管幾乎不可能檢測(cè)到某人在竊取session ID，Django確實(shí)有內(nèi)建的強(qiáng)力的session攻擊的防護(hù)，Session IDs存儲(chǔ)為哈希(而
不是連續(xù)的數(shù)字)，這防止了強(qiáng)力攻擊，并且如果用戶嘗試一個(gè)不存在的sessino ID時(shí)用戶將一直得到一個(gè)新的session ID，
這防止了session定置
注意這些原則和工具中沒(méi)有一個(gè)防止了中間人攻擊，這種類型的攻擊幾乎無(wú)法檢測(cè)，如果你的站點(diǎn)允許登錄用戶看到一些類
型的敏感數(shù)據(jù)，你應(yīng)該一直通過(guò)HTTPS來(lái)服務(wù)站點(diǎn)，而且，如果你有一個(gè)允許SSL的站點(diǎn)，你應(yīng)該設(shè)置SESSION_COOKIE_SECURE
設(shè)置為True，這將使Django只通過(guò)HTTPS發(fā)送session cookie

E-mail頭部注射
SQL注射的很少有人知道的姐妹e-mail頭部注射竊取email發(fā)送web表單并使用它們來(lái)發(fā)送垃圾郵件，任何從web表單數(shù)據(jù)構(gòu)建
email頭部的形式都是這種類型的攻擊
讓我們看看規(guī)范的許多站點(diǎn)的聯(lián)系人表單，通常它email一個(gè)硬編碼的email地址，所以第一眼看來(lái)沒(méi)有垃圾郵件濫用的攻擊
盡管如此，大部分的這種表單也允許用戶輸入他自己的email主題(還有一個(gè)發(fā)送地址，有時(shí)候一些其他域)，這個(gè)主題域被
用來(lái)構(gòu)建email信息的主題頭部
如果當(dāng)構(gòu)建email信息時(shí)頭部沒(méi)有escape，攻擊者可以使用類似于"hello\ncc:spamvictim@example.com"(這里\n是換行字符)
這將使得構(gòu)建的email頭部變成:

To: hardcoded@example.com
Subject: hello
cc: spamvictim@example.com

和SQL注射一樣，如果我們信任用戶給定的主題行，我們將允許他后見(jiàn)一些惡意的頭部，則它們可以使用我們的聯(lián)系表單來(lái)
發(fā)送垃圾郵件

解決方案
我們可以用我們預(yù)防SQL注射同樣的方式來(lái)防止這種攻擊:一直escape或者驗(yàn)證用戶提交的內(nèi)容
Django內(nèi)建的mail方法(位于django.core.mail)簡(jiǎn)單的不允許用于構(gòu)建頭部(發(fā)送和接受地址以及主題)的任何域中有換行
如果你嘗試使用django.core.mail.send_mail和一個(gè)包含換行的主題，Django將觸發(fā)BadHeaderError異常
如果你決定使用發(fā)送email的其他方法，你將需要確認(rèn)頭部的換行導(dǎo)致出錯(cuò)或者被清除，你可能想檢查django.core.mail中的
SafeMIMEText類來(lái)看看Django怎樣做這件事

目錄穿越
目錄穿越使另一個(gè)注射風(fēng)格的攻擊，其中惡意的用戶欺騙文件系統(tǒng)代碼來(lái)讀和/或?qū)憌eb服務(wù)器應(yīng)該不允許訪問(wèn)的文件
一個(gè)例子可能為一個(gè)從硬盤(pán)讀文件而不清除文件名的視圖:

def dump_file(request):
    filename = request.GET["filename"]
    filename = os.path.join(BASE_PATH, filename)
    content = open(filename).read()

    # ...

盡管它看起來(lái)限制了文件訪問(wèn)為訪問(wèn)BASE_PATH(通過(guò)使用os.path.join)下面的文件，如果攻擊者傳遞一個(gè)包含..(這是兩個(gè)
句點(diǎn)，UNIX對(duì)"父目錄"的捷徑)的filename，他可以訪問(wèn)BASE_PATH"之上"的文件，他發(fā)現(xiàn)正確數(shù)量的小數(shù)點(diǎn)來(lái)成功訪問(wèn)只是
時(shí)間問(wèn)題，比如../../../../../etc/passwd
讀取文件而不正確的escape的東西對(duì)于此問(wèn)題是易受攻擊的，寫(xiě)文件的視圖只是易受攻擊，但結(jié)果加倍可怕
另一個(gè)該問(wèn)題的改變位于基于URL或者其他請(qǐng)求信息動(dòng)態(tài)載入模塊的代碼中，一個(gè)宣揚(yáng)良好的例子來(lái)自于Ruby on Rails世界
在2006中期之前，Rails使用類似于http://example.com/person/poke/1的URLs來(lái)直接載入模塊和調(diào)用方法，結(jié)果是細(xì)心組織
的URL可能自動(dòng)載入任何的代碼，包括一個(gè)數(shù)據(jù)庫(kù)重置腳本!

解決方案
如果你的代碼需要基于用戶輸入讀寫(xiě)文件，你需要非常小心的清除請(qǐng)求路徑來(lái)確保攻擊者不能從你限制訪問(wèn)的基本目錄逃離
注意，不需要說(shuō)，你應(yīng)該從不寫(xiě)可以讀取硬盤(pán)任何位置的代碼
怎樣做這個(gè)escape的好例子位于Django內(nèi)建的靜態(tài)內(nèi)容服務(wù)視圖(位于django.views.static)，這里是相關(guān)的代碼:

import os
import posixpath

# ...

path = posixpath.normpath(urllib.unquote(path))
newpath = ''
for part in path.split('/'):
    if not part:
        # strip empty path components
        continue

    drive, part = os.path.splitdrive(part)
    head, part = os.path.split(part)
    if part in (os.curdir, os.pardir):
        # strip '.' amd '..' in path
        continue

    newpath = os.path.join(newpath, part).replace('\\', '/')

Django本身不讀文件(除非你使用static.serve方法，但是它被上面顯示的代碼保護(hù))，所以這個(gè)弱點(diǎn)不會(huì)影響核心代碼很多
另外，使用URL配置抽象意味著Django將從不載入你沒(méi)有顯示告訴它載入的代碼，沒(méi)有創(chuàng)建一個(gè)URL來(lái)導(dǎo)致Django載入沒(méi)有在
URL配置里提到的東西的方式

暴露出錯(cuò)信息
在開(kāi)發(fā)階段，可以在你的瀏覽器里看到堆棧和出錯(cuò)信息是非常有用的，Django有特別讓調(diào)試容易的非常"漂亮"和豐富的調(diào)試
信息
盡管如此，一旦站點(diǎn)上線的話如果這些錯(cuò)誤還顯示，它們有時(shí)候會(huì)無(wú)意的暴露幫助攻擊者的你的代碼或者配置的一些方面
而且，錯(cuò)誤和堆棧信息對(duì)最終用戶根本沒(méi)有用處，如果你點(diǎn)代碼觸發(fā)了不可處理的異常，站點(diǎn)訪問(wèn)者應(yīng)該不能看到完整的
堆棧信息--或者任何代碼片段或者Python(面向程序員的)出錯(cuò)信息，相反，訪問(wèn)者應(yīng)該看到友好的"該頁(yè)面不可得到"信息
當(dāng)然，自然開(kāi)發(fā)者需要看到堆棧信息來(lái)在他們的代碼中調(diào)試問(wèn)題，所以框架應(yīng)該從公眾隱藏所有的出錯(cuò)信息，但是它應(yīng)該
顯示他們給受信任的站點(diǎn)開(kāi)發(fā)人員

解決方案
Django有一個(gè)簡(jiǎn)單的標(biāo)記來(lái)控制這些錯(cuò)誤新的顯示，如果DEBUG設(shè)置被設(shè)為True，錯(cuò)誤信息將顯示在瀏覽器中，否則Django
將渲染返回一個(gè)HTTP500("內(nèi)部服務(wù)器錯(cuò)誤")信息并渲染一個(gè)你提供的錯(cuò)誤模板，這個(gè)錯(cuò)誤模板被稱作500.html，并且應(yīng)該
位于一個(gè)你的模板目錄的根目錄
既然開(kāi)發(fā)人員仍然需要看到上線站點(diǎn)生成的錯(cuò)誤信息，對(duì)于任何這種方式處理的錯(cuò)誤將把完整的堆棧信息發(fā)送email給在
ADMINS設(shè)置中給定的任何地址
在Apache和mod_python下部署的用戶應(yīng)該也確認(rèn)他們?cè)谒麄兊腁pache配置文件里設(shè)置了PythonDebug Off，這將確保任何在
Django有機(jī)會(huì)載入之前發(fā)生的錯(cuò)誤都將不會(huì)顯示給公眾

最后一句話
希望所有這些關(guān)于安全問(wèn)題的探討不會(huì)太有脅迫感，是這樣，web可以是一個(gè)瘋狂和野蠻的世界，但是通過(guò)一丁點(diǎn)的遠(yuǎn)見(jiàn)，你
可以有一個(gè)難以置信的安全網(wǎng)站
記住web安全是一個(gè)不斷改變的領(lǐng)域，如果你在閱讀本書(shū)的最終樹(shù)版本，確保檢查更多更新的對(duì)于已發(fā)現(xiàn)的新弱點(diǎn)的安全資源
事實(shí)上，每個(gè)月或者每星期花費(fèi)一些時(shí)間來(lái)研究和保持當(dāng)前狀態(tài)的web程序安全一直是個(gè)好主意，這是很小的投資，但是你得
 
安徽新華電腦學(xué)校專業(yè)職業(yè)規(guī)劃師為你提供更多幫助【在線咨詢】