① 如何檢查網站源碼是否有後門
一，把網站源碼放到空間里把網站建起來
二，網路搜360網站安全檢測，找到360用來檢測網站的站
三，認證網站，提交網址
四，幾分鍾後就會幫你檢測出網站的木馬或漏洞了
五，當然了，免費源碼漏洞肯有的，有些可能檢不出來，他是屬於程序員的經驗不足造成的，還有的是黑客故意留的，明顯的會檢查出來，免費源碼常理是不能用的，一是因為有版權問題，用了以後會有麻煩，另外還有安全隱患．別忘了放了這些源碼的都是些什麼人，他們讓你用這些源碼的目的．如果你是想正規做站，個人建議你還是去淘寶，200源碼網，拍拍，A5論壇花幾百元買些正品來用，注意是花幾百元，不是幾元幾十元，因為那些幾十元的大多也是免費的．
② 怎麼看一個網站的源碼是asp還是php還是asp.net
名鞋庫是PHP的，網頁文件後綴名是asp的則是asp源碼，是php的，則是php源碼，是aspx的，則是asp.net源碼。名鞋庫使用的是生成靜態頁設置，所以但從網址連接文件html是看不出的，要看頁面的核心源碼中是否包含了php鏈接來判斷是否采php系統。shopex是php系統
③ 網站如何添加https：//加密認證教程
網站想實現https加密訪問，必須申請部署SSL證書。SSL證書的申請流程如下：
第一步，生成並提交CSR（證書簽署請求）文件
CSR文件一般都可以通過在線生成（或伺服器上生成），申請人在製作的同時系統會產生兩個秘鑰，公鑰CSR和密鑰KEY。選擇了SSL證書申請之後，提交訂單並將製作生成的CSR文件一起提交到證書所在的CA頒發機構。
第二步，CA機構進行驗證
CA機構對提交的SSL證書申請有兩種驗證方式：
第一種是域名認證。系統自動會發送驗證郵件到域名的管理員郵箱（這個郵箱是通過WHOIS信息查詢到的域名聯系人郵箱）。管理員在收到郵件之後，確認無誤後點擊我確認完成郵件驗證。所有型號的SSL證書都必須進行域名認證。
第二種是企業相關信息認證。對於SSL證書申請的是OV SSL證書或者EV SSL證書的企業來說，除了域名認證，還得進行人工核實企業相關資料和信息，確保企業的真實性。
第三步，CA機構頒發證書
由於SSL證書申請的型號不同，所驗證的材料和方式有些區別，所以頒發時間也是不同的。
如果申請的是DV SSL證書最快10分鍾左右就能頒發。如果申請的是OV SSL證書或者EV SSL證書，一般3-7個工作日就能頒發。
等SSL證書頒發之後，將其正確部署到伺服器上就可以實現https加密訪問了。
④ 怎樣製作自己的網頁網站和添加SSL安全證書
網站製作好之後在數字證書網申請一張SSL證書部署到網站伺服器上即可
⑤ ASP.NET Core認證原理和實現
通常在應用程序中，安全分為前後兩個步驟：驗證和授權。驗證負責檢查當前請求者的身份，而授權則根據上一步得到的身份決定當前請求者是否能夠訪問期望的資源。
既然安全從驗證開始，我們也就從驗證開始介紹安全。
我們先從比較簡單的場景開始考慮，例如在 Web API 開發中，需要驗證請求方是否提供了安全令牌，安全令牌是否有效。如果無效，那麼 API 端應該拒絕提供服務。在命名空間 Microsoft.AspNetCore.Authentication 下，定義關於驗證的核心介面。對應的程序集是 Microsoft.AspNetCore.Authentication.Abstractions.dll。
在 ASP.NET 下，驗證中包含 3 個基本操作：
驗證操作負責基於當前請求的上下文，使用來自請求中的信息，例如請求頭、Cookie 等等來構造用戶標識。構建的結果是一個 AuthenticateResult 對象，它指示了驗證是否成功，如果成功的話，用戶標識將可以在驗證票據中找到。
常見的驗證包括：
在授權管理階段，如果用戶沒有得到驗證，但所期望訪問的資源要求必須得到驗證的時候，授權服務會發出質詢。例如，當匿名用戶訪問受限資源的時候，或者當用戶點擊登錄鏈接的時候。授權服務會通過質詢來相應用戶。
例如
質詢操作應該讓用戶知道應該使用何種驗證機制來訪問請求的資源。
在授權管理階段，如果用戶已經通過了驗證，但是對於其訪問的資源並沒有得到許可，此時會使用拒絕操作。
例如：
拒絕訪問處理應該讓用戶知道：
在這個場景下，可以看到，驗證需要提供的基本功能就包括了驗證和驗證失敗後的拒絕服務兩個操作。在 ASP.NET Core 中，驗證被稱為 Authenticate，拒絕被稱為 Forbid。 在供消費者訪問的網站上，如果我們希望在驗證失敗後，不是像 API 一樣直接返回一個錯誤頁面，而是將用戶導航到登錄頁面，那麼，就還需要增加一個操作，這個操作的本質是希望用戶再次提供安全憑據，在 ASP.NET Core 中，這個操作被稱為 Challenge。這 3 個操作結合在一起，就是驗證最基本的要求，以介面形式表示，就是 IAuthenticationHandler 介面，如下所示：
驗證的結果是一個 AuthenticateResult 對象。值得注意的是，它還提供了一個靜態方法 NoResult() 用來返回沒有得到結果，靜態方法 Fail() 生成一個表示驗證異常的結果，而 Success() 成功則需要提供驗證票據。
通過驗證之後，會返回一個包含了請求者票據的驗證結果。
在 GitHub 中查看 AuthenticateResult 源碼
那麼驗證的信息來自哪裡呢？除了前面介紹的 3 個操作之外，還要求一個初始化的操作 Initialize，通過這個方法來提供當前請求的上下文信息。
在 GitHub 中查看 IAuthenticationHandler 定義
有的時候，我們還希望提供登出操作，增加登出操作的介面被稱為 IAuthenticationSignOutHandler。
在 GitHub 中查看 IAuthenticationSignOutHandler 源碼
在登出的基礎上，如果還希望提供登錄操作，那麼就是 IAuthenticationSignInHandler 介面。
在 GitHub 中查看 IAuthenticationSignInHandler 源碼
直接實現介面還是比較麻煩的，在命名空間 Microsoft.AspNetCore.Authentication 下，微軟提供了抽象基類 AuthenticationHandler 以方便驗證控制器的開發，其它控制器可以從該控制器派生，以取得其提供的服務。
通過類的定義可以看到，它使用了泛型。每個控制器應該有一個對應該控制器的配置選項，通過泛型來指定驗證處理器所使用的配置類型，在構造函數中，可以看到它被用於獲取對應的配置選項對象。
在 GitHub 中查看 AuthenticationHandler 源碼
通過 InitializeAsync()，驗證處理器可以獲得當前請求的上下文對象 HttpContext。
最終，作為抽象類的 ，希望派生類來完成這個驗證任務，抽象方法 HandleAuthenticateAsync() 提供了擴展點。
驗證的結果是一個 AuthenticateResult。
而拒絕服務則簡單的多，直接在這個抽象基類中提供了默認實現。直接返回 HTTP 403。
剩下的一個也一樣，提供了默認實現。直接返回 HTTP 401 響應。
對於 JWT 來說，並不涉及到登入和登出，所以它需要從實現 IAuthenticationHandler 介面的抽象基類 AuthenticationHandler 派生出來即可。從 AuthenticationHandler 派生出來的 JwtBearerHandler 實現基於自己的配置選項 JwtBearerOptions。所以該類定義就變得如下所示，而構造函數顯然配合了抽象基類的要求。
在 GitHub 中查看 JwtBearerHandler 源碼
真正的驗證則在 HandleAuthenticateAsync() 中實現。下面的代碼是不是就很熟悉了，從請求頭中獲取附帶的 JWT 訪問令牌，然後驗證該令牌的有效性，核心代碼如下所示。
在 GitHub 中查看 JwtBearerHandler 源碼
在 ASP.NET Core 中，你可以使用各種驗證處理器，並不僅僅只能使用一個，驗證控制器需要一個名稱，它被看作該驗證模式 Schema 的名稱。Jwt 驗證模式的默認名稱就是 "Bearer"，通過字元串常量 JwtBearerDefaults.AuthenticationScheme 定義。
在 GitHub 中查看 JwtBearerDefaults 源碼
最終通過 AuthenticationBuilder 的擴展方法 AddJwtBearer() 將 Jwt 驗證控制器注冊到依賴注入的容器中。
在 GitHub 中查看 JwtBearerExtensions 擴展方法源碼
一種驗證處理器，加上對應的驗證配置選項，我們再為它起一個名字，組合起來就成為一種驗證架構 Schema。在 ASP.NET Core 中，可以注冊多種驗證架構。例如，授權策略可以使用架構的名稱來指定所使用的驗證架構來使用特定的驗證方式。在配置驗證的時候，通常設置默認的驗證架構。當沒有指定驗證架構的時候，就會使用默認架構進行處理。
還可以
注冊的驗證模式，最終變成 AuthenticationScheme，注冊到依賴注入服務中。
在 GitHub 中查看 AuthenticationScheme 源碼
各種驗證架構被保存到一個 IAuthenticationSchemeProvider 中。
在 GitHub 中查看 IAuthenticationSchemeProvider 源碼
最終的使用是通過 來實現的，通過一個驗證模式的字元串名稱，可以取得所對應的驗證控制器。
在 GitHub 中查看 源碼
它的默認實現是 AuthenticationHandlerProvider，源碼並不復雜。
在 GitHub 中查看 AuthenticationHandlerProvider 源碼
驗證中間件的處理就沒有那麼復雜了。
找到默認的驗證模式，使用默認驗證模式的名稱取得對應的驗證處理器，如果驗證成功的話，把當前請求用戶的主體放到當前請求上下文的 User 上。
裡面還有一段特別的代碼，用來找出哪些驗證處理器實現了 ，並依次調用它們，看看是否需要提取終止請求處理過程。
在 GitHub 中查看 AuthenticationMiddle 源碼