Odpowiedzi:
Istnieją dwa sposoby, jeden httpCookies
element web.config
pozwala na włączenie, requireSSL
któ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" />
W <system.web>
elemencie dodaj następujący element:
<httpCookies requireSSL="true" />
Jeśli jednak masz <forms>
element w swoim system.web\authentication
bloku, 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.
roleManager
element, jego atrybut cookieRequireSSL="true"
również powinien być ustawiony na true. Nr ref. msdn.microsoft.com/en-us/library/…
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.
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.
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 cookieRequireSSL
i 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 cookieRequireSSL
i te forms requireSSL
atrybuty 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. :)
<httpCookies requireSSL="true" />