Django Book學習筆記（下）

中大黑熊發表於2014-04-22
Django筆記

Django的Session框架

對於Django加密，大致使用這樣的格式：

hashtype$salt$hash

原因？

  • 一次雜湊是一次單向的加密過程，你能容易地計算出一個給定值的雜湊碼，但是幾乎不可能從一個雜湊碼解出它的原值。
  • 如果我們以普通文字儲存密碼,任何能進入資料庫的人都能輕易的獲取每個人的密碼。 使用雜湊方式來儲存密碼相應的減少了資料庫洩露密碼的可能。
  • 然而，攻擊者仍然可以使用 暴力破解 使用上百萬個密碼與儲存的值對比來獲取資料庫密碼。 這需要花一些時間，但是智慧電腦驚人的速度超出了你的想象。
  • 更糟糕的是我們可以公開地得到 rainbow tables （一種暴力密碼破解表）或預備有上百萬雜湊密碼值的資料庫。 使用rainbow tables可以在幾秒之內就能搞定最複雜的一個密碼。
  • 在儲存的hash值的基礎上，加入 salt 值（一個隨機值），增加了密碼的強度，使得破解更加困難。 因為每個密碼的salt值都不相同，這也限制了rainbow table的使用，使得攻擊者只能使用最原始的暴力破解方法。
  • 加入salt值得hash並不是絕對安全的儲存密碼的方法，然而卻是安全和方便之間很好的折衷。

 十.快取機制

      我在Django中使用了Memcached，Memcached完全就是基於記憶體的快取框架。Memcached有一個很好的特性是：它在多個伺服器間分享快取的能力。 這意味著您可以在多臺機器上執行Memcached的守護程式，該程式會把這些機器當成一個單一快取，而無需重複每臺機器上的快取值。 要充分利用此功能，請在CACHE_BACKEND裡引入所有伺服器的地址，用分號分隔。

      注意關於Memcached的一個缺點就是：基於記憶體的快取有一個重大的缺點。 由於快取的資料儲存在記憶體中，所以如果您的伺服器崩潰，資料將會消失。 顯然，記憶體不是用來持久化資料的，因此不要把基於記憶體的快取作為您唯一的儲存資料快取。 毫無疑問，在Django的快取後端不應該用於持久化，它們本來就被設計成快取的解決方案。但我們仍然指出此點，這裡是因為基於記憶體的快取是暫時的。

 

十一.Web開發中可能遇到的一些攻擊及其防範

下面一大段來自複製貼上，不喜勿噴：

SQL隱碼攻擊

  • SQL隱碼攻擊 是一個很常見的形式，在SQL隱碼攻擊中，攻擊者改變web網頁的引數（例如 GET /POST 資料或者URL地址），加入一些其他的SQL片段。 未加處理的網站會將這些資訊在後臺資料庫直接執行。
  • 這種危險通常在由使用者輸入構造SQL語句時產生。 例如，假設我們要寫一個函式，用來從通訊錄搜尋頁面收集一系列的聯絡資訊。 為防止垃圾郵件傳送器閱讀系統中的email，我們將在提供email地址以前，首先強制使用者輸入使用者名稱。
#無安全性的程式
def user_contacts(request):
    user = request.GET['username']
    sql = "SELECT * FROM user_contacts WHERE username = '%s';" % username
    # execute the SQL here...

如果攻擊者在查詢框中輸入 "' OR 'a'='a" 。 此時，查詢的字串會構造如下：

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

解決方案：
一些整合的web框架會自動幫你做好轉義操作，總之別要輕易使用get方法（除非確定是對系統資訊無害或者是自己已經做好了過濾的操作的情況下）

跨站點指令碼 (XSS)

      在Web應用中， 跨站點指令碼 (XSS)有時在被渲染成HTML之前，不能恰當地對使用者提交的內容進行轉義。 這使得攻擊者能夠向你的網站頁面插入通常以 <script> 標籤形式的任意HTML程式碼。    攻擊者通常利用XSS攻擊來竊取cookie和會話資訊，或者誘騙使用者將其私密資訊透漏給被人（又稱 釣魚 ）。

      這種型別的攻擊能夠採用多種不同的方式，並且擁有幾乎無限的變體，因此我們還是隻關注某個典型的例子吧。 讓我們來想想這樣一個極度簡單的Hello World檢視：

from django.http import HttpResponse

def say_hello(request):
    name = request.GET.get('name', 'world')
    return HttpResponse('<h1>Hello, %s!</h1>' % name)

 這個檢視只是簡單的從GET引數中讀取姓名然後將姓名傳遞給hello.html模板。 因此，如果我們訪問 http://example.com/hello/?name=Jacob ，被呈現的頁面將會包含一以下這些：

<h1>Hello, Jacob!</h1>

但是，等等，如果我們訪問 http://example.com/hello/?name=<i>Jacob</i> 時又會發生什麼呢？

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

當然，一個攻擊者不會使用<i>標籤開始的類似程式碼，他可能會用任意內容去包含一個完整的HTML集來劫持您的頁面。 這種型別的攻擊已經運用於虛假銀行站點以誘騙使用者輸入個人資訊，事實上這就是一種劫持XSS的形式，用以使使用者向攻擊者提供他們的銀行帳戶資訊。

解決方案：

解決方案是簡單的： 總是轉義可能來自某個使用者的任何內容。為了防止這種情況，Django的模板系統自動轉義所有的變數值。

偽造跨站點請求

  • 偽造跨站點請求(CSRF)發生在當某個惡意Web站點誘騙使用者不知不覺的從一個信任站點下載某個URL之時，這個信任站點已經被通過信任驗證，因此惡意站點就利用了這個被信任狀態。
  • Django擁有內建工具來防止這種攻擊

會話劫持（無線wifi下由其注意的安全問題）

  • 中間人攻擊：檢索所在有線（無線）網路，監聽會話資料。
  • 偽造會話 ：攻擊者利用會話ID（可能是通過中間人攻擊來獲得）將自己偽裝成另一個使用者。
  • 偽造cookie ：就是指某個攻擊者覆蓋了在某個cookie中本應該是隻讀的資料。
  • 會話滯留 ：攻擊者誘騙使用者設定或者重設定該使用者的會話ID。
  • 會話中毒 ：攻擊者通過使用者提交設定會話資料的Web表單向該使用者會話中注入潛在危險資料。

相關文章