web|xml| attack protects XML Web services from hackers, [] part I] [Part II]
Matt Powell
Microsoft Corporation
September 19, 2001
In the previous article, we discussed different kinds of attacks and how to configure them to avoid attack. In this article, we will focus on how to design and develop to avoid attack.
First, I'd like to introduce two very good new tools that are Microsoft® developed to maximize security for your WEB server. The IIS Lockdown Tool (English) can prevent possible attackers from accessing your microsoft®internet information Server (IIS). The lock tool also provides the "advanced" option, where you can select the settings you want. In addition, the "Rollback changes" option is also available. You can select this option when you are dissatisfied with the changes you made. Please try the tool.
Another important tool is the Hotfix Checking Tool (English) for IIS 5.0. The tool queries the XML document for all available security patches published by Microsoft, which is constantly updated, and then compares this document to the native-installed document and reports its differences. This tool makes it easier to manage security patches for individual Web servers or large web domains.
Design Problems
Designing WEB Services requires careful consideration of security issues and how to minimize the risk of being attacked. Many of the factors that might work when trying to prevent an attack can be considered at design time. For example, consider how to authenticate, or what kind of error you want to return.
Identify security requirements
Early in the design of XML WEB services, you need to determine the level of security required. Some XML Web services do not require authentication at all, while other services have very stringent requirements for determining who uses the service. What level of privacy is required for data received and sent by an XML Web service? If an XML Web service user declares that they did not request the services specified in your record, what costs might be incurred in terms of hours, processing power, or legal fees?
First, let's take a look at authentication. Some kinds of authentication are more susceptible to attack than other forms of authentication. At the low end, if you use HTTP Basic authentication, you can see your user name and password visible to all users of the packets on the network. If you send a request over the Internet, you cannot control who can see your packet. At the high end of the authentication level, you can consider using SSL client certificates for authentication, which provides an encoded channel and makes it difficult for a malicious attacker to attack a packet. For a detailed discussion of authentication options, see the authentication and Authorization of Mary Kirtland in the Your Service column.
We have alluded to privacy issues in the authentication process, and you should consider this issue when it comes to spoofing. You also need to know about the privacy issues associated with all the data sent and received from an XML Web service, not just your username and password. For example, you might generate a session key for authenticated users who send this key along with each request to identify themselves. If this key is not encrypted, the packet's malicious attacker can see the key and use it to send its own request to your Web service so that your Web service will consider it as the original legitimate user.
Another privacy issue is the simple data sent and received by the WEB service. Does the data need to be encrypted because of its strong sensitivity? The price of SSL encryption is that the WEB service sends and receives the entire encrypted channel, which degrades performance. You may be able to encrypt only the sensitive items in the request, but you may then need to install the custom-written software on the client to enable encryption/decryption. One advantage of using SSL to encrypt the entire channel is that most client platforms currently support basic SSL communication without the need to write specific code for the application.
As far as basic security design is concerned, the concept of denial must also be considered, that is, a user can refuse to acknowledge the actions it performs through an XML Web service. For example, if you provide a stock trading service, and some people claim that they did not ask your system to sell their shares, and deny the sale order. Obviously, some XML Web services may be more concerned about this problem than other services, but you should determine the risks that your service might encounter and what effective measures should be taken in the scenario.
Using a secure authentication system is certainly the first step in avoiding this type of danger. For example, using HTTP Basic authentication may not be secure, but using this authentication by using an encrypted channel with SSL is safe. If a user uses a blank password or an easily guessed password, even a secure authentication system is useless. Enforcing strong encryption passwords is an important step in preventing this type of problem from occurring. In short, users and service-holders are responsible for preventing password leaks.
Finally, if there is no audit of events that occur through the service, secure authentication and strong encryption passwords are meaningless when there is a denial. When there is a denial threat in a transaction, you should record enough information about these transactions and their users, time, dates, and so on to identify the details of the transaction. Otherwise, when there is an argument, you may lack sufficient evidence to substantiate your point of view.
auditing, reporting, and monitoring
Audits play an important role in reducing the risk of denial, and also play a key role in identifying other types of attacks. For example, if the statistics in your audit record indicate that your service has unusual usage, you may not be aware that your service is under attack. For example, do you notice that someone is making a dictionary attack on a login? So, we'll talk about issues that need to be considered when auditing, reporting, and monitoring to protect XML WEB services from attacks.
The concept of auditing is to record all information about each event that occurs. However, this idea may be impractical when the amount of data that is passed through an XML Web service is large. The audit record should include at least the time, date, and IP address of all requests. If the XML Web service is authenticated, you need to include the user name in each audit record. If your service supports multiple methods or message formats, you need to identify which one is invoked. Finally, you need to include enough information to meet your need to identify the calling details. For example, if an XML Web service uses a method, you might want to record all the parameters passed to the method.
You also need to consider other needs, such as when a site is attacked, you may need to roll back the transaction. Also, your audit records are often the best source of information for some reports. Because audit records can be quite large, you need to coordinate audit design and backup strategies.
Auditing deals with records of all events that occur at the same time through your service, reporting the use of the system to users, operators, and administrators. Reporting is an important part of protecting an XML Web service from attack because it allows you to observe the usage of the service. One of the main reporting types is reporting errors. The ability to report errors encountered by an XML Web service is paramount. Again, you need to report errors that may indicate malicious client attempts. For example, if a parameter in the received request is an exception long string, you need to report the error in an easily noticeable way. For this type of error, you should create events in the application event log so that they can be monitored accordingly. For more information about how to write an event to the event log, see event Logging in the operating system platform SDK.
Another type of report that is critical to your service is a report that summarizes service usage. It should have two forms: first, create a global report for your personal analysis that you can use to detect usage levels or exception patterns. You should have a good understanding of the appearance of the normal report so that you can discover unusual usage. Second, you need to provide reports to your users. Your users should also be able to monitor their use of the service. It is quite possible that an attack is not recorded in the global report, while individual users can immediately discover the problem in their respective reports.
If the XML Web service is running on Internet information Server (IIS), then it is necessary to mention a very useful report type that is available for free. That is, IIS logging for all incoming HTTP requests, including requests for your service. You can use the information provided in the IIS log to improve your own reports. '
Finally, after implementing the audit and appropriate reporting methods, you need to use some mechanism to discover the reported problems. This is surveillance.
can be monitored at different levels. Of course, a regular manual view of a report is a way to monitor the usage of an XML Web service, but you should also check for errors reported in the event log, use performance monitoring logs, and take advantage of one of several tools that can monitor WEB server downtime. Performance monitoring can be critical for detecting attacks. Fortunately, the large number of performance counters associated with IIS can provide many important statistical data for detection problems.
You may also want to create your own performance counters for XML Web services. For more information about creating your own performance counters, see Performance Monitoring (English). In order to ensure your special attention to exceptional situations, it is important that you notify you of the events that are occurring in some form. You can use performance monitoring alerts to send pop-up messages or run a program when an exception event occurs. The performance monitoring alerts shown in Figure 1 monitor the number of incomplete IIS ISAPI requests and the number of ASP requests in the current queue.
Figure 1: Creating Performance monitoring Alerts
If you do not do something about a problem that may occur, it is not useful to audit, report, and monitor abused operations. A denial of service attack may be defined to a specific IP address, which means that you may need to filter requests from that address in the router. However, denial of service attacks or spoofing attacks may be associated with specific users of an XML Web service. You must be able to disable the account when this problem occurs. You may want to disable the Windows user account only in microsoft®active directory™ when you complete this operation. Alternatively, if you are using your own design authentication method, you must add a status field in the user record that can represent the disabled account. You should also confirm that the users of the XML Web service agree to the terms of service document, which indicates under what circumstances you can delete or disable their accounts.
Defining interfaces
One of the main benefits of XML Web server applications, compared to other Web applications, is a good definition of the entire XML schema that is passed to your application. For application designers and developers, this means that you already know that the data that the XML WEB service must handle has a valid format. If the received data is malformed, then tools such as Microsoft®soap Toolkit 2.0 or the. NET Framework will filter out the request so that you don't have to worry about it.
For example, you do not have to parse whether the syntax for date input is valid. The date must have a valid XSD format, or the request will be discarded. You might want to take advantage of structural validation, so do not hide the structure in a string variable. The ability and flexibility to use XML can fully describe the data sent and received.
Servers that are not visible
When hackers attack your system, the first thing you look for is information. Does this web site reside in Windows or in other systems? Are you running Active Server Pages? Do you have the Index Server installed? Are known vulnerable components installed? Do you have a known vulnerable CGI application installed? Is the host running Microsoft®sql Server? Can I make a distributed COM (DCOM) call to this server?
For sites that do not want to be attacked, even very smart Internet users should not be able to answer any of these questions. The less you know about your system and the less you know about the platform, the harder it is to find problems on your server.
For example, imagine what they would know if the hacker only knew the URL of the XML Web service as "http://www.coldrooster.com/ssf/account.asp". Because this URL has an extension of. ASP, they can assume that this is a Windows computer running Active Server Pages. Based on hackers ' knowledge of the default configuration of the Internet information Server, they already have enough information to attack a large number of improperly configured vulnerabilities. They can make a lot of possible assumptions about the configuration method and use these assumptions to spy on the computer.
What if the URL is "http://www.coldrooster.com/ssf/account/"? In this case, the hacker does not have the information of the operating system used by any server, nor does it assume the configuration of the system. Mapping virtual directory-level requests to a particular ASP page is a very small configuration option, but can provide a lot of protection for the server.
Users familiar with the basic HTTP protocol may notice that the HTTP header specifically indicates the type of WEB server being used. Yes, this is another more complex way to determine the operating system on your computer, but you can also write an ISAPI filter to delete or replace this header. For information about how to do this, see Developing ISAPI Filters (English), and Sf_notify_send_response (English) notification in the IIS Programmer's Guide. The more difficult it is to identify the underlying system running on the server, the more likely it is that hackers write scripts to find a type of computer on the Internet.
But the operating system itself is not the only weakness. What do you do when you create an ASP page that executes SQL queries at the back end and throws an exception? Do you want to return exception information to the user's browser? This not only points out the Web server platform, but also points out the database platform. In addition, it can use the user to understand the specific SQL queries you are working on and provide them with information about how to change the content to be entered into the form to get information that they should not have access to.
What happens when other COM exceptions occur? If you propagate exception information to the user, the hacker will know which COM components are installed on your computer. If this COM object is a third-party DLL, the hacker can get a copy of it and make every effort to search for any weaknesses that may exist. This at least gives the hacker an opportunity to understand the problems that may exist on the server.
Similarly, hackers may use the fact of triggering a COM exception to block the server. Hackers realize that most exception code paths are not adequately tested and are often the cause of resource leaks or worse. To avoid this situation, the code on the server should be able to catch all exceptions and should return only universal errors. For XML Web Services, you should return SOAP errors with little platform information. You may want to return the data to the user in some way, along with the ID, to compare the errors with the records in the audit log, but place the error details in the audit log instead of the returned SOAP error. It is recommended that the Application Designer create a SOAP error schema for his or her application, provide a very short list of options, and return only the errors on this list. Clients calling XML Web services do not have to know the details about SQL query exceptions, they only need to know that a SOAP server error has occurred.
If you are using Microsoft®soap Toolkit 2.0, you can implement on the COM object
Isoaperrorinterface to return the exact SOAP error you want to return, rather than the generic toolkit error. A generic toolkit error can provide a large amount of information about what happened on the server when the error occurred. In the development phase, tool pack errors are useful for debugging, but they should not appear on the product server. They can provide a lot of potentially damaging information for hackers.
The user of an XML Web service needs to know the format of the SOAP message that your service sends and receives, as well as the endpoint location of your service. That's enough. Any other information will only provide a potential hacker with the means to destroy your system. To protect yourself, you should limit the return of platform-related information and eliminate unwanted content on your computer, including removing any default virtual directories or script mappings that help others identify your system.
Development issues
For hackers, the vulnerability of the server is inversely proportional to the quality of the code running on the server. It includes the quality of the underlying system (operating system, Web Server, and SOAP tools being used) and the quality of code written for a particular application. It may also include all other code running on the server, even if the code is not part of the application. But from a developer's perspective, we want to consider the issues we can control and what special actions can be taken to ensure the quality of the code, and avoid increasing the vulnerability of all other applications that are running on the XML Web service and on the server.
Buffer overflow
The most fearsome type of attack on the server is an attack that a remote user can perform malicious code that causes the system to be completely compromised. Most of these attacks are caused by a buffer overflow error. A typical example of this error is to assign a fixed length to a local variable in C code, and then the code copies the information from the HTTP request into the variable. If you think the data in the request is not larger than the value you set, a malicious request to your server can exceed that value and cause the data it sends to exceed the end when it is written to the allocated buffer. For local variables, the buffer is stored on the stack and the code address to return at the end of the current function is also stored in the stack. By writing beyond the end of the local variable buffer, the hacker can overwrite the return address and return the function to any address he wants, including Windows
CreateProcessThe address of the function. To pass to
CreateProcessThe parameters of the function are also stored on the stack, and if the hacker overwrites the location where the parameters are stored, you can effectively start any application they want to start on the server.
To avoid this type of attack, do not make any assumptions about the data read from the request, and then make sure that there are no errors in the processing code of the buffer. The following functions should be extra cautious for C/C + + programmers:
strcpy、
strcat、
memcpy、
gets、
sprintf、
scanfAnd variations of all of these functions, such as
lstrcpy、
wcscpy、
CopyMemoryetc.). Please note that
strncpyFunctions and other "n" functions are only slightly better because in these scenarios the length variable is often determined by the program, and it is still possible to overwrite a fixed-length buffer. The length parameters in the "n" function should be based on the size of the output buffer, not the size of the passed-in string. If you want to use these functions, use the "n" version and dynamically allocate your buffer from the heap to avoid possible stack overflows. In addition, the microsoft®visual studio®.net C compiler supports the new/GS switch, which allows the code to avoid many common buffer overflow problems.
With the. NET Framework and Management code, you can eliminate most potential buffer overflow problems. When Microsoft designed the. NET framework, it was aware of the benefits of garbage collection and how to eliminate problems caused by traditional buffer handling, so they provided the ability to manage code. You must be aware of the interaction between the management code and the unmanaged code. But at least you can ensure that your application is secure when you need it.
Check for errors
Check the return code of all calling functions. If you are calling the Win32 API, make sure that the call completed successfully. If you are allocating memory, make sure you do not return a NULL value. If you are making a COM call, especially if you are calling using Microsoft®visual basic® and you have specified an on Error Resume Next statement, make sure that the exception is not present. Again, do not make any assumptions about the results of such calls.
If you are calling Win32 security functions, you should be particularly cautious. For example, if you are calling
ImpersonateLoggedOnUser, you should check the return code for errors, otherwise it will be difficult to provide users with a higher security environment. Pay special attention to this when your WEB application is configured to run in-process on IIS, because the code may run with the local System account, which is almost unlimited on the local computer. It should also be noted that some cross COM calls may also run in threads with higher privileges.
Validate input as soon as possible
The first thing you should do when an XML Web service receives a request is to validate the submitted data. Web Service Description Language (WSDL) validation based on the schema will catch many errors, but you should immediately perform any application-level validation that is required. This includes checking for special characters, checking values in specific ranges, checking string lengths, and so on. Even if you think that all requests must come from a particular application, you should assume that the incoming data is invalid before you prove it. The fact is that requests for XML WEB services can come from anywhere. If you make assumptions about your data, you should assume that the data might come from a malicious user.
It is also important that the parameter validation code be completed quickly. The faster the identification of invalid requests is, the better. Otherwise, XML Web services are vulnerable to denial of service attacks. If your server handles illegal requests for a long time, it is likely that you will not be able to service legitimate requests. Always apply the same level of security as private data to the operations that consume time and resources. If you have to execute a time-consuming SQL query, or if an operation requires strong processing power, you first need to ensure that the request is legitimate. Is the user a legitimate user? Authenticating a request not only prevents invalid users from using resources on your server, but also provides the ability to track error usage in audit logs, allowing you to discover the illegal use of resources by specific users. If you are validating input, you should first validate the user's credentials. If you use the normal HTTP authentication mechanism, user authentication is performed for you before the code is called.
