Web|xml| attack
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.
Close the back door.
Sometimes it is appropriate to provide a way to solve certain problems on the server during the development phase of a project. For example, XML Web services often generate a key to identify the same user across multiple invocations, or to maintain a state between those calls. For ease of debugging, additional code is often added to accept a key consisting of all keys, rather than generating a real key. However, if you do provide a mechanism to avoid certain detections for legitimate debugging purposes, be sure to delete these back doors before the XML Web service takes effect.
Again, avoid providing smart mechanisms to ignore security issues, even if you think it will help support the long-term operation of the service in the long run. Consider the situation where an XML Web service is undergoing application-level authentication. The following might be tempting: The Secret administrator-level username is hard-coded into your code, allowing people who have forgotten their administrator account password to be able to access the system. However, after the first user has used the door, the secret is compromised and all other users of the code will be vulnerable.
In fact, the secret is likely to leak even before the first legal use of the back door. If the backdoor account and password are stored as strings in your code, it is easy for others to see any strings that have been defined in the code through the delivered binaries. If a hacker sees a string similar to "Secretadministrativeuser" in a DLL, he suspects that the string might be a backdoor into the code and try to use it.
Finally, on the back door, you should not provide a common way to collect information on the server. Although it usually helps to support the product, in many cases it produces the opposite result. Do not create code that can view or download source code in a configuration file or system. Although creating such code makes it easy to analyze unusual conditions on the server, hackers can use it to get the same information. Typically, user names and passwords are stored in the configuration file, and many companies believe that the intellectual property of their source code is its most valuable asset. This risk is even greater when you consider the ability to often view files for other applications on the server. So even if the XML Web service code is invulnerable to these capabilities, there may still be more vulnerable applications on the server.
Summary
Attacks on WEB systems do occur, such as the Red Code worm and its variants, which is a very troubling example. Fortunately, there are some steps you can take to reduce the risk level of XML Web services. Hopefully we can help you understand some of the potential vulnerabilities and how to avoid them so that you can create secure XML Web services.
