是什麼形式的認證來保護，而不是使用會話變量

我的工作，它使用Session變量來跟蹤用戶的應用程序，母版頁上檢查它的存在，否則敲出來登錄。我想改變這個表單身份驗證，因爲我認爲它更安全，數據被加密。是什麼形式的認證來保護，而不是使用會話變量

有人能告訴我什麼數據實際上是加密的嗎？我嘗試在我的網站上設置Forms Authentication，它工作正常，用戶正在被正確地跟蹤，並且不能在沒有登錄的情況下訪問頁面。但是，當我查看Request Body時，使用Fiddler，我看到了所有表單字段，內容。黑客不能使用它來更改數據並重新提交請求，就像使用從Session變量生成的cookie一樣？這個應用程序沒有使用SSL，所以我理解SSL會加密正文，但我認爲這也是Forms身份驗證所要做的。否則它會加密什麼，只是Cookie中的會話ID？

這裏是我使用的代碼：在登錄頁面我試圖手動創建的cookie

<authentication mode="Forms"> 
    <forms loginUrl="default.aspx" name=".ASPXFORMSAUTH_Test" defaultUrl="home.aspx" protection="All"/> 
</authentication> 
<authorization> 
    <deny users="?"/> 
</authorization>

：

    FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, 
        txtEmail.Text, 
        DateTime.Now, 
        DateTime.Now.AddMinutes(30), 
        false, 
        txtEmail.Text, 
        FormsAuthentication.FormsCookiePath); 

       // Encrypt the ticket. 
       string encTicket = FormsAuthentication.Encrypt(ticket); 

       // Create the cookie. 
       Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, encTicket)); 

       // Redirect back to original URL. 
       Response.Redirect(FormsAuthentication.GetRedirectUrl(txtEmail.Text, false));

我也試過：

FormsAuthentication.RedirectFromLoginPage(txtEmail.Text, false);

獲得相同的結果，Fiddler的請求主體顯示所有提交的字段及其內容。

來源

2013-05-14 Paritosh

不是你的問題的答案（我猜cookie值包含一些哈希信息，但不知道。）。無論如何，你不應該手動設置cookie。你應該依賴FormsAuthentication.SetAuthCookie。這裏的一些細節：http://stackoverflow.com/a/15199149/1236044 – jbl 2013-05-14 14:50:20

您不應該在沒有SSL的情況下處理用戶憑證或其他敏感數據。

無論你是否使用SSL，發佈的數據始終是從客戶端可見，而且總是可以「僞造」。 SSL（如果使用得當）可以防止「中間人」傾聽通信信息，但重要的是要認識到，如果不嚴格實施，它幾乎沒有用處，因此您還應該考慮使用Strict Transport Security，即使它不被所有瀏覽器支持。

會話ID不是「加密的」，但會話ID（在實踐中）不能被「猜測」。HTTP（S）是無狀態的，您無法確定某個客戶端的請求本身是否是惡意的。任何請求都會攜帶來自客戶端的所有cookies，並進行加密或不加密（當然，如果cookie內的數據是加密的，很難僞造它的內容）。

可以做什麼以及應該做什麼是嘗試和保護cookie免於逃避適當的上下文， XSS和CSRF攻擊。默認情況下，FormsAuthentication僅針對其Cookie使用HTTP。爲了確保您的網頁上的所有Cookie的HTTP只，放在你的web.config以下：

<httpCookies httpOnlyCookies="true" />

爲了確保所有Cookie綁定到一個安全的連接，使用：

<httpCookies requireSSL="true" />

現在，主要原因是您應該先使用Forms身份驗證，這是一種經過驗證的解決方案。 OWASP Top 10中破壞的認證和會話管理不是2，僅僅是因爲它比你想的要難。

表單身份驗證還增加了非常易於配置的優點，並正確加密了存儲區中的用戶憑據（如果您告訴它）。根據基於現代GPU的暴力可能性，標準實現決不是防彈的，但至少它沒有做錯。

如果您想了解更多關於標準實現如何執行業務的信息，您可以使用任何免費的反編譯器。

來源

2013-05-14 15:46:22

當你說發佈的數據總是可見的客戶端，你的意思是如果我使用或不使用SSL，在我的機器上運行的提琴手將始終顯示未加密的請求主體。但是，如果有人在服務器上安裝了fiddler，而我沒有使用SSL，他們會看到我的請求正文，但是如果使用SSL，他們會看到是否加密？ – Paritosh 2013-05-14 15:52:05

這就是理論，是的。實際上，與CRIME，BEAST或Lucky 13一樣，「安全」連接可能仍然會受到影響。從壓縮和其他修改可能應用的角度來看，SSL並不是一個統一的標準，並且當缺陷被揭示時，SSL又會被利用。這是關於這個主題的許多有趣和相當新聞的文章之一：http://arstechnica.com/security/2013/03/new-attacks-on-ssl-decrypt-authentication-cookies/。與往常一樣，安全是關於減輕風險，並減輕我們必須 - 除了相對意義上的情況外，我們不可能很快看到任何「安全」網絡。 – 2013-05-14 17:11:27

我發現我可能誤解了你的評論，所以要清楚 - 我所說的「理論」是，如果流量通過SSL進行保護，則不應該有可能被竊聽。在附註中，使用數字簽名可以確保任何數據（加密的或未加密的）在發送方和接收方之間的方向上都沒有改變。 – 2013-05-14 17:26:16

表單身份驗證使用FormsAuthentication對象爲用戶設置cookie。該cookie包含用戶的標識信息。我不確定這個cookie是否僅僅是HTTP，因爲只有HTTP的cookie只能在服務器上使用，而不能在客戶端上使用。這些cookie在服務器上解密，它抓住你的用戶ID等。

所以如果它不是一個HTTP唯一的cookie，那可能是一個問題，除了信息是加密的，所以用戶將不得不解密並知道底層的密鑰。會議我認爲只有會話ID被安全地跟蹤，而不是實際的信息。用戶的信息仍然存儲在服務器上。

最後，第一個和最重要的防禦，人們提到這些天是SSL。你可以從我發現得到便宜，因爲10 $證書......

來源

2013-05-14 14:44:35

當我看到在提琴手的餅乾，我看到它包含此：.ASPXFORMSAUTH_Test = BE08825FDBCD2B2679CDBA0095CCECXBE5117A7BC81022C5C142870B6576B943C4984F362318D5121FB28F644AE9B7EDC957F537AB83A839BA0511BB068AFFE067175A9D538F7B3C96DE8E22F0A3D8B4A6DB631298DD26607D8A72B1081979BBAB02D8CE8908C88A9CDE8EB8C26F709EAF7B376C59DBA227467C974CDDC634K6，我猜是加密的數據，你知道那是什麼，它只是SessionID？請求體仍然可以在Fiddler中看到，但看起來像是ViewState，猜測唯一的方法就是通過SSL來保護它。 – Paritosh 2013-05-14 15:00:30

這是加密的數據。注意表單身份驗證與會話ID無關，因此SessionID不會播放它。 Viewstate也是通過它的本質進行加密的。加密不是100％完美的，但非常非常難以打破，並且可能只能被一小部分非常熟練並願意花費大量時間來打破它的人羣打破。更常見的是，有人可能會嘗試暴力攻擊或重播攻擊。 – 2013-05-14 16:21:21

切換的方法給窗體身份驗證不會使它更安全。這意味着您將使用更加標準化的身份驗證機制，以便審覈您的軟件是否存在與身份驗證相關的問題。

而且FormsAuthentication通常能夠甚至當會話過期的用戶（或應用程序池回收），因爲它存儲了用戶的數據與自己的過期策略工作在加密的Cookie。

來源

2013-05-14 15:23:48

是什麼形式的認證來保護，而不是使用會話變量

回答

相關問題