CAll Us: +1 888-999-8231 Submit Ticket

10 Web Hosting Best Practices for Ecommerce Security

Ecommerce websites can provide vast sums of revenue, but adequately securing them can be difficult. These sites are often ripe targets for cyberattacks aiming for financial or other data. If there’s anything that recent times have taught us, it’s that things can change overnight. 

Over the past year or so, ecommerce sales have gone through the roof. Q1 2021 saw retail ecommerce in the US leaping 7.7% over the previous quarter.

Always-available ecommerce websites help us rake in sales around the clock, but safeguarding our sites and customers is a formidable undertaking. There are so many potential points of security weakness, from plugins to web host vulnerabilities.

To overcome this, you need the right mindset, tools, and habits in your inventory to ensure ecommerce security.

Web Hosting Considerations for Ecommerce Security

1. Work With Reputable Security Service Providers

Cloudflare’s DDoS mitigation capabilities include edge detection systems (Image Source: Cloudflare)

Regardless of whether you’re running WooCommerce, Magento, or any other kind of ecommerce platform, you’ll likely be using various security plugins or services. There are many of these in the market, but where possible, choose a reputable service provider.

You don’t need to choose one and work with them alone; there are industry leaders with varying areas of expertise. Cloudflare, for instance, is known for its content distribution network (CDN), which is excellent at mitigating Distributed Denial of Service (DDoS) attacks.

On the other hand, Sucuri offers excellent all-around website protection services, including a formidable Web Application Firewall (WAF).

2. Ensure Data Encryption in Transit

Most website owners today will know about the importance of Secure Sockets Layer (SSL) certificates. They help visitors verify website identity and, more importantly, help encrypt data between them and your ecommerce website.

There are, however, various levels of SSL certificates. Non-commercial websites can get away with using free SSL like Let’s Encrypt, but ecommerce websites should avoid those. Remember that you’re handling more sensitive data, including customer information, payments, invoicing, and more.

Ecommerce websites should always consider more advanced SSL solutions such as the Organization Validation certificate. Many reputable brands offer this, including GeoTrust and DigiCert.

3. Always Secure Service Credentials

Many password managers utilize a zero-knowledge encryption system to secure credentials.

Working online, running several websites, and using hundreds of connected services has taught me a lot about passwords. Unless you’re repeating the same one or jotting them down, it’s impossible to remember complex passwords for each site.

Password managers are a relatively cheap tool that you can use to help with this. They store all your credentials securely so that you can create and use passwords like “xaACI91&2@@-duh” with no problems.

Using simple passwords repeatedly is simply asking for trouble. A single data breach can compromise all your accounts, including administrative access to your ecommerce platform. 

4. Conduct Periodical Vulnerability Testing

Website owners who have their digital properties set up and tested are often averse to touching anything once it’s all running. This aversion is a mistake since tools and technologies are constantly changing.

Developers and security companies are constantly discovering new vulnerabilities, and cybercriminals can quickly get their hands on more modern and advanced tools.

Because of this, you need to be prepared to periodically reassess ecommerce security on your site. One way of doing this is to have regular Vulnerability, Assessment, and Penetration Testing (VAPT) sessions to discover and work towards mitigating potential threats.

5. Get the Right Security Certifications

Aside from your web assets, digitally-oriented organizations like ecommerce firms should look towards comprehensive security certifications. Depending on your location, this could mean several things.

One example of this is the ISO/IEC 27001 certificate, which ensures that you follow proper information security standards. Aside from helping increase your organization-wide resilience, it can also act as a form of customer assurance to let them know you treat their business with due respect.

To get one of the various certifications available, you will need to work with a third-party provider in your country. They’ll carry out an audit of your systems to ensure they meet guidelines, and if so, will issue the appropriate certificate.

6. Have a Strong Focus on Payments Security

One of the most vital weaknesses in ecommerce websites is when customers make the purchase. The exact link where money flows is a highly-valued cybersecurity target. This point is also where you need to ensure compliance with the proper ecommerce security standards.

Standards will vary depending on the payment methods accepted. For example, if you allow customers to pay by card, that means PCI-DSS. The standard helps ensure that proper safeguards are in place to protect payment information.

Failing to meet payment security standards can mean heavy fines, penalties, or future restrictions for your operations. Most payment standards will have guidelines to be followed before you’re certified. PCI-DSS, for instance, requires the use of encryption, antivirus, firewalls, and more.

7. Ensure Web Assets Are Monitored 24/7

Monitoring as a service is available through many brands like Pingdom (Image Source: Pingdom)

The internet never sleeps, and your ecommerce website could come under threat at any time. Having entire IT security teams on a constant watch can be expensive and introduces additional elements of human error.

That’s where automation comes into play, and with the right tools, you can have apps and services constantly monitoring your web server. One example is the use of a web server monitoring tool to keep watch on resource usage. If things spike past a threshold level, it could be an early warning sign of some form of cyberattack.

8. Customer Education

Although customers aren’t part of your infrastructure, they are intrinsically a link to your platform. Attacks against them can lead to ecommerce security compromises on your site. There are some ways you can help them increase security, such as mandating strong passwords or requiring Multi-Factor Authentication (MFA).

However, there are some things they need to do themselves. Educating customers on security best practices is in your best interest. You can do this via outreach programs designed to warn customers about potential dangers such as phishing attacks.

9. Always Have Systems Fully Patched

Ecommerce platforms typically have many moving parts. Even the web hosting solution will need multiple applications working together to properly function; the web server, operating system, ecommerce application, and more.

Developers and security researchers are constantly finding new security issues with existing software. When that happens, developers often release patches. While some of these may be automatically applied, that’s not always the case.

Always have periodical update reviews to ensure your systems are running the latest secure versions of all applications. If you’re using a modular platform like WordPress/WooCommerce, that means ensuring each plugin and theme is also updated.

Where possible, don’t rely on automated patches as these aren’t always the best solution. Sometimes, hastily applied patches may introduce new bugs to operational platforms.

10. Always Ensure Adequate Backup Systems are in Place

Backups are often an overlooked part of any IT system. However, remember that it is a vital pillar of business continuity in a disaster, especially where eCommerce websites are concerned. Having suitable backup systems can mean the difference between an online store that recovers within moments or a total loss.

For most people, backups can be as simple as duplicating data on an alternative location on the server. As the OVH data center fire has taught us, that is far from sufficient. Backup best practices usually involve creating multiple copies of data across various locations. Remember that the data backups also need to be frequently refreshed.

More importantly, you need to verify the integrity of backup systems and data. Instances have arisen where blind faith in backup systems resulted in the restoration of corrupted data.

Final Thoughts: Always Ensure Transparency

Even as you work diligently to secure your digital assets, always remember that customers are a core part of your business. Working with them, you can increase your security profile while offering the transparency that today’s consumers desire.

Sharing updates on security concerns, understanding security challenges faced by customers, and helping them stay safe is in your best interest.

Meanwhile, the security highway is constantly evolving, so don’t be complacent once you have everything established. Be aware of new threats and vectors; that’s the best way to ensure ecommerce security.

Source link

Magecart Attacks Again: the Latest on CardBleed

Only a couple of weeks after the first vulnerability with an associated CVE was discovered for Magento 1 after its end of life, reports about a large scale Magento 1 hack attempt surfaced. 

While stats are not definitive, as of today, around 3,000 sites were hacked. This attack, usually referred to as MageCart, is the most common type of attack against Magento 1 and it’s typically used to collect user credentials and credit card information from the application inputs and exfiltrate data to remote servers.

After carefully reviewing public reports and our WAF logs, Hostdedi identified the threat and swiftly added a fleet-wide block for /downloader. We also isolated the malicious content added to this prototype.js file and have removed it from every file, leaving the original malicious file as backup (prototype.js.bk) for the client’s reference. 

We already had filters for this, mostly against brute force attacks. But given that Magento discontinued Magento Connect after June 2020, we decided to block access and only re-enable it upon request for certain IPs. 

This is one of the biggest differences between a code based Magento 1 maintenance package versus a hosting-based approach. While almost every project issued notices and recommendations, they all required user intervention. 

Our approach was to deploy a fix to the entire server fleet without any user intervention.

While a few stores were impacted, the immense majority remained safe because of the infrastructure and systems we already had put in place. This foundation, plus our swift action, helped thousands of Hostdedi stores and customers to remain secure.

In addition, we released Nexcess_CSP for our Safe Harbor users. Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of attacks including Cross Site Scripting (XSS) and data injection attacks usually known as MageCart. This module helps any Magento 1 store to set CSP policies, avoid and report XSS attacks and has 2 main objectives:

  • Mitigate cross site scripting: disallowing the communication to certain URLs by specifying the domains that the browser should consider to be safe sources of scripts.
  • Mitigating package sniffing attacks: specifying which protocols are allowed to be used; a server can specify that all content must be loaded using HTTPS.

We did not find any intrusion for stores that had CSP_Nexcess installed and properly configured.  Hostdedi Safe Harbor provides an extra layer of protection against this type of attacks, which are likely to continue.

The best kind of protection against external attacks is a mix of server side protection in the form of a WAF plus modules and patches to keep your store protected.

Keeping your Magento 1 store fully operational means protecting it against known vulnerabilities. If you have yet to invest in Safe Harbor, this hack illustrates the importance of staying secure.

Hostdedi Safe Harbor is a sound foundation to keep your sites and stores protected while you are on M1.

Source link

How the Success of WordPress is Due to its Plugin Ecosystem



WordPress’s plugin ecosystem is one of its greatest strengths. As we write, there are over 50,000 plugins in the official repository, a number that doesn’t include premium plugins and custom plugins created for individual WordPress sites. Plugins range in functionality from tiny interface tweaks to full-featured ecommerce applications, all taking advantage of the hooks and frameworks built into WordPress by its developers.
About a third of the web runs on WordPress — tens of millions of sites — so we’re used to statistics about WordPress involving big numbers. However, it’s worth taking a moment to think about what a staggering achievement the WordPress plugin ecosystem is and how many thousands of hours of developer time have been dedicated to creating plugins, the vast majority of which are free and open source.
When Matt Mullenweg started work on WordPress in 2003, it was by no means a certainty that there would be a plugin ecosystem. Many early blogging engines were not designed with a modular architecture. Towards the end of 2003, Ryan Boren joined the nascent WordPress project and his work led to the creation of the plugin system we know today.
Mullenweg created Blogtimes, one of the first useful plugins which is still in the plugin repository, although it was last updated 14 years ago. He also created Hello Dolly, which was bundled with WordPress installations to demonstrate how to build plugins.

What Makes Plugins So Powerful?

Plugins are powerful because they allow anyone to create a feature for WordPress without it having to be included in every WordPress site. WordPress’s history would be very different if every possible feature had to be included in WordPress Core. It would be bloated beyond recognition if even a tiny fraction of the features available as plugins were installed as part of the application, not least because it would lead to a horrendously complex interface.
Plugins serve a purpose beyond allowing WordPress to maintain a slimline application and a manageable user experience. The WordPress 5.0 release lists 12 lead developers and 423 contributors. That’s a lot for an open source project, and it’s challenging to organize so many people, especially when most contribute for free. However, a conservative estimate for the number of people working on plugins is hundreds of times the number working on WordPress itself.
For all practical purposes, it’s impossible to organize that many people to work on a monolithic application while hitting deadlines, maintaining security, and adhering to quality standards. Plugins can be developed independently of the core application, by organizations and individuals that manage themselves, that aren’t tied to the needs and release schedules of the main application, and that can create features that are useful to thousands but that aren’t a good use of the core developer’s time.
Without the plugin system, WordPress as we know it wouldn’t exist. It may not have existed at all in 2019, perhaps being remembered only by historians of content management systems. How many WordPress users are familiar with b2/cafelog, the CMS that WordPress replaced?
Thanks to its modularity and the dedication of thousands of developers, WordPress went from strength to strength and is today one of the most important pieces of software in the world.

Source link

What Is a PCI DSS Audit?

Officially known as an annual PCI DSS assessment, this annual audit is required for Level 1 merchants and recently breached merchants to maintain PCI compliance. These assessments can only be performed by a qualified security assessor (QSA). Read on to learn what you, the merchant, should expect from the audit and how to prepare for it.

Top Reasons to Become PCI DSS Compliant

PCI DSS refers to Payment Card Industry Data Security Standards, and it is required for any store that accepts credit cards as payment. This applies both to stores that process credit cards, and stores that limit themselves to transmitting card data to third party payment gateways like PayPal and others. 

The case for “why PCI compliance” is two-fold:

  1. The five major credit card companies on the PCI Council (Visa, MasterCard, American Express, Discover, JCB) say it is.
  2. PCI-compliant merchants are more effective at protecting their customers’ data than merchants that are non-compliant. 

Or, as a third argument for the merchants unmoved by the first two: PCI DSS helps prevent breaches, and breaches cause downtime and lost revenue. 

For a more detailed breakdown of PCI compliance, see How Hostdedi Helps Your Store Stay PCI Compliant.

PCI DSS Risks

Only 29 percent of companies remain compliant a year after their initial validation because they pass once, then drift into complacency. pci storefront

Auditing is a required component of compliance for larger merchants, and it may be tempting to wonder about the consequences for non-compliance. Some might resent what they perceive as the credit card’s stranglehold on ecommerce. Others might just “have better things to do with my time, like run my business.” 

What’s the worst that could happen?

The short answer is non-compliant merchants can be fined, audited, breached, and suffer damage to their brand reputation. The longer answer is that PCI compliance is the beginning of security, not the end. It’s best to consider it as the “minimum acceptable standard” for securing your customers’ data.

How Much Does a PCI Audit Cost?

On average, a typical PCI audit for a smaller merchant costs about $15,000. This adds to other factors influencing PCI DSS certification cost, which usually relate to infrastructure and paying qualified personnel to apply and maintain best practices of data security. While this is not insignificant, the cost of ignoring compliance is far greater.

Beyond ethical concerns, failure to comply can result in:nexcess pci lock

  • Fines by credit card companies ranging between $5000—$100,000
  • Security breaches, which often involve downtime to resolve
  • Legal action by endangered customers and third parties
  • Damaged reputation and loss of consumer trust
  • Loss of revenue
  • Federal audits

How Does a PCI DSS Audit Work?

If you’re facing an upcoming audit, then you’re either a level 1 merchant with more than 6 million credit card transactions per year, or a merchant from lower PCI compliance levels (2–4) that suffered a recent data breach. Merchants on the lower PCI compliance levels (2The central goal of the audit find non-compliance, provide guidance on how to fix it, and verify you’ve addressed any and all issues. 

The first step is finding a Qualified Security Assessor (QSA) to perform the audit. Only QSAs are licensed to perform the audits, as these organizations are certified by the PCI council to understand their data security standards. 

The simplest way to find a QSA is by choosing one from the list on the PCI website. As with any service, it is usually wise to talk to a few, as not all are created equal. Never hire a company claiming to be a QSA if not present on the PCI list; these companies are either outsourcing your request, or planning to sell you other services. 

Once onsite, the auditor will assess multiple areas of your business. As you might expect, this includes your cardholder data environment (CDE), defined as any device, component, network, or application that stores, processes, or transmits cardholder data. It also includes your policies and procedures surrounding your use of these systems.

PCI Audit Requirements

  • Transparency and cooperation
  • Completed PCI audit checklist
  • Understanding of current PCI DSS
  • Your printed copy of your Report on Compliance (ROC) from the previous year
  • Evidence of quarterly scanning and penetration testing
  • Evidence of regular event log checks
  • Documentation on how you handle third party vulnerabilities

Remember: the role of the auditor is to prevent the compromise of cardholder data, not to punish your company. As long as you’re cooperative and vested, the auditor will explain where you need to improve and help you do it. To execute these changes efficiently, consider appointing a compliance leader within your organization. This individual takes responsibility for compliance efforts, but also should have the authority to compel change across your team.

9 Common PCI Mistakes Revealed by PCI Audits

nexcess data centerIf you care enough about PCI compliance to read this article, then you’re on the right track. Following are nine common mistakes for merchants undergoing audit, though your experience may vary according to your business needs and PCI compliance level. 

Hiring a PCI compliant hosting provider like Hostdedi will go a long way toward preventing these mistakes, but it’s not a magic bullet. Merchants must do their part as well, but most hosting providers can assist you in this task.

Reminder: CDE, or cardholder data environment, refers to any device, component, network, or application that stores, processes, or transmits cardholder data.

Unnecessary storage of credit card data 

As a general rule, you should take every reasonable step to avoid storing credit card data, and never store CVV numbers for any reason. Many merchants choose to store data to accelerate their customers’ checkout process without fully understanding the implications for compliance. Don’t be one of them.

Failure to separate the CDE network from rest the organization’s IT infrastructure

The key phrase to remember in PCI-compliance and access to cardholder data is “as-needed.” Make it your mantra. This applies more so to sub-networks within your organization. When applied to your network, it is known as “network segmentation,” though it usually applies to sub-networks within your organization. Sub-networks used for internal office communications should have no access—direct or indirect—to the sub-networks with access to the CDE.

Failure to restrict access to the CDE to only those employees that need it 

Once again, only employees needing access should have it. This refers both to physical access to areas housing devices within the CDE, but also permissions and passwords.

Insufficient training and security awareness

This extends to your team as well as yourself. If you employ a team, consider appointing someone as a Compliance Officer to take responsibility for training efforts, and give them enough authority to get the job done.

Weak password security policy

Passwords to any system within the CDE should be unique, complex, and never shared between employees. Password managers like LastPass, Zoho, 1Password, and many others are invaluable for safely generating and storing complex passwords. If your team isn’t using one, then it’s a red flag for your security practices. Two-factor authentication for any CDE system is likewise essential, whether Google Authenticator, Duo, or something similar.

Missing web application firewall (WAF) 

A web application firewall (WAF) identifies and interrupts malicious activity and exploits. Most merchants don’t use one in their infrastructure. You can pass a PCI assessment without, but it requires a code audit any time you make changes to your application (Magento, WordPress, and so on). Most hosting providers can provide a WAF solution, or you can use a cloud-based one, which will increase security and simplify PCI compliance.

Inadequate network activity logs 

A network log is a record of events, and is crucial for identifying and tracking the efforts of bad actors attempting to gain access. Again, if you’re a level 1 merchant that processes millions of credit card transactions per year, you’re an inviting target and likely have a network administrator in place. If you’re not a Level 1 merchant and you’re facing audit, then it means you were recently breached 

Missing or poorly configured firewalls and routers 

The security of a network firewall (not to be confused with web application firewall) or router is only as good as the person configuring it. Know your stuff or employ someone that does.

Unclear or outdated security incident response procedures 

Whether you use Magento, WooCommerce, or any other platform, you or your system administrator should take great pains to stay current on the latest vulnerabilities. Have a plan to respond to exploits when—not if, but when—they occur.

Don’t Wait for Your Audit to Get Started

As a final point, never forget that PCI compliance is an ongoing effort. Annual audits are only one component of compliance, but a proactive approach with upcoming changes to your CDE will often pay dividends. Engage your QSA about these changes well before they happen, as they can provide sage advice about maintaining compliance. 

 

For guidance with PCI compliance, contact our sales team between 9 a.m.–5 p.m. eastern time, Monday to Friday.  

Source link

Is the End Near for EV SSL Certificates?

Google, Firefox, and Apple certainly think so. Extended Validation (EV) SSLs are effectively being put out to pasture. Upcoming changes to Chrome and Firefox will soon remove the EV badge from their browsers, citing concerns with its diminished reputation for protecting consumers. 

Standard vs. EV SSL certificates

If you’re already familiar with SSL certificates and the difference between Standard and Extended Validation (EV) varieties, skip ahead to the Why Are Browsers Burying EV SSL Certificates? section. 

SSL certificates are digital certificates that authenticate the identity of a website and allow for secure transmission of credit card data, login credentials, and other sensitive information. Though many types are available, standard SSL certificates provide the padlock icon in most browsers, help make your site PCI-compliant, and are a good choice for most merchants. 

Gray SSL Padlock

In most browsers, sites without SSL certification receive the “Not Secure” label, and anyone clicking on it will read a dire warning. 

Not Secure SSL warning

Furthermore, most browsers also will warn the user before entering any credit card information. Even if they don’t notice the lock, it’s almost impossible to miss the alert upon checkout. This tends to have a chilling effect on most users’ buying experience.

SSL warning

EV SSL certificates attempt to enhance this authentication with a more rigorous (and expensive) validation process. The end result is the addition of the merchant’s established legal identity just to the left of the web address.

In theory, this provides an additional visual cue for consumers, which makes them feel safer and more likely to spend their money on the site. In practice, most consumers don’t notice the absence of a site’s “legal identity,” meaning the EV SSL certificate provide little value to anyone other than the organization selling it.

Why Are Browsers Burying EV SSL Certificates?

In cyber security circles, criticism of EV SSL is not new. The stated goals for EV SSL are 1) to make it harder for phishing scams to fake their online identity, and 2) make consumers feel more safe. Their argument is that EV SSLs are only marginally effective at #1, and utterly ineffective at #2. 

The core failing in the “legal identity” tactic against phishing scams is the relative fluidity of those legal identities. The phrase itself is a misnomer, one that falsely invokes images of face-to-face authentication and triple-checked claims. As demonstrated by one industry professional, the methods of identity verification vary by state, with many ranging between “woefully inadequate” and “cursory.” A determined bad actor would have little trouble registering “Identity Verified” or some other devious “legal identity” to dupe unsuspecting consumers into feeling secure.

However, such efforts would likely be wasted, because the same experts claim most users simply fail to notice the presence or absence of the legal identity. Apple has alread removed the visual cue from Safari and Mojave  for this very reason. Recently, Chrome and Firefox announced their intent to follow suit, with the former stating: 

Users do not appear to make choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection.

For Chrome, this takes effect on September 10. The change comes to Firefox on October 22. The legal identifier will still be available, but buried in the interface and only accessible to the determined clicks of a knowledgeable user. 

Despite the exaggerated claims of organizations eager to sell EV certificates, most users are content to see the padlock and not see any warnings at checkout, both of which are provided by other, less expensive SSL certificates.  

 

If you have questions about which SSL certificate is right for you, contact our sales team for assistance.

The post Is the End Near for EV SSL Certificates? appeared first on Hostdedi Blog.

Source link

How Hostdedi Helps Your Store Stay PCI Compliant

Having a PCI compliant store requires the sustained efforts of both yourself and your hosting provider. Although there are no shortcuts, choosing a credible web hosting provider is an effective place to start. Even so, most PCI requirements can only be met by you, the merchant. Read on to learn more about the dividing line between host and merchant, and why it can be worthwhile to go beyond PCI for your customers.

 

What Is PCI?

nexcess locked safeIn ecommerce, PCI is shorthand for Payment Card Industry Data Security Standards (PCI DSS). Created in 2004, PCI DSS aim to help protect consumers and prevent credit card fraud. It is required for any organization that receives, processes, or stores credit card data of any of the five members of the PCI Security Council: VISA, MasterCard, American Express, Discover, and JCB.

The list of requirements is extensive, to put it mildly. The requirements span six categories, and each category is divided into several hundred specific requirements. Some fall exclusively under the domain of either merchants or hosting providers, while some extend to both. PCI compliance is also not a one-time requirement, as the Security Council makes periodic adjustments to address new threats to consumers.

Compliance is not a “one-and-done” event. It requires daily, weekly, monthly, and annual tasks to maintain compliance. There are 12 general requirements divided among six categories. For illustrative purposes, we’ve listed these same categories, but also included more specific requirements from within PCI DSS. 

6 Key Categories for PCI Compliance

Build and maintain a secure network. Install and maintain a firewall. Use unique, high-security passwords with special care to replace default passwords.

Protect cardholder data. Whenever possible, do not store cardholder data. If there is a business need to store cardholder data, then you must protect this data. Encrypt any data passed across public networks, including data passed between your shopping cart, your Web-hosting provider, and your customers.

Maintain a vulnerability management program. Use antivirus software and keep it up to date. Develop and maintain secure operating systems and payment applications. Ensure your antivirus software applications are compliant with your chosen card companies.

Implement strong access control measures. Access to cardholder data, both electronic and physical, should be on a need-to-know basis. Ensure those people with electronic access have a unique ID and password. Do not allow people to share login credentials. Educate yourself and your employees on data security, and specifically the PCI Data Security Standard (DSS).

Regularly monitor and test networks. Track and monitor all access to networks and cardholder data. Maintain a regular testing schedule for security systems and processes, including: firewalls, patches, web servers, email servers, and antivirus.

Maintain an information security policy. Establish a clear and thorough organizational data security policy. Disseminate and update this policy regularly.

PCI non-compliance can result in fines ranging between $5000—$100,000 per month, depending on the size of the offending organization, its severity, and other factors. Non-compliance can also result in legal action, security breaches, and lost revenue.

PCI Requirements for Hosting Providers 

nexcess monitoringIt is virtually impossible for the typical merchant to be PCI compliant without enlisting the services of a compliant hosting provider. Merchants that host their own websites must meet hosting provider requirements in addition to meeting those for merchants. Such a model works for massive enterprises like Amazon and WalMart, but few others. 

Following are some of the highlights of our systems and policies that uphold our status as a PCI compliant hosting provider. The term “cardholder data environment” refers to any system that stores, processes, or transmits credit card data as well as any system that has access to cardholder data environment itself.

We maintain a web application firewall (WAF), which monitors all connections between the cardholder data environment and other networks. ModSec prohibits public access to sensitive areas, identifies untrusted connections, and hides IP addresses and routing information from unauthorized parties. 

We apply industry-accepted configuration standards for all system components that address all known security vulnerabilities. This extends to our internal and external network, our operating systems, and hardware required to host web services.

We apply cryptography and security protocols that encrypt and protect cardholder data even when transmitted across public networks. SSL certificates and other trusted security keys are unilaterally enforced. Only modern TLS ciphers are permitted.

We restrict physical access to our data center with 24-hour security policies and a team trained to implement them. This includes, but is not limited to:

  • Video surveillance with 90-day footage history
  • Secured entry with at least two-factor authentication (PIN, access card) in most areas, and three-factor authentication (PIN, access card, thumbprint) in areas housing the cardholder data environment
  • Visible identification on all team members
  • Visitor policy that prevents unauthorized public access; authorized external individuals have access only to required areas and are escorted at all times 
  • Team members are given access to the cardholder data environment only if their role requires it
  • Restricted access to network jacks, wireless access points, gateways, networks, and other lines of communication

We track and monitor access to network resources and cardholder data, though it falls to clients to maintain logs and monitor logins for their own applications (Magento, WordPress, and so on).  

We regularly test our security systems and processes, and perform internal penetration testing at regular intervals as well as after any significant infrastructure upgrade. 

PCI Requirements for Merchants

Secure store with HostdediProperly implemented, PCI compliance helps merchants adhere to commonly accepted best practices of data security. Hosting with a PCI compliant provider is a solid first step, but becoming compliant still requires action on your part.

If your store accepts credit cards as payment, it must be PCI compliant whether you store that data or not. Choosing a PCI Compliant web host is only the first step. Most credible web hosts can provide merchants with materials outlining their respective responsibilities upon request, but ultimately it is on merchants to understand and meet these requirements. 

Regrettably, there is no “one size fits all” checklist. Your specific responsibilities will vary according to your merchant level (1–4, with 1 being the highest), which is generally determined by the number of credit card transactions your store processes annually. 

The general process for most merchants is:

  1. Identify, understand, and implement the appropriate PCI DSS requirements. 
  2. Complete a Self Assessment Questionnaire (SAQ). The SAQ is a checklist outlining the requirements. Depending on your level, some or all of them will apply to you. Level 1 merchants have the most requirements; level 4, the least.
    Resist the temptation to simply “check every box” in the SAQ. Doing so endangers your customers and exposes your business to liability. The PCI stands to lose money from breaches, and in response may investigate your SAQ and AOC.
  3. Submit to a quarterly scan by an Approved Scanning Vendor (ASV), an independent, qualified authority that performs external vulnerability scans on your systems. 
  4. Complete the Attestation of Compliance (AOC), a document asserting that you are both eligible to perform and have in fact performed the SAQ to the best of your ability.
  5. If classified as a level 1 merchant, you must take additional steps, including an on-site assessment. 

If climbing the considerable hurdle of PCI compliance doesn’t appeal to you, you’re not alone. Your hosting provider can answer questions related to overlapping responsibility, and third party Qualified Security Assessors (QSAs) can help businesses run the PCI gauntlet (for a price). 

Even businesses offering only PayPal, Auth.net, and other payment services as payment options must be PCI compliant because those businesses must still transmit credit card data.

One universal component is the need to confirm that all of your service providers are PCI compliant. This includes your hosting provider, but also extends to payment processors, payment gateways, POS providers, and any other entities that touch your customers’ cardholder data. 

Some PCI Essentials for Merchants

  • Maintain PCI compliance. Compliance requires ongoing awareness and daily application. Tasks range between daily and annual, but all are recurring.
  • Don’t just check “Yes” to every question in the SAQ. Due diligence protects your business and your customers.
  • Know your code, or use a developer that does. Implement best practices of deployment using staging and dev sites without exception.
  • Establish a secure password policy. Use complex, unique passwords and never allow your staff to share login credentials or use default passwords.
  • Enable two-factor authentication for all of your internal users, and consider providing it as an option for customers logging in to your site.
  • Use a web application firewall (WAF). At Hostdedi, we provide one for all clients and it’s enabled by default.
  • Don’t just take your hosting provider’s word for it. Confirm they’re PCI Compliant and competent by asking for (and getting) their Attestation of Compliance (AOC).
  • Keep your applications and extensions current to the latest stable release, and actively monitor for new threats and versions.

Beyond PCI

If PCI compliance were enough, breaches of high-profile organizations would be far less common. Compliant should not mean complacent.

In reality, PCI compliance is “Cardholder Data Security 101.” It is the minimum acceptable standard and a reasonable introduction, but PCI is far from infallible. Credit card companies require compliance. Merchants adhering to PCI standards will be more effective at protecting consumers than businesses that just pay them lip service, but PCI compliance is only the first step. 

The very nature of PCI — a large, curated document updated only periodically — makes it vulnerable. Standards deemed sufficient in the “current” version are often exposed as inadequate. It can take months or even years for PCI to “catch up,” and bad actors are well aware of its limitations.

The best protection is knowledge. At Hostdedi, we have team members that specialize in web security who stay well-versed in the newest threats, breaches, and countermeasures. Many merchants may be reluctant to enlist the services of a security expert. At the very least, we recommend subscribing to security notifications for your ecommerce application and following at least one credible web security news source. Both sources react much faster than the PCI, and following them will help you “spot the smoke” before it becomes a fire. 

We’re on the List!

Don’t forget, we’re “On the List” of PCI compliant providers officially recognized by the Visa Global Registry. That means we’ve shown a continued commitment to reviewing and improving our security policies to match and exceed PCI compliance requirements. If you’re looking for a PCI compliant provider, hosting with Hostdedi means you’re hosting with an approved and recognized provider. Learn more about the PCI compliant hosting with Hostdedi. 

For guidance with PCI compliance, contact our sales team between 9 a.m.–5 p.m. eastern time, Monday to Friday.  

Source link

How Hostdedi Helps Your Store Stay PCI-Compliant

Having a PCI-compliant store requires the sustained efforts of both yourself and your hosting provider. Although there are no shortcuts, choosing a credible web hosting provider is an effective place to start. Even so, most PCI requirements can only be met by you, the merchant. Read on to learn more about the dividing line between host and merchant, and why it can be worthwhile to go beyond PCI for your customers.

 

What Is PCI?

nexcess locked safeIn ecommerce, PCI is shorthand for Payment Card Industry Data Security Standards (PCI DSS). Created in 2004, PCI DSS aim to help protect consumers and prevent credit card fraud. It is required for any organization that receives, processes, or stores credit card data of any of the five members of the PCI Security Council: VISA, MasterCard, American Express, Discover, and JCB.

The list of requirements is extensive, to put it mildly. The requirements span six categories, and each category is divided into several hundred specific requirements. Some fall exclusively under the domain of either merchants or hosting providers, while some extend to both. PCI compliance is also not a one-time requirement, as the Security Council makes periodic adjustments to address new threats to consumers.

Compliance is not a “one-and-done” event. It requires daily, weekly, monthly, and annual tasks to maintain compliance. There are 12 general requirements divided among six categories. For illustrative purposes, we’ve listed these same categories, but also included more specific requirements from within PCI DSS. 

6 Key Categories for PCI Compliance

Build and maintain a secure network. Install and maintain a firewall. Use unique, high-security passwords with special care to replace default passwords.

Protect cardholder data. Whenever possible, do not store cardholder data. If there is a business need to store cardholder data, then you must protect this data. Encrypt any data passed across public networks, including data passed between your shopping cart, your Web-hosting provider, and your customers.

Maintain a vulnerability management program. Use antivirus software and keep it up to date. Develop and maintain secure operating systems and payment applications. Ensure your antivirus software applications are compliant with your chosen card companies.

Implement strong access control measures. Access to cardholder data, both electronic and physical, should be on a need-to-know basis. Ensure those people with electronic access have a unique ID and password. Do not allow people to share login credentials. Educate yourself and your employees on data security, and specifically the PCI Data Security Standard (DSS).

Regularly monitor and test networks. Track and monitor all access to networks and cardholder data. Maintain a regular testing schedule for security systems and processes, including: firewalls, patches, web servers, email servers, and antivirus.

Maintain an information security policy. Establish a clear and thorough organizational data security policy. Disseminate and update this policy regularly.

PCI non-compliance can result in fines ranging between $5000—$100,000 per month, depending on the size of the offending organization, its severity, and other factors. Non-compliance can also result in legal action, security breaches, and lost revenue.

PCI Requirements for Hosting Providers 

nexcess monitoringIt is virtually impossible for the typical merchant to be PCI compliant without enlisting the services of a compliant hosting provider. Merchants that host their own websites must meet hosting provider requirements in addition to meeting those for merchants. Such a model works for massive enterprises like Amazon and WalMart, but few others. 

Following are some of the highlights of our systems and policies that uphold our status as a PCI-compliant hosting provider. The term “cardholder data environment” refers to any system that stores, processes, or transmits credit card data as well as any system that has access to cardholder data environment itself.

We maintain a web application firewall (WAF), which monitors all connections between the cardholder data environment and other networks. ModSec prohibits public access to sensitive areas, identifies untrusted connections, and hides IP addresses and routing information from unauthorized parties. 

We apply industry-accepted configuration standards for all system components that address all known security vulnerabilities. This extends to our internal and external network, our operating systems, and hardware required to host web services.

We apply cryptography and security protocols that encrypt and protect cardholder data even when transmitted across public networks. SSL certificates and other trusted security keys are unilaterally enforced. Only modern TLS ciphers are permitted.

We restrict physical access to our data center with 24-hour security policies and a team trained to implement them. This includes, but is not limited to:

  • Video surveillance with 90-day footage history
  • Secured entry with at least two-factor authentication (PIN, access card) in most areas, and three-factor authentication (PIN, access card, thumbprint) in areas housing the cardholder data environment
  • Visible identification on all team members
  • Visitor policy that prevents unauthorized public access; authorized external individuals have access only to required areas and are escorted at all times 
  • Team members are given access to the cardholder data environment only if their role requires it
  • Restricted access to network jacks, wireless access points, gateways, networks, and other lines of communication

We track and monitor access to network resources and cardholder data, though it falls to clients to maintain logs and monitor logins for their own applications (Magento, WordPress, and so on).  

We regularly test our security systems and processes, and perform internal penetration testing at regular intervals as well as after any significant infrastructure upgrade. 

PCI Requirements for Merchants

Secure store with HostdediProperly implemented, PCI compliance helps merchants adhere to commonly accepted best practices of data security. Hosting with a PCI-compliant provider is a solid first step, but becoming compliant still requires action on your partt.

If your store accepts credit cards as payment, it must be PCI-compliant whether you store that data or not. Choosing a PCI-compliant web host is only the first step. Most credible web hosts can provide merchants with materials outlining their respective responsibilities upon request, but ultimately it is on merchants to understand and meet these requirements. 

Regrettably, there is no “one size fits all” checklist. Your specific responsibilities will vary according to your merchant level (1–4, with 1 being the highest), which is generally determined by the number of credit card transactions your store processes annually. 

The general process for most merchants is:

  1. Identify, understand, and implement the appropriate PCI DSS requirements. 
  2. Complete a Self Assessment Questionnaire (SAQ). The SAQ is a checklist outlining the requirements. Depending on your level, some or all of them will apply to you. Level 1 merchants have the most requirements; level 4, the least.
    Resist the temptation to simply “check every box” in the SAQ. Doing so endangers your customers and exposes your business to liability. The PCI stands to lose money from breaches, and in response may investigate your SAQ and AOC.
  3. Submit to a quarterly scan by an Approved Scanning Vendor (ASV), an independent, qualified authority that performs external vulnerability scans on your systems. 
  4. Complete the Attestation of Compliance (AOC), a document asserting that you are both eligible to perform and have in fact performed the SAQ to the best of your ability.
  5. If classified as a level 1 merchant, you must take additional steps, including an on-site assessment. 

If climbing the considerable hurdle of PCI compliance doesn’t appeal to you, you’re not alone. Your hosting provider can answer questions related to overlapping responsibility, and third party Qualified Security Assessors (QSAs) can help businesses run the PCI gauntlet (for a price). 

Even businesses offering only PayPal, Auth.net, and other payment services as payment options must be PCI-compliant because those businesses must still transmit credit card data.

One universal component is the need to confirm that all of your service providers are PCI-compliant. This includes your hosting provider, but also extends to payment processors, payment gateways, POS providers, and any other entities that touch your customers’ cardholder data. 

Some PCI Essentials for Merchants

  • Maintain PCI compliance. Compliance requires ongoing awareness and daily application. Tasks range between daily and annual, but all are recurring.
  • Don’t just check “Yes” to every question in the SAQ. Due diligence protects your business and your customers.
  • Know your code, or use a developer that does. Implement best practices of deployment using staging and dev sites without exception.
  • Establish a secure password policy. Use complex, unique passwords and never allow your staff to share login credentials or use default passwords.
  • Enable two-factor authentication for all of your internal users, and consider providing it as an option for customers logging in to your site.
  • Use a web application firewall (WAF). At Hostdedi, we provide one for all clients and it’s enabled by default.
  • Don’t just take your hosting provider’s word for it. Confirm they’re PCI-compliant and competent by asking for (and getting) their Attestation of Compliance (AOC).
  • Keep your applications and extensions current to the latest stable release, and actively monitor for new threats and versions.

Beyond PCI

If PCI compliance were enough, breaches of high-profile organizations would be far less common. Compliant should not mean complacent.

In reality, PCI compliance is “Cardholder Data Security 101.” It is the minimum acceptable standard and a reasonable introduction, but PCI is far from infallible. Credit card companies require compliance. Merchants adhering to PCI standards will be more effective at protecting consumers than businesses that just pay them lip service, but PCI compliance is only the first step. 

The very nature of PCI — a large, curated document updated only periodically — makes it vulnerable. Standards deemed sufficient in the “current” version are often exposed as inadequate. It can take months or even years for PCI to “catch up,” and bad actors are well aware of its limitations.

The best protection is knowledge. At Hostdedi, we have team members that specialize in web security who stay well-versed in the newest threats, breaches, and countermeasures. Many merchants may be reluctant to enlist the services of a security expert. At the very least, we recommend subscribing to security notifications for your ecommerce application and following at least one credible web security news source. Both sources react much faster than the PCI, and following them will help you “spot the smoke” before it becomes a fire. 

We’re on the List!

Don’t forget, we’re “On the List” of PCI compliant providers officially recognized by the Visa Global Registry. That means we’ve shown a continued commitment to reviewing and improving our security policies to match and exceed PCI compliance requirements. If you’re looking for a PCI compliant provider, hosting with Hostdedi means you’re hosting with an approved and recognized provider. Learn more about the PCI compliant hosting with Hostdedi. 

For guidance with PCI compliance, contact our sales team between 9 a.m.–5 p.m. eastern time, Monday to Friday.  

Source link

Does Cloud Security Depend on Processor Security Vulnerabilities?

Does Cloud Security Depend on Processor Security Vulnerabilities?Readers with long memories will recall the suspicion the cloud was greeted with when it was first introduced more than a decade ago. Site owners who managed their servers doubted that cloud vendors could do a better job, especially where security is concerned. Who knew what lurked beneath the virtualization layer? In subsequent years, as cloud platforms came to dominate the infrastructure hosting world, concerns about their security largely evaporated.

In 2019, most companies run most of their infrastructure in the cloud. The benefits of cloud infrastructure have proven immense for improving reliability, scalability, and cost-efficiency for everyone from boutique ecommerce retailers to the largest online stores. Cloud adoption has not resulted in widely exploited vulnerabilities. Servers are still hacked, and data is still leaked, but the exploited vulnerabilities are almost at the application or database layer, not at the virtualization layer or in the underlying physical hardware.

However, no platform is entirely secure, including the cloud. Last year, the Spectre and Meltdown vulnerabilities hit the headlines. Flaws in some CPUs allowed malicious users who could run code on a server to access sensitive information owned by other cloud users. This year, further vulnerabilities were discovered, including ZombieLoad, which could allow an attacker to steal data recently processed by a CPU.

All servers with affected processors are vulnerable to this type of attack, but because cloud platforms are shared computing environments, the risks are higher. A malicious user could exploit the vulnerability by running code in their cloud environment, accessing the information of other cloud users hosted on the same server.

Does this mean the cloud is no longer secure?

No. In fact, cloud platforms like the Hostdedi Cloud are still the most secure infrastructure hosting option. While processor vulnerabilities like ZombieLoad are a real problem for the hosting industry, cloud platforms are best placed to protect their users.

Cloud platforms have access to greater technical expertise. Building a secure cloud platform is not easy, and cloud platforms are not equally secure. However, we have staff developers and system administrators who have decades of experience with infrastructure security. They understand what the risks are and how to manage them. Few hosting clients have access to such breadth and depth of knowledge.

Patches are applied to all servers quickly. When news of the Spectre and Meltdown vulnerabilities broke, Hostdedi quickly patched its servers and released a blog article explaining what was happening. We follow the same procedure for all vulnerabilities that might impact our cloud hosting clients. Ecommerce retailers and other businesses running on owned servers cannot react with the same speed and agility.

Platforms like the Hostdedi Cloud are not secure by default; they are secure because engineers build and maintain them, constantly monitoring security threats and reacting accordingly. Our cloud platform is secure because security is our top priority. That’s not true of most businesses, which is why owned infrastructure tends to be less secure than cloud infrastructure. Bloggers want to blog and ecommerce retailers want to sell. But we’re obsessive about security, and that’s why our cloud platform is the secure hosting choice.

Posted in:
Security

Source link

Getting Started With File Permissions

Getting started with file permissionsFile permissions are an important aspect to consider for any website. This is even more important in a shared hosting environment, since neighboring clients can potentially read or write to your files if the permissions are configured incorrectly.

Even just the ability to read files can expose sensitive information from site configuration files, such as the credentials necessary to access your database. The ability to write or alter your files could allow others to use your site to run malicious code, spread malware, or perform any other number of unwanted activities, including vandalizing your site.

 

Why Are File Permissions Important?

While file permissions are important in any hosting environment, this article will be dealing specifically with current Hostdedi hosting environments. If file permissions are new to you, ask your service provider about best practices pertaining to your specific environment before making any changes.

Before attempting to set or alter permissions, you should first understand how they are represented on a typical web server.

Permissions are granted to three categories: user, group, and other. The user is the user on the system that owns the file. On Hostdedi systems, the group owner will typically be the user. On other hosts, you may have shared groups set up for the web server, FTP processes, and so on. In this context, “other” means absolutely any user having access to the system, including the group and owner.

 

What File Permissions Are There?

Each of the above categories can be granted three standard permissions: read, write, and execute.

The read permission allows a user to see the contents of the file. The write permission allows users to alter the contents of a file. The execute permission gives a user the ability to run a file if the file type is executable on the system, or can be run within a directory. This would not typically grant any special abilities on a normal image file.

The read, write, and execute permissions are typically represented in two forms. One form is the letters r (read), w (write), x (execute).

 

Octal Form File Permissions

The other form is known as an octal form, where 4 represents read, 2 represents write, and 1 represents execute.  

If more than one permission is being granted, the numbers are added together, with the numbers shown in the order, user–group–other. For example, permissions of 700 would mean the file owner (user) has read, write, and execute permissions, but the group and everyone else has no permissions. If the permissions were set to 600, the file owner would have read and write privileges (4+2), with all others having no permissions. 777 grants read, write, and execute access to all users.

One special, helpful permission, is the setgid permission. Using this on a directory will cause any file created in the directory to inherit the same group as the parent directory. There are other special permissions, as well as access control lists that can be applied to files and folders beyond the user, group, and other categories, but they are outside the scope of this article.  

 

Hostdedi File Permission Defaults

Current Hostdedi systems run the Apache web server as a separate user, so directories typically need “other” execute permission. This allows Apache to operate on the contents of the directories.

Apache needs read access for any .htaccess files used by your site, and read access to static files like CSS, JS, and image files. These permissions allow Apache to read and transmit files to the end client requesting them. All PHP files will be executed by your system user using PHP-FPM, and should typically only have permissions granted to the user.

Since PHP processes and application run as your user on the system, these files typically only need to be accessible by your user.

To summarize general permission settings for securing a web application:

  • Directories should be 711, which allow your user full access and allow the web service access to the directories to read static files.
  • PHP files and application configuration files should have permissions of 600, which allows only your user access.
  • Image files and static site assets such as CSS, JS, font files, and so on need permissions of 644, which allows Apache to serve these as expected without receiving a 403 or forbidden response.

 

Checking File Permissions

Two easy ways to check file permissions are with the stat and ll commands.

Issuing the stat command on a file does show much more information that simply the permissions, but on the first line that starts with Access: will show the permissions in both numerical and alphabetic forms. The stat below shows the permissions as 0660 or -rw-rw—- . Which would be user and group having read and write access but all others having not access.

 

  $ stat file.xyz 
  File: `file.xyz'
  Size: 0          Blocks: 0          IO Block: 4096 regular empty file
  Device: 807h/2055d Inode: 524917      Links: 1
  Access: (0660/-rw-rw----)  Uid: (1337/uzer) Gid: (1337/uzer)
  Access: 2018-07-19 15:01:42.000000000 -0400
  Modify: 2017-04-04 08:36:53.000000000 -0400
  Change: 2018-07-19 15:01:42.891553118 -0400



Using the ll command you will only receive the alphabetic form of the permissions, output from the same file above looks like the content below when using ll.

 

  ll file.xyz 
  -rw-rw---- 1 uzer uzer 0 Apr  4 2017 file.xyz

 

Setting File Permissions

The chmod command is used to change permissions, it accepts the permissions in several formats. Below we are changing the permissions to 600 for the file.xyz file.

 

  chmod 600 file.xyz

 

To express this in the non numeric way, we would use the command below. This would set it so the user has read and write access.

 

  chmod u+rw file.xyz

 

To add permissions so a user group can have read and write access, you would use the following syntax.

 

  chmod ug+rw file.xyz

 

Bulk File Permission Changes With the Chmod Command

Changing the permissions on a large number of files at once can be done by using the -r or recursive flag with the chmod command. You can also use the find command, in conjunction with the chmod command, to select certain files or file types and adjust their permissions.

An easy way to help secure file permissions across your site is to run the following commands from your web application root directory.

First we set all directory permissions to 711.

 

  find . -type d -exec chmod 711 {} ;

 

You may want to use the setgid on the directories, this would be set on all directories with the following command.

 

  find . -type d -exec chmod 2711 {} ;

 

Then we set all file permissions to 644 so your user has read and write access and your group and others have read access. This will allow Apache to access and serve static site files.

 

  find . -type f -exec chmod 644 {} ;

 

We would then want to go through and tighten security on all PHP files so only your user has access to them.

 

  find . -type f -name “*.php” -exec chmod 600 {} ;

 

After doing the above, you would want to manually change the permissions with chmod on any sensitive site files without the .php extension to 600. For something like Magento 1.X with a local.xml configuration file, the command would be the following, run from your web application root:

 

  chmod 600 app/etc/local.xml 

 

Application Specific Configuration Files

Below are some notable application-specific configuration files that should use 600 permissions exclusively. For additional security, some of the below applications also recommend moving directories containing configuration files outside of the website’s document root. If your application has been modified, some of these files may be in a different location, or there may be additional sensitive configuration files. When in doubt, contact your web host or development team.  

Magento 1.X

app/etc/local.xml

Magento 2.x

app/etc/env.php

WordPress

wp-config.php

Drupal

sites/default/settings.php

ExpressionEngine

system/expressionengine/config/config.php

Craft

craft/config/db.php

Posted in:
Linux, Security

Source link

The Dangers Of Exposed Git Repos

The Dangers Of Exposed Git ReposStoring Git’s repository directory – the .git directory – in a publicly accessible area of a website may expose sensitive information that bad actors can use to steal data or compromise the site.

Git is a version control system and a major part of many development workflows. WordPress and Magento developers use Git to version control code and to collaborate on its development. Git itself is secure, but developers can cause security issues if they aren’t careful where version controlled code is stored.

In a recent survey of many millions of domains, security researcher Vladimír Smitka shows just how prevalent this misuse of Git is. After scanning more than 230 million domains, Smitka discovered 40,000 WordPress sites, 4,000 WooCommerce sites, and 2,000 with exposed .git directories.

Why Are Exposed Git Directories Bad For Security?

The .git folder contains records of every change made to a site’s code. That information is useful to bad actors looking for clues about vulnerabilities in the site. Information about how code is structured, which libraries are used and their versions, API endpoints, and other details about the site can be used by bad actors to develop a plan of attack. Ordinarily, this information is difficult to find, but an exposed .git repo makes life much easier for bad actors.

This situation is made worse if developers version control sensitive information such as database passwords and API keys. Sensitive data should never be stored in version control systems that are accessible to the public – in fact, they should not be stored in version control at all. Unfortunately, many developers do store sensitive information in Git repositories. If they also have .git in their web server’s public directory, the whole world can access them.

Does Your Site Serve A Git Repository To Visitors?

As Smitka points out, the straightforward method for finding a .git repository often doesn’t work. If a developer tries to visit https://example.com/.git they may receive a 403 error even if there is an exposed repository. The error is caused by a missing index.html file and configuration that denies directory listing.

However, a bad actor could visit https://example.com/.git/HEAD and, with a little trouble, access the sensitive information they want.

Mitigating The Problem

The best solution is the simplest. Don’t put sensitive data in Git repositories. Don’t keep .git in directories that are served by your web server. If you have decided that you need to keep version control information in a directory that would by default be publicly accessible, you can block access with a rule in the site’s .htaccess file.

There are various ways to block access to the .git directory, but Smitka has created a simple .htaccess rule that works well for Apache 2.4:

<Directory ~ "/.(?!well-known/)">
 Require all denied
</Directory>

This rule blocks access to all dot directories except .well-known, which is often used to provide site metadata to web clients. You will find a version suitable for Apache 2.2 here.

Posted in:
Security

Source link