Matteo Conta - 15 Maggio, 2019 - 9 ’ read

Imagicle applications security: vulnerabilities and threats mitigation.

Owasp top 10, Web application security, Web vulnerability scanners

If you work with software solutions like I do, you are probably well aware of the importance of online security. You may think you have it handled, but like many other companies, there probably hasn’t been enough done to secure your web applications. Scroll through the article, explore the most common vulnerabilities and learn some basic method of threat mitigation we’ve developed at Imagicle to keep malicious hackers at bay.

Getting started with web application security.

Application security encompasses measures taken to improve the security of an application often by finding, fixing and preventing security vulnerabilities.

Using up-to-date encryption, requiring proper authentication and having good software development best practices are important steps to protect your apps from exploitation, but the truth is that expert attackers may be able to find vulnerabilities even in a robust security environment. Actually, vulnerabilities can occur in nearly every kind of software on various levels: operating systems, applications, programs’ libraries or communication protocols, and the average cost of a data breach for a company is so high that it makes apps security a top priority for enterprises, especially those who develop applications in-house.

Because of their easy accessibility, web applications are an easy point of attack. Everyone can open an URL, be it a simple static site or a complex dynamic application.

With a simple browser, it’s possible to exploit specific vulnerabilities to obtain important information, and even modify the behavior of an application for someone’s personal gain.

Of course the saying “better safe than sorry” applies perfectly here.

For pre-empting and countering the threats spread via the Internet, it’s essential to understand how a hypothetical hacker attack is usually carried out.

To get us started, let’s say it can be split into 5 steps. Each one has a specific objective ranging from collecting information about the target, searching for vulnerabilities, accessing the target system, extracting information, up to cover the evidence of the attack.

Here are the five basic phases of hacking a website or an online application:

Imagicle applications security: vulnerabilities and threats mitigation.

Reconnaissance: this is the first stage where the hacker tries to collect information about the target. It may include identifying the target and finding out the target’s IP Address Range, Network, DNS records, etc.
Scanning: this phase involves using tools like dialers, port scanners, network mappers, sweepers, and vulnerability scanners to scan data.
Gaining access and escalation: in this stage, the attacker would exploit a vulnerability to gain access to the target. Usually, this means taking control of one or more network devices.
Maintaining Access and exfiltration: once a hacker has gained access, he wants to keep that access for further exploitation and attacks. When he owns the system, he can use it as a base to launch additional attacks and to extract an organization’s most sensitive data.
Clearing tracks: once access is gained and privileges have been escalated, the hacker tries to cover his tracks. He will clear out sent emails, server logs, temp files, etc., will look for indications of the email provider alerting the user or for possible unauthorized logins.

No panic, though. There are as many solutions as problems. Even in these scenarios, indeed, it’s possible to adopt some tools to identify and fix vulnerabilities.

OWASP Top 10 web application security risks.

The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted.

The OWASP Top 10 is a regularly-updated report outlining security concerns for web application security, focusing on the 10 most critical risks. There are hundreds of issues that could affect the overall security of a web application, and this list doesn’t cover them all, but it’s certainly a good starting point for making a safety assessment and securing your web applications – which, in 2019, is quite simply necessary.

Cybercriminals can use several different paths to harm your business or organization through your apps. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention.

Sometimes these paths are easy to detect and manage, but sometimes they are extremely complex. Likewise, the harm may be of no consequence or it may put you out of business.

For reference, the 2017 OWASP top ten vulnerabilities are:

Injection	Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
Broken Authentication	Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
Sensitive Data Exposure	Sensitive data without extra protection, such as encryption at rest or in transit, may be compromised and requires special precautions when exchanged with the browser.
XML External Entities (XXE)	Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
Broken Access Control	Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
Security Misconfiguration	Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information.
Cross-Site Scripting (XSS)	XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
Insecure Deserialization	Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
Using Components with Known Vulnerabilities	Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover.
Insufficient Logging & Monitoring	Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Well, now that we’ve established a fair level of anxiety, it’s finally time to strike back.

In the next paragraph, we will examine some of the most frequent security breach dynamics and we’ll finally move on to the most important thing: solutions.

Use cases: securing applications and data.

Command injection

Injection flaws happen when untrusted data is sent to a system, and it’s interpreted as unintended commands.

Here is a comparison of the normal processing of the data sent by a client and what happens when a client sends harmful data to a vulnerable server:

Through an injection attack, it’s possible to steal data from the server, install malicious software and establish a communication channel from the attacker to the target server.

Action!

To stem command injection, multiple technical steps must be followed:

user’s input must be validated, even better if using a positive or white list input validation where the arguments allowed are explicitly defined;
whenever possible, a call to specific functions/API is preferable over calls to generic system functions using the user’s input;
calls to functions using the input values must use parametric values; this will strengthen the separation between data and command.

Cross-site scripting

This type of attack is similar to the injection vulnerability. Cross-site scripting vulnerabilities typically affects users’ browsers and involves the execution of malicious commands coming from untrusted data. It occurs when web applications allow users to add custom code into a URL path or onto a website that will be seen by other users. In fact, it’s common, on websites, to get user input using forms, usually through text fields, drop down list and other user input controls.

The server processes the input, and in some cases, it keeps it stored in order to visualize it to different users again later. The typical example is an online forum where users post text and visualize other people posts.

Normally, a user posts a malicious message with special HTML commands. When other users view the post, the malicious code is executed on their browsers, so that it can steal sensitive information from them.

Using XSS, it’s also possible to steal authentication cookies, allowing the attacker to “become you” and act as he wishes on the target website. He may even ask users to install a malicious application or redirect them to a malicious website.

Action!

Mitigation strategies for cross-site scripting include sanitizing user-generated content. The application code should never output data received as input into the browser without first checking them for malicious code.

Imagicle application security best practices

As the biggest 21st-century data breaches have taught us, cyber-attacks are costly incidents. They not only involve the financial losses and post-attack response, but also cause loss of trust and reputation (aka, loss of customer).

At Imagicle, we have long ago learned that, for our customers, the security of an application is a discriminating factor in choosing to adopt our products in the first place.

Here are some best practices we’ve put into practice to make sure not to lose anything or anyone we care about.

Hack yourself.

We are aware that, to protect an application, identifying known vulnerabilities may not be enough: to be able to prevent the highest possible number of attacks, it’s necessary to know in detail the ways it can be performed.

You have to identify all security issues and vulnerabilities within the application itself before a malicious hacker identifies and exploits them – which, simply put, means that an excellent way to know how to prevent an attack is trying to think of how you’d hack yourself.

Later in this post, you will find a useful tool to get some practice in.

Spread knowledge.

In general, an unsafe application exposes a company to incalculable risks, and while the big players have the resources to recover faster from such attacks, small and medium businesses may have to shut down.

Through a technique called “Privilege escalation”, in fact, a hacker can start from a simple vulnerability to gain more and more important permissions, up to take control over a server or the entire network of a company (and by then, mate, you’re in a whole world of hurt

In our case, we have started an internal discussion to spread the security culture and sensibility and stay informed on what is happening in the web application security industry.

Use a web vulnerability scanner.

Meanwhile, we began to use the Burp suite to analyze our applications. The Burp suite is a web vulnerability scanner. It covers over 100 generic vulnerabilities, such as SQL injection and cross-site scripting (XSS), with a great performance against all vulnerabilities in the OWASP top 10.

The Burp suite covers the first 2 phases in hypothetical hacker activity: reconnaissance and scanning. The adoption of this suite helped us to identify and fix some OWASP vulnerabilities based on XSS and SQL injection, along with other low priority problems like cross-site scripting, cross-domain post, directory listing, and others.

Phase 3 (gaining access) can be covered by using specific tools like Metasploit on Kali Linux, or developing a proof of concept able to demonstrate a potential vulnerability.

Pro tip. Let’s go to the gym

Remember the tool I mentioned above to practice hacking your own applications?

Well, here it is. This is the hacking gym where I train my white hacker skills.

Hack The Box is an online platform allowing you to test your penetration testing skills and exchange ideas and methodologies with thousands of people in the security field, and it’s a great starting point to get good at detecting vulnerabilities and security hacks.

But first you need to figure out how to get in!

(Give it a try! It’s a fun exercise!)

Conclusions.

The global nature of the internet exposes applications to a higher risk of cyber-attacks that may differ in scale, importance, complexity, etc., ending up interfering with the smooth functioning of the business. Putting the proper web application security best practices in place, as outlined above, will help ensure that your applications remain safe and your customer happy.

At Imagicle we work every day to make your applications safer, investing in research and progress to develop effective methods to be able to fight the highest possible number of threats.

What we do is trying to make a field of vague security requirements and unknown threats a bit less vague and better known.

So, if you found this article useful, share it and share your experience with us. Feel free to give us suggestions to make the world of communication a safer place.

#stayimagicle