Thoughts on Web Application Security (2)

Thank you for your interest and comments.
I want to use URL for security control as the basis for the security of my web application Program , there must be a lot of netizens who are puzzled, so let's explain the problem first.
using URL for permission control means:
1. As I mentioned in the previous article, the nature of Web applications is actually request. Therefore, the most direct and effective way to secure your web applications is to put every request within your control. This is like your web application is a large playground, and your security module is the entrance ticket check place for this playground. In this way, all the people who want to conduct your playground must have passed your qualification. In Web applications, they cannot bypass the entrance and go through the wall.
therefore, the key to using URL for security control is not to judge the URL, but to judge each request and check whether each request is valid to prevent security vulnerabilities.
I have already provided the practice, that is, the httpmodule implementation in the previous article.
2. Using URL for security control is a high abstraction of Web Application Security. You can call the new method when designing your web application regardless of security issues. You do not have to check whether you have the permission to call these methods before calling these methods. Because the legality of the user action has been verified before your method is executed, it is valid.
in this way, security control can be decoupled from the business logic, independent of each other. The advantage is self-evident: security control can be dynamically adjusted without affecting the web application itself; security control components can be reused without the need to reconsider this issue every time a new system is developed.

Before proceeding with my design, please refer to the security control method that comes with Asp.net.
Asp.net. config provides the location section to complete page authorization, which is essentially the same as my URL-based security control, so that each request must pass authentication.
However, it simply divides the authorization subject into anonymous users, user names and role names, authorization objects are URLs or folders, and all the information is hardcode in the configuration file. This may be suitable for a small system, but it is far from enough for developing large enterprise application systems such as ERP.
1. First, all roles of my users can be dynamically changed (users can be added or deleted)
2. My users can adjust the permissions of a user or role at any time according to their specific business needs (that is, they can assign permissions themselves)
3. When the photo supervisor is on vacation, you can also assign permissions to other users based on their own settings to complete functions such as proxy.
4. I have many enterprise application systems. I want to centrally manage my users, roles, and their permissions (a dedicated permission control or distribution system)

At the end of my thoughts on Web Application Security (1), I provided a general framework for permission control.
It has the following features:
1. It is an httpmodule
2. It captures the authorizerequest event.
3. It extracts the user ID (authentication) and judges whether the user has the right (authorization) in this event, as well as the processing action (rejection) that does not have the permission.

Therefore, our security control module is designed from the three parts.
First, we need to design these three interfaces:
1. Authentication Interface

Interface iauthenticate
{
//The parameter is not passed because all context information of the request can be obtained through httpcontext. Current.
//Returns the user ID. If the user is not logged on, null is returned.
StringAuthenticate ();
}

2. Authorization Interface

Interface iauthorize
{
//Pass in the user ID for permission judgment. Other parameters are also obtained through httpcontext. Current.
//False indicates no logon permission.
BoolAuthorize (StringUserid );
}

3. Actions not authorized for Logon

Interface irequestrefuser
{
//This method is used to reject requests without permission.
VoidRefuse ();
}

For how to use these three interfaces, I haveCode, Replace getuserid, hasright, and other methods.

Now we will implement one by one interface
1. Authentication Interface
To control all requests, it is obvious that there is only one authentication method that is far from enough, just like aspx and Web Service. The former can be stored and used through cookies or sessions.

User ID, which may be called through the SOAP header or a parameter. Other user ID extraction methods may appear in the future. So I am not using the default certification category

The hardcode method uses dynamic loading of dynamic modules.

// First, I will add an authentication module. Each Authentication Module implements a type of request authentication method.

Interface iauthenticatemodule
{
//Whether the request matches the current Authentication Module
BoolIsmatch ();

//Authentication
StringAuthenticate ();

}

// My authentication implementation
Class Defaultauthenticate: iauthenticate
{
// Loaded Authentication Module
Arraylist _ modules =   New Arraylist ();

Static Defaultauthenticate ()
{
Read the configuration of the system and dynamically load the authentication module using the reflection mechanism
}

// Authentication
String Authenticate ()
{
// Traverse each module and find the First Matching module for authentication.
// So it is related to the configuration order (if there are two identical matches, you can put the dedicated module in front)
Foreach (Iauthenticatemodule In _ Modules)
{
If(Module. ismatch ())
{
ReturnModule. Authenticate ();
}
}
}
}

// Implementation is simple.
// As follows:
Class Webformauthenticatemodule: iauthenticatemodule
{
Bool Ismatch ()
{
If(Request. URL requests the aspx file)
Return True;
Return False;
}

String Authenticate ()
{
If (Session [ " Userid " ] ! = Null )
Return Session [ " Userid " ]. Tostring ();
Return   Null ;
}
}

// The following is the WebService authentication method:
Class Webserviceauthenticatemodule: iauthenticatemodule
{
Bool Ismatch ()
{
If(Request. URL requests the asmx file)
Return True;
Return False;
}

String Authenticate ()
{
StringUserid=Extract the user ID column of the SOAP Header
ReturnUserid;

}
}

 

Of course, you can implement some Authentication Modules in your security modules by default, and then put them in later configuration. If your new system has a new authentication method, you only need to implement a new authentication module and then configure it.

Let's go here today. I will implement authorization in the next article, hoping to give you some inspiration.