The Increasing OAuth Phishing Threat

OAuth Phishing Threat
OAuth Phishing Threat

OAuth Phishing Threat

People are gradually growing more careful about phishing schemes that impersonate websites and ask for their passwords. But what if they don’t have to give a password to let an unauthorised party get at their data? That’s exactly what happened in a recent phishing campaign aimed at Google users. Hard numbers aren’t available on how many people were affected, but Google said the number was “fewer than 0.1% of Gmail users,” which could be as many as a million.

The Google Docs spoof

People received a message on their Gmail accounts, usually from an address they knew, asking them to open a “Google Doc.” If they did, it asked them to give Google Docs certain permissions, including permission to “read, send, delete, and manage your email.” No password confirmation was necessary, since the victim was already logged in. The only trouble was that the application wasn’t Google Docs but a malicious lookalike web app.

If the victim gave permission, the attacker could then use the account to send the same email to the victim’s contacts. This could have spread without limit if Google hadn’t promptly shut the application down.

The deception took advantage of design and implementation weaknesses in the widely used OAuth2 specification, which allows one Web application privileged access to another. Researchers had warned in 2011 that this kind of spoofing was possible, creating a proof-of-concept application. The 2017 attack may have drawn directly on that code.

What made the attack plausible

A combination of design issues with OAuth, social factors, and implementation choices by Google made the spoofing plausible to anyone without a strong understanding of security issues. The application was in fact hosted on Google, which lets users develop applications for public use. It was a reasonable imitation of Google Docs; the URL was wrong, but it was a Google URL. The mail came from trusted accounts.

The application was called “Google Docs.” Until very recently, Google didn’t prevent user applications from using its name. It still doesn’t provide any warning when an application making this type of request isn’t under Google’s control.

There’s no good reason Google Docs should ask for access to the user’s Gmail account, but people are used to wildly excessive requests for authorization. Websites that let your account connect to a LinkedIn account often ask for permission to post on your behalf. Most people apparently grant it without worrying.

OAuth Phishing Threat

The trouble with OAuth

The deeper problems, which aren’t restricted to Google, lie in the OAuth standard. It’s an authorization system which is weak on authentication. Without strong protections, it makes it easy to trick users into giving untrustworthy applications access to their private data.

In brief, OAuth2 lets a client application request permissions from a server. Only authorized applications can make requests. An application that’s allowed to use OAuth receives a client ID, which is public information, and a client secret (or key), which is confidential.

When the client app invites the user to give it permission, it redirects the user to a server URL. The server will inform the user of the request and give a choice of denying or allowing authorization. If the user allows it, the server redirects back to the client and sends an authorization code, which the client has to retain for as long as it wants to keep the permission. This could be just for a session or permanent. The server can limit its duration.

An obvious problem with this arrangement is that the server needs to trust a client over which it has no control. The client might be trustworthy at the time it gets permission, but a change of policy or a malware infection could change that. Theoretically, users should trust only applications in which they have very high confidence, but many people are far too trusting. The organization operating the server needs to carefully limit the clients it will give access to.

A poor implementation lets a client pretend to be a trusted application. The server has some control over this, since it knows what application is making the request, but it may or may not make it obvious to the user. If it just displays the application’s self-selected name, that’s weak protection.

Users who authorize a rogue application may not even realize there’s a problem. Google and other sites that use OAuth normally make a list of authorized applications available to the user and allow revocation, but it’s buried somewhere in the user settings.

Future risks

It’s a lucky thing that the Gmail attack apparently did little damage. One thing Google did right was to catch the rogue application and revoke its credentials within an hour. We can be sure others will try similar tricks, sometimes with services that don’t react so quickly. Any organization that uses OAuth to grant third-party applications access to its site should review its implementation and policy to make sure it isn’t vulnerable.

The most important precaution is to screen applicants for credentials carefully. A lot of users will give permission to any application that seems to do something useful, so it isn’t enough to trust them to exercise discretion.

Even if what an application currently does is legitimate, the applicant’s reputation needs to be good enough that it isn’t likely to misuse its authorization in the future. Clients should be periodically reviewed to make sure they still deserve trust. If there’s any sign they don’t, it’s important to follow up quickly and, if necessary, revoke authorization. Even an honest organization could have its credentials stolen or its code infected.

The organization should think carefully about what kinds of access it should authorize. The power to speak for the user can be used for fraudulent purposes. The power to read private data could allow theft of secrets. There needs to be a convincing case that the benefits from the application justify the risks.

Authorizing third-party applications can greatly increase the value of a service, but it carries serious responsibility. Anyone who implements it needs to be aware of its dangers and make choices that minimize the chances of abuse.

If you’re concerned with the security of your planned website, OrangeWebsite will provide hosting that will satisfy  your needs. Contact us to learn more.

Web Hosting Talk: Most Common Web Hosting Problems

Web Hosting Talk
Web Hosting Talk

Web Hosting Talk on the Most Common Web Hosting Problems

There are so many web hosting companies to choose from that many people find it confusing to choose one. Even once you’ve signed up with one, how do you know you’ve made the right choice? One of the interesting things about web hosting is that the better it is, the less you think of it. Ideally, your website is running so smoothly that you seldom give much thought to your web hosting company. It’s sort of like the electricity or plumbing in your house. You only notice it when something’s wrong. With this in mind, let’s have a little web hosting talk about some of the typical problems that individuals and businesses have with their hosts. These are all signs that it’s time to rethink your web hosting choice.

Slow or Unreliable Service

You depend on your web host to keep your website online. You also want to work with a company with fast and reliable servers so that your visitors and customers can load pages quickly. Nowadays, people have very little patience for slow-loading pages. Delays of even a few seconds mean losing visitors. That’s why you need web hosting that’s fast and reliable, with high uptime. Before you blame your web host for slow-loading pages, however, remember many factors affect page loading speed. For example, if you have images that aren’t optimized or lots of videos on your site, this can cause slowdowns. If you use WordPress, too many plugins could be the culprit. However, if you find that you’ve done everything possible to optimize your site and it’s still slow, your host may be the problem. If you’re shopping for a web host, try to identify some of their customers and test their websites for speed.

Web Hosting Talk

Unreliable Support

No matter what kind of website you have, it’s likely that you’re going to need support at some point. Whether it’s to ask a question about a certain feature or report a problem, it’s important that you can reach someone promptly and get your issue resolved. If you have a business, it’s even more crucial. Website problems can quickly translate into losing sales and customers. Unfortunately, not all web hosting provides reliable support. One feature to look for is that you can reach someone 24/7, not only during normal business hours. You don’t want to get stuck if a serious issue occurs on a weekend or late at night. Of course, support is more than someone answering the phone. You want to reach a knowledgeable and helpful person, not get stuck on hold or talking to someone who can’t solve your problem. Reading customer reviews of web hosts is a good way to gauge how strong a company is in this department.

Insufficient Security

With issues such as hacking and identity theft in the news, security is another essential element you want in a web host. If your site has already been hacked, this is a sign that your web host isn’t providing the level of security you want. Of course, you should also realize that security is also about the type of plan you choose. No matter who your web host is, a shared hosting plan is always your least secure option. If you have a growing business, you should seriously consider upgrading to VPS or dedicated hosting. However, even with shared hosting, there are different levels of security. Look for a web host with a secure data center (or multiple ones). Another important security feature is For example, your web host should offer security services such as two-factor authentication, which makes it harder for unauthorized parties to log in and access your site. Web hosts should also offer backup services to ensure you don’t lose your data.

Web Hosting Talk

Lack of Flexibility and Scalability

A website is not something static; you want it to grow and evolve along with your needs. As your business grows, your needs expand. A good web host makes it easy to scale your business. As mentioned, you may want to upgrade from shared hosting to VPS or dedicated. Beyond this, however, you want a web host that offers a great deal of flexibility. For example, if you do have VPS (Virtual Private Server) or dedicated hosting, does your host allow for unlimited data transfers? You also don’t want to overpay for hosting. A flexible host offers many plans so you’re only paying for the data you actually use. That way you can upgrade (or downgrade) your service based on your needs. Make sure that your web host is flexible enough to let your website grow.

You Don’t Have All the Features You Need

You shouldn’t have to compromise on the features or level of service you offer customers because your web host limits your capabilities. Does your web hosting company let you install PHP scripts, b2evolution, Joomla, WordPress, e-commerce platforms, or other features you need? Does it offer Windows as well as Linux hosting? While Linux hosting is the most common, some businesses use software that requires Windows hosting. The features you need depend on your own particular needs. When comparing web hosts, it’s wise to look ahead and consider the services you’re likely to want in the future.

Web Hosting Talk

Poor Value

When it comes to web hosting talk, you can’t ignore cost. At the same time, don’t be tempted to sign up with a web host simply because it’s cheap. Low price doesn’t always translate into good value. On the other hand, you don’t want to pay more than you have to for reliable hosting. When looking at plans and prices, make sure you read the fine print. Many web hosts offer cheap introductory prices but keep in mind you’ll have to pay the full price when you renew. Some reasonable plans force you to sign up for long periods such as two or three years. Carefully consider the cost along with all of the features and services the company offers to figure out whether you’re getting solid value.

These are some of the major factors to consider when assessing your web hosting or when shopping for a web host. Web hosting talk covers many issues, so it’s important to make sure that you carefully consider your own needs. If you’re looking for reliable, secure and affordable web hosting, contact us.

The Trouble with Let’s Encrypt

Lets Encrypt Free SSL

Lets Encrypt Free SSL

Lets Encrypt Free SSL

SSL certificates all perform the same task, but they aren’t all equal in quality. Let’s Encrypt issues certificates that are free of cost and easy to install, with the aim of making secure Web connections as universal as possible. The downside of this approach is that its certificates don’t offer much confidence in their authenticity. At OrangeWebsite, we’ve decided not to accept them on our shared hosting, though you can use them on a VPS or dedicated server. We’d like to let you know our reasons.

Not all SSL certificates are the same

Having an SSL certificate provides an encrypted connection between a browser and a Web server. The protocol family that supports this is widely known as SSL, but current versions are more properly called TLS. Connecting by TLS guarantees that the server belongs to the owner of the certificate. A certificate authority (CA) digitally signs the certificate, indicating it has confirmed its authenticity.

Anyone can create a self-signed certificate. It will enable encrypted connections, but without a CA’s signature, there’s no guarantee that the site owner is who it claims it is. Browsers warn users against trusting self-signed certificates.

Let’s Encrypt acts as a “free, automated, and open certificate authority.” It allows anyone to set up a secure website at no cost and with little effort. This is good, but prominent figures in the tech industry have expressed serious concerns about its certificates.

The process for setting up a certificate is simple. A couple of commands on a Linux server will do the whole job. The problem is with the level of authentication provided. The only validation is that the applicant for the certificate controls the domain it’s issued to. If you’re getting a certificate for example.com, you have to register it from example.com. There’s no checking who you are. This type is known as a “domain validated” certificate. Let’s Encrypt isn’t the only CA to issue domain validated certificates, but it’s the only one that doesn’t charge anything for them.

Lets Encrypt Free SSL

Certificates and trust

Just having an SSL certificate, especially one that’s only domain validated, doesn’t make a site trustworthy. It could be a near-lookalike for a well-known domain (e.g., micros0ft.com). Let’s Encrypt has reportedly issued over 14,000 certificates to domains that impersonate PayPal.

Some domains allow users control of subdomains (e.g., mydomain.example.com). They can obtain certificates for their subdomains. This can give the impression of approval by a well-known site. The subdomain may redirect to a different domain, on an independent server which the primary domain has no control over.

The most trustworthy SSL certificates are EV certificates. EV stands for “extended validation” and signifies that the CA has met certain standards for checking the applicant’s identity. It has checked and confirmed that the applying organization legally exists and is who it claims to be. Browsers generally indicate an EV certificate with a green symbol, such as a padlock.

Unfortunately, most people don’t recognize the nuances. If they see a padlock, they’re likely to assume the site is trustworthy. Since Let’s Encrypt doesn’t even require a payment method, its bar to registering a certificate is very low. It plans to check the Google Safe Browsing API for known phishing or malware sites, but that’s about the extent of its checking. There have been confirmed reports of malvertisers using its certificates. When certificates are free, it’s easy to set them up with throwaway domains.

We hope that in time, Internet users will better understand the difference between a secure site and a legitimate one. When the large majority of sites display a padlock in the address bar, browsers will need to make a clearer distinction among the levels of validation. Eventually they may warn users about sites whose certificates are only domain validated. If a browser did that today, though, it would have to issue a constant stream of warnings.

For the present, it’s a good habit to click on the padlock symbol of a secure site if there’s any doubt about it. The browser should give information about the site’s level of validation and its owner of record. Some browsers, though, will say nothing more than “This site is secure.”

Lets Encrypt Free SSL

Openness and trust

Let’s Encrypt has explained its policy. It argues that a CA is in a poor position to police a site’s content. It’s difficult to determine if a site is clean, and harder to check if it stays clean. The primary aim of the project is to make as much of the Web as possible use TLS. That will inevitably include rogue websites. These sites exist anyway; the only difference is that some people may trust them more when they see the padlock symbol.

Any issuer of domain validated certificates faces this risk, and even the EV level isn’t completely safe against malicious sites. A signed certificate isn’t and can’t be proof of trustworthiness. Let’s Encrypt doesn’t want to take on the role of a censor, and we appreciate that. At the same time, we don’t want to give dishonest websites the appearance of legitimacy if we can avoid it.

We offer several options for purchasing SSL certificates. The lowest priced ones are domain validated, but the annual fee will discourage acquiring certificates for throwaway domains. For a better level of validation, we offer the Comodo InstantSSL certificate with business-level validation. The best validation comes with our Comodo EV certificates, either for a single domain or for multiple domains sharing the same IP address.

Balancing trust and openness can require some difficult tradeoffs. One of our chief goals is to enable free expression, but we don’t want to be a magnet for deceptive and dangerous sites. We hope you understand the reasons for our choice. Feel free to contact us with any questions.

What Is a 403 Error?

What Is a 403 Error?
What Is a 403 Error?

What Is a 403 Error?

Every response on the Web comes with an HTTP status code. Users don’t see most of them on their browsers. The browser just uses them to do its work. The most common one, 200, says that the request succeeded. Others indicate redirection to another URL, a software error, or a problem delivering the requested content.

The last category — that the server can’t or won’t deliver what was requested — uses numbers starting with 4, and those often are visible on the browser. Everyone has run into code 404, “not found.” It comes back when the user enters the wrong URL, or when the page it used to serve is no longer available.

Code 403, meaning “forbidden,” isn’t as common, but most regular Web users have seen it. The World Wide Web Consortium’s official description is “The server understood the request, but is refusing to fulfill it.” It generally means that the content exists but isn’t available to the user.

Sometimes this code indicates a bug on the server side. If OrangeWebsite hosts your content, we’ll help you to make sure your audience doesn’t get it by mistake.

Causes of 403 responses

A request can get a 403 response for several reasons. Some are legitimate rejections of the request, but others may indicate errors in setting up the server. Legitimate refusals can be for these reasons:

  • The content is private, and the viewer isn’t logged in as its owner.
  • The content is restricted to a set of authenticated users.
  • The IP address in the request is prohibited. This can happen if the client is listed as a malicious site, or if the content is geographically restricted.
  • The IP address is temporarily blocked, for reasons such as too many failed login attempts.
  • Security software has flagged the request as malicious. For instance, its data might look like an SQL injection attempt.
What Is a 403 Error?

A 403 response can result from a mistake in setting up the server:

  • There is no default file that manages the site’s configuration. This will happen if the user enters a request like http://example.com/ and there is no file with the name index.html or another name which the server configuration recognizes as a default. The site configuration may allow directory listing, in which case the user will see a list of files instead. This option is a bad idea for both user-friendliness and security. The directory should have a default file.
  • File permissions aren’t set up correctly. This often happens when the owner of a file is different from the user the Web server runs as. For instance, if a file belongs to “admin” and is readable only by its owner, and the server runs as “apache,” it won’t be able to read the file and will return a 403 error.
  • A bug or configuration error is making security software refuse legitimate requests.
  • The .htaccess file, which controls the requests the server accepts, contains errors. A defective .htaccess file might block all requests or allow ones that shouldn’t be allowed.

Another possibility is that the user’s employer or ISP is blocking the request. Some countries mandate blocking on a nationwide scale. The blocking node returns a 403 code without passing the request on to the server.

What to do

A legitimate 403 response is no problem, but if users are getting them when they shouldn’t, it’s necessary to fix the issue. This checklist will let the administrator fix many problems:

  • Make sure the account that the server runs under has all necessary file permissions. The simplest way to do this is to have the content files belong to the same account. Alternatively, the files can belong to another user in the same group and be set as group-readable.
  • Review the .htaccess file to make sure it does what is intended and doesn’t have syntax errors.
  • Check that any security configuration software (e.g., mod_security) has the correct rules and isn’t excessively strict.
  • If only certain users are getting 403 resopnses, try to find out if the site is on a blacklist.
What Is a 403 Error?

Related status codes

The 403 response has a different meaning from other codes in the 400 and 500 series. Websites don’t always use the right code, and sometimes it’s unclear which one should be used. These are some that might appear:

  • 401 (unauthorized): The site is asking the user to present credentials, such as a password, before it will make the content available. This is different from a request to log in to the site.
  • 404 (not found): A site may use this when it doesn’t want unauthorized users even to know it’s a valid URL. Giving a 403 response tells the user that something resides there, and sometimes that’s more information than they want to give.
  • 406 (not acceptable): The content is available, but the request insisted on giving it in a form (e.g., a certain encoding) which the server can’t deliver.
  • 410 (gone): The content is no longer available. This is rare; most sites use 404 in this situation.
  • 451 (unavailable for legal reasons): This code is an IETF proposed standard. You may see it for legally blocked content as an alternative to 403. It could indicate regional blocking for copyright reasons or prohibition by a government. The number is a play on Ray Bradbury’s novel about book-burning, Fahrenheit 451.
  • 500 (internal server error): This usually indicates an uncaught error in the software running on the server.
  • 503 (service unavailable): A server may return this when it’s down for maintenance or overloaded. The resource will be available at a later time.

We can help

If your site is hosted on OrangeWebsite, we’re ready to help you fix mysterious 403 errors and other problems. Our service is second to none, with an average ticket response time of just fifteen minutes. Signing up for site hosting is simple and quick, and we don’t believe in censorship. As long as your content complies with our terms of service and Iceland’s laws, it won’t be “forbidden.”

What Can We Learn from the Cloudflare Leak?

Cloudflare Leak
Cloudflare Leak

What Can We Learn from the Cloudflare Leak?

Cloudflare calls itself the “web performance and security company,” so it was a serious blow to its reputation when researchers discovered that it had a security bug that made sites’ data visible on other sites. What was really disturbing was that supposedly secure data from HTTPS requests leaked out this way. Passwords, session cookies, credit card information, and other sensitive data simply showed up in random places.

Google researcher Tavis Ormandy discovered this problem on February 17, and tech media have attached the name “Cloudbleed” to it. Cloudflare provides services to millions of websites, and any of them could have suffered a loss of confidential data. Many of them have urged users to change their passwords. The risk to any individual is low, but the effect was so widespread that personal data could have been stolen from a significant number of people.

Cloudflare has fixed the bug, but the leaked data could still be lurking in the caches of search engines and edge servers, and data thieves now know to look for it.

Cloudflare’s incident report explains that the problem stemmed from a buffer overrun bug. For efficiency reasons, low-level system software is often written in programming languages, such as C, which don’t automatically guard against accessing memory structures outside their limits. An HTML parser had a bug of this type, resulting in its picking up data from whatever was past the end of a memory buffer. It could be anything, and sometimes it was private data from another website.

The risk in third-party services

Any website can have bugs in its software that open security holes. That’s one reason HTTPS connections aren’t 100% secure. Old versions of SSL (TLS) have problems. The “Heartbleed” bug in older versions of the widely used OpenSSL software showed it was possible to exploit the weaknesses. The latest version fixes the problem, but there’s no guarantee that it’s completely bug-free. Many websites still use old versions of OpenSSL, with known weaknesses.

When a site uses a third-party service such as a caching proxy or a content delivery network, it can gain or lose security. A top-quality CDN has better security measures than most do-it-yourself sites, and it filters requests to the sites’ servers. It can absorb DDoS attacks that would kill a one-machine server. Cloudflare features a web application firewall (WAF) that protects sites at the application level from many kinds of attacks.

This comes at a price, though.

To get the full range of services from Cloudflare, a website has to hand over its most precious secret: its private SSL key. Without that datum, Cloudflare couldn’t do anything with HTTPS requests and responses but pass them through. It wouldn’t be able to see anything except what server and port number they were going to.

The fact that the breach included HTTPS data underscores this issue. If Cloudflare didn’t have sites’ private keys, it could never have leaked passwords that were properly sent through HTTPS. By the same token, it couldn’t have provided a useful WAF to protect servers that use secure communication. Sharing a private key with a CDN creates a potential risk, even if there’s an overall gain in security.

Cloudflare Leak

Vulnerability to governments

However, giving a CDN a site’s private key opens up one serious hole, which no software can guard against. A government can demand it, compel the CDN to stay silent, and have access to all of the site’s SSL transactions. Government agents can spy on it indefinitely, and the site’s owners won’t have a clue that it’s happening.

In the United States, a National Security Letter can accomplish this. Anyone who receives one isn’t allowed to say anything about it or challenge it in an open court hearing. The Electronic Frontier Foundation has called the power to issue them “one of the most frightening and invasive” surveillance power created by the PATRIOT Act.

Cloudflare has received at least two NSLs and possibly more. The FBI could have compelled it to turn over customers’ private keys and not tell them. In a similar case, the FBI tried to compel Lavabit, a confidential email service, to turn over keys that would give it access to every user’s private mail, even though it was just after Edward Snowden. Founder Ladar Levison was under a gag order not to disclose this until recently.

Other countries have similar or worse issues. The UK’s Investigatory Powers Act gives law enforcement the authority to make telecommunication companies break their encryption. They would be under a compulsion of secrecy comparable to a National Security Letter. In the truly authoritarian states, the situation is even worse, with privacy being virtually non-existent.

How many websites do governments have access to, without their knowledge, because CDNs had to give up their private keys? There’s no way to know.

The OrangeWebsite Difference

At OrangeWebsite we take your privacy seriously. We don’t share our private keys, or yours, with third-party services. Government agencies in North America or Europe can’t demand anything from us. We maintain state-of-the-art server security, performing regular security audits and keeping system software up to date. Optional two-factor authentication is available.

Nomad Capitalist has called Iceland the best host country for data privacy. The Icelandic Modern Media Initiative, passed by our Parliament in 2010, commits the country to freedom of information and expression. We allow anonymous registration, so that even torture or telepathy wouldn’t get us to disclose your identity. Contact us to learn how to set up a secure, censorship-free website.