Jak ustawić flagę Secure w pliku cookie sesji ASP.NET?

146

Jak ustawić flagę Secure w pliku cookie sesji ASP.NET, aby był przesyłany tylko przez HTTPS, a nigdy przez zwykły HTTP?

Alex
źródło

Odpowiedzi:

127

Istnieją dwa sposoby, jeden httpCookieselement web.configpozwala na włączenie, requireSSLktóry przesyła tylko wszystkie pliki cookie, w tym tylko sesję SSL, a także uwierzytelnianie wewnątrz formularzy, ale jeśli włączysz SSL na httpcookies, musisz również włączyć go w konfiguracji formularzy.

Edytuj dla jasności: umieść to<system.web>

<httpCookies requireSSL="true" />
Akash Kava
źródło
13
+1 Aby wyjaśnić, należy to dodać do pliku web.config, aby ustawić bezpieczną flagę w pliku cookie uwierzytelniania na wartość true<httpCookies requireSSL="true" />
Tr1stan
8
Zauważ, że zależy to od konfiguracji (na poziomie serwera). Wyłączyłem region testowy z błędem „Aplikacja jest skonfigurowana do wysyłania bezpiecznych plików cookie. Te pliki cookie wymagają, aby przeglądarka wysyłała żądanie przez SSL (protokół https). Jednak bieżące żądanie nie jest przesyłane przez SSL”. Dzieje się tak, ponieważ mamy odwrotne proxy i przeglądarki łączą się z nim przez SSL, ale zwrotne proxy do serwera IIS jest na porcie 80, więc aplikacja nie uważała, że ​​jest zabezpieczona.
mlhDev
4
@Bargitta Obsługiwaliśmy zdarzenie Application_PreSendRequestHeaders i jeśli pewne ustawienie aplikacji jest prawdziwe, ustawiliśmy wszystkie pliki cookie na bezpieczne. To ustawienie aplikacji dotyczy tylko naszych zewnętrznych witryn HTTPS.
mlhDev
Rozumiem, więc cała twoja zewnętrzna witryna będzie używać HTTPS, dzięki.
Bargitta
Widziałem gdzie indziej, że po tym, jak IIS7 system.web został zastąpiony przez system.webserver, spróbowałem umieścić tam to ustawienie. W IIS 8.5 spowodowało to jednak błąd konfiguracji, ale wszystko działało, gdy dodałem sekcję system.web do pliku konfiguracyjnego i umieściłem tam ustawienie.
Eborbob
181

W <system.web>elemencie dodaj następujący element:

<httpCookies requireSSL="true" />

Jeśli jednak masz <forms>element w swoim system.web\authenticationbloku, spowoduje to nadpisanie ustawienia w programie httpCookies, przywracając go do wartości domyślnej false.

W takim przypadku musisz dodać requireSSL="true"atrybut również do elementu formularzy.

Więc skończysz z:

<system.web>
    <authentication mode="Forms">
        <forms requireSSL="true">
            <!-- forms content -->
        </forms>
    </authentication>
</system.web>

Zobacz tutaj i tutaj, aby uzyskać dokumentację MSDN dotyczącą tych elementów.

Martin Eden
źródło
2
Możesz uniknąć innych ustawień web.config zastępujących ustawienie <httpCookies requireSSL = "true" />, dołączając atrybut „lockItem”. Na przykład: <httpCookies requireSSL = "true" lockItem = "true" />. Więcej informacji tutaj dotnetnoob.com/2010/11/how-to-secure-aspnet-cookies.html
JTech
1
Ponadto, jeśli istnieje roleManagerelement, jego atrybut cookieRequireSSL="true"również powinien być ustawiony na true. Nr ref. msdn.microsoft.com/en-us/library/…
Jeff Mergler
dodając powyższe zmiany w powiązanych plikach, obiekty sesji nie działają w mojej aplikacji, stają się zerowe. jak mogę rozwiązać ten problem?
satya
Czy w swojej aplikacji używasz protokołu HTTP lub HTTPS? Flaga „bezpieczna”, którą tutaj ustawiamy, zapobiega wysyłaniu plików cookie przez połączenia niezaszyfrowane (tj. HTTP)
Martin Eden
21

Sprawy szybko się komplikują, jeśli mówisz o kodzie zaewidencjonowanym w środowisku przedsiębiorstwa. Odkryliśmy, że najlepszym rozwiązaniem jest umieszczenie w pliku web.Release.config następujących elementów:

<system.web>
  <compilation xdt:Transform="RemoveAttributes(debug)" />
  <authentication>
      <forms xdt:Transform="Replace" timeout="20" requireSSL="true" />
  </authentication>
</system.web>

W ten sposób nie dotyczy to programistów (działa w trybie debugowania), a tylko serwery, które otrzymują kompilacje wydania, wymagają, aby pliki cookie obsługiwały protokół SSL.

Mark D.
źródło
^^^ To ^^^ jest drogą. Więcej informacji: transformacje Web.Config
Jeff Mergler
0

bezpieczny - ten atrybut informuje przeglądarkę, aby wysyłała plik cookie tylko wtedy, gdy żądanie jest wysyłane przez bezpieczny kanał, taki jak HTTPS. Pomoże to chronić plik cookie przed przesyłaniem niezaszyfrowanych żądań. Jeśli dostęp do aplikacji można uzyskać zarówno za pośrednictwem protokołu HTTP, jak i HTTPS, istnieje możliwość, że plik cookie może zostać przesłany w postaci zwykłego tekstu.

Sanjeev Kumar
źródło
0

Opierając się na odpowiedzi @Mark D, użyłbym transformacji web.config, aby ustawić wszystkie różne pliki cookie na bezpieczne. Obejmuje to ustawienie anonymousIdentification cookieRequireSSLi httpCookies requireSSL.

W tym celu skonfigurowałbyś swój web.Release.config jako:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.web>
    <httpCookies xdt:Transform="SetAttributes(httpOnlyCookies)" httpOnlyCookies="true" />
    <httpCookies xdt:Transform="SetAttributes(requireSSL)" requireSSL="true" />
    <anonymousIdentification xdt:Transform="SetAttributes(cookieRequireSSL)" cookieRequireSSL="true" /> 
  </system.web>
</configuration>

Jeśli używasz ról i form uwierzytelniania z ASP.NET Membership Provider(wiem, że to starożytne) Warto również ustawić roleManager cookieRequireSSLi te forms requireSSLatrybuty jako zbyt bezpieczne. Jeśli tak, Twój plik web.release.config może wyglądać następująco (dołączony powyżej oraz nowe tagi dla interfejsu API członkostwa):

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.web>
    <httpCookies xdt:Transform="SetAttributes(httpOnlyCookies)" httpOnlyCookies="true" />
    <httpCookies xdt:Transform="SetAttributes(requireSSL)" requireSSL="true" />
    <anonymousIdentification xdt:Transform="SetAttributes(cookieRequireSSL)" cookieRequireSSL="true" /> 
    <roleManager xdt:Transform="SetAttributes(cookieRequireSSL)" cookieRequireSSL="true" />
    <authentication>
        <forms xdt:Transform="SetAttributes(requireSSL)" requireSSL="true" />
    </authentication>
  </system.web>
</configuration>

Tło na web.config zmienia się tutaj: http://go.microsoft.com/fwlink/?LinkId=125889

Oczywiście wykracza to poza pierwotne pytanie dotyczące PO, ale jeśli nie ustawisz ich wszystkich jako zabezpieczających, możesz spodziewać się, że narzędzie do skanowania bezpieczeństwa zauważy, a w raporcie pojawią się czerwone flagi. Zapytaj mnie, skąd wiem. :)

Jeff Mergler
źródło