staging-devopsy.kinsta.cloud

Tag: web application security

  • Developer’s Guide to Web Application Security

    Developer’s Guide to Web Application Security

    When it comes to security, there are many vulnerabilities that can leave your website or web app open to attack. In this article, we’ll go over 15 common web application security vulnerabilities and how you can prevent them.

    1. Insufficient Cryptography

    Cryptography is a critical security measure that is used to protect data in transit and at rest. Yet, many web applications do not use cryptography properly, leading to a number of serious vulnerabilities including potentially devastating code theft. For example, data can be easily intercepted and read if it is not properly encrypted or encryption keys can be easily guessed or stolen if they are not properly protected.

    To properly protect data, it is important to use strong cryptography. This includes using proper encryption algorithms, encrypting data in transit and at rest, properly protecting encryption keys and more. It is also important to keep all software up-to-date, as new cryptography vulnerabilities are constantly being discovered.

    2. Broken Access Control

    Access control is a security measure that controls who has access to what data and functionality in a system. It is an important part of any web application but often is not implemented correctly. This can lead to serious vulnerabilities such as sensitive data being leaked or attackers gaining access to administrative features.

    There are a number of common mistakes that can lead to broken access control, such as failing to properly restrict access to data and functionality, using insecure methods for storing and transmitting user credentials and not properly protecting session tokens. In order to prevent these kinds of vulnerabilities, it is important to implement proper access control measures in your web application.

    3. Broken Authentication and Session Management

    Authentication and session management are two of the most important security measures in any web application. Yet, they are very often not implemented correctly, leading to a number of serious vulnerabilities. For example, session ID’s can be easily guessed or stolen, cookies can be tampered with and passwords can be brute-forced.

    In order to properly protect user data and prevent these kinds of vulnerabilities, it is important to implement strong authentication and session management mechanisms. This includes using strong passwords, two-factor authentication, proper session expiration and invalidation, and more. It also means properly protecting any session IDs and cookies that are used by the application.

    4. Cross-Site Scripting

    Cross-site scripting (XSS) is a type of vulnerability that allows an attacker to inject malicious code into a web page. This can be used to steal data, hijack sessions, redirect users to malicious sites and more. XSS is one of the most common web application vulnerabilities, especially in our era of remote work. Despite security awareness training, many employees remain vulnerable to social engineering and phishing tactics when these risks are not properly addressed.

    To protect against XSS attacks, it is important to sanitize all user input and output. This includes properly escaping special characters, using a whitelist of allowed characters and more. It is also important to keep all software up-to-date as new XSS vulnerabilities are constantly being discovered.

    5. Insecure Direct Object References

    Insecure direct object references (IDOR) are a type of vulnerability that allows an attacker to directly access data that they should not have access to. For instance, an attacker could guess or brute-force the URL of a sensitive file, such as a customer’s credit card information, and then download it. IDORs can also be used to bypass security measures such as access control checks.

    In order to prevent IDOR vulnerabilities, it is important to properly validate all user input and restrict access to data and functionality to only those who are supposed to have access to it. It is also important to keep all software up-to-date as new IDOR vulnerabilities are constantly being discovered.

    6. Insufficient Authorization and Authentication

    Insufficient authorization and authentication is a type of vulnerability that allows an attacker to gain access to data or functionality that they should not have access to. This can be due to a number of factors, such as weak passwords, improperly implemented role-based access control, deliberate over-permissioning and more.

    To properly protect data and prevent these kinds of vulnerabilities, it is important to implement strong authentication and authorization mechanisms. This includes using strong passwords, two-factor authentication (2FA), proper role-based access control and more. It is also important to keep all software up-to-date as new vulnerabilities are constantly being discovered.

    7. Failure to Restrict URL Access

    Another common web application security vulnerability is the failure to restrict URL access. This can allow attackers to gain access to sensitive data or functionality that they should not have.

    One of the most common problems developers face is forgetting to properly restrict access to directories and files. For example, they may forget to add an index.html file to a directory. This oversight would give anyone who accesses that full directory read and write access to all the files in it.

    Another common issue is that developers do not properly restrict access to certain URL parameters. For example, they may allow anyone to access the “id” parameter, which could be used to view or modify data that they should not have access to.

    To prevent these kinds of vulnerabilities, it is important to make sure that all directories and files are properly restricted and that all URL parameters are properly sanitized before being used.

    8. Remote File Inclusion

    Remote file inclusion (RFI) is a type of vulnerability that allows an attacker to include a remote file, usually through a script or other type of application, on a vulnerable web page. This can be used to inject malicious code into the page which can then be executed by anyone who views it.

    One of the most common problems with RFI is that developers do not properly sanitize user input, which allows attackers to inject their own files into the page. Another issue is that developers often use static include paths which makes it easy for attackers to guess the path and inject their own files.

    To limit these kinds of vulnerabilities, it is important to make sure that all user input is properly sanitized and that dynamic include paths are used.

    9. Insufficient Logging and Monitoring

    Logging and monitoring are critical security measures that are used to detect and respond to security incidents. Despite these critically important functions, many web applications do not properly log and monitor activity, leading to a number of serious vulnerabilities. For example, an attacker could easily cover their tracks or an incident could go undetected if there is not proper monitoring in place.

    In order to properly detect and respond to security incidents, it is important to properly log and monitor activity. This includes logging all activity, monitoring for suspicious activity and more. It is also important to keep all software up-to-date, as new logging and monitoring vulnerabilities are constantly being discovered.

    10. Security Misconfiguration

    Security misconfiguration is a type of vulnerability that arises when a web application is not properly configured. This can lead to a number of serious security issues such as exposing sensitive data, making it easier for attackers to gain access to systems, and more.

    To mitigate risk when it comes to these kinds of vulnerabilities, it is important to properly configure all software and systems. This includes setting strong passwords, disabling unnecessary accounts and services, properly configuring firewalls and more. It is also important to keep all software up-to-date as new security misconfiguration vulnerabilities are constantly being discovered.

    11. Tampering with Data

    Data tampering occurs when an attacker tries to modify data without permission. This can end up having a number of serious consequences, such as corruption of data, loss of data integrity and more.

    To prevent data tampering, it is important to properly protect data through data handling and storage best practices. This includes using proper authentication and authorization mechanisms, encrypting data in transit and at rest, properly protecting encryption keys and more. It is also important to keep all software up-to-date as new data tampering vulnerabilities are constantly being discovered.

    12. Cross-Site Request Forgery (CSRF)

    Cross-site request forgery (CSRF) is a type of vulnerability that allows an attacker to trick a user into submitting a malicious request. The goal is to be granted requests to do things without the user’s knowledge or consent, such as changing their password, transferring funds and more.

    To prevent CSRF attacks, it is important to properly validate all requests. This includes using proper request validation mechanisms, such as checking for a valid CSRF token, 2FA and more.

    Be Aware of Vulnerabilities

    We use and rely on a large number of web apps in our daily and commercial lives. While most of these apps are relatively safe and secure, there are still a number of common security vulnerabilities that can leave them open to attack.

    To keep your web apps safe and secure, it is important to be aware of these vulnerabilities and know how to prevent them. This includes keeping all software up-to-date, using proper authentication and authorization mechanisms, encrypting data in transit and at rest and training users to identify social engineering and phishing attempts, among others. By following these best practices, you can help to ensure that your web apps are as safe and secure as possible.

  • The Evolution to Cloud-Native Applications and APIs

    The Evolution to Cloud-Native Applications and APIs

    If you’ve spent any length of time in application development, you’re familiar with change. It’s the only constant.

    And along with how we build applications come changes in the techniques used to keep them secure.

    Securing modern applications requires more diligence than ever before. A review of how application development has changed over the past decade will explain why more diligence is necessary.

    Traditional Web Applications: Placing an Order From a Menu

    The traditional web application operates like ordering food from a menu at a restaurant. You have a list of dishes available, and you ask for one. The chef decides which ingredients are necessary and how the plate looks when it arrives.

    In a traditional web app, the client fetches a URL. Let’s say you want to see a dashboard of marketing metrics, and thus your browser retrieves example.com/dashboard.jsp. The client doesn’t control what’s on the dashboard; it just knows to ask for it.

    The web server processes the request in three steps:

    1. The web server pulls data from the database.
    2. The server builds an HTML page with the data placed inside.
    3. The server returns the rendered HTML page to the client.

    The web server decides what data goes into the dashboard and where the data goes. The client simply asks for a resource and displays what the server returns.

    In this model, the client typically has very little code. It requests a URL from the server and displays what comes back. All rendering and data processing happens on the server.

    Modern Web Applications: Buffet Style

    Modern web applications put the client in control. It’s more like a buffet than a sit-down restaurant.

    The client is often a Single-Page Application (SPA), or an application that dynamically updates the same page instead of always requesting a new one from the server.

    In a buffet, you take your plate and pick and choose the foods you want. Each dish can have multiple configurations based on your needs at the time.

    SPAs work like those plates. Instead of a single server creating an entire page and returning it to the client, the client knows how to make the page and asks only for the data required to do it.

    Typically, Application Programming Interfaces or APIs provide this data to the client. Business logic is exposed to clients using APIs that return only what the client needs. Maybe the client only wants the last 20 notifications for an account or the ten most recent emails.

    The use of APIs for business logic and data retrieval opens up the world of application development. You no longer need to build a web application. You can use a mobile application instead. You can use any technology or form factor to access the data, from mobile to Internet of Things (IoT) or other developers building applications of their own.

    JSON, a lightweight data format, is one of the most useful enabling technologies for modern applications. It allows all of the APIs, the client, and the database to store and transmit data using the same format. There are no data transformations necessary, which helps keep the application responsive.

    Going back to the above dashboard example, an SPA wouldn’t ask the server for the entire dashboard at once. Instead, it would ask the appropriate APIs for the specific data it needs to build the dashboard itself.

    The desire for APIs and ultimate flexibility and speed of development gave way to the development of microservices. These services are kept small on purpose to be updated independently of each other and more frequently.

    SPAs emphasize the client, leading to more complex code in the clients and the risk of security vulnerabilities in the clients (more on that later). But this change has opened up transformational technologies like IoT devices.

    From Monoliths to Microservices

    A common theme in the evolution of application development has been toward breaking functionality and features into smaller and more granular components.  Just as with the SPA example above, the functionality of the web page is in isolated components, the same trend is true when you look at overall application architecture in general.

    Where a legacy application might have been designed with separate modules and functions, each internally making calls to each other, modern design now breaks out separate functions into discrete services.   Now rather than each development team maintaining similar code/functionality inside their application, many business functions are separated into clearly defined services.  Consider an ‘address verification’ service which can be used by many other applications.  The functionality of validating an address is decoupled from the ‘customers’ that use the service, which introduces value into the delivery lifecycle. This approach enables development teams to focus on smaller, more granular changes and therefore shorten their cycle time and accelerate delivery.

    Microservices – a Response to the Accelerating Pace of Change

    Digital transformation and the rapid acceleration of  the pace of change within the industry dictates a new way of thinking. This thinking is encapsulated in the following quote by Bronwyn Clere, Executive Director for Capital Planning & Delivery, at Telstra Corporation in PMI’s Pulse of the Profession 2017 report:‍

    We are implementing features and products and using technology that were not invented 18 months ago. No longer can we afford these large monolithic programs that go on for two to three years. We know that what we set out to do at the beginning of that time is not what we will finish out doing. So, we are focusing on very rapid delivery cycles, asking ourselves: How do we mobilize a project very quickly? How do we use the right delivery techniques to work through it quickly? How do we get product into market or to customers or into the business?”‍

    Business leaders everywhere are demanding technology teams deliver faster. As a result, teams have adopted new ways of working and new ways of architecting their solutions.  We’ve seen widespread adoption of Agile, CI/CD,  and DevOps tools.  Similarly, application development and architectures have evolved to further enable velocity.

    A Tour of Cloud-native Architecture

    The increasing pace of change would put significant stress on any IT infrastructure. But cloud-native architecture has fundamentally changed how applications can be built and scaled.

    Cloud-native technologies, such as containers, service meshes, microservices, immutable infrastructure, and declarative APIs, empower developers to build and run scalable applications on public, private, and hybrid clouds.

    Cloud-native architecture focuses on creating loosely coupled services with high resiliency. Developers can make changes frequently without negatively impacting the entire system.

    Let’s take a quick tour of cloud-native applications so you can see how they differ from traditional web applications.

    The bulk of cloud-native applications include many microservices deployed in containers. Each service is isolated from the others and can be destroyed and recreated easily without affecting other services.

    Often an orchestration tool like Kubernetes is used to monitor all of the microservices used in an application. Orchestration is necessary when hundreds of services serve a single application. Kubernetes can detect malfunctioning containers or services, destroy them, and recreate new ones to keep the application running smoothly.

    Each service can be created and updated independently from all the others. Each service can use a different programming language altogether. As long as each service exposes a documented API, the language used behind the scenes doesn’t matter.

    Below is a diagram of Microsoft’s eShop on Containers open source application. It demonstrates what a real-world application looks like using cloud-native technologies.

    In this example, the development team building the Marketing microservice can make changes as often as they want without affecting the ordering or cart functionality. Different technologies can be used within each service and each service has a separate datastore. Flexibility and speed are the hallmarks of modern development.

    In the next post, we’ll dive deeper into specific challenges and considerations you need to take when adopting cloud-native applications.

    4 Necessary Mindset Shifts For Cloud-native Success

    The pace of change affects more than technology. Processes, management styles, and even ways of thinking have to adjust to make modern application development successful within your company.

    Delivery: Think Agile and Devops

    Because of the intensive need to shorten delivery cycles and to automate delivery, cloud-native architectures embrace delivery practices that support short and responsive turn around. Developers can deploy new code in seconds, with some companies pushing new code to production hundreds of times a day.

    As a result, your project management processes have to change. Agile practices (Scrum, Sprint, Lean, etc.) along with strong DevOps capabilities (i.e. trunk based development, CI,CD,etc) best support wide scale microservice development. It’s critical to get delivery, cultural, and organizational changes completed before trying to do cloud-native development at scale. The DevOps Handbook is an excellent resource for those new to DevOps development.

    Production: Think Products, not Projects

    The days of ‘throw it over the wall’ and let Operations manage the application are over.  Given the complexity of modern applications with multiple microservices and associated APIs,  development/product teams need to ‘own’ the application in production as much as they do in development.  In order to successfully scale your adoption of cloud-native applications, you need to explore and embrace “Product Management” over “Project Management” as a practice to manage the full lifecycle of your application.

    Think of your application as a long-term product that will change over time. Market insights and customer feedback will continue to improve it. It’s not a one-and-done exercise.

    Security: Think Security Everywhere

    Security is a major concern in this new environment.  The traditional approach of building a fortress of defensive walls and moats around the application and then you ‘trust’ the activity inside the fortress is insufficient in a world where the individual elements of the application are expected to communicate with other components.  On many levels, the new paradigm for security is one where each microservice, each component must have security built in, they need to embrace “zero trust” as a policy for how they operate.

    Trust No One – Zero Trust in Microservices

    Zero trust is a security architecture that lives by the motto: “Never trust, always verify.” It means verifying every request before returning data or performing an action.

    In a traditional network architecture, we protect the perimeters. Firewalls and DMZs only allow certain types of traffic into the network. We use VPNs to enable secure communication between company servers and remote workers.

    However, the biggest flaw with this security method is that traffic within the network is implicitly trusted. It’s similar to a bouncer protecting a nightclub from a long line of wannabe party-goers. It’s tough to get into the club, but once the bouncer lets you in, you can pretty much do whatever you want.

    In a zero-trust network, all traffic is considered suspect. Just because a request comes from within your environment doesn’t mean you can trust it. Check every request first before the service returns data.

    Microservice architecture requires a zero-trust architecture to be secure. It’ll ensure no requests fall through the cracks.

    Diligence, Compliance and Oversight of Cloud-native Applications

    In addition to zero trust as an approach to enabling microservices to operate securely, organizations must rethink how they monitor and manage their security posture.  We’ve covered several significant changes in web applications, especially in the last ten years.

    • Faster change than ever before
    • Small, independent services on different platforms
    • Autonomous teams
    • Cloud-native
    • More moving parts
    • More can fall through the cracks.

    New levels of diligence are required to secure this new breed of application. Cloud-native applications and microservices create new security vulnerabilities companies must account for to keep up with attacks.

    In the next post, we’ll cover what security measures need to be in place to protect cloud-native applications.

  • Are Your Web Applications Prepared for the Holidays?

    Are Your Web Applications Prepared for the Holidays?

    Three best practices to secure your website for the coming retail boom 

    The holidays are upon us, which means retailers are racing to launch new promotions, sales and other temporary web pages in time for what is anticipated to be a record-breaking retail season. Amidst their haste to prepare, some businesses forget—or don’t realize—that there are often a number of critical vulnerabilities in their web applications and servers that go completely unnoticed or unaddressed. In fact, recent research has shown that retail has one of the worst records when it comes to applications failing security checks. This is because web applications are often created quickly, without security in mind. Or even worse, they are created, launched and then forgotten. And if there is one thing we know about applications—they age like milk, not wine.

    Our research shows that the average web application contains 11 vulnerabilities, with an average of seven critical vulnerabilities. And every one of those vulnerabilities is a chance for a criminal to breach your company. The last thing a retailer needs right before the holidays is to become yet another victim of cyberattack and negative headline.

    Security for Web Applications

    To sail smoothly through the holidays, here are three basic hygiene principles that can be used to ensure your business’ web apps are thoroughly safeguarded:

    Test Early, Scan Often

    The importance of scanning website applications regularly is critical to ensuring web applications aren’t launched with known vulnerabilities. According to CA Veracode’s State of Software Security Report, 60 percent of web applications are scanned less than four times a year, 36 percent of organizations don’t run any kind of static analysis security testing (SAST) and 48 percent of organizations aren’t running any kind of dynamic analysis security testing (DAST). Part of the problem is that so many web servers have vulnerabilities that have not been patched, with 25 percent of those scanned possessing a high or very high severity vulnerability—meaning they could be easily exploited by attackers to compromise websites and potentially steal or compromise consumer data.

    Best practice for IT departments is to make sure their web servers are not sending out information that could be valuable to an attacker, such as server version information, for example.

    Discovery scans of websites show that organizations have 30 percent to 40 percent more websites than they thought they had. This could include marketing pop-up sites that are left online and forgotten about. These sites often are left online with a redirect instead of being taken down—this is a “messy” practice that can create entry portals for hackers later on.

    Shockingly, applications are only scanned twice a year on average. But scanning more frequently during development allows developers to fix on average 48 percent more vulnerabilities versus conducting scans that only give applications an up-or-down on security policy.

    Prioritize Remediation Based on Risk

    Testing and scanning for vulnerabilities is only half the battle—businesses need to fix the flaws they find. Out of 400,000 application scans that took place over the course of a year, only 18 percent of flaws were closed in less than 30 days, while 49 percent of flaws fixed took more than 90 days to close. Because critical vulnerabilities put your organization at the most risk, companies should fix the most severe vulnerabilities first. Many organizations are wisely doing this already—data shows organizations fix high severity vulnerabilities at twice the overall fix rate.

    To prioritize risk, organizations must account for the severity of the flaw in addition to the business value of the application at risk. In addition, not all high-severity flaws are weighted equally—some organizations may choose to prioritize more high- and medium-level vulnerabilities that have more value, or are in more sensitive applications, over very high severity vulnerabilities in less sensitive applications.

    Empower Developers with Resources to Make Security Part of Their Process

    It’s important that cybersecurity professionals nurture their relationships with the people who are closest to the development process. But this is often deprioritized. According to findings from a survey conducted by CA Veracode and ESG, only 18 percent of development team leaders said security was the most important metric for measuring their team’s performance. And security education and ongoing training is equally neglected, with 68 percent of surveyed developers and IT pros saying their organizations aren’t supplying them with adequate training. This endemic goes all the way back to college—76 percent of respondents reported that they weren’t required to complete any security courses while in school.

    However, developers do care about security, and these stats should serve as a reminder to maintain vigilance in helping developers get the tools and reinforcement they need to fix vulnerabilities efficiently.  In fact, there is a 19 percent improvement in vulnerability fix rates when employers provide developers with on-demand training courses.

    As more cybersecurity threats continue to emerge, having a “clean” app landscape has unmatched long-term benefits and can help ensure customers continue to have trust in your brands.

    About the Author / Joe Pelletier

    Joe Pelletier is the Director of Product Management for Veracode’s Web Application Security and Runtime Protection product lines. He has worked in application security for over six years, originally helping large enterprise clients implement secure development practices and programs. Joe is a hands-on learner and passionate about building great products and teams. Prior to Veracode, Joe worked in the financial services industry and helped develop portfolio management and investment research platforms. He received his degree in Finance from Bryant University. Follow Joe on Twitter.