Website Security: A How to Guide on Protecting Your Library, Patrons, and Sensitive Information

Prior to the COVID-19 pandemic, there was a colossal rise in the number, size, and sophistication of ransomware attacks of 147 percent. With the demand for ransomware payments increasing at an alarming rate as the world moves swiftly through 2021, 2020 has been the best year yet for hackers.

As many as 30,000 to 50,000 websites get hacked every single day. It is also reported that fifty-six percent of all internet traffic traces back to automated sources such as hacking tools, scrapers, spammers, impersonators, and bots.  Most institutions don’t even realize that they’ve been hacked or compromised until after the damage has been done. The worst part is that libraries are amongst the top-targeted institutions in the world because their resources to invest in cyber protection are limited. Protect your library from hackers by reading background information on the history of security, common site vulnerabilities, key tactics you can enforce, as well as ways that LocalHop can keep your sensitive information protected and hacker proof.

 

The formal definition of website security is the act or practice of protecting websites from unauthorized access, use, modification, destruction, or disruption. It includes any action or application taken to ensure website data is not exposed to cybercriminals, or any steps taken to prevent exploitation of websites in any way. So, why is it so important? Mainly, web security is needed to keep hackers and cyber-thieves from accessing sensitive information of both a personal and organizational nature. Without a protective strategy, businesses risk the spread and escalation of malware, attacks on other websites, other networks, and other IT infrastructures.

After speaking with some of our team members, Cynerge Consulting‘s Chief Technology Officer, Mike Laney, stressed the importance of having solid website security, particularly with libraries. “Unfortunately, [hacks] happen every day all across the world, and libraries are typically one of the most targeted organizations for hackers and website security threats simply because they don’t have the IT experience.” He went on to discuss the necessity of updated systems, and how current systems could be the difference between safe software and permanent hacks.

“There’s been a history of large fortune 500 companies that were running old versions of Windows SQL servers 2008 where they lost billions of dollars because hackers got in due to how outdated everything was.” The result? Devastation. “Windows didn’t even support the 2008 SQL server anymore, so hackers got in and they put ransomware into the system. What this means is that you literally can’t do anything on any of the computers that were connected to any of those servers without paying the ransom.”

Hackers not only target your customers and clients, but they also cause a loss of favorable reputation and potential drops in revenue for businesses. Websites and companies that have digital facets can also be blacklisted, driving any potential customers or clients away from your business. The bottom line is this: for many companies, it isn’t until after a security breach has occured that website security becomes top priority, and the damage has already been done. The good news, on the other hand, is that by being proactive, consistent, and using effective tactics that work, your library can be as secure as Fort Knox!

 

The simple (but accurate) answer to this question is: EVERYONE. If your business or organization has any sort of online presence or digital platform or software, then absolutely you should be maintaining website security. Owning a website comes with responsibilities and obligations, so don’t let your system become a victim to vulnerability! While there are ways that institutions can organically protect themselves from any sort of cyberattack, it is highly recommended that a professional do it for you. This is why LocalHop is here to help! But first, let’s check out a bit of historical context.

When it comes to common website vulnerabilities, Developers’ Gergely Kalman lists ten of the most common website vulnerabilities that digital facets face, according to the Open Web Application Security Project (OWASP):

1. Injection Flaws

• What is it: Injection flaws constitute a common security vulnerability which allows a user to gain access to your backend database, shell command, or operating system if the web takes user input. When this occurs, the hacker can easily modify information within these input boxes as well as create, read, update, or permanently erase data from your system.
• How it happens: If any unfiltered data has been passed to the SQL (Structured Query Language) server, which then goes to the browser (XSS) and passes through to the LDAP (Lightweight Directory Access Protocol) server, the hacker can inject commands and coding to these facets. The end result? Loss of data and the hijacking of clients’ browsers. 
• How to prevent: Any time your application receives anything from untrusted or unsecured sources, they must be filtered. Refrain from using a backlist and filter your input properly by relying on your framework’s filtering functions. 

2. Broken Authentication

• What is it: Broken Authentication refers to hackers’ ability to compromise passwords, keys, user account information, or other sensitive details that can be used to assume user identities. 
• How it happens: Unfortunately, broken authentication happens quite easily. It can be due to poor design and implementation of identity and access control systems. It can also result from missing or ineffective multi-factor authentication, even if user sessions aren’t properly validated after a logout or during a period of inactivity. All these (and more) are enough to allow a hacker to get in, do irreversible damage, and get out without leaving a trace.
• How to prevent: The main thing to consider is to always use a framework or have experts build your system for you rather than implementing it yourself. Wherever possible, add in multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential reuse hacks.  Refrain from deploying any sort of default credentials, and take advantage of weak password checks! These alone can be the difference between security and crippling vulnerability.

3. Cross Site Scripting (XSS)

• What is it: Cross Site Scripting (otherwise known as XSS), is a client-side code injection attack. It means that the hacker plans on inserting malicious scripting into your web browser by including malicious code into a legitimate web page or app. 
• How it happens: Once the user (in this case, victim), visits the infected web page or application, the code the hacker implemented into the site becomes active, thus delivering the malicious code to the user’s browser. Common platforms for XSS attacks include forums, message boards, and web pages that allow comments. 
• How to prevent: The easiest thing to do in order to avoid Cross Site Scripting is to refrain from returning any HTML (Hypertext Markup Language) tags to your clients or others who use your online systems. This not only will defend against HTML injection, but will protect your initial coding as well, so hackers cannot modify the markup language. 

4. Insecure Direct Object References

• What is it: A direct object reference means that an internal body such as a database key or file is exposed to the user. Without an access control check or other protective methods, attackers can easily manipulate these exposures and access unauthorized data.
• How it happens: This particular vulnerability can occur when a name or key of an object is used during the development process of a web page. For example, if an authorized user tries to access information not intended for that user (such as a database record, specific file, or URL), an insecure direct object reference flaw can occur if the application fails to verify the user’s access to that specific object. 
• How to prevent: Each location where a user can supply input and which points to reference objects, needs to be tested. Perform user authorization properly and routinely. More often than not, the entire problem can usually be avoided by storing data internally instead of passing information from the client via CGI (Common Gateway Interface) parameters.

5. Security Misconfiguration

• What is it: Coming in as number five on the list, security misconfiguration is the failure to successfully implement all security controls for a server or application, or doing so with errors. This ultimately leaves your library open to risks. 
• How it happens: Security misconfiguration is actually very common, and without the right level of visibility, this particular vulnerability can be really dangerous for libraries and other institutions. Some examples of risks include:

• • Unnecessary administration ports that are open for an application. 
  • Having outbound connections to various internet services reveals unwanted behavior of the application in a critical environment, so try to avoid this as much as possible!
  • How to prevent: Have a solid, preferably automated, “build and deploy” process, which essentially prevents your coding from going out with default passwords! Visibility will also be your new bestie. Learning the behavior of your applications is crucial, and this can be done by having a real-time map of your entire digital ecosystem (your communication, flow paths across your data center environment, etc.). Visibility will not only help you learn more about your application behaviors, but it will help you to be able to identify potential misconfigurations at first glance.

6. Sensitive Data Exposure

• What is it: Sensitive data exposure can happen when an application, company, or other entity accidentally reveals personal data to which a hacker can gain access. If you aren’t adequately protecting a database where personal information is stored, then sensitive data exposure is bound to happen to your library!
• How it happens: Sensitive data exposure may be a result of a plethora of things, such as: weak encryption, no encryption at all, software flaws, or accidental uploads of information onto the wrong database. Data exposure can be traced back to how  a company handles certain information that is sensitive, and it can be identified by understanding whether websites use SSL (Secure Sockets Layer), or whether they have HTTPS (Hypertext Transfer Protocol Secure) security on the web pages that store their information. If your website is lacking on this end, your data is at risk of being exposed. Additionally, if you store your data in a database that is subjected to potential SQL injection, or has weak cryptographic algorithms or keys, and you fail to implement hashed and saltword practices, it will be easier for a hacker to get into your site and steal your information.
• How to prevent: Always use HTTPS with a proper certificate and PFS (Perfect Forward Secrecy). This will definitely keep your information more secure and less vulnerable to potential threats. You can also lower exposure when it comes to storage. If you don’t absolutely need sensitive data in your system, shred it. Try to avoid storing credit card information or anything else that could be traced back to personal banking accounts. In fact, some institutions use payment processors such as Stripe or Braintree, both of which completely eliminate the possibility of hackers gaining access. 

7. Missing Function-Level Access Control

• What is it: All this means is that server authorization failed because access was not requested properly.
• How to prevent: The way to rectify this is simple: always make sure your authorization is set up correctly and is maintained, otherwise, serious problems could occur.

8. Cross Site Request Forgery (CSRF)

• What is it: CSRF is a malicious attack that ensues when an ill-intentioned website, email, blog, instant message, or program causes a user’s web browser to perform forced actions on a trusted site once the user (victim) is authenticated. 
• How it happens: A CSRF attack happens because browser requests are automatically required to include all cookies, including session cookies. What this means is that if the user (victim) is authenticated to the site, then the site cannot distinguish between legitimate requests and forged (hacked) requests. To put it plainly, if a CSRF attacker succeeds in getting onto a web browser either through your platform or through a user that is supposed to be there, the hacker can do anything desired because the site recognizes the hacker as an authenticated user. A CSRF attack can allow the hacker to transfer funds, change passcodes, and make purchases with the authenticated user’s credentials. 
• How to prevent: While there are a lot of ways you can defend yourself and your library’s technology, the main thing is to ensure your framework has built-in CSRF protection. This validates any requests that cause site actions on the backend, which makes it very difficult for a hacker to even attempt CSRF.  Lastly, any sort of Cross-Site Scripting (XSS), can be used to defend against all CSRF mitigation capabilities. Not sure what this means? Check out OWASP’S XSS Prevention Cheat Sheet for some additional guidance. 

9. Using Components with Known Vulnerabilities

• What is it: According to security services provider Siemba, new cyber vulnerabilities are emerging each day, particularly when software dependencies from libraries and frameworks (which are previously known to be vulnerable from unpatched software fixes) are not implemented in time. Let us explain.
• How it happens: Libraries and frameworks used within an application are executed with full privileges most of the time. Because of this, hackers can easily make use of automated scan tools or perform a manual analysis of the application to search for flaws and exploit that vulnerability. Ransomware attackers can also use fingerprinting methods such as checking for known HTML elements, triggering eros, and employing forced browsing to find the dependencies. Using components with known vulnerabilities can bring a large risk to your library because of how easy they are to exploit. If hackers can locate the vulnerable components that a specific application is using, they can be exploited with ease. This methodology is already on the internet, so hackers only have to make use of it in order to cause a significant compromise to your data. Unfortunately, these vulnerabilities can be easily missed by the application security defence, and they also act as pivoting points to enable other potential attacks. For example, hackers can manipulate a web service using full permissions but without authorization, while focusing on vulnerable components such as SQL injection, XSS, and broken access control.
• How to prevent: The main reason this happens is most development teams fail to ensure these components and library sites are up to date. So, here is a list of preventative measures you can take to avoid using components with known vulnerabilities. 
• Know your application and prepare adequate documentation of all OS, web server, library, and network components, including current versions used by the application, to ensure the app is well maintained.
• Implement regular monitoring and security assessments testing. 
• Perform periodic vulnerability assessments to confirm the security of your application(s).
• Deploy a web application firewall for providing a defensive posture.

10. Unvalidated Redirects and Forwards

• What: Unvalidated redirects and forwards are the direct result of a web application’s accepting of an untrustworthy input which, in turn, causes the app to redirect the request to a URL containing malicious input. Basically, when an unsecure URL is modified and directly input to a malicious site, an attacker can successfully launch a phishing scam and steal the user's credentials.
• How does this happen: The server name in these modified links are identical to the original site that is the victim of the cyber-attack, so phishing attempts provide a much more trustworthy appearance. If a redirect and forward isn’t validated, a hacker can also craft a URL that would pass the application’s access control check (because it looks identical to the authorized site/user), which would then give hackers privileged functionality to which they normally wouldn’t be able to access.
• How to prevent: One way to completely avoid this vulnerability is to not use redirects and forwards altogether. But, if you or your library does use redirects and forwards, do not allow the URL as user input for the destination. Wherever possible, input an access point in which the user has to provide a short name, ID, or token which is mapped server-side to a full target URL. This provides the highest possible degree of protection against any hacker or cyber-attack that is tampering with your URL. In the event user input cannot be avoided, ensure the supplied value is valid, meant for the application, and authorized for the user. You can also create a list of trusted URLs, as well as force all redirects through a page notifying users that they are leaving your site first, in which they can click a link to confirm the new destination which would be clearly displayed.

After reading through this list, I asked Mike (in his opinion), what he thought some of the most frequently seen or common web vulnerabilities were, and how they easily could be avoided with proper website security. He immediately replied that failure to update packages is the biggest vulnerability. “As technology changes, and with the way these packages are all built, they are so intertwined with each other that scanning is absolutely necessary.” 

Mike went on to give an example. “Let’s say I want to build something simple such as a calendar date picker, and there’s a node package for that, right? I can go out and grab that to put into the site and use it. But, that node date picker may have fifteen, sixteen or even twenty different dependencies, so it has all of these other items that people have created which are plugged into this to make it work. Then you plug it into your site.” Sounds pretty self-explanatory, right? Well, there’s a catch. “If you’re not scanning these packages, then all twenty of those dependencies could have vulnerabilities.” 

As we discussed earlier in this post, vulnerabilities are what make hackers’ jobs easy. Lucky for us, Mike had some great advice about scanning these packages and how LocalHop can help. “A lot of people don’t scan for vulnerabilities, or [if they do], they only scan once or twice every few months, when in reality scans should be run hourly. If you’re using some of these bigger packages, such as items that have a lot of open source support and are frequently updated, that’s where libraries will get those quick fixes every hour or every ten minutes or every week.” Bouncing off this topic, I asked Mike if it was possible to automatically set scans to run every so often, and if so, is it easy to do for librarians that aren’t so technologically inclined? The short answer? Absolutely. 

LocalHop’s process is one of the most efficient, and Mike dove right in. 

“Usually what we do is everytime there is a change in the code, a scan happens. We also set things up to where you could have a scan at eight in the morning and another scan around midnight. For folks that don’t have the technical resources, know-how, or they themselves aren’t building the application, LocalHop will add their names to our email list and scan things for them. The email would then go out and say something along the lines of ‘hey, there were two vulnerable packages just found in your eight AM scan,’ and then they’ll get another email when the code is re-deployed with no vulnerable packages found because at that point we will have gone in and fixed those vulnerabilities.” 

Treading back to Mike’s opinion on the most common vulnerabilities, Mike stresses the importance of fixing those vulnerable packages. “Most of the big website security concerns for me are those vulnerable packages. I’m not saying that you’ll be in a situation where you receive a vulnerable message at eight AM and by noon, you know, your building’s on fire. That’s definitely not the case, but most IT departments that are in the old method of thinking will be running packages that are eight or nine or even ten years out-of-date, whereas LocalHop will keep you updated, revolutionary, and accessible.”

I then asked Mike the following question: so, for example, if we are talking about a local library that may not have the IT or experience, what would you suggest when they are considering website security and building a website? He responded immediately. “Libraries need to understand how to learn about scanning packages. If it’s something that LocalHop is building for them, then they don’t need to worry, but if it’s being built themselves, there are a wealth of resources out there. It really depends on how they are building their website, whether it’s Wix, WordPress, or testing PHP, etc. That’s really the main question: how do we protect ourselves?” Most companies usually have a free software-scanning suite that is built right into Google Chrome. The suite includes an audit feature that can give libraries something to work with if they are developing security on their own. 

Another question Mike brought up which libraries should consider, is what happens if you get hacked and now your website is being held hostage by Russian or Chinese malware? What do you do then? “If you have something built with LocalHop this would never happen because we are continuously doing backups, scans, and security tests around the clock, so within ten minutes your website is restored right back to where it was before a problem arose. However, if it’s not something LocalHop has built and they are doing it on their own, then I would suggest either manually creating a backup at least one per week, or figure out a way to automate a process which backs up your site every night at midnight or during the day. Having backups is essential.”

Whether or not you use an expert source such as LocalHop, or whether you try to implement successful website security yourself, all of the above key concepts and lists are crucial for safeguarding your data. 

It’s important to remember that websites are prone to get hacked at any time, not only because of developing technology, but because cybercriminals never have a specific site in mind when they plan to execute an attack. Churches, hospitals and libraries host a wealth of personally sensitive information, which is why they are among the most targeted institutions for hackers, so having strong and resilient website security is a must. We know that technology is vast, and preventative measures are even more complex, but LocalHop is here to help you make your platforms as secure as possible. We are dedicated to providing your library with the maximizing security benefits that will not only safeguard your community and private data, but will retain your patrons trust, brand reputation, and total protection of your data. 

Choose LocalHop; you won’t be disappointed.