Home Technology How to Prevent Web Server Attacks

How to Prevent Web Server Attacks

by admin

Frequent Attacks on Web Servers

 Denial of Service

One of the attacks on web servers is the Denial of Service (DoS) attack. Such an attack could target the web server or the network utilities that support it to hinder or deny legitimate users from leveraging the webserver services. 

One mitigation strategy for DoS attacks is to configure a web server to limit its use of OS resources in such a way. Any of the common methods to achieve this will be to place a cap on the hard disk space reserved for uploading and installing web content on logical partitions or hard drives that are separate from the web server application and the OS (Srivatsa et al., 2008).

How to Prevent Web Server Attacks

Injections Attacks

A command injection attack refers to an attack that aims to compromise the confidential information featured in the back end database that supports the interactive features of a web app. Themes including cross-site scripting (XSS) and Structured Query Language ( SQL) injection are included under this group. To curb this attack, during web development or planning phases, organizations need to plan and address security issues pertaining to their web solutions.

Examples of such approaches would be to hire Web application developers with adequate knowledge on the use of more sophisticated database capabilities such as 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 web utilities. Likewise, XSS problems can be addressed using Model Viewer Controller (MVC) frameworks such as Code ignitor when designing web applications. Such structures 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 because security issues are harder to handle once a system is deployed or implemented.

Illegitimate Access to Unencrypted Information

The third type of attack on web servers is the capture of unencrypted information channeled between the client browsers and the servers during contact sessions. The use of Secure Socket Layer ( SSL) in web-centric communication is one way to combat this problem. SSL helps to create an encrypted link between the communications between client and server. In particular, the concept uses SSL certificates (typical methods like symmetric and asymmetric encryption) to transfer sensitive information like social security numbers and credit card numbers. 

Illustrating the use of SSL

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. Afterward, the server uses its asymmetric private key to decrypt the asymmetric public key to obtain the symmetric session key. At this level, the browser and the server will be able 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 browser in addition to being specific to Hypertext Transfer Protocol (HTTP) sessions only knows the symmetric session key employed.

Architectural Design for Protecting Web Servers

architectural design for protecting web servers

Figure 1: An architectural design for protecting web servers

This approach suppresses DOS attacks through the use of two layers: congestion control and admission control. Congestion control regulates the level of resources designates to each admitted client. The server also uses application-specific information about the characteristic of the client-submitted request to vary the priority of a client adaptively. 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 illegal 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 US Government Cannot Take Action Against Web Attacks

Though knowledgeable about the ongoing attacks, the US government cannot deal with the security risks chiefly because of a leadership framework that leaves decisions regarding the implementation of DNSSEC to the individual federal agencies. This security management approach has seen the agencies disregarding the deployment 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-inbuilt capabilities like public-key encryption and digital signatures 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 CIOs’ beliefs that government sites are too secure to be hacked, yet the US federal agencies are so far the likely targets of hacktivist-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, corresponding IP addresses through digital signatures, and public encryption keys. Unfortunately, hackers have still been able to exploit the Kaminsky vulnerability despite the deployment of DNSSEC. Even if the use of DNSSEC would become widespread, it would still not individually eliminate the misdirection of the domain associated with a DNS. In this light, continued use of DNSSEC within the sites owned by the Federal agencies would need to be coupled with proper verification and authentication procedures. 


There is a need to perform an audit of the DNS of a domain at every authoritative source 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 US government agencies intend to depend on DNS as a trusted data source (Gregg & Haines, 2012). 


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. Also, DANE would permit a domain owner to define the CA permitted to give certificates for a specific resource, thus solving the problem of a CA being able to issue licenses to all domains. 

  • 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.

related articles

Leave a Comment