Fundamentals Of Web Applications Security .

Over the past ten years, we have heard much about the security of web applications, and the threats that can come from using them. For better or worse, modern businesses have become increasingly dependent on the use of web applications developed agile; from complex infrastructure systems to IoT devices.

Attacks on web applications provide intruders with ample opportunities such as:

-Access to a company’s internal resources and sensitive information;

-The opportunity to disrupt the functioning of an application or bypass business logic;

-Financial gains for the attacker, and losses, both financial and reputational, for the owner of web applications.

Users of web applications are at risk, because if an attack is successful, the intruder can steal credentials, perform actions on websites on behalf of users, and infect a system with malware. To avoid such situations it is important to take the help of a solution based on premise identity and access management solution that can easily manage your organization and mitigate any security threats.

In this article, we’ll talk about the types of attacks, the ways threat actors can damage your system, and how you can protect your company’s essential data.

There are different types of attacks. They differ depending on the sophistication of the way malefactors have chosen to steal sensitive data. The most popular attacks are:

1.Implementing SQL statements

2.Running OS commands

3.Path Traversal

4.Сross-site scripting

5.Denial of service

6.Сonnecting local files

7.Implementing XML external entities

8.Downloading random files

9.Cross-site request forgery

One of the most simple ways to wangle desired data from a web app is to use brute force attacks. This approach is reliant on a user’s laziness and carelessness, which are unfortunately traits that many of us share. With Google Cloud platform vulnerability management you can avoid attacks.

As we all know, to access an app, we need to create a username and password. However, it is very seldom that one thinks hard about this task. In most cases, people enter a password connected to their email, name, surname, date of birth, etc. It becomes even worse when the employee writes the password on a post-it note and leaves it on their computer screen.

As the goal of the attack is to find a valid username and password, it’s not as difficult as we would assume for intruders to spend a couple of hours scrolling Instagram profiles of a particular organization in search of a careless photo that reveals login details.

After finding that there has been an attack, most likely you will want to reactively block the intruder’s IP address. However, we would advise you to refrain from such impulsive actions because:

-the intruder can easily overcome this by dynamically changing the IP address

-blocking a public IP may cut off other users of the same address

Another bad idea is to block those users that have failed to log in multiple times. This is a dangerous approach. A potential intruder may try many valid usernames, and you’ll end up blocking each and every one of these people. Most likely this will annoy users and deter them from using your app. A lighter version of this solution is to lock an account temporarily, with a response such as “You entered your password incorrectly a few times in a row. Try again in 30 seconds.”

Of course it is great to receive confirmation from CAPTCHA that you’re not a robot, but unfortunately this method is inconvenient. It lacks usability in many cases, and is (unexpectedly) vulnerable to attacks. In applications that prioritize user friendliness, CAPTCHA should be considered a last resort.

Analyze what kind of resources/values should be defended above all else. Money? Sensitive data? Reputation? A hacked homepage can result in the loss of all three of these and should be obviously avoided at all costs.

To eradicate a brute force attack, you need first to detect it. For this, you need to use tools for monitoring the network traffic of your web app. Pay attention to metrics and logs. The HTTP metrics should be detailed enough to determine the URL and method of each incoming request, status, and the number of produced responses. Logs will provide more detailed information about each request that cannot always be collected and presented as metrics.

Secret questions can be beneficial if you want to detect attackers without bothering the regular users of your web app. As you know, the secret question and corresponding answer are configured in a user’s profile. If a user has failed to login a few times, give them the option of answering their secret question. Make sure to also ask these questions for invalid logins, so the attacker won’t know if an account really exists or not.

During a brute force attack an intruder will make attempts with many passwords. Implementing a delay between failed login attempts can dramatically decelerate the whole process, making it too time-consuming for an attacker. The additional latency won’t bother real users.

In a brute force attack, some penetration testing tools may be used, like THC-Hydra. These programs send requests with a User-Agent header set to a default value. This is a tell-tale sign of an attack tool.

By randomly returning the 200 status responses for requests with such header, an application can fool the attacker, who will no longer be able to distinguish between correct and failed attempts. It’ll work on amateur hackers who don’t know how to modify Hydra’s request headers. Note this isn’t a fully secure solution as request headers can’t always be relied on.

Many of the attacks committed nowadays are not particularly ingenious and can be easily avoided or detected by following the aforementioned pieces of advice. Nevertheless, we can’t get complacent. The technical expertise that modern cybercriminals possess make it possible to carry out attacks with a high level of complexity, including through a series of actions that occur at different times and at first glance do not seem related.