14 Min Read Application Security “for dummies”
Table of Contents
Summary
Internal and external web applications have become a major part of the modern world. Some of the world’s largest companies started with a single web application (Facebook and Google are two examples), and web platforms are crucial for commerce, finance, and the public sector. All organizations that want to be accessible and reach a large user base use web applications. Larger organizations often use dozens or hundreds of them. Think about yourself! How many applications have you used today? Facebook? Twitter? Reported absence from school? Checked the children’s school results? Downloaded books from the library? Checked the balance in the bank account? Ordered food? Shopped online? Read the emails? Teams meeting? Netflix? Spotify? Fitbit? Set the alarm at home when you left? All these applications are exposed to the web and therefore vulnerable.
Traditionally, the IT environments where the web applications are located were secured through network and infrastructure security. Well-established organizations often have a mature network and an infrastructure security program that account for most of their IT security budget. This type of security is often good but insufficient. The application that communicates with the external world through HTTP/S is usually not secured and compromises the entire infrastructure despite all the costly security measures. Network security is unable to review the seemingly legitimate traffic between the application and the user and if there are vulnerabilities in the application, they can be exploited to take over or damage the entire IT environment.
Web applications have become the main target of cybercriminals and now account for 3 out of 4 data breaches worldwide (Invicti). Web application security has never been more important and yet there is still some confusion about its place in the overall security landscape. This article will try to clarify this issue and describe the solution.
A changing world
Organizations continue to move more and more information and business processes to cloud platforms and they rely on web technologies to conduct their businesses. The organization’s information assets accessible through the web are now on the front lines of cyberattacks. Business and personal data are valued commodities. Therefore, cybercriminals focus on accessing our information assets through web applications that form the weakest link in our secure environment. Studies confirm that 3 out of 4 data breaches worldwide are now related to web applications. Physical perimeter protection is no longer enough to protect business data as a traditional division between private and public networks is now often logical rather than physical. What was once private and hidden is now often publicly exposed to the internet.
Web application environments tend to be very dynamic. Rapid development and distribution are the norms that are made possible by the widespread use of ready-made frameworks and libraries. Even in the largest applications with millions of users, new and updated code can be submitted into production environments on a daily basis. Web technology is developing rapidly and thus also the threat picture. All this means that even if a web application was tested and secured last month or last week, changes to the application, underlying libraries, or attack techniques can make it vulnerable again. We at eBuilder Security test several of our own applications on a daily basis to identify and fix new security holes as soon as possible.
An analogy with the legend of the Trojan horse – Application security explained
Most of us have probably heard the legend of the beautiful Helen of Troy and the Trojan Horse during our school days. It is still disputed today whether Troy really existed and whether the war was real or just a legend. We shall leave it open, but the legend will help us to visualize the problem of application security as an analogy.
According to the legend, as told in the Odyssey, the siege of Troy had lasted ten years when the Greeks came up with a war feint – a gigantic, hollow wooden horse. We can compare the city of Troy to a traditionally secure IT infrastructure with strong network defenses, firewalls, encryption, network segmentation, antivirus, IPS, and a bundle of other obscure abbreviations. At the siege of Troy, the enemy, i.e., the Greeks, constructed a hollow wooden horse, which they filled with soldiers. The wooden horse was then left as a gift to the Trojans who took it into the city. Trojans placed the horse inside of the defensive walls that served them so well. Greek soldiers got out of the horse that night, opened the gates to the city, and then leveled it to the ground. In our analogy, the enemy does not have to build and give us a wooden horse. We have built it ourselves or bought it in the form of a web application and placed it on the inside of our well-guarded Troy.
To understand the problem with web applications, we need to understand how they are structured. Modern web applications are not monoliths, but rather patchwork quilts consisting of many products and technologies. Development usually begins by choosing a web application framework that provides the backbone of the design and takes care of important but mundane tasks such as rendering the user interface or ensuring support for different browsers. Developers then work within the framework to code the application logic and bring in external libraries (often open source) to provide specific functionalities. Along with other external resources such as styles, fonts, and icons, the resulting web application is a complex network of dependencies. Each external component can have its own development history and its own vulnerabilities, making security testing a very complicated task.
Like Troy, our IT infrastructure has been secured with high walls, towers, and other defense mechanisms. At the same time, we have brought in a horse, i.e., the application that we and the defense mechanisms blindly trust, and placed it inside the defense wall. The application communicates completely legitimately with users outside of the wall through all the security mechanisms. After all, it is its job to obtain or provide users with information. As pointed out above, most applications contain a number of security flaws and with the right knowledge and information, a hacker can use these to take over and control the application. The takeover and control usually take place over seemingly normal HTTP/s traffic that network monitoring cannot control and that looks completely normal. The application is located on the inside of the network defense and is seen as a legitimate and reliable part of the IT infrastructure. The fact that it communicates internally and externally is also not something strange. It is therefore very difficult to detect that it has been taken over by malicious hackers and it is difficult to see what damage it can do before it is too late. Therefore, it’s important to identify the application’s weaknesses and security flaws yourself and close them before someone else finds and exploits them.
Today’s hackers are part of a new professional industry. They have enough time and money to be patient and once on the inside of your defense, they can covertly lie there for months and map the entire infrastructure and all the information of your organization. When they strike, they may already have stolen all your information and encrypted your data so it can’t be used. In the worst case, they have even infected backups so it is not possible to restore your systems. And then comes the demand letter in the postal mail… you no longer have an email! Not only you have received demand letters, but your entire business is down and there is no guarantee that you will get the systems up and running again even if you choose to pay the ransom. What’s stopping the hackers from striking again once you pay? The result is at best, a few weeks or months of downtime and a juicy ransom. You’ll probably have to replace all your IT infrastructure and in the worst case, you’ll have to shut down, Forever.!
On Thursday night, 16th December, a serious operational disruption was discovered in Kalix municipality’s IT system. In the afternoon of the same day, the municipality confirmed that it had suffered a so-called ransomware attack.
The home service and home health care did not have access to medical records and medication lists.
Salary payments to the municipality’s 1,900 employees were affected and the municipality was forced to pay the November salary instead of the December salary.
The municipality switched to pen and paper as they couldn’t access the systems.
All systems had to be built from scratch.
Every third computer had to be replaced.
The damage amounted to millions.
On the 2nd of July 2021, the Swedish Supermarket chain, Coop with about 800 stores, became a victim of the Supply Chain attack on Kaseya software. Although Coop was not a client of Kaseya, one of its software service providers had been using the services of Kaseya which brought chaos to Coop.
Encryption messages started appearing on displays of tills and self-service checkouts of Coop stores.
Thousands of customers shopping at Coop stores were suddenly unable to pay for their groceries.
About 700 out of its 800 stores were forced to shut down for about one week.
The solution: Identify the security holes and fix them.
We live in an application-centric world and application security must be an important part of overall cybersecurity. Traditional network security tools are not designed to control application traffic where attackers typically send malicious payloads through legitimate HTTP/S traffic.
The vast majority of people who work with IT security are familiar with network and system security because it has been around for a long time. However, web application security is often less well understood and requires a completely different approach. Administrators with a background in network security can scan web application environments with a network scanner to find and patch vulnerable servers, frameworks, and libraries. This is a good basis for security, but network security cannot secure the web application because there is no way to check if the application itself is safe.
CWE-89 – SQL injection: User-controlled input (such as a query parameter or form field text) is inserted directly into a SQL query that is sent to a database without validation. Attackers can inject SQL statements to extract data or modify database contents.
CWE-79 – Cross-Site Scripting (XSS): Unvalidated user input is included in the content of the web page. Attackers can inject JavaScript code to modify page content, hijack user sessions, or redirect users to a malicious website.
CWE-611 – XML External Entity (XXE) Injection: A weakly configured XML parser that allows external entities in legacy document type definitions (DTDs) is used. By providing a specially made XML document, attackers can crash the server, access local files, or run code on an internal machine to carry out further attacks.
The shift in application development to the cloud has removed many of the complexities from development workflows enabling distributed teams to collaborate effectively on fast-moving projects. In agile methods, new code can even be deployed daily. Any change to a web application potentially means that we introduce new vulnerabilities, and the application should be scanned before it is put into production. “Best practice” is to integrate the vulnerability scan as a natural part of the normal development process.
Even if the code and application are static, it is not a guarantee that it is secured. New security flaws are continuously identified in components that were previously considered safe. What was considered safe yesterday does not necessarily be safe today. The bottom line is that we should regularly scan all web applications – even those that are more or less static.
Vulnerabilities should not only be identified but they should also be fixed. When managing dozens of web assets, automation also becomes a necessity – and to automate, you need to be sure that your scan results are not “false positives“. This is where you need the dedicated solutions that eBuilder Security offers: Acunetix. Acunetix, with its Proof-Based Scanning technology, ensures that only verified issues are sent to developers to fix as it is important to minimize “false positives”.
eBuilder Security offers companies and organizations the market-leading vulnerability scanner, Acunetix, as a service. You don’t have to invest in expensive licenses with commitments over a long period of time and you don’t need to update any software. We ensure that you always have the latest vulnerability update and that you have support in the unlikely event that you have any problems. You also do not need to order a minimum number of targets and can even order scanning of a single target. You can scan a target once a day/week/month or whenever you feel like it. The price is the same. If you want to increase or decrease the number of targets, you can also do so. You only commit for 3 months for each target.
Final Words: Why Network Security Isn’t Enough
Network security and web application security are two separate and complementary parts of the cybersecurity puzzle. Each relates to different technologies and must deal with different threats. To stay safe in the connected modern world, organizations need to maintain solid cybersecurity in both areas, especially since the majority of cyberattacks and data breaches are related to web applications.
Maintaining a solid security posture in a cloud-based world requires the right tools and processes in all areas of IT security. Network and system security is still an important part of any comprehensive security program, but now the front line in the fight against cybercrime has moved towards web security. With so much at stake, if a cyberattack succeeds, organizations can’t afford to leave any gaps.
Quite simply, if you have web applications, you need web application security. eBuilder Security offers the best the market has to offer, Acunetix, as a service.
