.NET technology versus J2EE ,your security and that of your clients

Microsoft's .NET technology offers significant advantages over Sun's J2EE In June 2000, the Redmond company presented a language-independent environment designed to facilitate the development of Windows applications capable of working and communicating securely and simply. Eight years later, 70% of Spanish developers use .NET The numbers don't lie. Currently, the presence of this Microsoft programming environment in the market for Windows application development tools is overwhelming. And this platform has established itself as an effective alternative to Sun's J2EE (Java 2 Platform Enterprise Edition) (https://www.sun.com/java), which also provides important advantages when designing distributed applications. The key? Its two essential pillars: tools and web services. Inside .NET The components that make up this development environment are called .NET Framework and consist of the CLR (Common Language Runtime), a hierarchy of class libraries, and support for different types of applications, including tools modeled on the traditional client-server architecture, as well as web applications and services. In addition, .NET provides libraries that facilitate database access and XML management code; indeed, this metalanguage has positioned itself on this platform as a de facto standard for application interoperability. The CLR is at the heart of the environment; in fact, it is a virtual machine responsible for providing an abstraction layer between .NET bytecode and the hardware platform on which it runs (for example, the x86 architecture and compatibles). This layer, equivalent to the Java virtual machine in the J2EE environment, has serious implications for application development and security. In essence, the CLR prevents the developer from accessing the platform at a low level, this component being the only one that can, for example, access memory and manage pointers directly. In addition, code developed for the .NET platform runs under certain configurable security roles that vary depending on whether it is trusted and also according to its origin (intranet, Internet, etc.). Many of the attacks suffered by Windows operating systems have begun to disappear (among them, the well-known and infamous buffer overflow) because now the programmer does not have direct access to native memory management. It is evident that having this capability, this extra layer that abstracts from direct hardware manipulation (just as happens in the Java environment), has its cost in execution time, especially if the applications we write are distributed. Any compiler that generates code for the .NET platform must do so in an intermediate language known as IL (Intermediate Language), which in turn conforms to a specification that brings together the guidelines that .NET languages must comply with (CLS or Common Language Specification). The resulting IL is translated into native code using just-in-time strategies, so the time overhead caused by this intermediate layer is not excessive. A multilingual platform As we mentioned before, the .NET Framework is independent of the language used, which means that those we choose for our applications must be translated into a binary language understandable by the platform. For this reason, developers who use the services of this platform can employ several high-level languages and make them operate with each other. Microsoft has created compilers for Visual Basic, C++ and C#, although there are also compilers for this platform that have not been created by Microsoft. Language neutrality has greatly increased the attractiveness of .NET technology, especially when considering the cost that must be faced to migrate from other platforms. In fact, migration from J2EE is practically immediate, since a Java application can be converted without much effort into a .NET program using cross-compilers. Moreover, any group of Java developers can adopt C# as a language without serious consequences. C# is the language championed by Microsoft as the banner for .NET programmers and, at the same time, the tool with which it pursues the capture of developers from other platforms. Indeed, to attract programmers coming from the Java environment, Microsoft created an initiative called JUMP (Java Users Migration Path), which means something like 'the path a Java developer must follow to program in .NET'. In any case, Java and C# are two similar languages, especially at the semantic level, a capability that allows the existence of applications that facilitate conversion between both languages. Is .NET more secure than J2EE/Java? The .NET platform is, without a doubt, a much more secure execution framework than the standard environment provided by Windows. This does not mean that there is no possibility of security holes occurring; in fact, there are many problems of this nature that developers must face. Even so, it is fair to say that it lacks many security flaws that Java did suffer. Moreover, it is evident that Microsoft has learned from the mistakes Sun made in its early days, although this can also be counterproductive because it has not started its journey from scratch, and that lack of experience can also be a reason for distrust. However careful the development of the .NET platform may be, and indeed it is, one can reach the conclusion that the person really responsible for potential dangerous situations is the developer himself, who on many occasions ignores the basic principles of secure programming. Those programmers who create insecure web applications with VBScript and ASP will surely write potentially insecure applications when developing with Visual Basic in ASP.NET (a component of the .NET Framework that makes the existence of web applications and services possible). The CLR does not provide protection against code that contains defects or that unnecessarily exposes private or compromising information. The .NET class libraries are endowed with numerous security features that are used to ensure that applications will be as secure and robust as possible. In the field of web utilities, an example of these capabilities is the possibility of encoding all data in HTML to avoid XSS or cross-site scripting attacks (which exploit vulnerabilities in the embedded HTML validation system), and providing simple but secure methods when building dynamic SQL queries to avoid SQL injection attacks. In addition, session control and management in ASP.NET have become omnipresent. In this way, in addition to the control provided, it also allows scaling or growth of web applications from one server to a set of them, storing session variables in SQL Server database machines. SOAP and web services A key feature of the .NET platform is support for XML as a means for interaction between applications and web services. The latter expose fragments of the application's business logic outside the firewalls, although they normally use SOAP (Simple Object Access Protocol), a protocol that facilitates the exchange of XML-encoded data and the performance of remote procedure calls (invocation of functions or methods of other applications, whether local or remote). The .NET environment provides libraries that ensure data transport through a protocol (such as HTTP) and its security using digital certificates, thereby facilitating the creation of web services. The CLR, for its part, guarantees the robustness of the application that processes data received through a web service. However, using SOAP to communicate a .NET component with another J2EE component does not guarantee that this process will be carried out without difficulties. The Web Services Interoperability organization (WSI) works to resolve these inconveniences, a problem that must be considered when porting a web service to .NET. Facing migration When an application of considerable size is moved from one platform to another, there will surely be problems with the code. In some cases, the code with which the components used by the application to be migrated were developed is not available, or even the hardware to which we intend to migrate will impose its own conditions, making it impossible in many cases. Applications that use low-level code to communicate with other logic components cannot be ported to the managed environment offered by the CLR. For this reason, Microsoft has included certain functionality in this latter component that allows it, under certain circumstances, to execute unmanaged code preceded by the unsafe statement. This keyword is very interesting from a security point of view. Suppose a web application manages user request and data entry with C# (managed code). After being processed, this information is transmitted to unmanaged code that accesses the shared memory of a third-party developed component. This element handles communication with the company server. Under this scenario, the code that runs in the unmanaged section may contain errors, so a system user could ruin the entire application and even execute arbitrary code. For this reason, the unsafe keyword should be avoided as much as possible, as it cancels all the security options that the platform and the CLR offer to applications. The .NET Framework is also harmed by the temptation to package complete applications developed in C++ with this keyword and proclaim that they have been ported, opening huge security holes unfairly attributed to .NET. This technique is popular among developers who are running short on time to meet deadlines imposed by clients. Preventing attacks When developing code that is to run on the client, it is important to remember that the user can manipulate and interrupt execution regardless of the language in which it is written (Java, a .NET language, C++, C, etc.). With patience and time, code can be subjected to reverse engineering techniques that reveal relevant details, so it is recommended not to overlook secure coding advice and adopt sensible criteria, such as not including sensitive information in executables, especially passwords. Both Java bytecodes and .NET assemblies can easily be subjected to these types of techniques, even more easily than executables from a native platform. This is because both .NET and Java have an intermediate abstract layer that relies on a simple and clean specification, so 'understanding' executables for these platforms (there are tools such as dotfuscator to make these practices more difficult) is easier than 'decompiling' native executables (which will run directly on processors). From the client security perspective, a user can establish rules that grant different privileges to different portions of code. Code that runs in a restricted and controlled environment is said to be processed in a sandbox or sandpit. A user can choose to automatically run code that has been digitally signed by certain companies and, in this way, grant all privileges on their machine to any code coming from the intranet of those companies. In this way, any application coming from an unidentified environment will be labeled as hostile code and its execution will be carried out in a restricted and highly controlled environment. However, many attacks have been documented whose origin is attributed to implementation errors in the sandboxes of various Java virtual machine vendors, which are usually intimately related to class loaders. And if the identity of the loader that provides the code to be executed on the client can be hidden or falsified, then it is possible to allow code from an unauthorized vendor to pass itself off as code from a trusted vendor, thereby gaining access to all privileges on the user's system. So far, this type of attack has not occurred on the .NET platform. Unstoppable growth Microsoft's development environment provides many security improvements and significantly facilitates the implementation of distributed applications. Although Sun's J2EE development platform is much more mature than the .NET Framework, those in Redmond are betting heavily and are gaining key third-party support, very important in the sector. The advantages of running managed code are undeniable and the CLR has learned from the attacks suffered by Java, thereby avoiding a large part of the weaknesses known to date. However, it is important to remember that defects and errors in each developer's implementation are undetectable, and perhaps attackers are more interested in exploiting these weaknesses to access company data than in gaining access to the server on which the application is running.