2010-04-20 106 views
5

我最近開始在Django上工作,現在我的應用即將完成,我開始懷疑安全和最佳做法。Django查看安全和最佳做法

我有一個視圖,生成一個頁面和不同的功能,在頁面發佈AJAX請求到單個視圖。例如,我有一個名爲show_employees的視圖,我可以通過向視圖delete_employee和update_employee傳遞發佈請求來刪除和更新員工。

  1. 我已經把@login_required裝飾這些視圖之前,因爲我不希望任何人訪問這些未經驗證的情況做。這個可以嗎?

  2. 在delete_employee和update_employee視圖中,如果它是AJAX POST請求(uisng is_ajax()),我只迴應請求。這個可以嗎?

  3. 當視圖成功執行所需操作時會返回'成功',並且在表單中存在驗證錯誤時出現錯誤,但我仍未處理其他異常。我應該怎麼做?我應該通過一個AJAX響應返回標準500頁面,如this,通過用try-except塊封裝視圖來處理所有異常?

  4. 我還能做些什麼來保護我的視野嗎?

這裏是我的一個樣本觀點:

@login_required 
    def add_site(request): 
     data = {} 
     if request.method == 'POST': 
      if request.is_ajax(): 
       form = AddSiteForm(request.user, request.POST) 
       if form.is_valid(): 
        site = form.save(commit=False) 
        site.user = request.user 
        site.save() 
        data['status'] = 'success' 
        data['html'] = render_to_string('site.html', locals(), context_instance=RequestContext(request)) 
        return HttpResponse(simplejson.dumps(data), mimetype='application/json') 
       else: 
        data['status'] = 'error' 
        data['errors'] = {} 
        for field, error in form.errors.iteritems(): 
         data['errors']['id_'+field] = strip_tags(unicode(error)) 
        return HttpResponse(simplejson.dumps(data), mimetype='application/json') 

謝謝。

回答

11

嗯,而不是隻使用@login_required,我建議你看看permissions framework和相關permission required decorator。通過這種方式,您可以在用戶或組的基礎上優化訪問限制。與僅使用login_required裝飾器相比,使用權限更改用戶行爲也更簡單更安全。假設現在你只有管理員,但後來你想添加其他類型的用戶,那麼很容易就會錯過login_required裝飾器,然後授予這些用戶訪問管理員視圖的權限。您將不會有正確定義的權限的問題。

接下來,is_ajax只檢查HTTP_X_REQUESTED_WITH標頭。這與安全性無關,但與用戶友好的行爲有關。這樣,您可以防止普通用戶在瀏覽器中意外打開該頁面並獲取一些奇怪的數據。它對安全性沒有任何幫助,每個體面的黑客都可以設置額外的HTTP頭:)。

如果您不小心遺留在DEBUG=True上,則不會處理異常可能會帶來潛在危險,在這種情況下,django將提供代碼和回溯,可能會帶來不足之處。但是,如果此選項關閉,django將顯示它自己的500錯誤頁面。我的建議是:尋找所有預期的Django異常(並不是那麼多),並確保你正確地捕獲這些異常。另外我會說,讓另一個異常由django處理,django仍然會提供生成回溯和其他調試信息的可能性,並將這些信息發送給管理員,而不是在現場顯示它們。如果您發現所有意外錯誤,則此行爲將不會直接提供,可能會讓您未知代碼失敗。

最後,在您處理用戶輸入數據時,我建議您查看django書中的security chapter,它解釋了最重要的威脅以及如何在django框架中處理它們。