Keeping Web Security Top of Mind Throughout Website Redesigns (Part 2)

In Part 1 of this web security post, we examined what web security is, the importance of prioritizing it during the redesign effort of a digital solution, the motivations of different types of hackers, and approaches we can use to secure the involved solutions accordingly. In Part 2, we will walk through the processes we use to address web security across our digital projects.

Utilizing Technical Audits to Identify Web Security Vulnerabilities

When we start working with a new client, we typically conduct a technical audit of their digital solution to examine their existing set up and codebases. We often find ourselves running into the same types of issues during these audits. For example, even though many developers know that they should protect against SQL injections, there are projects that come in with SQL-injection issues. Another problem we see is that of predictable parameters in web parameter tampering attacks where hackers can manipulate the data that is exchanged between the client and server if they are able to easily guess the structure of this data. Hackers can use this tactic to modify application data such as user credentials and permissions, or the prices of products.

Fixes for some of these security flaws can be as simple as changing a user-ID before it is sent to the server. The following are considerations that we would take into account in this scenario. Though the ID may not be in the page URL, what about within API calls? Is it possible to change a user-ID in an API call and access another user’s information? Even if the user-ID parameter is safe, what about other parameters? If we’re requesting item X with ID 123, can we change the ID to 124 and access another item? These are the types of weaknesses that hackers will be looking out for. It’s important to note that though this type of information in and of itself may not be terribly valuable, it can be used to further the hacking attempt (similar to finding the next clue in a scavenger hunt).

Other examples of things we look to verify are whether a particular user should have access to the specific resource that they are requesting. It’s also imperative to verify that the user making the request truly is the user they claim to be. Verification processes have evolved to better ensure this. For example, two-factor authentication is increasingly being used to protect sensitive information. Ultimately, preventing security breaches is an ongoing challenge. The end goal is to control the level of access available to all users, both on the front-end and back-end.

Velir’s Current Web Security Practices

Our security practices include creating and utilizing a security checklist, following application hardening guidelines, performing Acunetix scans, and educating our team on Pen-Test (Penetration Testing) tools and techniques.

Providing Security Training for All Developers

A key way we stay up-to-date on current web security issues in our space is to attend workshops and provide our developers with security training. In August 2017, we attended the Web App Penetration Testing and Ethical Hacking training through SANS (the largest and most trusted authority for information security training in the world). The training focused on understanding major web application flaws and their exploitation. Specifically, the course syllabus covered topics including configuration, identity, authentication testing, injection, JavaScript and XSS (cross-site scripting), CSRF (cross-site request forgery), and web application logic flaws.  

Using what we learned, we then ran workshops for the rest of the team at Velir to provide information on how these vulnerabilities could apply to our projects and to show them how to do something like cross-site scripting, for example. By doing so, we were able to provide real-world examples that demonstrated the types of security vulnerabilities that can be exposed through code.

"We recommend a number of best practices to our developers such as using pre-tested libraries whenever possible, instead of rolling out their own versions. Developers are expected to meet a baseline standard of knowledge regarding coding practices to ensure web security."

Staying Up-to-Date on Web Security Vulnerabilities Using the OWASP Top 10 List

Our process also includes a formal framework to ensure fluency in vital web security topics. Every developer at Velir goes through in-house training that covers the OWASP Top 10 list.

OWASP (The Open Web Application Security Project) is an organization that sets security standards and provides awareness on what issues exist and what impact(s) they can have. The reality is that there are a lot of vulnerabilities out there; this non-profit organization puts this list together for developers and other individuals that are interested in web-security to help with making their applications more secure.

On average, the list changes every 4 to 5 years (the last release was in November of 2017) to reflect any changes in priority and/or new issues. The main reason behind this is that the attack vectors don’t change very often. There will always be SQL-injection and broken authentication issues. Things only start moving around on the list when something more dangerous crops up.

An important thing to note about the OWASP Top 10 list is that it isn’t platform dependent. For example, SQL-injection vulnerabilities aren’t limited to a vendor (like Oracle, SQL Server, or MySQL) or programming language (like Python, C#, or PHP). Similarly, most of the concepts on the list apply across web technologies. All of them need to transmit information from servers to clients. Several store and retrieve data from databases. These transactions, with data being passed back and forth between applications, present a vector for security vulnerabilities, and it is up to developers to follow best practices to ensure minimum risk with doing so.

Let’s look at an example from the OWASP list titled, ‘A9: Using Components with Known Vulnerabilities’. In this scenario, even if we were to assume that all existing infrastructure is patched and secure, we still need to be cognizant of the fact that a custom application can introduce vulnerabilities. Third-party code libraries are often included in a custom application to help speed up development and save weeks of time. However, they can contain security problems, so we work to track these libraries and look for updates and patches to them .

Though it is ultimately the responsibility of each developer to understand the vulnerabilities outlined in the OWASP Top 10, we empower them by periodically taking courses and hosting training workshops in-house to foster an overall culture of security-minded practices.

Helping Our Clients Define Priorities

Resolutions for the various issues that are identified during our technical and security audits depends on several factors. We provide clients with a list of recommendations that address a security issue based on whether it is high or low impact, the level of difficulty to breach, and the level of urgency. Clients can then go back and evaluate these recommendations based on the impact to their business, budget constraints, and timeline to resolve. This conversation can include staff members from their in-house development team, marketing department, and other stakeholders, so that concerns from various business units are adequately addressed. Sometimes, a client is able to fix the security issues in-house and other times we get involved with the fixes.

If a particular vulnerability is deemed to be low-impact and hard to pull off, then clients may choose to look into it a later time. The rule of thumb is that the larger the codebase, the higher the risk. On average, we expect to potentially find dozens of bugs (though they are not always security bugs) per 1,000 lines of code.

Patching to Keep Websites Protected from Vulnerabilities

The first step when it comes to patching an issue is verification. Vendors typically provide patches but don’t divulge all the details for the fix. In the security space, there’s a fine balance between communicating vulnerabilities to the parties that need to shore up their solutions without giving away information for hackers to take advantage of the vulnerability. If there’s a gap there between the time of discovery and the time of fixing the issue, a window of opportunity opens up during which hackers can exploit these systems.

We work with three of the top enterprise Digital Experience Platforms (DXPs) on the market, Sitecore, Drupal, and AEM. If any of them discovers a vulnerability and issues updates, we apply these updates to make our clients' sites more secure and up-to-date.

For example, when evaluating a Sitecore site, we verify that the client has applied all available patches for their Sitecore version. If patches need to be installed, we provide the steps for doing so. On Sitecore’s end, when critical issues pop up they will provide new versions that patch the vulnerability, but they won’t tell us what they’re patching or share additional details. This is done to prevent people from breaching the same issue in a different way or to protect other clients that are vulnerable because their solutions haven’t been patched yet. For critical issues, Sitecore reaches out to all their clients and lets them know they have to install the patch. For non-critical issues, they issue recommendations (especially with upgrades, cycles in the products, etc.).

In addition to the DXPs, underlying operating systems have their own vulnerabilities. Security patches are released for them, but they’re useless if the systems aren’t patched regularly. In this way, Windows Updates is a catch-22 as well. Hackers can look at what has changed and reverse-engineer the process to discover the vulnerability and hack systems that haven’t been patched yet. A lot of large organizations (such as banks) don’t allow local branches to patch their platforms until they issue a company-wide plan, so they can be sure of exactly which system every one of their branches is running. However, if one machine is hacked, the potential to hack others greatly increases.

We also keep an eye out for patches for front-end libraries such as JQuery, React, NuGet packages, etc. Even hardware like switches, routers, firewalls, etc. have periodic updates that we monitor. In this way, there’s a hardening guide we go through to make sure that our digital solutions are locked down as much as possible. By maintaining a cross-referenced list of which systems, libraries, hardware, and software packages we use for each client solution, we are better prepared to address issues when a vulnerability comes up.

Web Security Needs to be an Ongoing Consideration

Web security is an issue that can affect all layers of a digital ecosystem including infrastructure, servers, networks, the OS, middleware, and applications. It is also not a “one and done” deal. We always have to assume that it’s one development team against, potentially, thousands of hackers. Since we all use many of the same platforms, a bug only has to be discovered in one place—not necessarily targeted at us—before it can affect many of our businesses. Therefore, everyone from the IT and development teams, to marketing and management needs to do their part to ensure best practices are adhered to, to help create and maintain more secure systems. It is imperative that this is done by focusing on web security as an ongoing consideration across all digital projects.