Web|xml| Attack 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.
