ASP.NET application security program (1) - Authentication

zhaozj2021-02-16  83

ASP.NET application security program (1) - Authentication

ASP.NET application security program (1) - Authentication

Abstract: The concept of ASP.NET application authentication, introduces various authentication modes and compared, which describes the mechanism for selecting authentication mode, and gives a form of implementation based on form authentication mode.

Keywords: authentication Authentication ASP.NET web application

1. Authentication Concept Any successful application security policy is a solid authentication and authorization means, as well as secure communication for confidentiality and integrity of confidential data.

Authentication is a process identifying an application client. The clients here may include end users, services, processes, or computers, by authenticated clients as the main body (Principal). Authentication can occur across multiple layers of the application. End users start authenticate by the web application, typically performed according to the username and password; the request for the end user is processed by the intermediate layer application server and the database server, which will also authenticate and process these requests.

Figure 1 lists various security technologies and the main verification methods provided by each technology.

2. As shown in Figure 1, the authentication mode shows the following authentication on the .NET framework on Windows 2000:

ASP.NET Authentication Mode Enterprise Services Authentication SQL Server Authentication

2.1 ASP.NET Authentication Mode ASP.NET Authentication Mode includes Windows, Forms, Passport (passport), and NONE.

2.1.1 Windows authentication When this authentication mode is used, ASP.NET depends on IIS to verify the user and create a Windows Access Token to indicate the identity of the verified. IIS provides the following authentication mechanisms:

Basic authentication brief authentication Integration Windows Authentication Certificate Authentication Anonymous Authentication

2.1.2 Passport Authentication When using this authentication mode, ASP.NET uses Microsoft Passport's centralized authentication service, and ASP.NET provides a convenient packaging for the features provided by Microsoft Passport Software Development Cap (SDK). Wrapper). This SDK must be installed on the web server.

2.1.3 Form authentication This authentication method uses the client redirection function to forward the user who cannot pass authentication to a specific login form, requiring the user to enter its credential information (usually the username and password). These credential information is verified, the system generates an authentication ticket (Ticket) and returns it to the client. Authentication tickets can maintain the user's identity information during the user's session, and the list of roles belongs (optional).

2.1.4 None uses this authentication mode, indicating that you do not want to verify the user, or use a custom authentication protocol.

2.2 Enterprise Services Authentication Enterprise Services Authentication By using the underlying remote procedure call (RPC, Remote Procedure Call) transfer structure, this structure uses the operating system security service provider interface (SSPI, Security Service Provider Interface) . The client of the Enterprise Services application can be verified using the Kerberose or NTLM authentication mechanism. 2.3 SQL Server Authentication SQL Server can via the Windows Authentication Mechanism (Kerberose or NTLM), or by its built-in authentication scheme-SQL authentication mechanism verification mechanism. There are usually two available verification schemes.

2.3.1 SQL Server and Windows clients can be used to connect an instance of SQL Server via SQL Server authentication or Windows authentication mechanism. This approach is sometimes referred to as a mixed mode authentication.

2.3.2 Windows Only clients must connect to an instance of SQL Server by using a Windows authentication mechanism.

3. Selecting an authentication mechanism to design a distributed application authentication is a challenging task. In the early stages of application development, appropriate authentication design helps to reduce many security risks.

3.1 Comparison of various authentication mechanisms

Does the user need to have a Windows account in the server domain to support whether the delegate requires a Windows 2000 client and server credentials whether it is clearly transmitted (required SSL) whether to support non-IE browser

Basic authentication

Yes

Yes

no

Yes

Yes

Brief identification

Yes

no

Yes

no

no

NTLM authentication

Yes

no

no

no

no

Kerberos authentication

Yes

Yes

Yes

no

no

Certificate authentication

no

Yes

no

no

Yes

Form authentication

no

Yes

no

Yes

Yes

Passport authentication

no

Yes

no

no

Yes

3.2 Select the factors that the authentication mechanism needs to be considered

Labeling that only when the user has a Windows account with a trusted authority (which can be accessed by the application web server), using a Windows authentication mechanism is appropriate.

A critical advantage of credential management of Windows authentication is that it can use the operating system for credential management. When using non-Windows authentication methods, such as form authentication, you must carefully consider where and how to save user credentials. The most common way is to use the SQL Server database or use the User object located in Active Directory.

Identify whether the flow needs to implement an analog / entrustment model, and the secure context of the original caller is run across the operating system level - for example, to support the audit or subtle authorization for each user.

Does the browser type application have IE browser? Or do you need to support a user base with a hybrid browser? We need to consider the above factors based on the characteristics of various methods.

3.3 Selection Decision Process of the Intranet System See Figure 2.

3.4 SQL Server users verify the client of SQL Server verify, generally speaking that Windows authentication is more secure than SQL Server authentication, with the following main points:

The former is responsible for managing the credential information of the user, and the user's credentials will not transmit on the network. You can avoid embedding your username and password in the connection string. The login security can be improved by password expiration time, minimum password length, and account lock request after multiple invalid logins. This can be seen in the threat of a small dictionary attack. However, Windows authentication is not allowed in some specific application scenarios, for example:

Database clients and database servers are separated by a firewall, resulting in unable to use Windows authentication. The application needs to connect to one or more databases using multiple identifiers. The connected database is not SQL Server. There is no safe way in ASP.NET running code as a specific Windows user. In these scenarios, SQL authentication, or native authentication mechanisms of the database. 4. ASP.NET authentication implementation

4.1 Program characteristics In this section, only one of the authentication of the Intranet subdrafting mutual web application, this program assumes that the following features:

Only the app has passed the authenticated client to access the application. The database believes that the application has authenticated the user - that is, the application calls the database on behalf of the user. The web application is connected to the database by using the ASP.NET process account. The user's credential information is verified according to the SQL Server database. Use the form authentication mode. In a web application, the user's credential information is based on the SQL Server database, which is easy to implement user personalized design. The application represents the user's way to call the database, and the trusted subsystem model can be used to better utilize the database connection pool, and ensure that the user cannot directly access the backend database, and can reduce the backend ACL management work.

4.2 Safety Configuration Steps

4.2.1 IIS Configuration Steps Enable anonymous access to the virtual root directory of the Web service.

The main method is to use the IIS MMC management unit, right-click the virtual directory of the application, and then click Properties ---> Directory Security -> Anonymous Access and Security Control -> Editing.

4.2.2 ASP.NET Configuration Step 1. Reset the password (for running the ASP.NET) to a more secure password.

This allows a local account (with the same username and password) to be copied on the database server. To use Windows authentication to connect to the database, you can respond to network authentication requirements from the database from the database, which is necessary.

The specific method is to edit the Machine.config file located in the% windr% / microsoft.net / framework / v1.1.4322 / config directory, reconfigure the password properties on the element, and the default value is change to .

2. Configure ASP.NET to use Form authentication.

Edit the web.config file under the virtual root directory of the web service, set the element to:

4.2.3 Configuring SQL Server 1. Create a Windows account that matches the ASP.NET process account on the SQL Server database.

The username and password must match the ASP.NET application account.

2. Configure SQL Server to make it use Windows authentication. 3. Create a SQL Server login for a custom ASP.NET application account, grant access to SQL Server.

4. Create a new database user and map the login name as a database user.

5. Create a user-defined new database role and add a database user to the role.

6. Determine the database permissions for the database role.

4.3 Program Code

4.3.1 Authentication Event Sequence When the user who does not pass authentication triggers a protected file or resource rejection, the triggered event sequence is shown in Figure 3.

4.3.2 Code Realization Step 1. Build a web login form and verify the credential information provided by the user

Verify the credential information according to the SQL Server database.

2. Get a list of roles from your database

3. Create a form authentication ticket

Save the acquired role information in the ticket. The sample code is as follows:

Private void btnlogin_click (Object Sender, System.EventArgs E)

{

// Verify according to the SQL Server database (the specific implementation is omitted).

Bool isauthenticated = isauthenticated (txtusername.text, txtpassword.text);

IF (isauthenticated == true)

{

/ / Get the role of the user

String Roles = getroles (txtusername.text, txtpassword.text);

// create an authentication ticket FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket (1, // versiontxtUserName.Text, // user nameDateTime.Now, // creationDateTime.Now.AddMinutes (60), // Expirationfalse, // Persistentroles); // User Data

String encryptedticket = formsauthentication.encrypt (authticket); // Create cookiehttpcookie authcookie = new httpcookie (Formsauthentication.formscookiename, EncryptedTicket);

Response.cookies.add (authcookie);

// Redirect the user to the original request page. Response.Redirect (FormsAuthentication.GetRedirectURL (txtusername.text, false);}} 4. Creating an application_AuthenticateRequest event creates an iPrincipal object in the Application_AuthenticateRequest event, usually using the genericprincipal class.

5. Place the IPRINCIPAL object in the current HTTP context

protected void Application_AuthenticateRequest (Object sender, EventArgs e) {// Forms to provide authentication cookiestring cookieName = FormsAuthentication.FormsCookieName; HttpCookie authCookie = Context.Request.Cookies [cookieName];

IF (null == authcookie) {return;}

FormsAuthenticationTicket authTicket = null; try {authTicket = FormsAuthentication.Decrypt (authCookie.Value);} catch (Exception ex) {return;} if (null == authTicket) {return;} // extracted character string [] roles = authTicket. Userdata.split (new char [] {'|'});

// Create an Identity ObjectFormSidentity ID = New Formentity (Authticket);

GenericPrincipal Principal = New GenericPrincipal (ID, ROLES); Context.user = Principal;} The specific code reader can supplement itself.

5. The following will be discussed with the content related to the authorization and security communication.

转载请注明原文地址:https://www.9cbs.com/read-17874.html

New Post(0)