How does OAuth 2.0 work?

Photo by FLY:D on Unsplash

OAuth 2.0 was originally developed as a way of sharing access to specific data between applications. It works by defining a series of interactions between three distinct parties, namely a client application, a resource owner, and the OAuth service provider.

  • Client application – The website or web application that wants to access the user’s data.
  • Resource owner – The user whose data the client application wants to access.
  • OAuth service provider – The website or application that controls the user’s data and access to it. They support OAuth by providing an API for interacting with both an authorization server and a resource server.

There are numerous different ways that the actual OAuth process can be implemented. These are known as OAuth “flows” or “grant types”. In this topic, we’ll focus on the “authorization code” and “implicit” grant types as these are by far the most common. Broadly speaking, both of these grant types involve the following stages:

  1. The client application requests access to a subset of the user’s data, specifying which grant type they want to use and what kind of access they want.
  2. The user is prompted to log in to the OAuth service and explicitly give their consent for the requested access.
  3. The client application receives a unique access token that proves they have permission from the user to access the requested data. Exactly how this happens varies significantly depending on the grant type.
  4. The client application uses this access token to make API calls fetching the relevant data from the resource server.

Before learning how OAuth is used for authentication, it’s important to understand the fundamentals of this basic OAuth process. If you’re completely new to OAuth, we recommend familiarizing yourself with the details of both of the grant types we’re going to cover before reading further.

What is Phishing?

Photo by Yogas Design on Unsplash

Phishing is a cyber attack that gathers sensitive information like login credentials, credit card numbers, bank account numbers, or other financial information by masquerading as a legitimate website or email. Personal information like social security numbers, phone numbers, and social media account information are also common targets for cybercriminals who perform identity theft.

Common phishing attempts clone financial institutions, emails from colleagues, auction sites, social media sites, and online payment processors. Despite being one of the oldest cyber crimes, phishing remains a large cyber threat to many organizations. This is due to its widespread use and sophisticated phishing campaigns. Phishers are increasingly gathering information about their targets to improve the effectiveness of their phishing messages.

Security awareness training is a great way to minimize phishing’s cyber security risk. Phishing emails may also contain infected attachments to install malware such as ransomware or to gain unauthorized access to sensitive data to cause a data breach.

It’s important to remember that some of the biggest data breaches come from outside of your organization. If your third-party vendors have access to sensitive data, then it’s as important to have them educate their staff about phishing risks. Third-party risk, fourth-party risk, and vendor risk related to phishing must be part of your third-party risk management framework and vendor risk management program.

What is Clickjacking?

Photo by Sigmund on Unsplash

Clickjacking is an interface-based attack in which a user is tricked into clicking on actionable content on a hidden website by clicking on some other content in a decoy website. Consider the following example:

A web user accesses a decoy website (perhaps this is a link provided by an email) and clicks on a button to win a prize. Unknowingly, they have been deceived by an attacker into pressing an alternative hidden button and this results in the payment of an account on another site. This is an example of a clickjacking attack. The technique depends upon the incorporation of an invisible, actionable web page (or multiple pages) containing a button or hidden link, say, within an iframe. The iframe is overlaid on top of the user’s anticipated decoy web page content. This attack differs from a CSRF attack in that the user is required to perform an action such as a button click whereas a CSRF attack depends upon forging an entire request without the user’s knowledge or input.

Protection against CSRF attacks is often provided by the use of a CSRF token: a session-specific, single-use number or nonce. Clickjacking attacks are not mitigated by the CSRF token as a target session is established with content loaded from an authentic website and with all requests happening on-domain. CSRF tokens are placed into requests and passed to the server as part of a normally behaved session. The difference compared to a normal user session is that the process occurs within a hidden iframe.

What is an Exploit?

An exploit is a piece of software, data, or sequence of commands that takes advantage of a vulnerability to cause unintended behavior or to gain unauthorized access to sensitive data.

Once vulnerabilities are identified, they are posted on Common Vulnerabilities and Exposures (CVE).CVE is a free vulnerability dictionary designed to improve global cyber security and resilience by creating a standardized identifier for a given vulnerability or exposure.

How Do Exploits Work?

Exploits take advantage of a security flaw in an operating system, piece of software, computer system, Internet of Things (IoT) device, or other security vulnerability. Once an exploit has been used, it becomes known to the vulnerable system or software developers, is often fixed through a patch and becomes unusable. This is why many cyber criminals and military or government agencies do not publish exploits to CVE but choose to keep them private.

When this happens, the vulnerability is known as a zero-day exploit. One famous example of a government agency (the NSA) choosing to keep a software vulnerability private is EternalBlue. EternalBlue exploited legacy versions of the Microsoft Windows operating system that used an outdated version of the Server Message Block (SMB) protocol.

Cybercriminals developed the WannaCry ransomware worm that exploited EternalBlue. It spread to an estimated 200,000+ computers across 150 countries, with damages ranging from hundreds of millions to billions of dollars before EternalBlue was patched. Despite software developers issuing a patch to fix EternalBlue, this known vulnerability continues to be a considerable cybersecurity risk because of poor user adoption of the patch.

XML External Entities (XXE)

Photo by Mohammad Rahmani on Unsplash

Extensible Markup Language (XML) describes data, like the contents of a webpage or database file. XML formatting allows applications to understand information and share data consistently. In order to read this data, you need to have an XML processor. Also referred to as an XML parser, these automated tools read files, transform the content, update databases, and deliver that content so the program can access it.

However, when web applications use an XML format to transmit data between the browser and server, they often use APIs to process the data. Within the XML standard, storage units are called “entities.” External entity refers to a storage unit that can access local or remote content.

An XXE vulnerability can arise from failure to:

  • Know the source before accepting or uploading XML data
  • Disable document type definitions (DTDs)
  • Use less complex data formats like JSON
  • Patch XML processors or underlying operating system
  • Detect XXE in source code

HTTP Status Codes For Burp Suite Testing

Photo by Vlad Rosh on Unsplash

I’ll preface the testing first by mentioning that it’s important to have familiarity with the HTTP status codes to help us better understand how the server is handling our attack packets. Below is a subset of HTTP status codes from OWASP that can be used as a point of reference:

Status codeMessageDescription
200OKResponse to a successful REST API action. The HTTP method can be GET, POST, PUT, PATCH or DELETE.
201CreatedThe request has been fulfilled and resource created. A URL for the created resource is returned in the Location header.
202AcceptedThe request has been accepted for processing, but processing is not yet complete.
400Bad RequestThe request is malformed, such as message body format error.
401UnauthorizedWrong or no authentication ID/password provided.
403ForbiddenUsed when the authentication succeeded, but the authenticated user doesn’t have permission to the request resource.
404Not FoundWhen a non-existent resource is requested.
406UnacceptableThe client presented a content type in the Accept header which is not supported by the server API.
405Method Not AllowedThe error for an unexpected HTTP method. For example, the REST API is expecting HTTP GET, but HTTP PUT is used.
413Payload too largeUses to signal that the request size exceeded the given limit e.g. regarding file uploads.
415Unsupported Media TypeThe requested content type is not supported by the REST service.
429Too Many RequestsUsed when there may be DOS attack detected or the request is rejected due to rate limiting
500Internal Server ErrorAn unexpected condition prevented the server from fulfilling the request. Be aware that the response should not reveal internal information that helps an attacker, e.g. detailed error messages or stack traces.
501Not ImplementedThe REST service does not implement the requested operation yet.
503Service UnavailableThe REST service is temporarily unable to process the request. Used to inform the client it should retry later.

Cross-Site Request Forgery (CSRF) Attacks

Photo by Markus Spiske on Unsplash

What is CSRF

Cross-site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.

A successful CSRF attack can be devastating for both the business and the user. It can result in damaged client relationships, unauthorized fund transfers changed passwords and data theft—including stolen session cookies.

CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.

CSRF Attack Example

Before executing an assault, a perpetrator typically studies an application in order to make a forged request appear as legitimate as possible.

For example, a typical GET request for a $100 bank transfer might look like:

A bad actor can embed the request into an innocent-looking hyperlink:

Next, he can distribute the hyperlink via email to a large number of bank customers. Those who click on the link while logged into their bank account will unintentionally initiate the $100 transfer.

Note that if the bank’s website is only using POST requests, it’s impossible to frame malicious requests using a <a> href tag. However, the attack could be delivered in a <form> tag with the automatic execution of the embedded JavaScript.

How to Check Your HTTP Security Headers

Photo by Kelly Sikkema on Unsplash

Below are three quick and easy ways to check your HTTP security headers, as part of your HTTP response headers.

1. KeyCDN’s HTTP Header Checker Tool

KeyCDN has an online HTTP Header Checker tool that you can easily use to retrieve which HTTP security headers are currently running on your website. Simply input the URL you want to check.

It will then return with your HTTP response headers.

2. Chrome DevTools – Response Headers

Another quick and easy way to access your HTTP security headers, as part of your response headers, is to fire up Chrome DevTools. To run this click into the “Network” panel press Ctrl + R (Cmd + R) to refresh the page. Click into your domain’s request and you will see a section for your response headers.

3. Scan Your Website With securityheaders.io

A third way to check your HTTP security headers is to scan your website on securityheaders.io. This is a handy little tool that was developed by Scott Helme, an information security consultant. It gives your website a score, based on present HTTP security headers, from an A+ grade down to an F grade. Make sure to bookmark it. Here is an example of an A+ grade on his own website.

Here is an example of an F grade without any of the HTTP security headers present on Citi’s corporate website.

It spits out both your raw HTTP headers and gives you a nice summary of each HTTP security header and what is missing.

Scott also created both a Chrome extension and Firefox extension in which you can scan the HTTP security headers of a website you want to analyze. He did an analysis in February 2016 of the Alexa top 1 million sites to see what their HTTP security header usage was and the results might surprise you. The number of sites using the strict-transport-security header nearly doubled. So it appears more people are starting to implement them, especially now that many companies are making the transition to HTTPS. We recommend during an HTTPS migration to do a full evaluation of your current security policies.

Content Security Policy (CSP) especially can be a powerful mechanism to prevent Cross-Site Scripting (XSS) attacks which accounts for 84% of all security vulnerabilities in web sites. However, as you can see above less than 5% of websites are actively using the headers. This needs to change.

Summary

As you can see HTTP security headers can help harden the security of your website and in most scenarios, there is no reason not to use them. If you don’t control access to your own web servers we recommend reaching out to your web host and let them know. Maybe send them a link from securityheaders.io, an F grade is never a good thing!

Operating System (OS) command injection

Photo by Gabriel Heinzer on Unsplash

Some web applications make calls to operating systems so that they can communicate with the operating system or hardware. OS calls include functions like:

  • Process control: monitoring what an application is doing and providing for termination
  • File management: giving the application access to interact with files
  • Device management: requesting or managing hardware like processing power
  • Information maintenance: managing or maintaining information as part of keeping data updated
  • Inter-process communication: coordinating processes for effective operation

Insecure OS command calls allow users to supply invalidated inputs. In other words, the malicious actors can take the OS command call, add an additional query notation, and gain valuable information about how to exploit the application.

What is SSRF?

Photo by Denny Bú on Unsplash

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.