The Importance of Heightened Security for Web Applications


With the Internet playing such a great part in our lives today, with more people engaging on social media, and with the dramatic increase in e-commerce, the security of Web applications is a major concern for users, developers and businesses. Here is a comprehensive look at the vulnerability and security of Web applications.

We all think twice before entering any of our sensitive personal details like bank account number, address or phone number on any Web application platform, fearing others might access these and use them inappropriately. Well, that fear is quite justified. As per the 2017 TrustWave Global Security Report, almost 99.7 per cent of Web applications scanned by TrustWave had at least one vulnerability. This makes it quite challenging for stalwarts like Amazon and Walmart to maintain the trust of their customers in terms of the data security provided by them on their platforms. They need to envelope their Web applications using a highly insulated security sheath that does not let any cyber criminals invade or attack their app.

As technology evolves, cyber attackers are becoming wiser and trying out different means to attack various Web applications. They continuously keep looking for even small glitches that can let them enter applications and steal data. Nowadays, malvertisements are being widely used by cyber criminals in different applications. With a mere US$ 5, they can infect more than 1000 vulnerable computers using these malicious advertisements. Likewise, there are a few other factors that add to the vulnerability of a Web application.

The first criterion for Web app developers is to fulfil the functional requirements of the customer and then take care of the performance of the application. They must ensure the application is fast and is flexible enough to adapt in the evolving IT arena. Typically, the security of the Web application is the last consideration. But not giving security priority often leads to something big going wrong, and it’s only then that the developers become concerned about it. However, implementing security checks at this juncture amounts to a good deal of extra cost for the stakeholders.

Web application security mainly deals with protecting a Web application or online service against various security threats that exploit vulnerabilities associated with the application’s code. It’s actually a cross-functional concern. If a Web app developer carefully checks out and removes the maximum possible vulnerabilities from the code during the development phase itself, then automatically, the security threat associated with the Web app reduces to a great extent. Some of the common targets for Web app attacks are content management systems, database administration tools and SaaS applications.

There are a couple of common measures like SSL encryption, using a secure host, etc, that can reduce the risk and vulnerability associated with Web applications. But at the same time, it’s also necessary for Web apps to have their platforms updated, because hackers are always on the lookout for flaws that might be found in case of outdated versions of scripts. There should be a very strict and strong password policy for every Web application. Nowadays, hackers use sophisticated software (brute force attacks) to crack different passwords. So to protect against such attacks, passwords need to be complex. If by any chance the developer fails to secure the Web app on a particular e-retailer’s site, the client’s information can be stolen and ruin the relationship between the seller and buyer. In the worst case, it may even lead to legal proceedings; so caution is advocated.

Figure 1: How a Web app firewall works

Why Web applications are targeted by cyber criminals

Web apps are targeted mainly for the following reasons:

  1. The inherent complexity of the source code for the Web apps increases the likelihood of unattended vulnerabilities, as well as the chances for malicious code manipulation.
  2. It’s easy to break the security of Web apps as most of the attacks can be automated by using Web bots that can be launched against tens of thousands of targets at the same time.
  3. Hacking a Web app can yield high value rewards including sensitive data that can be collected using successful source code manipulation.

A few critical Web application security risks

Most hackers attack Web applications through cross-site scripting and SQL injection. Any flaws in the code, and a failure to sanitise application inputs and outputs, result in this. There are a bunch of other such critical security risks that cyber criminals exploit. As per the Open Web Application Security Project (OWASP), here are the ten most critical security risks of 2017.

  1. SQL injection
  2. Broken authentication
  3. Sensitive data exposure
  4. XML external entities (XXE)
  5. Insecure direct object references
  6. Security misconfiguration
  7. Cross-site scripting (XSS)
  8. Insecure de-serialisation
  9. Using components with known vulnerabilities
  10. Insufficient logging and monitoring

How to build a secure Web application

Here are some of the significant steps that lead to security-centric computer programming and help build a low-risk Web app.

Query parametrisation: There have been a couple of high-visibility attacks against different Web applications that have been traced back to attacks involving SQL injection, which has enabled the stealing of passwords. Governments, businesses and social network sites have all fallen victim to this, making it a universal issue. As a testament to the size of the problem, a recent ‘Website Security Statistics Report’ by White Hat found that 7 per cent of all the Web apps still contain SQL injections. While many of us consider it as a vendor issue, it’s actually a developer and programming issue. Data fields, Web form comment boxes or any another area of a form that allows free data entry or open string input, can actually lead to this kind of vulnerability. This can also be transmitted through various non-visible Web elements like HTTP header values. This kind of simple insertion of malicious SQL code (which is impractical to validate and protect, at times) can be used to potentially wipe out entire databases or even run different malicious OS commands against the database. Hence, to stop SQL injection, developers must prevent all such untrusted inputs from being interpreted as SQL commands. This can be best implemented using query parametrisation.

Secure password storage: Indeed, the worst method for storing passwords is in the form of plain text; however, encryption is also not much better. Next on the list is MD5 or any such standard hashing algorithms that are, of course, fallible. Most of the hackers today have access to powerful computing resources that are not very expensive and allow them to create, or buy, rainbow tables. This helps different modestly strong passwords to be deciphered in real-time. Rainbow tables are not much in use these days, while high performance computers can be used to carry out high speed dictionary attacks. Salting is actually the coding technique required to help defeat rainbow table attacks. With a few resources, attackers can create a GPU cracking rig that can execute around 25 billion attempts or even more per second —against the stored passwords. So it’s recommended that you combine three major techniques, i.e., usage of the one-way algorithm, a salt, and an algorithm that is purposely slow, to prevent GPU cracking rigs and other similar resources from exposing passwords. Some of the algorithms like PBKDF2 and SCRYPT are amazing examples of algorithms that can be used safely to store passwords.

Contextual output encoding XSS defence: Cross-site scripting (also called XSS) or JavaScript injection can be used for site defacement, session hijacking, network scanning, site redirection/phishing, undermining cross-site request forgery (CSRF) defences, data theft and keystroke logging. Contextual output encoding is one of the crucial programming techniques required to stop XSS. This is usually performed on the output (while building a user interface), at the last moment, before any untrusted data is added to the HTML part during runtime.

Content security policy: A content security policy is one of the emerging browser standards. The main reason behind this policy is to create a standardised framework in order to provide browser-based protection that stops XSS, with less developer involvement. In order to put the content security policy into practice, all JavaScript that is embedded in HTML has to be removed and then deployed in a separate external JavaScript file. If a content security policy-aware browser detects any JavaScript embedded in a HTML document – for instance, if a hacker tries to insert JavaScript — then the action is rejected. This ultimately locks down the browser, preventing many forms of XSS attacks.

Cross-site request forgery: If a user has logged into a secure site and then tries to open another tab and launch a malicious site, the secure site could possibly host a forged request taking advantage of the fact that the current user is already logged in. The malicious website could then submit a fake request, which really has a great chance of spreading harm such as tricking the user transferring money from a banking website. To prevent such attacks, Web app developers need to consider the deployment of cryptographic tokens and mandate users to re-authenticate in order to complete a transaction or event, preventing in-session hijacks.

Figure 2: Architecture for a Web app firewall

Multi-factor authentication: Most of us know that passwords are no more the only authentication factor nowadays. A better authentication solution is 2FA (two-factor authentication) or even multi-factor authentication (MFA). Both have really been slow to gain popularity in the past due to the difficulty of always carrying around a second device just to verify the identity of a user. But as mobile devices have become a device that we always carry, it has solved this difficulty to a great extent. While native apps and SMS for MFA are not perfect, they do really reduce risks associated with password-only authentication to a great extent. Many of the consumer websites and online services are now offering multi-factor authentication, for instance Apple, Google, Facebook, Twitter, and more.

Forgotten password security design: Many of the websites allow their users to request an existing or even new password be sent to the registered email address, with little verification. But there can be a stronger process for this such as adequately validating the identity with security questions, sending the user a randomly generated token through an out-of-band method, allowing verification code in the same Web session and enforcing a lockout policy. For hackers to circumvent these kinds of security measures would really need a lot of pieces to rebuild the system, which does not make things easy for them.

Role of the Web app firewall in handling security

Web app firewalls are hardware and software solutions that protect apps. These solutions are specifically designed to examine all the incoming traffic to block malicious attack attempts, thereby compensating for any of the code sanitisation deficiencies. By securing application data from manipulation and theft, Web app firewall deployments meet one of the key criteria for PCI DSS certification. As per Requirement 6.6 of this certification, all debit and credit cardholder data held in any database must be protected. Generally, deployment of a Web app firewall doesn’t require making any changes to a Web app, as it’s placed well ahead of its DMZ at the edge of a network. From there, it starts acting as a gateway for all the incoming traffic, blocking any malicious request before it gets a chance to interact with the application.

Web app firewalls use several different heuristics in order to determine which traffic is given access to the app and which needs to be removed. A constantly-updated signature pool helps the firewalls to instantly identify different bad actors. Almost all Web app firewalls (WAFs) can be customised for specific use cases and security policies in order to combat emerging threats. Finally, most of the modern solutions leverage the behaviour and reputational data to gain additional insights into the incoming traffic. WAFs are also integrated with other security solutions in order to form a security perimeter. These include Distributed Denial of Service (DDoS) protection to provide the additional scalability required to block a high-volume attack.

Figure 3: Statistics of the increase in the security breaches in the healthcare sector

Best practices for securing a Web application

  • Manually review the application to identify entry points and client-side codes. Classify the third-party hosted content separately to avoid any confusion.
  • Test the application for all possible path traversals, horizontal and vertical access control issues, missing authorisation or any insecure, direct object references.
  • Switch off all the unnecessary functionalities of the application.
  • Always keep the remote access limited and secure, as hackers try to enter the application through this.
  • Secure all the data transmissions involved in different parts of the Web application.
  • Use accounts with limited privileges and permissions.
  • Segregate the environments for development, testing and live usage of the Web application. Avoid testing on the development environment.
  • Always install all the security patches and keep them updated. Always monitor and audit the server logs.
  • Improve the application’s resilience against Denial of Service threats by testing it perfectly for account lockout, anti-automation, HTTP protocol and SQL wildcard DoS.
Figure 4: Some of the common causes of security breaches in Web applications in 2018

Points to ponder

As per the 2017 Trustwave Global Security Report:

  1. The mean number of vulnerabilities associated with a Web application is 11.
  2. The median number of days required to detect an application intrusion dropped to almost half in 2017 from that of 2016. Some of the internally-detected breaches were found in about 16 days itself.
  3. Geographically, North America has been hit most with 49 per cent of all the data breaches occurring in 2017. The Asia Pacific region claimed 21 per cent of all breaches, while 20 per cent happened in Europe, the Middle East and Africa, and the remaining 10 per cent in Latin America.
  4. The retail sector was the most hit industry, accounting for almost 22 per cent of the breaches. The point-of-sale breaches associated with the retail sector accounted for most of these breaches.
  5. Breach incidents in e-commerce dropped by 12 per cent in 2017 as compared to 2016 due to security solutions implemented in the e-commerce sector.
  6. In 2017, 35 per cent of the spam messages contained malware, which is actually a dramatic increase from the 3 per cent in 2016. And around 60 per cent of all inbound email tested was found to be spam.


Please enter your comment!
Please enter your name here