Security issues and solutions for Ajax access to Xml Web Service

In asp.net ajax, updatepanel is commonly used. The operations that need to be refreshed are embedded in updatepanel and become ajax operations! However, ajax also supports interaction with Xml Web Services. This method is more like the traditional ajaxpro and other ajax frameworks, such as jquery, magicajax, and extjs. However, MS is always unique, who makes his product design so powerful! I'm afraid I can't tell you what to say. Let's talk a little bit about how asp.net ajax calls xml web service. If you're familiar with it, just skip it.

1. create an Asp. net Ajax websites or network applications, I use vs2008. In vs2008, if the website is supported. net framework 3.5 has the default support for ajax, which is nothing to say about Chen zhima.

2. After creating the project, add a Web Service UserService. asmx in the root directory of the website, and add the following method to UserService. asmx:

[WebMethod]
Public bool UserAdd (string userName, string pwd)
{
Return true;
}

Note that Attribute must be added to the upper part of the service class.

[System. Web. Script. Services. ScriptService]

3. Modify the ScriptManager in default. aspx to the following code:

<Asp: ScriptManager ID = "ScriptManager1" runat = "server">

<Services>

<Asp: ServiceReference Path = "UserService. asmx"/>

</Services>
</Asp: ScriptManager>

Next we will create the code to consume this UserService Using Ajax on the page: mainly including:

<H2> Example 1 of Ajax calling Xml Web Service
<Div style = "border: 1px solid Black; width: 50%; padding: 10px;">

<Table class = "style1">

<Tr>

<Td>

User name:

</Td>

<Td>

<Input id = "txtName" type = "text"/>

</Td>

</Tr>

<Tr>

<Td>

Password:

</Td>

<Td>

<Input id = "txtPwd" type = "password"/>

</Td>

</Tr>

<Tr>

<Td>

& Nbsp;

</Td>

<Td>

<Input id = "Button2" type = "button" value = "Submit" onclick = "userAdd ()"/>

</Td>

</Tr>

</Table>

</Div>

Add the following script in Function userAdd ()

{

Var name = $ get ("txtName"). value;

Var pwd = $ get ("txtPwd"). value;

AjaxWs. UserService. UserAdd (name, pwd, userAddCallBack );

}

Function userAddCallBack (res)

{

Alert (res );

}

4. Well, now a simple example code for ajax to call web service has been completed, and Luo suo has a lot to do. In fact, it is simple and cannot be simple. Run the page and click Submit. The effect is as follows:

Success. Generally, this step will be successful. Except for the following ,:)

Some of them are normal. That's all right here. Long live ajax! Good web service! The following are some of the questions after thinking a little bit.

Question 1:

The preceding Xml Web Service is not protected. If UserAdd is a database insert operation, the system can only be called successfully by authorized users. In the past, I saw some friends discuss how ajax calls xml web service with SoapHeader. I think it is not necessary! Js is a client-side thing that cannot be sent out and cannot be returned. The Sky knows what kind of goods the user is. If I try to pass the identity information to SoapHeader through js, the possibility of password interception is relatively high. The correct method is actually Session. we know that you can use the Session by adding a [WebMethod (EnableSession = true)] to the Web Service method. Session is used to maintain the Session, adds a network service method. The implementation function of this method is the same as that of UserAdd, but adds access restrictions.

[WebMethod (EnableSession = true)]

Public bool UserAddSecurity (string userName, string pwd)

{

If (Session ["UserID"] = null)

{

Return false;

}

Return true;

}

On the page, set AjaxWs. userService. userAdd (name, pwd, userAddCallBack); changed to AjaxWs. userService. userAddSecurity (name, pwd, userAddCallBack); click Submit. the pop-up result is false!

Add a button to the page, click this button to simulate login, and click the Code:

Protected void Button3_Click (object sender, EventArgs e)

{

Session ["UserID"] = "jillzhang ";

}

After clicking the login button, click submit again to return true. In this way, access to the xml web service is restricted. Solved Problem 1.

Question 2:

This problem involves the xml web service Architecture defect, which has been corrected and compensated in WCF. We know that web service is a technology that exposes and shares strength. It is called a service and must be provided to other applications. But in fact, many services serve local or special individuals, rather than the ideal public. In the old xml web service, the release of wsdl is tied to the release of the network service. I deploy. asmx to iis, then add? The wsdl can access the service's wsdl. Wsdl is a description of a service. If you know it, you can develop a customer proxy to consume the service. However, there is a problem: My service only needs to be known to some or special people, others do not want to access it. This is troublesome. I release. asmx, And the wsdl will be released. The discovery of wsdl relies on UDDI, which is described in the following section:

How can UDDI be used?

If the industry releases a UDDI standard for flight Rate Detection and booking, airlines can register their services in a UDDI directory. Then the travel agency can search for the UDDI directory to find the airline reservation interface. When this interface is found, the travel agency can immediately communicate with this service, because it uses a set of well-defined booking interfaces.

If the UDDI directory is traversed, it is not difficult to find the WSDL. After the WSDL is found, the development client can interact with the service. This is not a good thing. In problem 1, authorization can solve a problem. But if my service is like this, it returns the current time of the server, this method is open to users on our website. It may be difficult to add a Session. However, I only want my own ajax to access this service and do not want others to discover and call it. However, the original xml web service Architecture does not meet this requirement. If an attacker finds that he may develop a client based on the public wsdl, and then continuously launch DDOS attacks and disasters!

I still have no good solutions for the original web service. Of course, this does not mean that there is no solution. Some friends know this, so please be patient.

However, the above issue is fully taken into account for the WCF architecture. Let's take a look at the comparison between the old Xml Web Service Architecture and the WCF architecture below:

1) Old Architecture

 

2) New Architecture

 
The difference is obvious. The old architecture, MEX, has a very high degree of coupling with the business, and the new architecture, however, will separate the two, but will increase flexibility. If it is a service developed by WCF, you can configure it to remove the MEX endpoint when releasing the website, so that the above problems can be solved. The specific instance is discussed below, a bit sleepy, sleep!

Attached sample project:

/Files/jillzhang/AjaxWs.rar