Web Server Application Attacks - Research Paper Example

Web Server Attacks Web Server Attacks Common Attacks on Web Servers Denial of Service One of the attacks on web servers is theDenial of Service (DoS) attack. Such an attack could target the web server or the network utilities that support it with the intention of hindering or denying legitimate users from leveraging the web server services. One mitigation strategy for DoS attacks is to configure a web server in such a way aimed at letting it limit its consumption of OS resources. Some of the particular methods to accomplish this would be to set a limit on the level of hard drive space designated for uploads and installation of web content on logical partitions or hard drives that are different from web server application and the OS (Srivatsa et al., 2008). Injections Attacks A command injection attack refers to an attack aimed at compromising the sensitive information featured in the back end database that supports the interactive aspects of a web application. Included under this category are issues like cross-site scripting (XSS) and Structured Query Language (SQL) injection. To curb this attack, organizations need to plan and address the security matters that pertain to their web solutions during web development or planning stages. Examples of such approaches would be to hire web application developers with proper knowledge on use of more sophisticated database capabilities like stored procedures to reside in the back end database system or the concept of data objects when writing APIs to access the database system that supports the web utilities. Equally, XSS issues can be handled by employing Model Viewer Controller (MVC) frameworks like Codeignitor while developing web applications. Such frameworks have in-built capabilities to suppress the efforts of clients who try to launch XSS attacks. A precaution taken during the development or planning of a web application is worthwhile for the reason that security issues are harder to handle once a system is deployed or implemented. Illegitimate Access of Unencrypted Information The third type of attack that targets web servers is interception of unencrypted information that is channeled in communication sessions that take place between the client browsers and the servers. One way to combat this problem is to use Secure Socket Layer (SSL) in web-centered communication. SSL helps in creating an encrypted link between client-server communications. In particular, the concept uses SSL certificates (typically methods like symmetric and asymmetric encryption) to transfer sensitive information like social security numbers and credit card numbers. Figure 1: Illustrating the use of SSL In the diagram, the server first sends a copy that bears its asymmetric public key. In response to this, the browser will create a symmetric session key then encrypt the same using the asymmetric public key associated with the server. Afterwards, the server uses its asymmetric private key to decrypt the asymmetric public key in order to obtain the symmetric session key. At this level, the browser and the server will be in a position to use the symmetric session key to decrypt and encrypt internet-transmitted data (Tracy, Jansen & McLarnon, 2002). This measure is better placed in terms of jeopardizing illegitimate access of information given that the symmetric session key employed is only known to the browser in addition to being specific to Hypertext Transfer Protocol (HTTP) sessions. Architectural Design for Protecting Web Servers Fig 1: An architectural design for protecting web servers This approach suppresses DOS attacks through the use of two layers namely: congestion control and admission control. Congestion control regulates the level of resources designate to each admitted client. In addition, the server uses application-specific information about the characteristic of the client-submitted request in order to adaptively vary the priority of a client. On the other hand, admission control can be implemented by declaring a destination port number to serve as a basis for authentication for client machines. Lack of knowledge of the port number associated with the application makes it difficult for any illegitimate client to initiate a DoS attack. This prevents illegitimate client packets from consuming memory, network or computer resources at the web server as they go through higher layers within the network stack. Reasons why the U.S Government Cannot Take Action against Web Attacks Though knowledgeable about the ongoing attacks, the U.S government cannot deal with the security risks chiefly because of a leadership framework that leaves decisions regarding implementation of DNSSEC to the individual federal agencies. This security management approach has seen of the agencies totally disregarding the implementation of DNSSEC thus providing an avenue for hackers to initiate attacks aimed at poisoning the server cache. Consequently, the affected sites cannot take advantage of DNSSEC-in-built capabilities like public-key encryption and digital signatures in order to validate their domain names plus the corresponding IP addresses. In another sphere, many of the federal agencies have been very reluctant towards the idea of embracing DNSSEC in their sites. This is partly attributed to the beliefs of the CIOs that government sites are too secure to be hacked, yet the U.S federal agencies are so far the likely targets of hactivist-style attacks that are on the rise. Bettering DNSSEC DNSSEC is intended to counteract every DNS cache poisoning attack by permitting the verification of domain names plus the corresponding IP addresses through digital signatures as well as public encryption keys. Unfortunately, hackers have still been in a position to exploit the Kaminsky vulnerability despite the deployment of DNSSEC. Even if a situation arises where the use of DNSSEC would become widespread, it would still not individually eliminate the misdirection of the domain associated with a DNS. It is in this light that continued use of DNSSEC within the sites owned by the Federal agencies would need to be coupled with proper verification and authentication procedures. Verification There is need to perform verification of the DNS of a domain at every authoritative source in order to attain security in DNSSEC. This verification solution would need to be extended to cover the present pitfall in the way DNSSEC addresses cache poisoning. In particular, the approach works by validating the responses generated by caching servers at ISPs along with the business enterprise of interest. Though the technological methods could vary, implementation of this two-layer approach would be worthwhile if the U.S government agencies intend to depend on DNS as a trusted data source (Gregg & Haines, 2012). Authentication The DNSSEC used in the US government sites would need the DNS-based Authentication for Named Entities (DANE) protocol for authentication purposes. This approach will allow authentication of TLS (Transport Layer Security) clients plus server entities that do not bear a certificate authority (CA). DANE would make it possible for a domain name administrator to certify every key that is leveraged in servers or TSL clients within that domain by storing those details in the DNS. In addition, DANE would permit a domain owner to define the CA permitted to give certificates for a specific resource thus can help in solving the problem of a CA being able to issue certificates to all domains. References Gregg, M., Haines, B. (2012). CASP CompTIA Advanced Security Practitioner Study Guide: Exam CAS-001. Hoboken: John Wiley & Sons. Srivatsa, M., Iyengar, A., Yin, J., & Liu, L. (2008). Mitigating application-level denial of service attacks on Web servers: A client-transparent approach. ACM Transactions on the Web (TWEB), 2(3), 15. Tracy, M., Jansen, W., McLarnon, M. (2002). Guidelines on Securing Public Web Servers Web Servers. NIST Special Publication, 800, 44. Read More